Mercedes probably changed field names

[LeonSol]

Describe the bug

After having some connection problems with Mercedes Api the connection can be established again but some field names might have been changed as @ReneNulschDE mentioned here #32071 (comment).

Problem: no odometer value transmitted and the car is not recognized by evcc anymore when plugged in.

Steps to reproduce

1.Odometer missing: check configuration details
2.plugin Mercedes
3.not recognized by evcc
...

Configuration details

vehicles:
- name: Luke
  type: template
  template: mercedes
  title: Luke
  capacity: 66
  user: roland@schiefke.de
  region: EMEA
  accessToken: my_access-token
  refreshToken: my_refresh-token
  vin: my_vin
  icon: car
  phases: 3
  mode: pv
  minCurrent: 6
  maxCurrent: 16
  cache: 15m

Log details

[lp-1  ] DEBUG 2026/07/23 11:34:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:34:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:34:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:34:53 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:34:53 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:34:53 charger status: A
[lp-1  ] DEBUG 2026/07/23 11:35:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:35:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:35:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:35:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:35:33 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:35:33 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:35:33 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:35:33 charge start energy: 2028.591kWh
[lp-1  ] INFO 2026/07/23 11:35:33 car connected
[lp-1  ] DEBUG 2026/07/23 11:35:33 vehicle api cache reset
[lp-1  ] DEBUG 2026/07/23 11:35:33 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:35:34 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:35:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:35:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:36:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:36:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:36:13 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:36:13 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:36:13 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:36:14 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:36:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:36:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:36:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:36:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:36:53 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:36:53 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:36:53 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:36:53 vehicle api cache reset
[lp-1  ] DEBUG 2026/07/23 11:36:54 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:37:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:37:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:37:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:37:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:37:33 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:37:33 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:37:33 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:37:34 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:37:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:37:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:38:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:38:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:38:13 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:38:13 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:38:13 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:38:13 vehicle api cache reset
[lp-1  ] DEBUG 2026/07/23 11:38:14 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:38:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:38:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:38:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:38:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:38:53 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:38:53 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:38:53 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:38:53 vehicle api cache reset
[lp-1  ] DEBUG 2026/07/23 11:38:54 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:39:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:39:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:39:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:39:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:39:33 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:39:33 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:39:33 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:39:33 vehicle api cache reset
[lp-1  ] DEBUG 2026/07/23 11:39:34 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:39:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:39:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:40:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:40:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:40:13 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:40:13 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:40:13 charger status: B
[lp-1  ] DEBUG 2026/07/23 11:40:14 !! plan: plan time zero
[lp-1  ] DEBUG 2026/07/23 11:40:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:40:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:40:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:40:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:40:53 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:40:53 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:40:53 charger status: A
[lp-1  ] INFO 2026/07/23 11:40:53 car disconnected
[lp-1  ] DEBUG 2026/07/23 11:40:53 set battery boost: false
[lp-1  ] DEBUG 2026/07/23 11:40:53 set session soc limit: 0
[lp-1  ] DEBUG 2026/07/23 11:40:53 set session energy limit: 0
[lp-1  ] DEBUG 2026/07/23 11:41:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:41:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:41:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:41:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:41:33 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:41:33 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:41:33 charger status: A
[lp-1  ] DEBUG 2026/07/23 11:41:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:41:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:42:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:42:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:42:13 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:42:13 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:42:13 charger status: A
[lp-1  ] DEBUG 2026/07/23 11:42:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:42:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:42:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:42:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:42:53 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:42:53 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:42:53 charger status: A
[lp-1  ] DEBUG 2026/07/23 11:43:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:43:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:43:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:43:33 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:43:33 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:43:33 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:43:33 charger status: A
[lp-1  ] DEBUG 2026/07/23 11:43:53 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:43:53 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:44:13 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:44:13 charge currents: [0 0 0]A
[lp-1  ] DEBUG 2026/07/23 11:44:13 charge voltages: [0 0 0]V
[lp-1  ] DEBUG 2026/07/23 11:44:13 charge total import: 2028.591kWh
[lp-1  ] DEBUG 2026/07/23 11:44:13 charger status: A
[lp-1  ] DEBUG 2026/07/23 11:44:33 charge power: 0W
[lp-1  ] DEBUG 2026/07/23 11:44:33 charge currents: [0 0 0]A

What type of operating system or environment does evcc run on?

Linux

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

v0.312.1

[github-actions]

Confirmed root cause: Mercedes-Benz has changed the response of the vehicle attributes API (https://widget.<region>.mobilesdk.mercedes-benz.com/v1/vehicle/<vin>/vehicleattributes), which no longer includes the odo, chargingstatus and maxSoc attributes that evcc relies on — as also confirmed by @ReneNulschDE in #32071.

In vehicle/mercedes/api.go (Status()):

• Odometer is only set if the odo attribute is present (vehicle/mercedes/api.go:76-79); if it's missing, Odometer() in vehicle/mercedes/provider.go:40-43 returns 0.
• More importantly, when chargingstatus is missing, the code falls back to a hardcoded value of 3 (vehicle/mercedes/api.go:94-98), which MapChargeStatus (vehicle/mercedes/provider.go:119-127) maps to api.StatusA (disconnected). This means a plugged-in/charging Mercedes is now always reported as disconnected, matching the "car is not recognized when plugged in" symptom.

This is an upstream Mercedes API change, not a local configuration issue, and per the linked thread @ReneNulschDE (who maintains the Mercedes integration) has already confirmed the fields are gone server-side and indicated a rework is needed to source this data differently. This is not a small/obvious fix, so I'm not opening a PR for it — leaving it for @ReneNulschDE's ongoing work referenced in #32071.

🤖 Generated with Claude Code

[ReneNulschDE]

The GitHub-bot is right... let me analyze it...

[ReneNulschDE]

@andig : Kannst Du Dir das mal ansehen bevor ich anfange.

Plan: Mercedes-Integration auf Websocket-Push (VSU) + Username/Passwort-Auth umstellen

1. Motivation

Der aktuell genutzte Widget-REST-Endpunkt (GET /v1/vehicle/<vin>/vehicleattributes)
liefert nicht mehr alle Fahrzeugwerte. Die Mercedes-App selbst bezieht Fahrzeugdaten
per Websocket-Push. Das Home-Assistant-Projekt mbapi2020 hat diese Logik produktiv
im Einsatz;

Zwei Grundsatzentscheidungen:

1. Nur der VSU-Pfad. Mit aktualisierten RIS-Headern liefert das Backend
   vehicle_status_updates (VSU, typisiert) statt der alten vepUpdates (String-Map).
   Wir implementieren ausschließlich VSU — RIS-Konstanten-Update und
   Websocket-Umstellung sind damit gekoppelt und landen im selben PR.
2. Username/Passwort-Auth statt Token-Konfiguration. Heute müssen Nutzer Access-
   und Refresh-Token extern beschaffen (Anleitung verweist auf das mbapi2020-Token-Tool).
   Wir implementieren den CIAM-Login-Flow direkt in evcc. Das entfernt die externe
   Abhängigkeit und ermöglicht automatisches Re-Login (u.a. nach HTTP 429).

2. Ist-Zustand

evcc (vehicle/mercedes):

• Polling über util.Cached → REST-Widget → VEPUpdate-Protobuf → StatusResponse (api.go)
• Auth: tokens (access/refresh) aus der YAML-Konfiguration; identity.go refresht nur
  (id.mercedes-benz.com/as/token.oauth2), Token-Persistenz in der Settings-DB;
  eine Identity-Instanz pro Account (helper.go)
• Go-Protos in vehicle/mercedes/pb von einem älteren Proto-Stand generiert:
  kein vehicle_status_updates (PushMessage-Feld 24), kein
  AcknowledgeVehicleStatusUpdates (ClientMessage-Feld 28)
• github.com/coder/websocket bereits direkte Abhängigkeit
  (Vorbilder: charger/warp-ws.go, meter/dsmr_ws.go); cenkalti/backoff vorhanden
• smart-eq nutzt denselben Codepfad (Registry-Alias in vehicle/mercedes.go)

Referenzen:

• Verbindungs-/Robustheitslogik: mbapi2020/custom_components/mbapi2020/websocket.py, client.py
• Login-Flow: mbapi2020/custom_components/mbapi2020/oauth.py (async_login_new)
• Proto-Quellen: MBSDK-CarKit-iOS/Proto/*.proto (proto3)

3. Zielbild

3.1 Auth (Username/Passwort, CIAM-Flow)

Konfiguration wechselt auf user/password (konsistent mit anderen
Fahrzeug-Integrationen). Login-Ablauf nach Vorbild async_login_new:

1. Session mit CIAM.DEVICE-Cookie (persistierte Device-GUID, Settings-DB)
2. Authorize-Request mit PKCE (S256) → resume-Parameter extrahieren
3. POST /ciam/auth/ua (User-Agent-Info)
4. POST /ciam/auth/login/user (E-Mail)
5. POST /ciam/auth/login/pass (Passwort + rid); ggf. disablePasskeyDemo,
   ggf. saveLoginConsent (Legal Texts)
6. Resume der Authorization → Auth-Code → Token-Exchange

Fehlerfälle: Konten mit aktivierter 2FA werden nicht unterstützt
(GOTO_LOGIN_OTP) → klare Fehlermeldung. Mobile-Safari-Header erforderlich.

Migration: bestehende, in der Settings-DB persistierte Tokens bleiben gültig und
werden weiter refresht; der Login-Flow greift erst, wenn kein gültiges Token
(mehr) vorhanden ist. Die tokens-Konfiguration wird als deprecated markiert und
in einem Folgerelease entfernt.

3.2 Websocket (nur VSU)

• Ein Websocket pro Account (nicht pro Fahrzeug), analog zur geteilten Identity.
  Endpunkt: wss://websocket.{emea|amap|cn}-prod.mobilesdk.mercedes-benz.com/v2/ws
• Header: Authorization = rohes Access-Token (ohne "Bearer"), OUTPUT-FORMAT: PROTO,
  APP-SESSION-ID/X-SessionId (stabile UUID pro Session), X-TrackingId (pro Connect neu),
  aktuelle RIS-Header (App 1.68.0 (3060), SDK 4.10.0, OS 26.3),
  regionsspezifischer User-Agent. Die RIS-Konstanten werden statisch gepflegt
  (kein dynamischer App-Versions-Lookup).
• Nachrichtenverarbeitung: Type-Switch auf *pb.PushMessage_VehicleStatusUpdates;
  pro VIN mergen, Ack per ClientMessage{AcknowledgeVehicleStatusUpdates{SequenceNumber}}
  (int64). Andere sequenznummerierte Pushtypen werden nur quittiert
  (kleine Ack-Tabelle), inhaltlich ignoriert — sonst stellt der Server sie erneut zu.
• Zustand: map[VIN]*pb.VehicleStatusUpdate unter Mutex.
  full_update == true ersetzt den Eintrag; Partial-Updates werden per
  protoreflect.Range feld-weise ersetzt (kein proto.Merge — das würde
  repeated-Felder wie charge_programs konkatenieren).
• Provider: liest ausschließlich den Websocket-Cache (Frische-Guard über das
  bestehende cache-Intervall). Der REST-Widget-Poll und die gesamte
  VEP-Dekodierung entfallen ersatzlos: Der Widget-Endpunkt liefert ohnehin
  unvollständige Daten, nach jedem Connect kommt ein Full-Update, und bei einer
  429-Sperre wäre der REST-Pfad ebenso blockiert. Bis zum ersten Full-Update
  liefert der Provider einen Fehler (Retry-Semantik). Der BFF-Endpunkt für die
  Fahrzeugliste (/v2/vehicles, JSON) bleibt unverändert.
• Robustheit (Erfahrungswerte aus mbapi2020, dort als 429-Schutz dokumentiert):
  • Nach Connect schickt der Server ein Full-Update → jeder Reconnect ist ein Poll-Äquivalent
  • Idle-Watchdog: 30 s ohne Nachricht → trennen; Reconnect nach 60 s (Duty-Cycle)
  • Ping ~30 s; exponentielles Backoff bei Verbindungsfehlern
  • Bei HTTP 429: begrenzte Re-Login-Versuche mit Username/Passwort
    (max. 3, wie mbapi2020), danach langes Backoff + REST-Fallback
• Lebenszyklus: prozesslange Goroutine pro Account (Vehicles haben kein Close();
  Muster bei Chargern etabliert)

4. Umsetzungsschritte (PR-Schnitte)

PR 1 — Protos neu generieren (keine Verhaltensänderung, unabhängig mergebar)

• Quellen: MBSDK-CarKit-iOS/Proto/*.proto
• Quellen haben kein option go_package → --go_opt=M<file>=…-Mappings, sodass die
  bestehende Struktur erhalten bleibt: Paket protos in pb/, protos.proto nach
  pb/protos/ → keine Import-Änderungen im übrigen Code
• gogo.proto (transitiv über vehicleapi.proto/vehicle-commands.proto) auf
  github.com/gogo/protobuf/gogoproto mappen; protoc-gen-go ignoriert die Optionen
• Ergebnis: vehicle-events.pb.go wächst deutlich (~250 typisierte Attribute)

PR 2 — Username/Passwort-Login (eigenständig nützlich)

• CIAM-Login-Flow in identity.go (Ablauf siehe 3.1), Device-GUID + Tokens in Settings-DB
• Template mercedes.yaml (und smart-eq): user/password statt
  accessToken/refreshToken; tokens deprecated, aber übergangsweise akzeptiert
• Klare Fehlermeldung bei 2FA-Konten

PR 3 — Mapping-Schicht (keine Verhaltensänderung)

• mapVSU(*pb.VehicleStatusUpdate) StatusResponse als neue, alleinige Mapping-Funktion
  (die bestehende VEP-Extraktion in api.go bleibt bis PR 4 unangetastet und wird
  dort mitsamt REST-Widget-Pfad entfernt):

  StatusResponse	VSU-Feld	Typ / Feld-Nr.
  Soc	soc	Int64RatioAttribute, 196
  Range	rangeelectric	Int64DistanceAttribute, 183
  Odometer	odo	Int64DistanceAttribute, 147
  EndOfChargeTime	endofchargetime	Int64ClockHourAttribute, 96
  ChargingStatus	chargingstatus	EnumAttribute, 50
  SelectedChargeProgram	selected_charge_program	EnumAttribute, 190
  SocLimit	max_soc / charge_programs	Int64RatioAttribute 138 / Array 27
  Preconditioning	precond_active	BoolAttribute, 167 (precond_now ist jetzt Enum!)
  Position	position_lat/position_long	DoubleAttribute, 165/166

• Unit-Tests mit aufgezeichneten Binär-Frames

PR 4 — Websocket-Client + Umstellung (die eigentliche Änderung)

• vehicle/mercedes/websocket.go: Verbindungs-Manager pro Account (Registry analog
  helper.go), Read-Loop, VSU-Verarbeitung, Acks, Merge, Duty-Cycle, Backoff,
  429-Re-Login über den Flow aus PR 2
• RIS-Konstanten aktualisieren (zwingend im selben PR — erst die neuen Header
  schalten das Backend auf VSU um)
• provider.go: liest den Websocket-Cache; cache wird zum Frische-Schwellwert
• REST-Widget-Pfad (Status() in api.go) und VEP-Extraktion ersatzlos entfernen;
  Vehicles() (BFF, JSON) bleibt

Später/optional

• Position() aus dem VSU-Strom bedienen

5. Offene Fragen / Entscheidungen fürs Core-Team

1. Manager-Lebenszyklus: Der Verbindungs-Manager (eine Goroutine pro Account)
   öffnet und schließt die Websocket-Verbindung im Duty-Cycle selbst — das ist
   nicht die Frage. Die Frage ist das Lebensende des Managers: api.Vehicle hat
   kein Close(), d.h. wird ein Fahrzeug zur Laufzeit gelöscht, läuft der
   Account-Manager bis zum Prozess-Neustart weiter (durch die Account-Registry
   maximal einer pro Account; Umkonfigurieren erzeugt keine Duplikate).
   Akzeptabel wie bei den Websocket-Chargern, oder Referenzzählung mit
   Abschaltung gewünscht?
2. Generierter Code: vehicle-events.pb.go wird groß (~250 Attribute). Committen wie bisher?
3. Duty-Cycle-Werte (30 s Idle / 60 s Reconnect) aus mbapi2020 übernehmen oder ans
   cache-Intervall koppeln? - Erfordert Test über mehrere Tage um die optimalen Werte zu finden.
4. Token-Migration: Übergangsfrist für die deprecated tokens-Konfiguration —
   ein Release oder länger?
5. 2FA: Konten mit aktivierter 2FA können nicht unterstützt werden —
   dokumentieren als bekannte Einschränkung?
6. smart-eq: Der Registry Eintrag in der mercedes.go ist eine Leiche von Anfang 2025. Kann das bereinigt werden?

6. Risiken

• Inoffizielle API: Mercedes kann Login-Flow, Header-Anforderungen und Protokoll
  jederzeit ändern (gilt heute schon für den REST-Pfad). Der CIAM-Login ist der
  fragilste Teil (Passkey-Prompts, Legal-Consent-Zwischenschritte) — mbapi2020
  dient als laufend gepflegte Referenz.
• Falsche Verbindungs-Kadenz kann zu 429-Kontosperren führen → Duty-Cycle und
  Backoff strikt an mbapi2020 orientieren; Re-Login-Versuche hart begrenzen.
• Kein REST-Fallback mehr: Ist der Websocket länger gestört, liefert das Fahrzeug
  keine Daten (Provider-Fehler). Bewusst akzeptiert — der Widget-Endpunkt wäre
  in diesen Fällen ebenfalls unvollständig bzw. mitgesperrt.
• Ack-Pflicht: fehlende Acks führen zu Redelivery/Disconnects → Acks gehören in den
  Read-Loop mit Fehlerbehandlung.
• Passwort steht in der evcc-Konfiguration (wie bei anderen Fahrzeug-Integrationen üblich).

7. Test & Validierung

• Unit: Mapping + Merge gegen aufgezeichnete VSU-Frames (Capture über lokalen Binary-Dump);
  Login-Flow gegen aufgezeichnete CIAM-Responses (httptest)
• Manuell: realer EMEA-Account — Erst-Login, Token-Refresh, Ladesession
  (Soc/Range/Status/Limit), Langzeitlauf, 429-Verhalten
• Rollout über Nightly

[andig]

Klingt grausam. Ich kann mich dunkel erinnern, dass Mercedes eine offizielle API hat(te). Warum können wir die nicht nutzen oder- alternativ- das EUDA Angebot? Falls es keins gibt wäre das über BNetzA-Beschwerde zu erzwingen...

[ReneNulschDE]

Es gibt keine offizielle API für Privatpersonen. EUDA liefert nur eine Maschine-lesbare Datei aber keine API zum Abruf. Bei Netz-Beschwerde bin ich raus. Wie bereits in meinem Repo diskutiert, das EU-Gesetz ist einfach ungenau meiner Meinung nach.

Wenn es zu grausam ist, dann bin ich raus. Es gibt keine andere Möglichkeit meines Wissens nach. Dann solltet Ihr MB entfernen und auf Home-Assistant, Openhab oder all die anderen Integrationen verweisen.

[andig]

EUDA liefert nur eine Maschine-lesbare Datei aber keine API zum Abruf.

Das ist natürlich Mist, aber bei VW bleibt uns auch nix anderes. Können wir die anbinden? Wenigstens gibts da einen verlässlichen Kontrakt.

Dann solltet Ihr MB entfernen und auf Home-Assistant, Openhab oder all die anderen Integrationen verweisen.

Das ist (leider) eine echte Option. Deine Arbeit ist unglaublich wertvoll, aber willst Du Dir das wirklich langfristig ans Bein binden? Den Anwendern kann man leider nur sagen: Finger weg von Mercedes. Kauft Euch einen BMW (und demnächst auch wieder Skoda)...

[LeonSol]

Immerhin wird der SOC (und die Reichweite) ja noch über die bisherige Integration übertragen. Muss man halt die Fahrzeugauswahl manuell vornehmen wie auch bei VW und wenn man will, den Kilometerstand hinterher manuell nachtragen. Ist nicht schön, aber immer noch besser als bei VW, wo der SOC beim Anstecken nicht sofort verfügbar ist.

[LeonSol]

Man kann sich mit seinem MB-Login auch auf der Developer-Seite anmelden und dort ein Paket kaufen, welches alle benötigten Daten bereit stellt:

Ich kenne den Prozess nicht, aber vielleicht ist über diesen (kostenpflichtigen) Weg die vollumfängliche Integration eines Mercedes mit den hier vorhandenen Mitteln möglich?

[ReneNulschDE]

Du benötigst aber eine Ust-Id und den Nachweis, dass Du ein Geschäftskunde bist...

[LeonSol]

Ich habe jetzt einmal den Datenabruf nach EU Data-Act gemacht. Erste Beobachtung: dies sind fast Echtzeitdaten, also ohne zeitliche Verzögerung. Ich sehe als Laie jedoch Schwierigkeiten, automatisiert an diese Daten zu kommen. Hier einmal die Beschreibung, wie man an den download der zip-Datei kommt:

1. Mercedes-Me Benutzerkonto anlegen und das Fahrzeug hinterlegen.
2. Login to https://id.mercedes-benz.com/ciam/auth/login (haut nicht immer hin, kann aber auch an meinem cache liegen)
   Erfahrung: es geht auch über https://www.mercedes-benz.de/passengercars/my-area/my-settings.html#/privacy
   Dies führt direkt zur Eingabe der eMailadresse
   Dann weiter drücken und Passwort eingeben und wieder weiter drücken
3. Klicke auf deinen Namen in der rechten, oberen Ecke
4. aus dem dropdown-Menü selektiere "Datenschutz & Rechtliches"
5. scrolle nach unten und selektiere "Datenzugriff EU-Datenverordnung"
6. setze einen Haken bei "Ich akzeptiere die Vereinbarung über den Datenzugang..." - ja, muss jedes Mal selektiert werden
7. Man kann einen Haken bei "Metadaten" setzen, dann erhalten die json-Datenpunkte jeweils eine ausführliche Beschreibung
8. Drücke "Download starten"
9. Die zip-Datei wird herunter geladen

Ich habe das Fahrzeug angestöpselt und bin zum Computer zurück, Daten abgerufen und diese haben bereits den Kontakt mit der Wallbox ausgespuckt. Dies funktioniert also deutlich besser als bei VW.

Ist somit vielleicht eine Integration über diesen Weg möglich?

[andig]

Da hat Mercedes doch direkt versucht, es kompliziert zu machen. Genauso mies wie VW. Kein Lerneffekt in der Industrie. Wie dem auch sei- das lässt sich mit Zugangsdaten automatisieren und einbauen solange es kein captcha gibt.

[LeonSol]

In meinem Anmeldeprozess wurde nirgendwo ein captcha gefordert.