前回の記事では、家族が触る mando のボタン——「開ける」「点ける」の裏側を書きました。今回はボタンの下、画面いちばん下にある「きろく」セクションの話です。

きっかけは単純でした。「今日どれくらい発電した?」「書斎のCO2はいま高い?」と家族に聞かれても、そのたびに別のアプリを開いて探すのは面倒です。家のデータはすでに embalse という自作のデータレイクに溜まっていたので、mando の同じ画面から見られるようにしよう、というのが出発点でした。

見せたいものを先に決めた

最初に決めたのは、太陽光発電・電力収支・CO2・温度・湿度(部屋別)の5種類のグラフと、今日/週/月の期間タブだけ、というシンプルな範囲です。設計は2026-07-15、翌日には期間タブとSVGチャートを備えた「きろくセクション」が動いていました。

mandoは「execして描くだけ」に徹する

embalse 側にデータを1つのJSON配列に整えて返すクエリCLIを置き、mando はそれを設定ファイルのコマンド列としてexec(実行)するだけ、という役割分担にしました。

[{"ts": "2026-07-15T10:00:00+09:00", "series": "書斎", "value": 812.0}]

検討したのは3案です。設定ファイルにSQLを直書きする案は設定が肥大化するため、mando が生データを直接読みに行く案は「下のデータ基盤が何であるかをmandoが知らない」という原則に反するため、それぞれ却下しました。採用したのは、embalse 側にクエリCLIを立てて mando はそのコマンド列を実行するだけ、という形です。コマンドの中身が何であるか——CLIなのかHTTPなのか——を mando 本体は知りません。

チャートは外部ライブラリを足さずSVGを手描きしていて、単一バイナリでオフライン動作するという mando の性質を崩していません。取得はセクションが画面に現れたときと期間タブの切り替え時だけで、ポーリングはしません。家のデータは1〜5分間隔でしか増えないので、それで十分でした。

データの置き場所が変わった日、mando側は1行も変えなかった

2026-07-19、embalse のデータ置き場がラズパイからNASへ切り替わりました。それまで mando はラズパイ上のクエリCLIをssh経由でexecしていましたが、この日からはNAS常駐のHTTP APIを叩く必要が出てきます。

ここで効いたのが、mando が「コマンドの中身を知らない」という前提でした。設定ファイルのコマンド列を、ssh経由のCLI呼び出しから curl に差し替えるだけで切り替えが完了し、mando 本体のRustコードは変更ゼロで済みました。

query = ["curl", "-fsS", "--max-time", "30", "http://<NASのアドレス>:8526/api/graphs/generation?period={period}"]

「transportをmando本体に持ち込まない」という設計方針を先に決めていたおかげで、バックエンドの引っ越しが設定ファイルの書き換えだけで終わった、というのがこの日の答え合わせです。

ラズパイ自身も同じ仕組みで見張ることにした

きろくを作ってから3日後の2026-07-18、今度はラズパイ自身の健康状態も同じ仕組みに乗せました。これも設計から実装まで同じ日のうちに終わっています。

見る指標はCPU使用率・メモリ使用率・ディスク使用率・CPU温度の4項目だけに絞りました。それぞれにしきい値を持たせ、ok / warn / crit に加えて stale(直近15分にデータが来ていない=収集そのものが止まっている)という状態も用意しています。収集が止まっていることに気づけないのでは意味がないからです。

指標warncrit理由
ディスク使用率80%90%逼迫するとレイクへの書き込みが止まる
メモリ使用率85%95%ラズパイはswapが薄く、枯渇がすぐOOMに近づく
CPU使用率90%95%5分おきの瞬時値。高止まりの検知が目的
CPU温度70℃80℃80℃前後でソフトウェアスロットリングが始まる

判定するのは embalse 側で、mando は結果を受け取って画面に出すだけです。バナーは全部正常なら何も表示せず、異常があるときだけ画面上部に出ます。これもポーリングはせず、画面を開いたときに1回取得するだけにしました。

グラフに出た数字がおかしいことに気づいた

機能を作ってからしばらくして、このグラフを見ていてCPU使用率の数字がどうも高すぎることに気づきました。実際に手元で測ると25.2%ほどなのに、レイクに溜まっている値は46.9%——20ポイント以上、ずっと過大に出続けていたことが分かりました。

原因は測定方法にありました。CPU使用率は「1秒空けて2回読んで差分を取る」という単純な方式にしていたのですが、収集は5分ごとに複数のコマンドがまとめて動くタイミングと重なっていて、その1秒はまさに「自分たちの収集コマンド自体が一番忙しい瞬間」を測っていたのです。

直したのは、前回の実行結果を保存しておき、次回の実行との差分(収集間隔である300秒分)から計算する方式です。これで「直前の5分間の平均」という意味のある値になりました。値を貯めておく必要が出た分、他のツールが徹底しているステートレスな one-shot の原則からは唯一外れることになりましたが、正しい値を出すことを優先しました。

捨てたこと

チャートライブラリの導入は見送りました。単一バイナリでオフライン動作するという mando の性質を保つためです。データの取得結果をキャッシュする仕組みも最初は入れていません。グラフ用の実行は専用の実行枠で直列に処理されるので、重くなったら考える、という順番にしました。異常の知らせ方も、通知アプリへのプッシュではなく画面のバナー表示だけに留めています。

住んでみて

太陽光発電はいまも%表示と1日の合計kWhの両方が見えるようになっていて、電力収支もグラフの内訳として見られる形に育っています。いまのところ4項目で足りていますが、ラズパイ以外の機器の温度を見たくなっても、同じ仕組みにnodeを1つ足すだけで拡張できる形にはしてあります。