エアコン自動化は、室温が26℃を超えたら冷房を強くするだけに見える。
しかし、温度計の一回の値だけで操作すると、センサーの揺れを追いかけ、赤外線信号を何度も送る装置になりやすい。
制御方針として定めているのは、25〜26℃を帯として扱い、温度の傾向を見ながら設定温度を1℃ずつ動かす考え方だ。
この方針に基づく自動制御の実装と実機運転は未確認であり、全経路の実機確認が終わっているわけではない。
2026年7月21日のライブ確認では、エアコンの既知状態として冷房24℃相当を取得できた。
温度センサー連動、赤外線の物理受信、室温変化までの一連の自動運転は未確認である。
「既知状態」は室内の事実ではない
2026年7月21日に状態APIから確認できたのは、ソフトウェア上の既知状態がcool_24、すなわち冷房24℃相当だったことだ。
これが最後に送信された完全状態信号かは未確認であり、エアコン本体が信号を受け取ったことも、吹き出しが始まったことも、室温が24℃になったことも証明できない。
赤外線リモコンは、ネットワーク機器のように受信確認を返さないことが多い。
送信処理が成功しても、遮蔽物、向き、距離、機器の一時状態で届かない可能性がある。
したがって、記録は最低でも三つに分ける。
| 記録 | 内容 |
|---|
| 判断 | どの温度と傾向から、なぜ操作を選んだか |
| 送信 | どの完全状態信号を、いつ送ったか |
| 観測 | 送信後に温度や別センサーがどう変化したか |
「送信成功」と「冷房成功」を同一視しないことが第一の安全策になる。
25〜26℃を一点ではなく帯で見る
目標は25〜26℃である。
0.2℃の細い閾値で頻繁に切り替えるのではなく、帯の中か、上に外れたか、下に外れたかを見る。
制御方針は次の通りだ。
• 25〜26℃の帯内なら、温度が下がっている途中も含めて現在設定を維持する。
• 26℃を超え、温度が停滞または上昇しているときだけ、冷房設定を1℃下げる。
• 設定温度を下げる下限は18℃とする。
• 25℃未満なら、冷房設定を一回につき1℃上げる。
• 十分に冷えたあと停止を選ぶ場合も、室温が26℃へ戻ったことを確認してからにする。
この方針には、急な操作を避ける意図がある。
26℃を少し超えていても、すでに温度が下がっているなら待つ。
逆に同じ26.5℃でも、横ばいか上昇中なら一段だけ強める。
なぜ1℃ずつなのか
室温は、設定温度を変えた直後には反応しない。
部屋の広さ、日射、人、家電の発熱、空気の混ざり方で遅れが生まれる。
一度に数℃動かすと、効いたかどうかを判断する前に次の操作が重なりやすい。
1℃ずつなら、どの変更が温度の傾向へ影響したかを追いやすい。
ただし、1℃刻みにしただけでは十分ではない。
操作後には待機時間を置き、同じ条件で連打しないロックを設ける。
センサー値が欠けた、古い、急に跳ねた場合は、前回設定を維持して通知する。
完全状態信号を送る
エアコンの赤外線は、電源だけを反転するトグルではなく、運転モード、設定温度、風量などをまとめた完全状態として扱う方が安全だ。
たとえば「冷房24℃」を送れば、以前の状態を推測して温度ボタンを何回押す必要がない。
一方で、完全状態信号でも物理受信は分からない。
赤外線送信後に室温の傾向、消費電力、吹き出し口付近の温度など、独立した観測を一つ以上組み合わせたい。
どの観測を採用するかは、機器を改造せず安全に取れる範囲で決める。
通知は操作のあとではなく、判断と結果に付ける
通知には「設定を下げた」だけでなく、その理由と確認状況を含める。
たとえば、次のように分ける。
• 室温が帯内で低下中のため、冷房24℃を維持した。
• 室温が26℃を超えて上昇中のため、設定を1℃下げる信号を送った。
• 信号は送信したが、物理受信は確認できていない。
• センサー値が不正なため、操作せず停止した。
通知先は生活環境の中で確実に気づける場所へ限定し、同じ判断の連続通知はまとめる。
自動化の目的は通知を増やすことではなく、人が介入すべき例外を減らすことだ。
現在地と次の検証
現時点で確認できたのは、ソフトウェア上の既知状態がcool_24だったことである。
完全状態信号を使う考え方と25〜26℃の制御方針は定義しているが、その自動送信と実機運転は未確認だ。
まだ完了と言えないのは、室温センサーから判断、赤外線送信、物理受信、温度変化、通知までを一つの記録で追う実機試験だ。
この試験では、帯内、26℃超で低下中、26℃超で上昇中、25℃未満、センサー欠損の各場面を分けて確認する。
エアコン自動化の賢さは、操作回数では測れない。
何もしない方がよい場面で待ち、必要なときだけ1℃動かし、その結果を確認できることが重要である。
