1. profil_schreiben awaitete wunsch_uebernehmen und damit bis zu drei
HTTP-Runden zu flespi - bei 39 Aufrufstellen von profilSpeichern() im Panel
je Feldaenderung. Laeuft jetzt als eigene Aufgabe.
2. Ein gescheiterter Schreibversuch wurde bei jedem Speichern wiederholt, weil
der Fehlerstand kein "werte" hat. Er merkt sich jetzt unter "versucht", was
gescheitert ist. Dazu: kein zweites Schreiben, wenn der Wert schon als
pending bereitliegt.
3. buendelPasst() versprach im Kommentar, ein aelteres Buendel abzulehnen,
pruefte aber nur Ungleichheit - deshalb meldete die App "diese Fassung
aendert auch Natives", obwohl nur das Buendel nach einem Versionssprung
nicht neu gebaut war. Vergleicht jetzt gegen die Serverfassung, drei
Regressionstests (der entscheidende gegen den alten Stand rot). Der Text
behauptet keine Ursache mehr, die die App nicht kennen kann.
4. Das Regler-Minimum ging heute von 0 auf 1, ein bereits gespeicherter Wert
darunter lief ungeprueft durch. Beide Oberflaechen klemmen jetzt auf 1-60.
182/182 Tests, 28 Backend-Dateien py_compile, beide Frontends als Modul
geparst, Dienst- und Katalog-Konsistenz in beide Richtungen geprueft, Buendel
auf derselben Fassung wie das Manifest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flespi legt beim Schreiben das ganze Objekt als pending ab. In der Kachel stand
deshalb "Sleep Mode 102: 2 -> 2 unterwegs", obwohl sich an type nichts aendert.
vergleichen() zeigt offen jetzt nur noch bei echtem Unterschied.
Gefunden an der ersten Fahrt mit echten Daten. Dieselbe Fahrt hat zwei weitere
Befunde geliefert, in AGENTS.md festgehalten: die Zuendung steht auf "an", weil
das der letzte je gesendete Wert ist (das Aus kam nie an) - der Fall, fuer den
"Fahrt beenden" gebaut ist; und address=connection hat 30 Minuten durchgehende
Verbindung nicht zum Zustellen genutzt, pending steht weiter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Regler "Fahrt beenden" ist jetzt eine Zahl fuer zwei Dinge: unsere eigene
Wartezeit bis zum Fahrtende und der Schlaf-Timeout des FMM003 (103). So lange
bleibt der Dongle wach und wartet darauf, dass es gleich weitergeht; danach
schlaeft er. Die 180 s Ignition OFF Delay laufen davor und bleiben unsichtbar -
sie werden nur von der Fahrtdauer abgezogen. Der Regler geht deshalb von 1 bis
60 in Einerschritten; das Geraet kennt kein Timeout 0.
flespi.py liest und schreibt die Geraete-Konfiguration. Drei Annahmen sind an
der echten API gefallen und stehen als Messung im Modulkopf: der Wert liegt in
current (nicht value), die Einstellung heisst sleep_mode mit dem Wert eine Ebene
tiefer unter mode, und ein PUT braucht {"properties": ..., "address": ...}.
Die eigene Auftrags-Warteschlange ist wieder entfallen. Sie war fuer "das Geraet
schlaeft" gebaut - das gilt aber nur fuer das Geraet, nicht fuer die
Schnittstelle: die vollstaendige Konfiguration kam herein, waehrend das Fahrzeug
seit dem Vortag stand. flespi puffert selbst (pending + address=connection), ein
zweites Auftragsbuch waere eine zweite Warteschlange fuer dieselbe Aufgabe.
Gegengelesen wird nach jedem Schreiben; als Erfolg zaehlt current ODER pending -
letzteres ist bei stehendem Fahrzeug der Normalfall.
Live gegen den echten Account belegt: Token sieht genau ein Geraet, 127
Einstellungen bei parkendem Fahrzeug gelesen, Regler 15 geschrieben und als
pending bestaetigt (Nachbarfelder unveraendert), zweiter Neustart ohne erneute
Anfrage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tobias