👶

泣く前に対応！ぴよログデータを活用した育児支援ダッシュボードとLINE通知

2024/03/07に公開

GCP

概要

赤ちゃん対応に必要な情報を親が簡単に収集できるようにするため、
赤ちゃんの情報を可視化した育児サポートダッシュボードを作成しました。
また、ダッシュボードの機能を用いて、おむつ交換の時間を知らせるLINE通知も実装しました。

成果物

リビングでの運用状況
現在のダッシュボード構成
LINE通知画像

システム構成

ぴよログに貯めたデータをGoogle Cloud FunctionsでPlanetscaleに入れ、Grafanaで視覚化し、
家族が常に確認できるようリビングにおいたタブレットに表示しています。
また、おむつ交換が必要なタイミングには
Grafanaのアラート機能を使用してLINE経由で親のスマホに通知を行います。

PlanetScale,Grafanaどちらも無料プランで収まっています。
Google Cloudについては無料トライアル期間中ですが、
終了後も1ヶ月100円以内には収まりそうなリソース利用料なので
継続利用してもいいかな〜って思っています。

きっかけ

赤ちゃんは自分の欲求を言葉で伝えることがまだできません。
そのため、親は赤ちゃんの行動や泣き声から何が必要か、どのようなケアが求められているかを推測しなければなりません。
しかし、推測に必要な情報を赤ちゃんが泣くたびに都度整理し、
適切な行動を決定するのは非常に大変な作業です。
さらに言えば、親としては問題が発生する前に、できるだけ早く対処したいと考えたいですよね。

この課題に対処するために、
赤ちゃんのケアに必要な情報を一箇所に集め、簡単にアクセスでき、常時表示可能な形式で提供することが、
親の判断をサポートし、問題に先回りして対応するための鍵となると考えました。
そこで、日々の育児ログをリアルタイムで可視化し、
赤ちゃんが泣き始める前に適切な対応ができるようにするダッシュボードを作ろうと考えました。

導入効果

導入後、妻からは「別のことしながらでも情報が目に入ってきて助かるね」といってもらえました。
私自身、データを可視化システム構築ができたエンジニア的な自己満足感だけでなく、
実際に日々の育児がスムーズになったことを実感しています。
授乳やミルクを泣く前に先回りして準備できたり、
おむつ漏らしの回数が激減しました。(特に時間を忘れがちな外出先)

実装項目

次の授乳時刻: 泣く前に授乳やミルクを準備できるようにします。
次のおむつ交換時刻: おむつ漏れを防ぎます
本日のうんち状況: 便秘気味のため、1日うんちしてなければマッサージしてます
寝室の気温:昼寝や夜間の睡眠時に適温が保てているか確認します
一日の摂取ミルク量: 母乳とミルクの混合育児を行う我が家では、月齢に応じたミルク摂取量上限を超えないようにしていました

その後、分析観点でその時確認したいデータ、グラフを入れ替えてたり、
明日の回収ゴミに付いての情報を追加したりと、
我が家にカスタムされたダッシュボードとして成長してきています。

システムフロー

1. ぴよログに赤ちゃんのログを貯める

https://www.piyolog.com/
ぴよログというアプリを使って赤ちゃんの行動データを集めます。
このアプリはどの端末からでもアクセスできるため、赤ちゃんの食事、睡眠、おむつの交換といった情報を家族全員で共有できます。

2. 貯まったぴよログデータをエクスポート & Google Driveにアップロード

ぴよログのデータ出力は、API提供されていないため、Android端末を用いてデータを定期的にエクスポートし、Google Driveにアップロードしています。
5分ごとに最新のデータがDriveに保存されるようになりました。
引き出しで眠っていたPixel4aを専用端末としてセットアップし、
Android端末で実行する自動化アプリmacrodroidを入れました。

このアプリを用いて、定期的にぴよログデータをGoogle Driveへアップロードしています。

3. Google Cloud FunctionsでデータをPlanetScaleに保存

Google Cloud Schedulerで定期的にGoogle Cloud Functionsを実行しています。
GooGle Driveにアップロードされたデータを取得し、
PlanetScaleに作成したデータベースに保存します。

PlanetScaleについて

https://planetscale.com/

PlanetScaleはMysql互換DBaaSです。
無料プランだと、以下の制約を受けます。

データベースは1つ、5GBまで
月間制約読み取り10億行書き込み1千万行

今回のような個人利用での要件としては全く問題なさそうなので採用しました。

以下、1ヶ月のうち、1週間が経過した頃の利用状況です。

Row reads,writesについてやっぱり全然余裕ですね。

モダンなGUIを提供してくれており、
ブラウザ上で、コンソール接続やスロークエリ含むパフォーマンス分析など実施できます。
またRDBMSが必要な場面では使いたいなあと思った、非常に便利なDBaaSでした。

データソースについて

データソースはGoogleDriveのぴよログデータ、switchbotAPI,市役所HPです。
ぴよログデータはアップロードした情報ですが、それ以外にもSwitchBot ハブ2のデータをswitchbotAPIから、地域のゴミ出しカレンダー情報を市役所HPから取得しています。
Cloud Schedulerで定期的にcloud functionsを実行しており、
ぴよログデータ、switchbotは5分に1回、市役所HPからのデータ取得は月1で
それぞれ準備したCloud Functionsを定期実行しています。

テーブル構成

CREATE TABLE ACTIVITY (
    record_id int NOT NULL AUTO_INCREMENT,
    date date NOT NULL,
    time time NOT NULL,
    activity_type varchar(255) NOT NULL,
    duration int DEFAULT NULL,
    side varchar(10) DEFAULT NULL,
    quantity int DEFAULT NULL,
    note text,
    ins_ymd datetime DEFAULT NULL,
    PRIMARY KEY(record_id),
    UNIQUE KEY date(date, time, activity_type)
)

CREATE TABLE SWITCHBOT(
    record_id int NOT NULL AUTO_INCREMENT,
    deviceId varchar(255) DEFAULT NULL,
    deviceType varchar(255) DEFAULT NULL,
    hubDeviceId varchar(255) DEFAULT NULL,
    humidity decimal(5, 2) DEFAULT NULL,
    temperature decimal(5, 2) DEFAULT NULL,
    lightLevel int DEFAULT NULL,
    version varchar(255) DEFAULT NULL,
    ins_ymd datetime DEFAULT NULL,
    PRIMARY KEY(record_id)
)

CREATE TABLE GOMI(
    record_id int NOT NULL AUTO_INCREMENT,
    date date NOT NULL,
    items varchar(255) NOT NULL,
    created timestamp NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY(record_id)
)

4. Grafanaでダッシュボードを作成

Grafanaでダッシュボードを作成しています。
PlanetScaleをデータソースとし、閲覧したい情報をパネル化していきます。
SQLの結果に応じて画像の出し分けを行うプラグインも利用しています。
Dynamic image panel

利用する画像はみんな大好きいらすとやの画像をパターンに応じて選び、Google Drive上に保存して、共有URLを設定することでホスティングし、Grafanaから参照しています。

5. タブレットでモニタリング

Grafanaのダッシュボードをブラウザで開き、1分ごとにリロードしています。
家に余ってるモニターがないため、
転がっていたKindle Fire HD8タブレットを利用しています。
開発者モードでディスプレイ常時オンにして置いてあります。
Fire HD8はコンパクトでインテリアに溶け込む反面、
画面自体が小さく、silkブラウザの仕様で全画面表示ができなかったりするため、
表示可能域が限られてしまっています。
理想はやっぱりどデカモニターでの運用ですねえ

6. Grafanaのアラートシステムを用いてLINEに通知

アラート通知の際に利用しているNotification Templatesは以下です。
おむつ交換状況に応じてLINE通知の内容をカスタマイズしています。
我が家では、前回のおむつ交換から3時間半以上経つとおむつ漏れの危険性があがっていました。
そのため、3時間半で交換要請通知、交換後には解決通知を送るようにしています。

{{ define "omutu_panpan.title" }}
  {{ if eq .Status "firing" }}🔥 おむつがパンパン
  {{ else if eq .Status "resolved" }}✅ 交換済み
  {{ end }}
  {{ if eq .Status "firing" }}おむつ交換から{{ .CommonAnnotations.valueA }}分経過中！！！😱 
  {{ else if eq .Status "resolved" }}すっきりしました😘 
  {{ end }}
  https://<dashboard URL>
{{ end }}

アラート検知には、おむつ交換からの経過時間の計算SQLを利用し、
経過時間をカスタムアノテーションとして設定して、Notification Templatesで取り込むことで、
LINE通知を見ると交換後何分経過しているのか分かるようになっています。

SELECT
  FLOOR((UNIX_TIMESTAMP() - (UNIX_TIMESTAMP(CONCAT(date, ' ', time)) )) / 60) AS total_minutes
FROM
  `piyolog-analytics`.activity
WHERE
  activity_type IN ('おしっこ', 'うんち')
ORDER BY
  UNIX_TIMESTAMP(CONCAT(date, ' ', time)) DESC
LIMIT 1;

まとめ

育休中のリハビリ的にも非常に楽しかったですし、実際役に立つものが作れてよかったです。
もし同じように育児に奮闘中のエンジニアの方々にとって、
この記事の情報が何かしら役に立てば良いなと思います。

参考

当初思い立ってから調べると、n番煎じなことに気づき、大いに参考にさせていただきました。
本当にありがとうございます。

概要

成果物