Skip to content

Skoda TP4b: Abfahrtstimer lesen und setzen (Admin + Portal) - #228

Merged
CallMeTechie merged 11 commits into
masterfrom
feat/skoda-departure-timers-tp4b
Jul 25, 2026
Merged

Skoda TP4b: Abfahrtstimer lesen und setzen (Admin + Portal)#228
CallMeTechie merged 11 commits into
masterfrom
feat/skoda-departure-timers-tp4b

Conversation

@CallMeTechie

Copy link
Copy Markdown
Owner

Abfahrtstimer (Klima-Timer) der Fahrzeuge lesen und setzen — An/Aus, Uhrzeit, Wochentage — in der Admin-Seite /skoda und im Portal-Widget (login- und besitzergegatet wie TP3).

Live-Spike zuerst (Ground Truth)

Der geplante Endpunkt ist für beide Autos tot: GET /api/v1/vehicle-automatization/{vin}/departure/timers antwortet 500, in vier deviceDateTime-Formaten und ganz ohne Query-Parameter; /v2 und /departure-timers liefern 403. Im selben Lauf waren connection-status/readiness und air-conditioning sauber — die Session war intakt. Gleiches Muster wie trip-statistics in TP4a.

Der funktionierende Pfad ist der Klima-Endpunkt (beide Autos tragen die Capability AIR_CONDITIONING_TIMERS):

  • Lesen: GET /api/v2/air-conditioning/{vin} liefert timers[]{id, enabled, time, type, selectedDays} — steckt bereits im Sync-Payload, kein zusätzlicher Abruf.
  • Schreiben: POST /api/v2/air-conditioning/{vin}/timers mit {"timers":[<einer>]}202.

Zwei weitere gemessene Fakten:

  • Slot-Erhalt bewiesen: am Enyaq Timer 1 von 05:15 auf 05:16 geschrieben, Timer 2 danach byte-identisch, anschließend zurückgesetzt und verifiziert. Netto keine Änderung am Fahrzeug.
  • Übernahmelatenz ~55 Sekunden. Der 202 ist ein angenommener Auftrag, keine Bestätigung. Ein alter Wert kurz nach dem Speichern ist deshalb der Normalfall, kein Fehlschlag — das steht so im CHANGELOG.

Umgesetzt

  • normalizeVehicleState übernimmt die Timer als climate.timers (nie null).
  • Portal-Redaktion reicht genau fünf Felder durch — und nur an eingeloggte Nutzer: Abfahrtszeiten sind ein Anwesenheitsprofil des Haushalts und folgen damit derselben Regel wie die GPS-Position (trust never relaxes the sensitive bit).
  • Neuer Command timer_set im bestehenden Whitelist-Muster: Validierung vor jedem Cloud-Kontakt, withAccountLock, afterCommand-Refresh. type stammt immer aus einem frischen Cloud-Read, nie aus dem Request. ONE_OFF-Slots werden nicht geschrieben (SKODA_TIMER_READONLY) — der Spike hat nur RECURRING gesehen, erfundene Wochentage in einem Einmal-Timer wären stiller Datenschaden.
  • Keine neuen Routen: beide Command-Routen reichen action/args generisch durch.
  • Editor in beiden Oberflächen als zweiter Aufklapper, mit optimistischer Anzeige, 30-Sekunden-Watchdog und Schutz gegen Rebuilds, die ungespeicherte Eingaben fressen.
  • 19 + 19 i18n-Keys in de/en, GC.t-Whitelist aller drei Layouts, PT-Block, mit Bridge-Regressionstest.

Prüfung

Volle Suite 2285 bestanden, 0 fehlgeschlagen. Spec und Plan durchliefen je einen Preflight (sechs unabhängige Prüfer), jede Task einen eigenen Review, dazu ein Abschlussreview über den ganzen Branch — Urteil merge-reif, keine kritischen oder wichtigen Befunde.

Der Preflight fing unter anderem: den Portal-Redaktionspfad ohne Login-Gate, einen Ersetzungsbereich, der fail() mitgelöscht hätte (Seite wäre beim Laden gestorben, an allen Tests vorbei), und zwei CSS-Variablen, die im Portal gar nicht existieren.

Offen (rollout, nicht merge)

End-to-End-Beweis über die gebaute Oberfläche: je einen Timer in Admin und Portal ändern und in der Skoda-App gegenprüfen — wegen der Übernahmelatenz frühestens eine Minute nach dem Speichern.

Vorgänger: TP1 #222 · Login-Fix #223 · TP2 #224 · TP3 #226 · TP4a #227

@CallMeTechie
CallMeTechie merged commit 6632d10 into master Jul 25, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant