風呂のスイッチを遠隔で一度押せれば、「お風呂を自動で入れられる」と言いたくなる。
だが、トグル操作には現在状態がない。
同じ命令が、停止中なら開始、運転中なら停止になる。
今回確認できたのは、風呂スイッチへトグル命令を送る経路が存在することだった。
一方、状態取得用として試した経路は404を返し、現在状態を取得できなかった。
湯張り開始、完了、停止の物理状態も確認できていない。
この記事でいう自動化は、既存機器のスイッチ操作を補助する試作経路を指す。
給湯器の安全機構を変更したり、燃焼や給水を直接制御したりするものではない。
現在確認できている範囲
事実を段階に分けると、現在地が見えやすい。
| 項目 | 確認状況 | 言えること |
|---|
| トグル命令の経路 | 確認済み | スイッチ操作を要求する入口がある |
| トグル経路の呼び出し記録 | 確認済み | 過去に経路を呼び出した記録はあるが、下流への送信成功と機器受信は未確認 |
| 現在状態の取得 | 未確認 | 開始中か停止中かをAPIから判断できない |
| 湯張り開始 | 未確認 | 機器が命令を受けた証拠がない |
| 湯張り完了 | 未確認 | 浴槽へ適量の湯が入った証拠がない |
写真：既存の壁面パネルに小型サーボと制御基板を追加した試作構成。写真だけでは命令送信、機器受信、湯張り状態を確認できない。
したがって、現状を「風呂自動化が完成した」とは書けない。
正確には、遠隔トグルの試作経路がある段階だ。
トグルは再送に弱い
ネットワーク処理には、タイムアウトと再試行がある。
一回目の命令が実際には届いていたのに応答だけ失われ、同じトグルをもう一度送ると、開始した直後に停止させる可能性がある。
人がボタンを目で見て押す場合、表示ランプや機器音から結果を判断できる。
遠隔操作では、その観測を別に用意しなければならない。
特に風呂では、「命令を受け付けた」「湯張りを始めた」「設定量へ到達した」は別の状態である。
一つの成功フラグにまとめると、空の浴槽を完了として通知したり、運転中に再送したりする。
望ましいのは開始と停止を分けること
安全なAPIは、状態不明のトグルではなく、希望状態を明示する。
• 開始は、停止中のときだけ開始する。
• 停止は、運転中のときだけ停止する。
• すでに希望状態なら、何も変えず同じ結果を返す。
• 状態を取得できない場合は、推測で押さずエラーにする。
この性質を冪等性という。
同じ要求が二度届いても、結果が反転しない。
既存機器がトグル入力しか持たない場合は、外側で現在状態を観測してから一度だけ押す。
観測できない間は、再送を禁止し、人の確認へ戻す。
何を観測すればよいか
状態取得の方法は、既存機器を改造せず、メーカーの安全機構を残したまま選ぶ。
候補は複数ある。
• スイッチを押す機構の位置を検出する。
• 操作パネルの表示灯を、電気的に接続せず光センサーで読む。
• 給湯器が提供する正規の連携機能や通知を利用する。
• 浴室の温度や流量など、目的に合う独立したセンサーを使う。
どれか一つで「湯張り完了」を断定できるとは限らない。
たとえばスイッチ位置は、押したことを示しても給湯成功を示さない。
表示灯は運転中を示しても、浴槽の水位を示さない。
必要な完了条件を先に定義し、それを直接観測できる手段を選ぶ。
「入浴できる状態」を目標にするなら、命令送信だけでは足りない。
タイムアウトと手動復帰を先に作る
風呂は水と熱を扱う。
そのため、便利な起動ボタンより先に停止条件を用意する。
- 状態を取得できなければ操作しない。
- 開始後、一定時間内に進行状態を観測できなければ、異常を通知して自動処理を停止する。
- トグルは再送せず、機器の停止は現場でメーカー正規の手動手段により確認する。
- 同じ命令を自動で連打しない。
- 通信が切れても、既存機器の安全機構と手動操作を使える状態に保つ。
- 実機試験中は人が現場を確認し、無人運転へ移さない。
給湯器本体の安全機構を迂回してはならない。
自動化側は、既存の正規操作を補助し、状態が分からなければ手動へ戻す立場にとどめる。
Jarvisが答えるべき言葉
現在の構成でJarvisがトグル命令を送った場合、正しい返答は「お風呂ができました」ではない。
「スイッチ操作を送信しました。湯張り状態と完了は確認できません」が、確認できた事実に合う。
状態観測が追加されたあとも、開始、進行、完了を分けて通知する。
最後の完了通知は、独立した観測が条件を満たしたときだけ出す。
自動化で最初に作るべきものは、押す指ではない。
押したあとを見届ける目と、分からないときに止まる判断である。
