跳到主要內容

[筆記]Fitbit API - HR Time Series

由於之前使用FITBIT api不同 type 要資料時，回傳json檔案格式不盡相同，也並非所有api所提供的URL都能取得資料，因此決定專門整理一篇，將app type設為client與personal 進行回傳資料格式實測並記錄結果

當app type為client時：


一般的Time Series：


Resource URL：

當 URL 為 https://api.fitbit.com/1/user/[user-id]/activities/heart/date/[date]/[period].json
  1. 回傳資料：取得僅daily總結資料，包含restingHeartRate(型態同API)
  1. period：1d、7d、30d、1w、1m，回傳資料是period前所設定的 [ date ] 往回推 [ period ] time，30d與1m差別於，取 [ date ] 往前推算的整整30天，或是 [ date ] 往前推的一個月
當 URL 為 https://api.fitbit.com/1/user/[user-id]/activities/heart/date/[base-date]/[end-date].json
  1. 日期可以跨月份任意指定

Intraday Time Series


Resource URL：

當 URL 為
1.     GET https://api.fitbit.com/1/user/-/activities/heart/date/[date]/[end-date]/[detail-level].json
2.     GET https://api.fitbit.com/1/user/-/activities/heart/date/[date]/[end-date]/[detail-level]/time/[start-time]/[end-time].json
3.     GET https://api.fitbit.com/1/user/-/activities/heart/date/[date]/1d/[detail-level].json
4.     GET https://api.fitbit.com/1/user/-/activities/heart/date/[date]/1d/[detail-level]/time/[start-time]/[end-time].json
以上URL僅回傳錯誤訊息403

 

當app type為personal時：


一般的Time Series：


Resource URL：

當 URL 為   https://api.fitbit.com/1/user/[user-id]/activities/heart/date/[date]/[period].json
  1. 回傳資料：
    1. period = 1d，以一分鐘為單位，回傳當日「細度」心率。
    2. 其餘資料回傳格式同 app type為 client 回傳資料
當 URL 為 https://api.fitbit.com/1/user/[user-id]/activities/heart/date/[base-date]/[end-date].json
  1. 日期可以跨月份任意指定，回傳資料格式同 app type為 client 回傳資料


Intraday Time Series：


Resource URL：
  • 當 URL 為   https://api.fitbit.com/1/user/-/activities/heart/date/[date]/[end-date]/[detail-level].json
 實測結果：回傳一般心率值，不包含細度資料

  • 當 URL 為   https://api.fitbit.com/1/user/-/activities/heart/date/[date]/[end-date]/[detail- 
 level]/time/[start-time]/[end-time].json
實測結果：error 400

  • 當 URL 為    https://api.fitbit.com/1/user/-/activities/heart/date/[date]/1d/[detail-level].json
實測結果：回傳一般心率資料以及當日00:00至23:59細度刻度資料，刻度以 [ detail-level ] 為單位
  • 當 URL 為    https://api.fitbit.com/1/user/-/activities/heart/date/[date]/1d/[detail-level]/time/[start- time]/[end-time].json
實測結果：回傳一般心率資料以及當日指定時間內細度刻度資料，刻度以 [ detail-level ] 為單位


    標籤：

    留言

    張貼留言

    這個網誌中的熱門文章

    1042東南大學交換心得

            位於南京的東南大學，創校於 1902 年，除了擁有長達百年的校史，更為中國大陸一線大學，其理工科相關院系可以說是在江蘇省，甚至整個南方擁有獨霸一方擁名氣與實力，更有 985 工程、 211 工程以及全中國大陸 34 所可以獨立招生的大學等殊榮。很榮幸在 1042 申請前往該校的信息工程學系，進行為期一學期的交換，體驗與參與，中國大陸最頂尖的學生的校園生活與文化。 一、關於東大競賽         關於東南大學的校園生活中，多樣化且專業化的校園較賽最令我印象深刻。在東大這樣的頂尖學校中，學生的競爭並不局限於課堂上的考試分數與成績排名。從才藝競賽到學術競賽，各式各樣的校園競賽，大約每隔兩周就會有一項在校園的某一隅熱烈上演。例如東南達人秀、「十佳歌手」、東大「沙場點兵」、東大具代表性的「樓道」歌唱大賽等才藝鬥智比賽，或是「結構創新競賽」、「數學建模競賽」、「嵌入式電路系統設計」、「智慧生活設計」、多種程式競賽、各項性質的文案設計比賽等等，東大學子透過各項學科競賽，將理論與應用相結合。同時，由於東大的理工學系劃分仔細，基於術業有專攻的道理，為了競賽擁有好成績，促進學生們積極向外尋找不同科系學生們互組成團隊參賽，過程中培養了學生對於不同專業的尊重，以及互助合作對於團隊的重要性。         在東大生活中，由於一些系統問題，我無法報名參加校內所舉辦的各項競賽，但是很幸運我遇到一群很好的同學，讓我以觀摩的身分，跟著他們的組別一同準備。我所觀摩的競賽是「結構創新競賽」與「數學建模競賽」。結構競賽根據主辦方所提供的材料種類與數量，發揮創意設計建築結構圖，並加以實作出作品，最後透過分為八級的強度測試，篩選出建材最少、抗震力最佳的作品。「數學建模競賽」，在東大算是一場極為盛大的比賽，因為東大中，「數學建模」是所有理工科系的必修課，因此該比賽就成為學生們在考試前一爭高下的最好時機。今年的校內數學建模競賽題目是給定太陽軌跡照片，已知條件為拍照的時間與日期，參賽者必須用科學方法，找出並證明該太陽軌跡的照射地點。今年的挑戰難度在於參賽者處理太陽軌跡數...
    張貼留言
    閱讀完整內容

    南京初行

    南京交換一個多月了，從一開始過得很痛苦每天都想直接飛回台灣，到現在慢慢融入這裡生活，感謝主讓我始終是幸運的。 很幸運從決定交後，親戚給我各式資訊，父母給我足夠支持與鼓勵，陪我來南京辦東辦西熟悉環境兼旅遊，讓我不至於手忙腳亂，也讓我有獨自一人生活的勇氣，同時還幫我這個有點雷的女兒張羅個識時務伴手禮。 很幸運在元智友一群很carry的白癡損友，為我辦wechat想辦法幫我翻牆幫我跑單位聯絡老師退課選課想作業，然後塵埃落定後依舊時不時和我聊天打屁，在冷颼颼的南京跨海給我一點溫暖 很幸運一開始遇到一個帥哥學伴，幫我讓在這裡的日常生活步入正軌，雖然現在幾乎沒有聯絡讓我小感傷，但重要的是曾經擁有 很幸運有一群很親切的室友學姊，常常分我零食餅乾水果雞蛋，還叮嚀我要去哪玩哪邊很雷不要去玩 很幸運遇到一群友善的同學，很快地接納來自台灣的我，邀請我去春遊上課借我筆記戴我體驗校園競賽 很幸運遇到一群個性算合拍的交換小夥伴，在南京大小事上彼此互相照顧，連出去玩彼此也是不離不棄 回想起來原來有這麼多的幸運，相較之下初來到時的無助顯得那麼微不足道 然後是本文重點，講講同時炫耀一下出去玩的心得，依時間序大概去了 西湖→南京總統府→夫子廟→雞鳴寺、玄武湖→紫金山 →雨花台、老門東→明孝陵→閱江樓→朝天宮 →鎮江 金山、西津都→莫愁湖公園 大部分都是一些極具歷史文化遺產的地方，真的很典雅而且古色古香，漂亮的景色讓怎麼拍都好看，甚至有一度被鎮江美哭，當國文與歷史課本所讀到的詩詞古賦圖突然變成眼前的風景，很感動。以後看電視應該對於一些講述古裝或是穿越的故事劇情會略有心得。 在這裡有趣的是看看不同城市開發狀況。城市硬體設施建設，到對整個市容的設計規劃，都可以明顯看出這個城市是屬於正常發展或是經由政府推動發的階段性發展輪廓 同時這裡保留很多傳統文化，受西方影響程度的確比較不明顯，很有趣的一點，是這裡的人都有非常明顯的特徵可以略窺一二他們所屬的年代，每個年代之間彼此都有明顯的價值觀與審美觀落差。我想大概是因為改革開放影響，這裡的民間發展有一點跨時代的現象。在這邊極不相似的風格特色與時代文化卻可以融合在一起，看起來很突兀，卻又不突兀。 以上是我來南京以後小小心得，希望待越久可以有更多的發現與體悟，大家不要擔心，我過馬路還是會看紅綠燈，搭捷運位記得排隊，遵守先下後上原則的！
    張貼留言
    閱讀完整內容

    [筆記] 串接 知識決策模型 / 知識推論引擎 / 工作流程模型 / 工作分派引擎 ，一起手牽手心連心！ Case實例

    生字： Ontology 知識本體論：   定義特定的應用領域中，知識術語的集合。什麼種類的事情可以存在， 以及它們之間的交互關係，以達到知識共享目的。 如：包含語彙（Vocabulary），語意上的相互連結（Semantic Interconnection）， 以及在推論（Inference）和邏輯（Logic）上的簡單規則（Hendler , 2001）。 OWL：The Web Ontology Language SWRL ：Semantic Web Rule Language ，以語 義 的方式呈現規則的 一種語言 ，細節待研究 Protégé： 本體編輯和 知識取得 軟體，一種工具而已，不用想太多。 Jess Rule Engine：Java寫的一種工具，也不用想太多  ------------------------------------------------------- 知識決策人工智慧的領域演化過程： > 從20年前的數學模型、機率統計 >  語意描述建模 > 語意法則 > 推論引擎去分析推斷，產生真實的邏輯判斷結果 過去Ontology定義領域知識架構與其樹狀圖，在進步一點的利用RDF標準化結構。 今日利用OWL定義Ontology結構與親屬關係，建立實例 ( Instance ) 轉化為 Rule， Rule再利用推論引擎產生推論結果。 知識決策模型(Hypothesis) + 知識推論引擎(Procedure) + 工作流程模型(Model) + 工作分派引擎(Procedure) + 系統開發 (Implementation)  結合實例 //Ontology架構  知識決策架構 瞭解 領域環境 分析 & 歸納 領域問題 定義   領域知識 & 知識關聯架構  透過   OWL-DL語言 建立 Ontology 模型  透過   Protégé工具 ， 管理 Ontology (亦可用於建立)  定義   屬性(Property)  建立 ...
    張貼留言
    閱讀完整內容