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