Tab "Fahrzeuge" > Button "Status" #8

New issue

Open

opened 2026-08-27 23:01:54 +02:00 by erdbruegger · 1 comment

erdbruegger commented

2026-08-27 23:01:54 +02:00

Owner

Kannst du im Admin Web Dashboard unter der Navigation "Fahrzeuge">"Status" dieses Popup mit den Werten bearbeiten?
Anstatt Position etc (ist ja auch obsolet, wenn du da den neuen "latest" endpoint ziehst, der "gps" liefert) eine kleine Karte mit Standort einblenden? Plus: Siehst du eine Möglichkeit die Restweite "dynamisch" zu errechnen, falls sie mit null geliefert wird?

Kannst du im Admin Web Dashboard unter der Navigation "Fahrzeuge">"Status" dieses Popup mit den Werten bearbeiten? Anstatt Position etc (ist ja auch obsolet, wenn du da den neuen "latest" endpoint ziehst, der "gps" liefert) eine kleine Karte mit Standort einblenden? Plus: Siehst du eine Möglichkeit die Restweite "dynamisch" zu errechnen, falls sie mit null geliefert wird?

erdbruegger added the

claude

label

2026-08-27 23:01:59 +02:00

claudecode added the

in-progress

label

2026-08-27 23:04:04 +02:00

claudecode referenced this issue from a commit

2026-08-27 23:10:13 +02:00

release: Status-Popup mit Standortkarte und geschaetzter Restweite (#8)

claudecode commented

2026-08-27 23:20:58 +02:00

Collaborator

Umgesetzt in d4a3fc1 (release) — CI grün, deployt, live verifiziert.

1. Karte statt Koordinatenzeile

Das Status-Popup zieht die Position aus dem gps-Feld von /latest und zeigt sie als eingebettete OpenStreetMap-Karte mit Marker (~600 m Ausschnitt). Darunter stehen Koordinaten, Alter des Fixes und ein Link „größer auf OpenStreetMap“. Die Zeile Position ist damit weg.

Bewusst ohne Kartenbibliothek: ein iframe auf den OSM-Embed — kein API-Key, kein Tracker, kein zusätzliches Frontend-Bundle. Ohne Fix erscheint statt einer leeren Karte der Hinweis „Kein Standort bekannt“. Auf dem Telefon wird die Karte flacher (180 statt 240 px).

2. Restweite dynamisch — ja, aus dem eigenen Verbrauch

Meldet das Fahrzeug kein range_km (cache_data führt die Spalte nicht), liefert /vehicles/:id/latest jetzt zusätzlich range_estimate. Statt eine Herstellerangabe fest zu verdrahten, wird der Verbrauch aus der eigenen Fahrhistorie der letzten 30 Tage gemessen: Kilometer je SoC-Prozentpunkt, mal aktueller SoC. Das passt sich Fahrprofil, Jahreszeit und Batteriealterung von selbst an.

Live an Fahrzeug 1 (SoC 60 %, kein range_km):

"range_estimate": { "value": 276, "kmPerSoc": 4.6, "km": 59.8,
                    "socUsed": 13, "segments": 4,
                    "fromTs": "2026-08-17T06:59:51.000Z", "toTs": "2026-08-19T07:19:33.000Z" }

4,6 km/% ≈ 21 kWh/100 km — für den U5 plausibel. Im Dashboard steht das als ca. 276 km (geschätzt aus 4.6 km/% · 59.8 km Fahrt, SoC von vor 8 d).

Was nicht mitzählt (sonst lügt die Zahl):

Ladevorgänge — SoC steigt, kein Verbrauch.
Standzeiten ohne Wegstrecke — Vampirverbrauch ist pro Zeit, nicht pro km; er würde die Reichweite künstlich drücken.
Datenlücken > 6 h und unplausible Raten (< 0,2 / > 12 km je Prozent), z. B. nach Odometer-Sprüngen.
Segmente über Quellengrenzen: .inx und cache_data melden für denselben Wagen Odometerstände, die ~1800 km auseinanderliegen. Jede Quelle wird deshalb eigen verkettet — sonst misst man den Versatz statt den Verbrauch.

Reicht die Basis nicht (< 3 Segmente oder < 5 % SoC-Hub), gibt es bewusst keine Zahl statt einer geratenen. Die Schätzung steht in einem eigenen Feld und ist im Dashboard mit „ca.“ plus Datenbasis markiert — sie darf sich nicht als Messwert ausgeben.

Annahmen (Blocker-Policy: proceed-with-default)

30-Tage-Fenster, stündlich verdichtet: die Telemetrie kommt im 10-s-Takt, das wären ~260.000 Zeilen für eine Zahl. Je Stunde und Quelle der letzte Record → höchstens ~720 Zeilen, für eine Verbrauchsrechnung fein genug. Die zweite Abfrage läuft nur, wenn range_km wirklich fehlt.
OSM-Embed statt Leaflet/Tiles vom eigenen Server: kleinster Eingriff. Wenn dir der externe iframe nicht passt (Datenschutz/offline), sag Bescheid — dann kommt eine selbst gehostete Variante.

Selbsttests für beides laufen in CI: Bounding-Box-Mathematik und Kartenaufbau (routes/selftest.ts), Schätzlogik inkl. Laden/Stehen/Lücken/Quellentrennung (vehicles/rangeSelftest.ts).

**Umgesetzt** in `d4a3fc1` (release) — CI grün, deployt, live verifiziert. ### 1. Karte statt Koordinatenzeile Das Status-Popup zieht die Position aus dem `gps`-Feld von `/latest` und zeigt sie als eingebettete **OpenStreetMap-Karte mit Marker** (~600 m Ausschnitt). Darunter stehen Koordinaten, Alter des Fixes und ein Link „größer auf OpenStreetMap“. Die Zeile *Position* ist damit weg. Bewusst ohne Kartenbibliothek: ein `iframe` auf den OSM-Embed — kein API-Key, kein Tracker, kein zusätzliches Frontend-Bundle. Ohne Fix erscheint statt einer leeren Karte der Hinweis „Kein Standort bekannt“. Auf dem Telefon wird die Karte flacher (180 statt 240 px). ### 2. Restweite dynamisch — ja, aus dem eigenen Verbrauch Meldet das Fahrzeug kein `range_km` (cache_data führt die Spalte nicht), liefert `/vehicles/:id/latest` jetzt zusätzlich **`range_estimate`**. Statt eine Herstellerangabe fest zu verdrahten, wird der Verbrauch aus der **eigenen Fahrhistorie der letzten 30 Tage** gemessen: Kilometer je SoC-Prozentpunkt, mal aktueller SoC. Das passt sich Fahrprofil, Jahreszeit und Batteriealterung von selbst an. Live an Fahrzeug 1 (SoC 60 %, kein `range_km`): ```json "range_estimate": { "value": 276, "kmPerSoc": 4.6, "km": 59.8, "socUsed": 13, "segments": 4, "fromTs": "2026-08-17T06:59:51.000Z", "toTs": "2026-08-19T07:19:33.000Z" } ``` 4,6 km/% ≈ 21 kWh/100 km — für den U5 plausibel. Im Dashboard steht das als `ca. 276 km (geschätzt aus 4.6 km/% · 59.8 km Fahrt, SoC von vor 8 d)`. **Was nicht mitzählt** (sonst lügt die Zahl): - Ladevorgänge — SoC steigt, kein Verbrauch. - Standzeiten ohne Wegstrecke — Vampirverbrauch ist pro Zeit, nicht pro km; er würde die Reichweite künstlich drücken. - Datenlücken > 6 h und unplausible Raten (< 0,2 / > 12 km je Prozent), z. B. nach Odometer-Sprüngen. - **Segmente über Quellengrenzen**: `.inx` und `cache_data` melden für denselben Wagen Odometerstände, die ~1800 km auseinanderliegen. Jede Quelle wird deshalb eigen verkettet — sonst misst man den Versatz statt den Verbrauch. Reicht die Basis nicht (< 3 Segmente oder < 5 % SoC-Hub), gibt es **bewusst keine Zahl** statt einer geratenen. Die Schätzung steht in einem eigenen Feld und ist im Dashboard mit „ca.“ plus Datenbasis markiert — sie darf sich nicht als Messwert ausgeben. ### Annahmen (Blocker-Policy: proceed-with-default) - **30-Tage-Fenster, stündlich verdichtet**: die Telemetrie kommt im 10-s-Takt, das wären ~260.000 Zeilen für eine Zahl. Je Stunde und Quelle der letzte Record → höchstens ~720 Zeilen, für eine Verbrauchsrechnung fein genug. Die zweite Abfrage läuft nur, wenn `range_km` wirklich fehlt. - **OSM-Embed statt Leaflet/Tiles vom eigenen Server**: kleinster Eingriff. Wenn dir der externe iframe nicht passt (Datenschutz/offline), sag Bescheid — dann kommt eine selbst gehostete Variante. Selbsttests für beides laufen in CI: Bounding-Box-Mathematik und Kartenaufbau (`routes/selftest.ts`), Schätzlogik inkl. Laden/Stehen/Lücken/Quellentrennung (`vehicles/rangeSelftest.ts`).

claudecode added

needs-review

and removed

in-progress

labels

2026-08-27 23:21:01 +02:00