SwitchBotプラグミニで自宅サーバーの消費電力を記録する方法

常設機器が少しずつ増え、「どの系統が、いつ電気を使っているのか」を知りたいラボ運用者にとって、電力の見える化は故障対応より前に効く記録です。某所ラボでは現在、7系統の消費電力を市販のスマートプラグで測り、事務所画面に直近24時間の推移として並べています。

意外だったのは、計測対象を増やすだけでは済まなかったことです。7系統をすべて60秒ごとに取得すると、クラウドAPIの1日あたり1万回という上限を約10,104回で超えます。そこで変化の遅いエアコン関連だけを5分間隔にし、実運用では約6,648回に収めました。

数字を細かく取ることより、無理なく取り続けることを選んだ結果、メインPCからエアコンまでの電力が同じ画面に残るようになりました。これは工作展・第2期で予告した小さな道具の、最初の一つです。

電源を測り始めると、ラボの動きが時系列になる

電源や発熱を感覚だけで判断しないために、以前からホームラボの電源・消費電力・発熱を実測で扱う考え方を置いてきました。今回は、その実測を単発で終わらせず、日々の変化として眺められるようにした回です。

使っているのはSwitchBotプラグミニです。コンセントと機器の間に挿し、系統ごとの消費電力を一定間隔で取得します。値は1サンプル1行で、系統ごと・日ごとにファイルを切り替えて保存しています。1系統の1日分は、およそ190KBです。

最初は1系統だけでした。2026年8月5日にUPSとUPSなしのサーバ系統を加え、翌8月6日にはエアコン関連の3系統も追加しています。途中の8月3日には、複数系統化の設定が作業中に一度巻き戻る場面もありましたが、8月5日に構成を作り直しました。完成形を一度に設計するより、見たい対象が増えた時点で計測を足していく方が、この道具には合っていました。

7系統を同じ細かさで測らない構成にした

現在は4系統を60秒間隔、3系統を300秒間隔で測っています。エアコン関連は分単位で状態が動かないため、5分間隔へ緩めました。

図1は、現在の計測構成です。実画面ではなく、実際に動いている系統数と取得間隔を整理した構成図です。

図1: 構成図: 7系統の取得間隔と1日あたり約6,648回の呼び出し

対象	系統数	取得間隔
メインPC・小物類・UPS・サーバ（UPSなし）	4	60秒
エアコン関連	3	300秒（5分）
表示名の定期取り込み	—	1時間ごと

図1で重要なのは、エアコン関連だけが遅いことです。ここは精度を捨てた部分ではありません。分単位の変化を追う必要が薄い対象を分けることで、残りの4系統を60秒間隔のまま維持しています。

選択肢	1日あたりの呼び出し回数	このラボでの判断
7系統すべてを60秒間隔で取得	約10,104回	1万回の上限を超えるため採用しない
4系統を60秒、3系統を300秒で取得	約6,648回	現在の構成
計測しない	0回	系統ごとの変化を時系列で比べられない

全部を細かく見たい、という要求は自然です。ただし、呼び出し回数の上限を越えれば、記録は継続できません。今回の構成は、必要な場所の粒度を保ちながら、日々の計測を続けるための折衷案です。

注意: スマートプラグとクラウドAPIを使う場合、購入前・構築前に、利用するサービスの呼び出し上限と自分の計測間隔を掛け合わせてください。系統数を増やしてから上限に当たると、記録の連続性が崩れます。

1サンプル1行が、あとから見返せる電力の履歴になる

取得した値は、系統ごと・日ごとのファイルに1サンプル1行で蓄積します。形式は地味ですが、「今だけ」の消費電力を、後から比較できる履歴へ変えます。

2026年8月8日には、保持期限内に残っていた2026年7月24日12:54からライブ計測開始直前までの過去ログ38,289サンプルを、グラフ用の基盤にまとめて投入しました。これにより、ライブ計測が始まった瞬間だけでなく、手元に残っていた過去分も含めて時系列として見られるようになっています。

図2は、計測から表示までの流れです。

図2: 構成図: スマートプラグの1サンプルが事務所画面の24時間グラフになるまで

段階	実際に行うこと
計測	スマートプラグで系統ごとの消費電力を定期取得する
記録	1サンプル1行で、系統ごと・日ごとのファイルに貯める
表示	事務所画面で、系統ごとの直近24時間グラフを自動生成する

図2では、系統を追加しても表示側のタイルを作り直さない点が効きます。データからタイルを自動生成するため、新しい計測対象を加えた後も、画面側で同じ作業を繰り返さずに済みます。

名前を変えるだけで、タイルの見出しも追随する

事務所画面には、各系統の直近24時間のグラフと、現在・平均・最小・最大を表示しています。電力タイルを含む画面そのものは、先にラボの仕事ぶりを一目で見る「事務所」として作っていました。

ここで小さく便利なのが、タイルの見出しです。スマートプラグのアプリで登録した名前をそのまま使い、定期処理が1時間ごとに名前を取り込みます。アプリ側で名前を変えると、最大1時間で事務所画面にも反映されます。

計測対象を増やすと、名前の整理も必要になります。記録名と表示名が別々に固定されていると、後から画面だけが古い呼び名のまま残りがちです。登録名を表示に追随させるだけで、計測の運用は少し静かになります。

最小構成なら、まず1系統と1日の記録で足りる

同じ体験を試すなら、最初から複数系統へ広げる必要はありません。市販の消費電力計測対応スマートプラグを1つ用意し、気になる1系統を定期的に記録し、1日分を時系列で眺める。この最小構成でも、電力が「瞬間の数値」から「その機器の振る舞い」へ変わります。

複数系統化は、記録を見て次の対象が気になった時に足せば十分です。今回も、1系統から始め、現在は7系統になりました。

購入前には、電力を測る目的と上限を先に照らし合わせる

• 接続する機器とスマートプラグの対応条件
• 消費電力を取得できるかどうか
• 利用するサービスの呼び出し上限
• 測りたい変化に対して十分な取得間隔か
• 系統名を後から整理できるか

このラボでは、7系統が今も動いています。事務所画面を開けば、メインPCからエアコンまで、系統ごとの電力が同じ時刻に並びます。

まだ電気を測っていない場所が、ラボにはまだあります。まずは気になる1系統を1日だけ記録して、次に見たい場所が本当にあるかを見てください。

取得値が1行ずつ増えるところまでを端末で確かめる

上記の実測環境は、SwitchBotプラグミニ、Linux上の常駐収集処理、系統別・日別のログ、事務所画面の組み合わせです。APIのトークンや署名鍵はログへ書かず、収集処理の実行環境からだけ読ませています。

読者の環境では、まず収集処理を1回実行し、その前後で対象ファイルの行数が1行増えることを確認します。収集コマンド名と保存先は自分の実装へ置き換えてください。

DEVICE_ID=<YOUR_DEVICE_ID>
POWER_LOG="$HOME/wall-power/plug-mini-$(date +%F).jsonl"
python3 switchbot_status.py status "$DEVICE_ID" \
  | tee /tmp/switchbot-status.json
jq '{weight,voltage,electricCurrent,electricityOfDay}' \
  /tmp/switchbot-status.json
before=$(wc -l < "$POWER_LOG" 2>/dev/null || printf '0')
systemctl is-active --quiet wall-power.service
sleep "$COLLECTION_INTERVAL_SECONDS"
after=$(wc -l < "$POWER_LOG")
printf 'before=%s after=%s\n' "$before" "$after"
tail -n 1 "$POWER_LOG"

成功時はafterがbeforeより1大きくなり、末尾に今回の1サンプルが出ます。行数が増えない場合は、グラフ側を触る前に収集処理の終了コード、APIの呼び出し上限、保存先の権限を確認します。

成功: before より after が1大きい / 末尾に今回のサンプルが1行ある
失敗: 行数が同じ、またはログファイルを読めない

7系統へ広げる前に、この確認を1系統・1日分で通すのが安全です。今回の環境では1系統から始め、60秒間隔の4系統と300秒間隔の3系統へ増やしました。