Fitbitの睡眠データを自動でスプレッドシートに記録

前回、FitbitのAPIで取得した活動データを、GAS(Google Apps Script)を用いてスプレッドシートに自動で書き込みました。今回は睡眠データの記録です。

GASのコード

スプレッドシートの用意までは、前々回の体重データの書き込みと同じです。

スプレッドシートのシート名は「睡眠」としておきます。

FitbitのAPIは、呼び出すデータや返ってくるデータの違いによって、プログラム調整が必要です。

睡眠データを記録するためのGASコードは下記です。

GASのトリガー設定で、getSleep()をタイマーで毎日実行することで、自動的に記録されます。

Fitbitアプリで睡眠データを同期した後でなければ、記録ができないので注意が必要です。

記録されたスプレッドシート

日付、睡眠時間、目覚めた状態の時間, レム睡眠の時間、浅い眠りの時間、 深い眠りの時間が記録されました。

ただ、睡眠時間を分で見ると分かりにくいです。

データを「時:分」で表示

「時:分」の形式に変換します。

GASから「時:分」形式でスプレッドシートにデータを書き込むように、getSleep()を調整します。

0:${分}でデータを送るように改修しています。

スプレッドシート側の自動変換が賢く、例えば100分は「0:100」という入力で「1:40」に変換されます。

また、睡眠時間は、レム睡眠+浅い眠り+深い眠りの時間が正確なため、修正しています。

睡眠記録は効果的?

今回は検証も兼ね、今年初めて8時間以上寝ました。

8時間寝ると、やはり仕事の作業効率も上がるような気がします。

睡眠データを記録すると、睡眠を客観的に観察できるメリットを感じます。

Fitbitデフォルトの睡眠目標は8時間ですが、毎日継続はちょっと厳しいかもしれません。

7時間くらいをできれば継続して、体調への変化を確認します。

Fitbitの活動データを自動でスプレッドシートに記録

FitbitのAPIで取得したデータを、GAS(Google Apps Script)を用いてスプレッドシートに自動で書き込みます。今回は歩数や消費カロリーなどの活動データの記録です。

GASのコード

スプレッドシートの用意までは、前回の体重データの書き込みと同じです。

スプレッドシートのシート名は「運動」としておきます。

GASのコードは下記を使います。(前回より汎用的にコードを修正しました)

getActivities()をタイマーで実行することで、自動的に記録が始まります。

活動データの記録タイミングは?

1日の活動データの記録が終わるのはデフォルトで深夜0時です。

そのため翌日に記録することになります。

注意しないといけないのは、Fitbitアプリとの同期です。

Fitbitアプリに活動データが同期されていないと、APIから最新データを取得できません。

私の場合は、朝起きてから睡眠時間の確認でFitbitアプリを立ち上げるため、朝一で前日までの活動データが同期されます。

午前中の遅めにGASのタイマーを設定しておけば、正常に活動データを書き込むことができます。

スプレッドシートの記録確認

タイマーでGASが正常に作動していれば、自動でスプレッドシートに書き込まれていきます。

日付、歩数、距離、消費カロリー、アクティブな時間が記録されています。

並べてデータを見ることで、新たな気づきがありました。

11,253歩、歩いた日より、7,016歩で縄跳びを途中やった日の方が、消費カロリーが高いです。

歩数や時間では分からない運動の質も、消費カロリーで把握できるようです。

 

以上、スプレッドシートに自動で活動データを記録する方法でした。

日々記録することで、運動の習慣化にもつながると思います。

Fitbitのスプレッドシート記録をGASで自動化

FitbitのAPIで取得したデータを、GAS(Google Apps Script)を用いてスプレッドシートに書き込みます。毎日タイマーを使って、記録を自動的に行えます。

FitbitのAPIを利用できるように

まずはFitbitのデータを持ってこれるように、APIを利用可能な状態にします。

FitbitのAPIを手っ取り早く試してみる方法」が参考になります。

スプレッドシートとGAS

FitbitのAPIを使えるようになったら、新規のスプレッドシートを作ります。

メニューの「ツール」から「スクリプト エディタ」を選択。

GASのエディタが現れたら、下記のコードを記述します。これは体重を取得してスプレッドシートに書き込むサンプルです。

[token]と[user-id]は自分のID(英数字の羅列)を入れます。

これを実行して、スプレッドシートに体重データが書き込まれれば成功です。

グラフを作っておくと、より変化が分かりやすくなるでしょう。

1日1回タイマーで記録

体重の場合は、1日1回測れば十分です。記録も1日1回タイマーで行います。

スクリプト エディタの左メニューから「トリガー」を選択。

右下の「トリガー追加」を選び、セレクトボックスを下記のように設定します。

  • 実行する関数を選択・・・getFitbitAPI
  • イベントのソースを選択・・・時間主導型
  • 時間ベースのトリガーのタイプを選択・・・日付ベースのタイマー
  • 時刻を選択・・・(好きな時間帯)

体重のように時間帯で変わってしまうものは、午後12時~1時をトリガーにして、午前のデータのみ記録するのも良いでしょう。体重推移が正確に分かります。

Fitbit APIでスプレッドシートに体重を記録(Node.js利用)

Withingsの体重計のデータを、FitbitのAPIから取得することができました。今回は、取得した体重データをスプレッドシートに記録します。

デバイスと環境

体重計・・・Withings「Body +」
活動量計・・・Fitbit「Alta HR」

Windows10
Node.js 14.15.4

スプレッドシートをサーバー化

まずは記録用のスプレッドシートを簡易サーバーとして設定ます。

Google Spreadsheet を簡易 Webサーバーとして動かして、手軽にWebHookを受け取る方法」を参考にしながら、下記のコードを用意しました。

デプロイ時にWebアプリケーションURLが発行されます。

Node.jsでFitbitのAPIを取得

Fitbitの体重データAPIの取得は、Node.jsを利用しました。

Fitbitのトークンと、先ほどスプレッドシートで発行したWebアプリケーションURLを使って、下記のJavaScriptを用意します。

これをapp.jsなどの名前で保存して、コマンドプロントで「node app.js」を実行すれば、スプレッドシートに体重・体脂肪などが記入されていきます。

体重データ取得の注意

Fitbitの体重取得APIで、不思議な結果が返ってくることがあります。

なぜか今日23時59分59秒の体重が返ってきます。まだ朝です。

取得しているデータをNode.jsのログで見てみます。

23時59分59秒に、fat(体脂肪率)がないデータが存在します。fatが記録できないのも問題なので、このデータは除外しましょう。前述のコードでは、fatがない時に1つ前のデータを取得するようにしています。

なぜこのデータが存在するのかは分かっていません。

スプレッドシートの確認

問題なく動作していれば、スプレッドシートに今日の体重が追記されます。

今回作ったNode.jsアプリを1日1回、体重を測った後に実行させると、体重推移を確認できます。

日付と体重の列を指定してグラフを作成すれば、データと連動してグラフも更新されていきます。

Withingsで測った体重をFitbit API経由で取得

WithingsのAPIが一時的に使えません。代案として、WithingsとFitbitを同期させ、FitbitのAPIから体重を取得することにしました。

デバイス

体重計・・・Withings「Body +」
活動量計・・・Fitbit「Alta HR」

※クラウドにデータを保存できれば、別のデバイスでも問題ないと思います。

WithingsのデータをFitbitに同期させる

下記URLで設定すれば、WithingsのデータをFitbitに同期させられます。

https://www.fitbit.com/weight/withings

もし、Withings、Fitbitのアカウントがない場合は作る必要があります。

体重データがFitbitのアプリでも確認できるようになったら、同期はうまくいっています。

FitbitのAPIを利用可能にする

Fitbitで体重データを見られるようになったら、FitbitのAPIを使えるように設定します。

FitbitのAPIを手っ取り早く試してみる方法」で、分かりやすく解説されています。

APIの取得が可能になったら、Fitbit公式ドキュメントの「Body & Weight」で体重を取得する書き方を確認します。

過去30日間の体重データを取得する

コマンドプロント(ターミナル)で下記のコマンドを実行してみます。※[token]、[user-id]、[yyyy-mm-dd]は書き換えてください。

すると最大30日分(存在していれば)の体重データを取得できます。

今朝は測った体重(”weight”:72.8)が、JSONで返ってきました。

Withingsアプリのオリジナルデータと、APIで取得したデータを比べると、正しく取得できていることを確認できます。

体重以外にも、体脂肪やBMI、計測時刻も取得できていました。

動作確認としてはOKです。

次回、スプレッドシートへの記録を行います。

サーバーダウン中?WithingsのAPI

体重管理を始めようと思い、Withingsの「Body+」というネットに接続可能な体重計を使うことにしました。しかし現在、WithingsのAPIが使えない状態のようです。

※追記 2021年2月13日復旧していることを確認しました。

サーバーエラー

WithingsのData APIの使い方を見ると、まずWithings APIに登録が必要とのことです。

しかし、掲載されているリンク先へ移動すると、「Service Unavailable」と表示されてしまいます。

サーバーにエラーが起こっているようで、数分後にもう一度試すよう、促されます。

数分後に試したものの、表示は変わらず、結局翌日確認してもサーバーエラーは改善されていませんでした。

IFTTTでも連携不可

IFTTTを使うと連携できるかも試しましたが、やはりIFTTTとWithingsの接続でエラーがでます。

他、調べてみると、WithingsとFitbitの接続はうまくいくことに気づきました。

こうなったら 一度Fitbitに体重データを同期して、FitbitのAPIを利用することにします。

ガスト注文タブレットのUIが優れている

妻が初めて見るガストのタブレット端末で、スムーズに注文をしていました。画面設計を見ると、UIデザインが非常に作り込まれています。これは使いやすいです。

基本的に色を多用しない

ガストに注文用タブレットが導入されていました。画面を見ると、配色がとても落ち着いています。

この配色はマクドナルドのWebやアプリでも見られました

どうしても飲食店だと、食欲を増進させるような鮮やかな配色を使いたくなるかもしれません。特にガストなら、ロゴカラーの赤を使いたくもなるでしょう。

しかし、ガストのタブレットUIには、ほぼ無彩色が用いられています。

下手な色の組み合わせで可読性を落とすこともなく、文字と背景のコントラスト比が一定なので、読んだり操作したりするのが楽になります。

そして何より、画面全体に無彩色を使うことで、重要な情報を引き立てることができます。

注文がAmazonに見えるのが良い

重要なボタンには色が付いています。注文確定へすすむボタンが、黄色ボタンでショッピングカートのアイコン付き。

もはやAmazonです。

ガストにショッピングカートはないだろ!という現実は重要でなく、アプリやWeb利用者の慣例が重要になります。

注文ならショッピングカート。

認知できるかどうかは、見慣れているかと関係し、利用者が多いAmazonの注文ボタンに近づけるのは、UIデザインのセオリーです。

ユーザーが知っているボタンなら、理解するストレスが少なくて済みます。

待機中に出る広告が良い

UIデザインはシンプルですが、タブレット待機中に表示される広告は、鮮やかでおいしく見えるようにデザインされています。

使うデザインと目にとめるデザインは根本的に違い、ガストのタブレットは、待機中と操作中でデザインを使い分けています。

機械音痴でも完遂できる!

見れば見るほど、ガストのタブレットUIの作り込みに驚かされます。

機械音痴の妻が、タブレットでスムーズに注文を進めていきます。

すき家の注文画面では操作を断念した妻が、初見で注文を完遂しました。

間違いなくガストのタブレットのUIは優れています。

ページングナビゲーションの「前へ」「次へ」は未来・過去どっち?

Web制作でページの下部に、「< 前へ」「次へ >」といった、ページングナビゲーションを設置することがあります。多くの場合、古いページが「次」となります。

古いのに次?新しいのに前?

日常生活の感覚では、古い情報を「次」と言い、新しい情報を「前」と言うのは違和感があります。

しかし、Webサイトで時系列で並ぶコンテンツは、多くの場合、日付が降順に並んでいます。

代表的なものがブログで、新しい記事から古い記事の順番で並んでいます。「次へ」で進んでいくと、時間がさかのぼっていきます。

Web制作の現場でも意見が分かれていた

ページングナビゲーションについて、参考情報を探ります。

WebNAUT

ブログページの「前へ」「次へ」はどっちが新しい?あいまいワーディングの罠

ページングナビゲーションの文言や配置は、Web制作メンバーにアンケートを取っても、想像以上に意見が分かれることに驚きました。確かにワーディングは重要です。

時間に密接なコンテンツか?

User Experience(Stack Exchange)

Which direction indicates newer/older?

海外でもナビゲーションの新しい、古い問題が議論されています。

慣例では、「次」は「古い」と同等という回答が見られます。

また、そのサイトが時間に密接なコンテンツかどうかが判断基準になるという意見もあります。

時間に密接なコンテンツはなかなか思い当たりませんが、例えば天気サイトでしょうか。

天気サイトにおいて「次」は、1時間後や明日といった未来の意味になることが適切でしょう。

ブログの場合は、ユーザーにとって時間と密接なコンテンツとは言えない場合がほとんどで、慣例として「次」は過去の意味で良いと考えます。

「前のページ」と「次のページ」の方が適切

WebNAUTやUser Experienceの意見を参考にして考えると、ナビゲーションは例外(時間密接サイト)を除き、「前のページ」「次のページ」と記述するのが適切だと思います。

ほぼ無意識レベルの話ですが、「次へ」だけだと、人によっては時系列を意識することがあります。「ページ」を付けることで本をめくるような意識になり、時間が意識から離れます。

時間の意識を切り離すことができれば、「次」が古くても違和感はありません。

ちなみに、大手アメーバブログのナビゲーションが「前ページ」「次ページ」となっています。

日本語表現としては「前ページ」より「前のページ」の方が厳格かもしれませんが、1文字でも少ない方が認識にかかる時間が減ります。

日本語に厳しくないサイトでは「前ページ」「次ページ」で良いでしょう。

記事タイトルを入れた方がもっと適切

実装工数やCMSの有無にもよりますが、もし可能なら「次のページ」「前のページ」ではなく、次のページのタイトルと、前のページのタイトルを、ナビゲーションに入れたほうが良いでしょう。

次も前も、ユーザーにとって何か分からないため、具体的な情報の方が判断できます。

関連情報リンクの方が適切なことも

時系列があまり重要でないコンテンツがほとんどなので、次や前よりも、関連情報のリンクが並んでいた方が使いやすいとも考えられます。

定期的に新着情報を見に来るユーザーもいるため、ページングナビゲーションを完全に削除するのは得策とは言えませんが、見せ方としては、関連情報(リコメンド)よりページングの優先順位を下げて良いと思います。

もちろん実装工数と費用対効果も考える必要はありますが、ユーザーにとってページングがそこまで重要ではない可能性も考慮できればと思います。

Fitbit Alta HRバンドは消耗品?

歩数や睡眠の記録のため「Fitbit Alta HR」を手に付けっぱなしで生活しています。5か月前買った交換バンドが早速切れました。このバンドは消耗品と考えたほうがよさそうです。

ランニングコスト100円/月

Amazonで500円の「Fitbit Alta HR交換バンド」を再購入しました。写真左は5か月使ったもの。右は同じ商品の新品です。

ベルトの穴の横に亀裂が入り、Fitbitを落としてしまう前に交換します。

500円で5か月もったので、ランニングコストは100円/月となります。

Fitbitは運動や睡眠の記録を有効に使えているので、ランニングコスト100円なら高く感じません。純正品のベルトも切れるし、また同じベルトを再購入しました。

ベルトは消耗品です。

Fitbitの新商品買い替えは保留

Alta HRの後継機(?)に、Inspire HR、Inspire 2があります。ベルトが切れたタイミングで、買い替えも考えましたが保留します。

Alta HRで十分満足しており、今のところ買い替えるほどの魅力的な追加機能がありません。

バッテリーについても、Alta HRはたまに充電するくらいの感覚で、良くもちます。仕様上は7日もつようです。

もうすぐ2年になりますが、バッテリーの劣化も気になりません。

しばらくベルト交換での運用となりそうです。

サーモグラフィーとカメラ映像を重ねる

前回、サーモグラフィー「AMG8833」とWebカメラ「OV5640」モジュールを合体させ、サーマルカメラを作りました。今回は検温に使ったコードを記載します。サーモグラフィーとカメラ映像を重ねています。

先に動作サンプル

カメラに顔を合わせると、体温が表示されます。

距離によって温度が変わるため、近づきすぎると「はなれて!」と警告がでます。

開発環境

ハード

Raspberry Pi 3 model B+
スイッチサイエンス「AMG8833」モジュール
Webカメラ「OV5640」モジュール

ソフト

OS:raspbian 10.7
Python 3.7.3
Node.js 10.21.0
Chromium 86

検温のコード

サーマルカメラで取得した温度をHTMLに読み込むまではこちらを参照

ブラウザに表示するHTML(CSS、JavaScript)だけが、下記に変わっています。

サーモグラフィーの画像とカメラ映像をmix-blend-mode: screen;で重ねて、分かりやすく表示しています。

検温していると±1℃くらいブレるので、キャリブレーションがまだ必要です。

体温で±1℃は、でかすぎます。

カメラに近づくほど温度の精度が高まるので、至近距離で検温するように調整し直した方がよさそうです。

カメラ映像があればJavaScriptでも顔認識はできるので、距離もある程度推定できます。

もう少し調整しましょう。