晴れたり沼ったり

へんなものに沼ることがあります。

今回のchatGPTは比較的優秀だったかも

switchbotの外気温計を使ってraspiから読めるようになったので、

「外気温が低くなったのにエアコンを気が付かずに使い続けていることがある」

という問題点を回避できるような監視ツールを作ってみることにした。

 

前回懲りたので、仕様書を書いた段階でこの仕様に問題はないかと質問してみた。しょうもない質問もあるが、仕様書のプログラム構築側からのレビューだと考えれば結構いい質問もある。ユーザ部門からいい加減な仕様書を受け取ってメーカに発注できるレベルの仕様書を再構築し、メーカーにシステムを作らせる担当だったころ(大昔)にこれが使えたら発生しなかったトラブルもいっぱいあったような気もする:-)

曖昧・不明確・誤記の可能性がある点

1. **「その日の初回起動時」**とは何を基準に判定?

  • 現在時刻で当日の「初回」かどうかをどう判断するのか明示されていません。

    • inout.txtalarmed のタイムスタンプを見る?

    • 同日かどうかの判断はファイルの mtimedate 比較か?

➡️ 提案: inout.txtalarmed の更新日を見て、「当日でなければ初回」と判断する仕様を明記してください。


2. 外気温・湿度の取得時刻のタイミング

  • 外気温・湿度は /tmp/out の内容から取得するとされていますが、このファイルの更新時刻との整合性は保証されていません。

    • /tmp/out の更新が最新である保証が必要

    • さもないと、古いデータで評価してしまう危険あり

➡️ 提案: /tmp/outmtime をチェックし、例えば5分以内でなければ無視するなどの条件を加えるべきです。


3. 「3回以上のデータがあり…」の「5割以上」の意味がやや曖昧

  • 例えば4行あって、2行が条件を満たすと「ちょうど5割」→判定されるか?

    • 「5割以上」と書かれているが、「超える」でないと意図が不明確

➡️ 提案: 「条件を満たす行数 / 総行数 > 0.5」なのか「≥ 0.5」なのかを明記してください。


4. 時刻の「10分単位丸め」の仕様

  • 「10分単位に丸める」とありますが、切り捨て/四捨五入/切り上げのどれか不明

➡️ 提案: 「10分単位に切り捨て(例: 16:37 → 16:30)」など、明記が必要です。


5. 湿度や雨条件が複数満たされる場合のメッセージ順

  • メッセージ追記の順序は仕様通りに固定すべきです(例:「湿度」→「雨」)

➡️ 提案: 指定がない場合は以下順に追記とします:

  1. "現在の外気温はxx度です。"

  2. "ただし湿度は高めです。"

  3. "ただし、雨かもしれません。"


6. inout.txt のデータ形式に日付が入っていない

  • 内容は 14:30 28.5 26.9 61.0 のように記録されると思われますが、日付がないためログが1日を超えると破綻します。

➡️ 提案: "YYYY-MM-DD HH:MM" の形式にした方が良いかもしれません。もしくは毎日起動時にファイルを初期化する運用が前提ならば明記を。


7. inout.txt の列数と形式の明記が必要

  • HH:MM 室内気温 外気温 外湿度 だと思われますが、これを明確にしておくべきです。


8. announce.txt の書式と存在チェック

  • /tmp/announce.txt の存在有無で状態を管理しているように見えますが、意図的に残す想定かどうか不明

    • 例えば、削除されたら次のアナウンスが出るか?

    • alarmed だけで時間制御しているなら announce.txt は一時ファイルでよい?


9. 外気温と室内気温が共に None だった場合の扱い

  • smpl.py/tmp/out の出力異常時(センサー故障など)にエラー処理や早期リターンが必要

ということで一旦音声再生はやめてテキストファイルでのみ書き込む状態にして運用中。今のところトラブルは発見されてない。

 

ちなみに室内側のセンサーはこんな感じでラズパイにくっつけている。

ラズパイ本体の熱の影響を受けにくいように離して設置している。

センサは bosch社のBME280利用のもの。boschといえば車の電装部品メーカか電動工具かってイメージだが、この温度センサー系は電装パーツに必要だったのかもしれないが、結構市場シェアを取ってそうな気がする。

センサ用のスクリプトはスイッチサイエンスさんのスクリプトをほぼ流用。