Integration von XPENG G6 / G9

[JHammerschmid]

Fahre derzeit Tesla M3, Easee Wallbox und bin mit EVCC super zufrieden.
Das nächste Auto könnte ein XPENG G6 werden.
Da XPENG als Fahrzeug in der Doku nicht aufgeführt wird stellt sich mir die Frage wie binde ich G6 in EVCC ein ?

[mfuchs1984]

Es gibt https://evlinkha.se/ womit sich Xpeng Fahrzeuge wohl mit Home Assistant verbinden lassen, dann könntest du das Auto als Home Assistant Vehicle in evcc einbinden.

[VolkerK62]

Bei XPENG nach dem Datenzugriff fragen.
#23684

[mfuchs1984]

Könntest du übrigens vermutlich auch ohne Home Assistant machen, in evcc direkt auf die die ABRP API gehen, hast du das mal probiert? Welche Datenpunkte liefert die API noch?

[mfuchs1984]

Custom-Fahrzeuge werden nicht automatisch erkannt

Das stimmt so nicht. Voraussetzung für eine automatische Erkennung ist die Implementierung von status, du hast halt nur soc implementiert.
https://docs.evcc.io/de/user-defined-devices/#lese-attribute-2

[afuxi]

Claude meint dazu:

Ja, guter Punkt — das geht auch komplett ohne Home Assistant. Der EVCC-custom-Block zeigt dann einfach direkt auf die Iternio-URL statt auf einen HA-Sensor:

  soc:
    source: http
    uri: https://api.iternio.com/1/tlm/get_telemetry?token=<TELEMETRY_TOKEN>
    method: GET
    headers:
      Authorization: APIKEY <API_KEY>
    jq: .result.telemetry.soc
    cache: 5m

Ehrlich gesagt hab ich den direkten Weg (noch) nicht produktiv laufen — ich bin bewusst über HA gegangen, weil ich den SOC dort ohnehin fürs Dashboard/für Automationen wollte und HA eine leere API-Antwort abfängt. Für reine EVCC-Nutzung ist der direkte Weg aber schlanker. Die API selbst liefert die Daten jedenfalls direkt (gerade getestet).

Was get_telemetry liefert (result.telemetry – hängt von Fahrzeug/Zustand ab; bei mir parkt der Wagen gerade):

• soc (%) ← das Relevante für EVCC
• is_charging (true/false)
• lat / lon (Position)
• calib_ref_cons (ABRP-interner Referenzverbrauch)

Auf result-Ebene außerdem: timestamp (Frische), is_connected, vehicle_id, typecode, name. Im Fahr-/Ladebetrieb kommen je nach Enode/Fahrzeug noch weitere Felder dazu. is_charging ließe sich in EVCC bei Bedarf auch als Status-Quelle nutzen.

[afuxi]

Custom-Fahrzeuge werden nicht automatisch erkannt
Das stimmt so nicht. Voraussetzung für eine automatische Erkennung ist die Implementierung von status, du hast halt nur soc implementiert.
https://docs.evcc.io/de/user-defined-devices/#lese-attribute-2

Claude/Opus4.8 dankt (Als Opa, 74, habe ich selbst nur noch eine blasse Ahnung worüber Ihr hier redet.):

Danke, wieder berechtigt — das war zu absolut. Ich hatte im custom-Vehicle nur soc; für die automatische Erkennung fehlt das status-Attribut (A/B/C = getrennt/verbunden/lädt). Mit status erkennt EVCC das Fahrzeug selbst — „wird nicht erkannt" stimmt so also nicht, danke für den Doku-Link.

Ehrliche Einschränkung für genau diesen ABRP-Weg: Der Status ließe sich nur aus is_charging/is_connected der Cloud ableiten — der ist aber nicht wallbox-spezifisch (ABRP weiß nicht, ob das Auto an meiner Wallbox hängt) und beim Parken nur stündlich aktuell. Für eine einzelne Wallbox vermutlich brauchbar, für Multi-Wallbox eher wackelig. Ich passe die Anleitung entsprechend an.

[afuxi]

Korregierte Fassung:

XPeng G6 – Ladestand (SOC) in Home Assistant holen & für EVCC-PV-Überschussladen nutzen

Der XPeng G6 hat (Stand 08/2026) keine nutzbare Hersteller-API für den Ladestand.
Dieser Weg holt den SOC ohne HACS/Add-on – nur mit Bordmitteln – über ABRP in Home
Assistant und stellt ihn EVCC als Fahrzeug-Ladestand bereit (für PV-Überschussladen).

Datenfluss

XPeng-Cloud → Enode → ABRP (A Better Routeplanner) → Iternio Telemetry-API
           → HA REST-Sensor  →  EVCC (vehicle type: custom)

Voraussetzungen

• ABRP mit eingerichteter Enode-Fahrzeugverbindung (XPeng verknüpft, ABRP zeigt den SOC).
  Enode ist ABRPs Anbindung an die XPeng-Cloud. (ABRP Premium.)
• In ABRP zusätzlich einen Telemetry-Token und einen eigenen API-Key erzeugen
  (Fahrzeug-Einstellungen → „Generic"/Live-Data → Send/Read telemetry).
• Laufendes Home Assistant und EVCC.

⚠️ Die Enode-Verbindung in ABRP nicht trennen – sie liefert den SOC. Der Token wird
nur zusätzlich erzeugt, damit man den vorhandenen Wert über die Telemetry-API lesen kann.

Schritt 1 – Werte kurz testen (optional)

curl -s "https://api.iternio.com/1/tlm/get_telemetry?token=<DEIN_TELEMETRY_TOKEN>" \
  -H "Authorization: APIKEY <DEIN_API_KEY>"

Die Antwort enthält u. a. result.telemetry.soc (%), is_charging und result.timestamp.

Schritt 2 – REST-Sensor in Home Assistant

In configuration.yaml (Token/Key gehören eigentlich in secrets.yaml):

rest:
  - resource: "https://api.iternio.com/1/tlm/get_telemetry?token=<DEIN_TELEMETRY_TOKEN>"
    scan_interval: 300          # alle 5 Min – Enode aktualisiert ohnehin nur grob
    timeout: 20
    headers:
      Authorization: "APIKEY <DEIN_API_KEY>"
    sensor:
      - name: "XPeng G6 Ladestand"
        unique_id: xpeng_g6_soc
        value_template: >-
          {{ (value_json.result.telemetry.soc | round(0))
             if (value_json is defined and value_json.result is defined
                  and value_json.result.telemetry is defined
                  and value_json.result.telemetry.soc is defined) else none }}
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement
        json_attributes_path: "$.result.telemetry"
        json_attributes:
          - is_charging

YAML neu laden (bzw. HA neu starten). Ergebnis: sensor.xpeng_g6_ladestand (%) mit
Attribut is_charging. Der defensive value_template liefert bei einer leeren API-Antwort
none statt einer Fehlermeldung.

Schritt 3 – EVCC-Fahrzeug als type: custom

In evcc.yaml unter vehicles::

- name: XPENG
  title: XPENG G6
  type: custom
  icon: car
  capacity: 87.5
  phases: 3
  soc:
    source: http
    uri: http://<HA-IP>:8123/api/states/sensor.xpeng_g6_ladestand
    method: GET
    headers:
      Authorization: Bearer <DEIN_HA_LONG_LIVED_TOKEN>
    jq: ".state | tonumber"
    cache: 5m
    timeout: 10s
  onIdentify:                 # Lade-Voreinstellungen, sobald EVCC den XPeng erkennt
    mode: pv                  # PV-Überschussladen
    minCurrent: 6
    maxCurrent: 16
    priority: 3

⚠️ Stolperfallen (haben Zeit gekostet)

1. mode, minCurrent, maxCurrent, priority gehören in den onIdentify:-Block (siehe oben) –
   nicht direkt auf die Fahrzeug-Ebene. Direkt oben stehend → FATAL beim Start:
   invalid keys: mincurrent, mode, priority; MaxCurrent expected a map.
   (Danke an die EVCC-Community für die Korrektur – die Parameter sind also erlaubt, nur an der richtigen Stelle.)
2. evcc checkconfig erkennt diesen Fehler NICHT – es meldet fälschlich „config valid".
   Deshalb nach jeder Änderung neu starten und ins Log schauen:

   sudo systemctl restart evcc
   journalctl -u evcc -n 50 --no-pager | grep -i fatal

3. Automatische Erkennung braucht ein status-Attribut (A/B/C = getrennt / verbunden / lädt).
   Mit nur soc (wie oben) ordnet EVCC das Fahrzeug nicht selbst zu → am Ladepunkt manuell
   auswählen. Mit zusätzlichem status klappt die Auto-Erkennung (s. EVCC-Doku „Lese-Attribute").
   Bei Cloud-Quellen wie ABRP ist dieser Status aber nicht wallbox-spezifisch und verzögert –
   für eine einzelne Wallbox meist trotzdem brauchbar.
4. Der SOC taucht in /api/state erst auf, wenn der XPeng am Ladepunkt verbunden/aktiv ist.

Grenzen

• Aktualität hängt an Enode/XPeng: parkend nur stundenweise, beim Laden häufiger –
  für PV-Überschussladen in der Praxis ausreichend.
• Rein Bordmittel: kein HACS, kein Add-on – nur HA-REST-Sensor + EVCC-custom-Fahrzeug.

---

Getestet mit EVCC 0.313.1 und einem XPeng G6 (87,5 kWh), Live-SOC verifiziert.
Alle Tokens/IPs sind Platzhalter – bitte durch eigene Werte ersetzen.

[G9PGIT]

Ich habe auch einen XPeng und möchte gern evcc nutzen. SMA Homemanager 2.0 und Easee Wallbox gehen wohl. Aber XPeng noch nicht…. Oder gibt es was neues?

[afuxi]

Also am besten zuerst einmal über die App bei Xpeng G6 bezüglich der APi Anfragen. (Siehe oben)

Bis dahin kann man die erforderliche Lade Menge abschätzen und entsprechend in der Lade Planung hinterlegen.

[beforesun-set]

ich habe XPENG heute unter data-privacy@xiaopeng.com aufgefordert mir die Echtzeit Daten zur Verfügung zu stellen. Kurze Zeit später kam die folgende Standardantwort:

**Thank you for your request for access to vehicle data pursuant to the EU Data Act.

Please be informed that a direct, real-time API mechanism is currently under development and is expected to be available in the coming months. However, to ensure your right of access is fulfilled, we can provide you a copy of telematic data in encrypted Excel file. If you want to proceed with this request, please kindly provide:

• Vehicle Identification Number (VIN)
• XPeng APP registration email address

Once we receive this information, we will begin processing your request and will inform you of the next steps.**

[afuxi]

Na, dann besteht ja eventuell Hoffnung. Danke für die Information.

[G9PGIT]

Danke für die Info. Ich meine, die Antwort gab es vor ein paar Monaten schon einmal mit gleichem Wortlaut 😉. Aber nun ja…. Ist immer noch richtig😉 Am 20.07.2026 um 17:48 schrieb afuxi ***@***.***>:  Na, dann besteht ja eventuell Hoffnung. Danke für die Information. — Reply to this email directly, view it on GitHub<#25819?email_source=notifications&email_token=B4RRJYG7GCWGBBK4QNN7WPL5FY5LVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGAZTONRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17703767>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B4RRJYH2QUWGNYHENS5UD3D5FY5LVAVCNFSNUABHKJSXA33TNF2G64TZHMZDENRTGY4DGMZYHNCGS43DOVZXG2LPNY5TSMRQHEZTQNNBOYBA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/B4RRJYAZBS337GVG5N42SID5FY5LVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGAZTONRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android<https://github.com/notifications/mobile/android/B4RRJYCOMTSRKKAEIFI6UCL5FY5LVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGAZTONRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[Funkymaddox]

Auch bei uns könnte sich ein XPeng anbahnen. Aktuell Tesla MY, was umständlich aber gut eingebunden werden kann, und ein VW ID3 ... und nach dem Drama mit dem VW ist das nicht vorhanden sein einer XPeng API schon fast ein Grund doch keinen zu beschaffen :/

Nur fürs verständnis, wenn ich nun einen G6 an eine Wallbox hänge, dann erkennt er den Ladestand nicht, ich kann aber auf PV stellen und er lädt bis er voll ist (Was ich erkenne, wenn nicht weiter geladen wird in EVCC). Ladeplanung ala "morgen um 0600 benötige ich 70% im Akku" gehen nicht, aber lade bis morgen 40kWh, oder?
Hatte noch nie ein Kfz in EVCC, dass keinerlei Daten gesendet hat. Die aktuellste Mailantwort hier im Topic lässt zwar hoffen, aber never buy a promise!

[mfuchs1984]

Ja

[ChristophWeigert]

Was nach wie vor klappt, via https://www.evconduit.com/ -> Home Assitant > evcc den Akku Stand. Allerdings ist wohl der Zugang über enode aktuell voll. Wie das mit dem ABRP Weg aussieht kann ich dir jedoch nicht sagen.
Was auch eine (teure) Möglichkeit wäre z.B. die Tinkerforge WARP 4 Pro, hier (sollte) sich der SoC direkt auslesen lassen. Ich hab leider noch eine 3 und noch keinen akuten Drang hier das Upgrade Kit zu kaufen.