Workaround: read VW-Group car data via Home Assistant while the dsg / EU Data Act template returns HTTP 500

[whentotrade]

Sharing a workaround in case it helps others. The few evcc config lines below makes my EVCC working again, utilizing HA solutions which still provide car data more reliable than the EVCC dsg integration. Like several people here, my Audi stopped reporting data after the switch to the drivesomethinggreater (EU Data Act) template. evcc logs a steady stream of:

[dsg] ERROR ... unexpected status: 500 (Internal Server Error) GET https://eu-data-act.drivesomethinggreater.com/.../list

The portal-side 500 seems to be outside evcc's control, so here's an approach that's been rock-solid for me while the dsg path gets sorted out.

Idea

If you already run Home Assistant, the community HA integrations for VW-Group cars (e.g. vwgroup-connect) still authenticate and deliver live car data. So instead of evcc talking to the portal directly, we let HA own all the VW-Group auth/maintenance (device-grant login, token refresh, the rotating x-qmauth header, future API changes) and have evcc simply read HA's sensor states via the REST API.

It's a drop-in replacement for the affected vehicle in evcc.yaml — no rebuild, fully reversible.

Requirements

• A working Home Assistant / HACS instance with your car's sensors available (SoC, range, charging state).
• A HA long-lived access token (HA → your profile → Security → Long-lived access tokens → Create Token).
• Your car's entity IDs (see below).

Finding your entity IDs

1. In Home Assistant, open Developer Tools → States (or Settings → Devices & Services → your car device → Entities).
2. In the filter box, type part of your car's name (e.g. audi, or your model).
3. Look for these three and copy their entity_id:
   • State of charge — a sensor with unit % / device class battery, e.g. sensor.audi_q6_suv_e_tron_state_of_charge
   • Range — unit km, e.g. sensor.audi_q6_suv_e_tron_range
   • Charging state — text values like charging / off / readyForCharging, e.g. sensor.audi_q6_suv_e_tron_charging_state
4. (Optional sanity check) confirm an entity is reachable from the machine running evcc before editing the config:

   curl -s -H "Authorization: Bearer <LONG_LIVED_TOKEN>" \
     <HA_URL>/api/states/sensor.<your_car>_state_of_charge

   You should get JSON back with a "state": "86" field.

Drop-in vehicle config

Replace your broken vehicle entry under vehicles: with this, then systemctl restart evcc. Swap in your own <HA_URL>, <LONG_LIVED_TOKEN>, and entity IDs:

vehicles:
  - name: car
    type: custom
    title: My Car
    capacity: 100          # usable battery kWh

    soc:
      source: http
      uri: <HA_URL>/api/states/sensor.<your_car>_state_of_charge
      headers:
        Authorization: Bearer <LONG_LIVED_TOKEN>
      jq: ".state | tonumber"

    range:
      source: http
      uri: <HA_URL>/api/states/sensor.<your_car>_range
      headers:
        Authorization: Bearer <LONG_LIVED_TOKEN>
      jq: ".state | tonumber"

    # Optional: A=unplugged / B=plugged / C=charging.
    # If you have a smart wallbox it already reports this to the loadpoint,
    # so this is supplementary.
    status:
      source: http
      uri: <HA_URL>/api/states/sensor.<your_car>_charging_state
      headers:
        Authorization: Bearer <LONG_LIVED_TOKEN>
      jq: '.state | if . == "charging" then "C" elif . == "off" then "A" else "B" end'

Notes

• Works for any HA-exposed vehicle, not just Audi — VW, Škoda, Seat, Cupra, and others all follow the same pattern; just point at the matching entity IDs.
• The status mapping depends on your integration's charging_state values — tweak the jq line if yours differ.
• The long-lived token sits in evcc.yaml in plain text (normal for evcc), and is revocable/rotatable anytime from HA.
• Re: the native type: homeassistant vehicle — I tried it first, but on evcc 0.308.x its auth has moved to an OAuth2/zeroconf pairing and the old token: field is ignored, so the REST-API approach above was the simpler, version-stable route for me. (Might be worth a docs note?)

Full write-up / config: https://gist.github.com/whentotrade/a08dfc672ea5c771476bd41da32d1da4

Happy to help document this for other HA users if that's useful.

[chnbr]

This can even be done simpler using the 'homeassistant' template:

vehicles:
- name: audi_ha
  type: template
  template: homeassistant
  uri: http://<HA-IP>:8123
  soc: sensor.audi_state_of_charge # replace by your HA SOC entity 
  title: Audi
  range: sensor.audi_secondary_engine_range # replace by your HA engine range entity
  capacity: 13           # whatever
  maxCurrent: 15.2       # whatever
  phases: 1              # whatever                  
  mode: pv               # whatever                                

Add this to evcc.yaml and restart evcc. Then go to evcc configuration page and grant evcc access to your HA. That's it.

[thomasscherm]

works.
great
5 min to configure for 2 cars.
Thank you!

[flautze]

Which integration are you using in HA? I am using Volkswagen Connect and get errors when signing in.

Edit: nevermind… https://github.com/its-me-prash/vwgroup-connect-ha

Edit2: I tried this integration with my VW id buzz, but getting no data. Connection seems ok. But note that currently I also have connected EVCC separately. So I assume this exceeds the interval formulates (15 minutes) and that is why there is no data…

[whentotrade]

I also had issues during times when I had different solutions in parallel (Tibber, 2 HA integrations and EVCC). Once I disabled and just kept one running (HA -> vwgroup-connect-ha), it seems working. Anyhow, I would propose follow the vwgroup-connect-ha repo, as it is maintained very well and receives regular updates day by day, so keeping your HACS integration up-to-date with the repo seems to be important.

[chnbr]

I use Audi Connect - Version 2.1.2

https://github.com/audiconnect/audi_connect_ha

[regda1986]

The workaround doesnt work. I still get an API Error and no useful entities: 2026-06-10 18:11:45.324 ERROR (MainThread) [custom_components.vag_connect.cariad.api.seat_cupra] OLA 403 persistent (5 consecutive) — flagging for HA Repair issue. Likely cause: OLA backend updated app-header requirements again. Check for integration update.

No more other integration like Pycupra or tibber is installed.