スマートホームの自動化では、「応答がない」ことを「不在」と読み替えたくなる。しかし、検出系が壊れたときにその解釈を採用すると、家は人がいるのに照明を消す。今回、在宅検知のログとCO2センサーの記録を突き合わせて、移行後の検出不良が自動消灯に与えた影響を調べた。
移行後に「不在」が増えた
自宅では、30分ごとにスマートフォンがLAN上で検出できたかどうかをJSONLへ記録し、その結果を照明や空調の制御に利用している。ホストをRaspberry Piから別のLinux環境へ移行したあと、mDNSの検出に必要な仕組みが新環境へ引き継がれていない期間があった。
その結果、スマートフォンが実際にいないのではなく、「検出できない」状態が続いた。ところが制御側はこの無応答を不在として扱い、移行後の数日間に照明を消すイベントを記録していた。移行で壊れたのは照明制御そのものではなく、制御へ渡す前段の観測だった。
CO2ログが誤判定を裏付けた
ログに残っていた消灯イベントを、別系統のCO2センサーと照合した。消灯直前にCO2濃度が443ppmから458ppmへ上昇していたイベントが少なくとも2件あり、在室者の呼吸による上昇と考えるのが自然だった。一方、別のイベントではCO2が下降しており、在室者がいないタイミングで正しく消灯できた可能性もある。
CO2は在室の証明ではない。換気や気流の影響も受けるし、30分単位のログでは細かい滞在状況を復元できない。それでも、ネットワーク検出が「不在」と判定した瞬間に、独立したセンサーが一貫して在室側を示していたことは、誤判定を検証する材料になった。単一センサーの値を信じるのではなく、異なる原理の観測を後から突き合わせることに意味がある。
131日分の素朴なログが役に立った
同じ環境には、空調制御のログも数か月分残っていた。約131日、30分単位の記録が一度も途切れず、移行前後でデータ形式も日付形式も変わっていなかった。移行時に最も壊れやすいのは、実は複雑な処理よりも、周辺の依存関係と記録の入口なのかもしれない。
- 移行前後で検出件数を比較する
- 検出不能と不在を別の状態として保存する
- 制御イベントの前後を、独立したセンサーで検証できるようにする
- ログの形式を変えず、後から集計できる状態を保つ
長期集計では、移行前の在宅率が約89%、移行後が約82%だった。月別の変動も見えたが、30分ごとの全期間平均だけでは日ごとの違いが潰れてしまう。平均値は概要を示すには便利でも、誤作動の調査ではイベントの前後関係の方が重要になる。
「不確実なら何もしない」を制御側に置く
今回の修正では、ネットワーク検出を別の実装へ置き換えるだけでなく、応答がないときに即座に不在と判定しないフェイルセーフも加えた。検出系が不調なとき、照明を消すことは利用者に直接影響する。一方、数分間照明を消さずに待つことは、多くの場合それほど危険ではない。
この差は、オートメーションの設計で見落とされやすい。状態を二値の「在宅／不在」に押し込める前に、「在宅」「不在」「検出不能」「未評価」を分ける。特に、検出不能を不在へ暗黙に変換する処理は、便利な省略ではなく、障害時の動作を決める設計判断である。
移行チェックリストに加えたいこと
サービスが起動するか、設定ファイルが存在するかだけでは、在宅検知の移行確認として足りない。次のようなエンドツーエンドの確認が必要になる。
- 検出に使うOSサービスや権限が新環境に存在するか
- 検出不能時の状態が、制御側でどう解釈されるか
- 実際の検出ログと制御イベントが時刻付きで追跡できるか
- 別のセンサーを使って、誤判定を後から検証できるか
移行の成功は、プロセスが起動したことではなく、利用者の目的まで一周して初めて確認できる。自動化では「観測できる」「判断できる」「安全に制御できる」を分けてテストする方が、単純な稼働確認よりも現実に近い。
家のログは、何かを制御するためだけにあるのではない。検出器が目を閉じたとき、別のセンサーが何を見ていたかを後から確かめるためにもある。素朴なJSONLと、異なる原理のCO2測定。その二つが残っていたことで、誤消灯は推測ではなく、少なくとも一部については検証可能な出来事になった。