以下の内容はhttps://handat.hatenablog.com/entry/send-switchbot-metrics-to-mackerelより取得しました。


Switchbot APIから取得した自宅の温湿度をMakerelに送信するLambda関数を作った

自宅のスマートホームには主にGoogle HomeとSwitchbotの機器で使っている。 最近、Switchbot APIが存在することを知ったので自宅の温湿度をMackerelのサービスメトリックに送信してみた。

作ったもの

github.com

主な特徴

  • SwitchbotAPIから取得したメトリクスをMackerelのサービスメトリックに送信
    • 温湿度計では取得できる温度、湿度、バッテリー残量に加えて不快指数の4種類
  • 実行環境はEventBridgeでスケジュール実行されたLambda関数
  • AWS SAMを利用してLambda関数をデプロイ
    • デプロイ時に指定する環境変数APIキーやLambda関数の実行間隔を変更可能

サンプル

我が家には各部屋+ベランダ(防水温湿度計)の3つの温湿度系があるので、取得したメトリクスをメトリクスをダッシュボードにまとめてみた。
Switchbotのアプリと違ってグラフを重ねて表示出来るので見やすい!!

余談だが、ベランダにはエアコンの室外機もあるし、直射日光に当たる時間もあるので天気予報よりも温度が高くなりがちで暑い日だと40℃を超えている日もありそうだった。

AWS SAM

AWS SAMを使ってみたのは今回が初めてだった。
sam initで選択出来る公式のHello World exampleがtypescriptに対応していたので、環境構築はCLIに沿って進めていけばすぐにできるしローカルでの実行も出来てちょっとしたLambda関数を作るには便利だった。

一つだけ、ローカル実行はsam local invokeで実行できるのだがTypescriptで書いていると都度sam buildでビルドする必要がありそうなのが少し不便だった。
実際には"invoke": "npm run build && sam local invoke",というスクリプトをpackage.jsonに定義していたのでそこまで困りはしなかった。

詰まりどころ

将来、消費電力とか他のメトリクスも収集したいので、npm workspaceを使ってAPI周りの処理をローカルパッケージに分離するディレクトリ構成にした。

send-switchbot-metrics-to-mackerel
├── libs (API呼出系のモジュール)
│   └── package.json
├── meter (温湿度計のメトリクス送信するLambda関数)
│   ├── app.ts
│   └── package.json
├── package.json
├── samconfig.toml
└── template.yaml

しかし、この構成でsam buildをしようとするとnpm install時にlibsの依存解決に失敗しビルドがエラーになってしまう。

Build Failed
Error: NodejsNpmEsbuildBuilder:NpmInstall - NPM Failed: npm WARN config production Use `--omit=dev` instead.
npm ERR! code ETARGET
npm ERR! notarget No matching version found for libs@1.0.0.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

sam build --build-in-sourceとオプションを付けることでビルドできるようになった。

これは、通常ではビルド時に一時フォルダにファイルが展開されてビルドされるため、ディレクトリの異なるlibsが展開されないことが原因のようで、--build-in-sourceを付けることでソースのnode_modulesが参照されるためlibsの依存関係が解消できるようになったということらしい。
参考: [アップデート]AWS SAM CLIでnodejsをビルドする際に元々のソースディレクトリを参照しビルドができるようになりました | DevelopersIO

監視ルール

せっかくMackerelにメトリクス送信するなら監視ルールを設定したいよなということで考えていたのだが、室温で監視ルールを設定したところで、家にいて暑ければアラートがなくてもエアコンつけるだろうから意味ないよなと思っていた。

そんなときに、不快指数という指標を見つけてこれを使って監視ルールを設定することにした。
部屋内が外よりも不快指数が高ければwarningを出して窓を開けて換気を促すという監視ルールに決めた。

具体的にはこの条件式が0未満になったときにアラートを出すという条件

diff(
  service(Home, switchbot.thi.outdoor),
  service(Home, switchbot.thi.living)
)

とはいえ、寒くなると不快指数は低くなるので作っていてこの監視ルールは今の秋口限定になりそうな気もしている。70~75が快適というのはメトリクスを追うには不便でならない。
といいつつ、昨日時点でもう涼しくなって1日中warningが出続けていたので、もう使う機会はないのかもしれない...

Google Home APIが一般提供されたら難しいワークフローも作れるようになるのかな。一歩も動かずに家のことが全部できるようになりたい!




以上の内容はhttps://handat.hatenablog.com/entry/send-switchbot-metrics-to-mackerelより取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14