Beta - VW Group EU Data Act – vehicle data for VW, Audi, Škoda, SEAT, Cupra & Bentley (official portal)

[TommiG1 (Thomas Graf)]

[Beta] VW Group EU Data Act – vehicle data for VW, Audi, Škoda, SEAT, Cupra & Bentley (official portal)

Hi everyone,

After Volkswagen/Cupra restricted unofficial third-party access to the WeConnect/OLA API, vehicle owners in the EU have an official path through the EU Data Act portal:

👉 https://eu-data-act.drivesomethinggreater.com/

I built a Home Assistant custom integration that reads your vehicle data from that portal — read-only, legal, and without unofficial APIs.

GitHub: https://github.com/TommiG1/HA_VAG-EU-Data-Act

---

What it does

• Sign in with your brand credentials (VW ID, myAudi, Cupra ID, etc.)
• Supported brands: Volkswagen, VW Commercial Vehicles, Audi, Škoda, SEAT, Cupra, Bentley
• Sensors for SoC, range, odometer, charging state, lock status, and more
• Optional diagnostic sensors from the official VW data dictionary
• Adaptive polling aligned with ~15-minute portal delivery

What it does not do

• No vehicle control (climate, start/stop charging, etc.)
• No real-time data — typically ~15 minutes latency
• Not a replacement for cupra_we_connect or legacy WeConnect integrations with command support

---

Prerequisites (important)

The integration only downloads datasets you have already requested on the portal:

1. Log in on the portal and link your vehicle
2. Under Data clusters → Vehicle overview, create a continuous data request with a 15-minute interval
3. Wait until real ZIP files appear (sometimes only _no_content_found — normal if the car had no telemetry in that window)

In Home Assistant: pick the correct brand — VW credentials will not work with the Cupra brand (and vice versa).

---

Installation (HACS)

1. HACS → ⋮ → Custom repositories
2. Add https://github.com/TommiG1/HA_VAG-EU-Data-Act (type: Integration)
3. Install VW Group EU Data Act → restart Home Assistant
4. Settings → Devices & Services → Add Integration

Requires Home Assistant 2024.12.0 or newer.

---

Beta — looking for testers

The integration is working (login, vehicle list, dataset download), but I need community feedback — especially from different brands and models.

Brand	Testers needed
Volkswagen	yes
Audi	yes
Škoda	yes
SEAT	yes
Cupra	early testing in progress
Bentley	yes
VW Commercial Vehicles	yes

Optional smoke test before HA (no Home Assistant required):

git clone https://github.com/TommiG1/HA_VAG-EU-Data-Act.git
cd HA_VAG-EU-Data-Act
python3 -m venv .venv && .venv/bin/pip install aiohttp
.venv/bin/python tools/test_login.py --brand audi [email protected] 'your-password'

Exit code	Meaning
0	OK — real vehicle data downloaded
2	Login OK, portal not delivering real data yet (common at first)
1	Error — check brand and credentials

Please report via GitHub Issues with:

• Brand & model (no VIN needed)
• test_login.py exit code (redact your email)
• Whether the portal delivers real ZIPs or only _no_content_found
• Home Assistant version

👉 https://github.com/TommiG1/HA_VAG-EU-Data-Act/issues

---

Background / license

This integration uses the official EU Data Act portal with your own account on your own Home Assistant instance. It does not use unofficial APIs.

Derived from hass-vw-eu-data-act (MIT), extended with multi-brand OIDC. License: MIT.

---

If this integration helps you and you’d like to support development, optional donation via PayPal:
https://www.paypal.com/paypalme/tommigraf

Thanks for testing and for any feedback!
Tommi

[cameron]

Thank you for your integration.

I have a VW Golf 8 and it’s working so far. 77 entities but lots of them not used. Only one I would have liked would be the position sensor.

[suchtak22]

Thank you.

Did i miss something? I have only 7 entities in VW Group integration. I have an ID.3 VW

[TommiG1 (Thomas Graf)]

Hi @suchtak22 — you didn’t miss a setup step in Home Assistant. 7 entities is normal right after adding the integration, before the first real vehicle dataset arrives from the portal.

Those 7 are the built-in diagnostic sensors (Integration status, Last connected, Dataset generated, Uncurated fields, etc.). All vehicle sensors (SoC, range, mileage, charging, …) are created automatically once the integration downloads the first ZIP with real data — no reload needed.

Please check:

1. Integration status sensor on the device — what does it show? (Waiting for data, Delivery not ready, Empty snapshots only, or OK?)
2. Settings → System → Repairs — the integration surfaces portal hints there too.
3. On eu-data-act.drivesomethinggreater.com:

• Vehicle linked under Data clusters → Vehicle overview
• Active continuous 15-minute data request
• Dataset = All Data (not only Charging — charging-only delivers far fewer fields)
• Brand in HA = Volkswagen (VW ID credentials)

4. Wake the car (drive, ignition, or open the VW app) so it can upload telemetry.
5. First real data often takes 15–60 minutes, sometimes a few hours after creating the portal request. Empty _no_content_found snapshots are normal and are skipped automatically.

Once status shows OK and Uncurated fields is > 0, you should see many more entities appear within one poll cycle. If status stays stuck for several hours, please share the Integration status value and whether Repairs shows a warning — happy to help debug.

[TommiG1 (Thomas Graf)]

Hi @cameron — glad the Golf 8 is working, thanks for testing.

Many entities: That’s expected. Besides the curated sensors (battery, range, charge state, mileage, …), the integration exposes every field from the portal ZIP as a diagnostic raw sensor (disabled by default). With a full All Data dataset that adds up quickly. You can disable or hide anything you don’t use under Settings → Devices & services → your vehicle → Entities — you don’t need all 77 on a dashboard.

Position / map sensor: Not available yet. The beta focused on the core vehicle data (SoC, range, charging, lock status, …). A device_tracker / map card is on the wishlist, but it depends on whether the EU Data Act portal actually delivers GPS coordinates in the dataset — that’s not clearly documented and I haven’t seen reliable lat/lon fields in test data so far. Also keep in mind: this integration is read-only with ~15 minute updates, so even with a location entity it would be “last known parking position”, not live tracking like the old WeConnect integrations.

If you’re curious: in Developer tools → States, search your vehicle entities for lat, lon, location, or gps. If you find coordinate fields in your 77 entities, please mention the entity names here (or open a GitHub issue) — that would help decide whether we can add a proper map entity in a future release.

Thanks again for the feedback.

[chrismrudge (Chris R)]

Hi,

I set this up last night on a Cupra Tavascan. I'm in the UK but still got data through successfully.

Haven't driven anywhere yet but was charging overnight so saw some data for that.

There's something odd going on with distance units. Mileage and range both say they're Km but it looks like range is actually in miles. Not sure if I can get them both in miles.

Charge power wasn't reporting correctly as it was full power charging but only reporting at around 3KW. I wonder if this is something to do with the 15 minute reporting and it's doing some sort of averaging over the 15 minute reporting period.... Although some of my Octopus charging slots were long enough that this shouldn't be an issue??

This is a great integration and looks like it has the potential to report most of what I need now the Cupra Weconnect will no longer work. I never used the control side, only the reporting.

Only other thing that would be useful (but recognise you can only report what is provided) is whether the car is switched on or not. I had an automation that calculated miles/KWh by detecting when it was started and stopped for each journey. Maybe I can just track changes in miles driven as the trigger instead.

[cameron]

Hi @TommiG1
Thanks for the suggestion.
I had a search for the position (lat,lon,location and gps) but no sensor from VW for that.

[TommiG1 (Thomas Graf)]

Hi @chrismrudge — great to hear the Tavascan is working from the UK, and thanks for the detailed feedback.

Distance units: The integration reads units from the portal (mileage.unit, range.unit) — it does not hardcode km for those sensors. There is one exception: if your Electric range comes from value_of_the_primary_range (some Cupra datasets use that instead of range.value), that sensor currently defaults to km even when the value is in miles. That sounds like what you’re seeing. Could you check which range entity you’re using (Developer tools → States)? If it’s …_value_of_the_primary_range, that’s a known gap I can fix by inheriting the unit from mileage.unit or range.unit. HA won’t convert km ↔ mi for you — it shows whatever unit the portal declares.

Charge power ~3 kW: The integration passes through battery_state_report.charge_power as reported in the ZIP (kW); we don’t average over 15 minutes ourselves. Low readings usually mean the snapshot caught a low-power moment (end of charge, tapering, reduced current on the charger, or between Octopus slots) — not that HA is averaging a full-power session down to 3 kW. Also make sure you’re looking at Charge power (kW), not Charge rate (mi/h or km/h — that’s range gained per hour, not electrical power). If you can share a reading from a known full-power window (e.g. steady 7 kW AC), I can compare with the raw portal field.

Car on/off: There’s no curated “ignition on” sensor yet. The portal does expose related raw fields such as vehicleIsStandingStill and update_reason (includes CLAMP_15_ON/OFF). They appear as disabled diagnostic entities — you can enable them under the device’s Entities. Tracking mileage changes for trip detection is a good workaround, with ~15 minute resolution. A proper ignition/clamp binary sensor is on my list if the Tavascan dataset includes those fields reliably.

Thanks again — this is exactly the kind of real-world feedback that helps polish the beta.

[TommiG1 (Thomas Graf)]

Hi @chrismrudge — quick follow-up on the distance units point from my earlier reply.

That gap is fixed in v0.6.14. The value_of_the_primary_range electric-range sensor no longer defaults to km — it now inherits the unit from the portal using the same fallback chain as the other distance sensors: range.unit → mileage.unit → battery_state_report.cruising_ranges.*.unit (then km if none of those are present).

After updating (HACS or manual copy from the release), reload the integration once (Settings → Devices & services → VW Group EU Data Act → Reload). Your range entity should then show mi if the portal declares MILES in one of those fields.

The charge power and car on/off points from my earlier message are unchanged — still happy to dig into those if you can share an example from a steady full-power charge window.

Thanks again for the Tavascan feedback — it directly led to this fix.

[chrismrudge (Chris R)]

@TommiG1 that's brilliant! Range and mileage now work correctly in miles once I'd updated the units on the entity in HA with v0.6.14. Mileage was actually OK in v0.6.12, as you suspected, once I'd fixed the units.

The charging power is an odd one. I've just pulled down the json data file from the VW EU data portal and can see there are two entries for this in the file:

      "key": "c8cb205f-01c6-3c81-bda1-059b99ae6515",
      "dataFieldName": "battery_state_report.charge_power",
      "value": "6.0"
    }

and also

    {
      "key": "8087d3b7-03bd-350a-95ef-bd8cb3ba20fa",
      "dataFieldName": "battery_state_report.charge_power",
      "value": "0.0"
    }

and then I'm getting the charging power reported in HA as 3KW - maybe it's coincidence that it's the average of the two. The first value of 6.0 is almost certainly the correct one.

I'm wondering if this is deliberate double reporting of the value as it also has:

    {
      "key": "25096bfe-96e0-3bcc-8c78-5ed5b72d5399",
      "dataFieldName": "update_reason",
      "value": "UPDATE_REASON_CHARGING"
    }

and then there are multiple timestamps separated by 1 minute each. My car did start charging at this point (Octopus Intelligent controlled) so the 0KW is likely the first timestamp at 8:01 UTC and the second one at 8:02 or 8:03 UTC.

For info, the data hasn't updated again - it's still producing 15 minute data files but no updated data since then. This is despite it stopping charging and me doing two 6 mile journeys since then. Obviously you can't influence this, but interesting data point to understand the reliability/usefulness of this data source

[TommiG1 (Thomas Graf)]

Hi @chrismrudge — glad v0.6.14 fixed miles for range and mileage, and thanks for the portal JSON.

Charge power: we do not average duplicates. Two battery_state_report.charge_power rows in one ZIP (e.g. 6.0 and 0.0) → we pick one (freshest timestampUtc, else stable UUID tie-break) — never (6+0)/2. So 3 kW probably isn’t from those two rows; check it’s Charge power (kW), not Charge rate (mi/h or km/h), and compare the live state in Developer tools, not only the history chart.

Bundling several minute-level snapshots into one 15‑min ZIP (UPDATE_REASON_CHARGING) is normal portal behaviour — 0.0 at start and 6.0 a minute later can sit in the same file.

If you can help debug further, please share:

1. Both charge_power objects including timestampUtc
2. The exact HA state of the charge power sensor at that moment
3. One redacted JSON/ZIP from that charging window (GitHub issue is fine)

Stale data after driving: if new ZIPs arrive but car_captured_time stays old, the EU Data Act pipeline hasn’t got fresh telemetry yet — MyCupra can still be live. Does the portal UI show a newer snapshot time after a drive, or also the old one?

Thanks again — really helpful beta feedback.

[TommiG1 (Thomas Graf)]

Workaround: Fresher SoC values for Cupra / VW Group via Octopus (DE)

The VW Group EU Data Act integration delivers reliable vehicle data, but the battery level (sensor.*_battery) typically arrives via portal snapshots with ~15 minutes latency. For automations (openWB, charge planning, dashboards) that can be too stale.

Workaround: You can add your vehicle under Devices in the Octopus app — this works even without an Intelligent Go / Flex tariff (e.g. on Octopus Relax). The Octopus Germany integration can then read a fresher SoC from the Octopus/Kraken API, regardless of whether you use smart charging.

Important: Disable smart charging (safety)

If you are not on a Flex / Intelligent tariff (e.g. Octopus Relax), make sure to disable “Smart charging” in the Octopus app settings.

Otherwise Octopus could influence your charging — even though you are not on a smart tariff. This workaround is only meant for SoC telemetry, not charge control by Octopus.

In Home Assistant you can verify this via status SMART_CONTROL_OFF and switch ..._smart_control = off.

Short version: Connect vehicle = yes. Smart charging = only if you intentionally use a Flex/Intelligent tariff — otherwise keep it OFF.

Requirements

• Octopus customer in Germany (e.g. Relax, Intelligent Go, or another tariff)
• Vehicle connected in the Octopus app under Devices (VW Group: VW, Audi, Škoda, SEAT, Cupra)
• Smart charging OFF if you do not have a Flex / Intelligent tariff
• Home Assistant: octopus_germany v0.0.93+ (currently v0.0.96)
• Runs in parallel with the EU Data Act integration — both can coexist

What Octopus provides (and what it does not)

Data	Octopus Germany	EU Data Act
SoC (current)	sensor.<vehicle>_soc	, but ~15 min old
Charge target	(if smart charging is active)	target_charge_level
Range		electric_range
Charge power, status, etc.	limited (SmartFlex status)	extensive

Octopus reads SoC via SmartFlexVehicleStatus.stateOfCharge — “the latest SoC received from the vehicle”. This is not a real-time stream, but in practice often fresher than the EU Data Act snapshot.

Finding the sensor

After setup and vehicle linking, you should see entities like:

sensor.<vehicle_name>_octopus_<account>_<vehicle>_soc

Example (entity IDs vary by device name in Octopus):

sensor.cupra_born_electric_vehicles_octopus_a_c1846326_cupra_born_soc

Related entities:

sensor.<...>_battery_size    # kWh
sensor.<...>_status          # e.g. SMART_CONTROL_OFF
binary_sensor.<...>_plugged  # plugged in (v0.0.94+)

Note: If all Octopus vehicle entities show unavailable → check the vehicle link in the Octopus app, reload the integration, or update to v0.0.93+ (the SoC sensor was added in v0.0.93).

Example: Send SoC to openWB (MQTT)

alias: Cupra - Link SOC from Octopus to openWB
description: Sends Cupra SoC from Octopus integration to openWB via MQTT.
triggers:
  - trigger: state
    entity_id: sensor.cupra_born_electric_vehicles_octopus_a_c1846326_cupra_born_soc
actions:
  - action: mqtt.publish
    data:
      topic: openWB/set/mqtt/vehicle/1/get/soc
      retain: true
      payload: "{{ states('sensor.cupra_born_electric_vehicles_octopus_a_c1846326_cupra_born_soc') | int }}"

Range still from EU Data Act (Octopus has no range):

alias: Cupra - Link range from EU Data Act to openWB
triggers:
  - trigger: state
    entity_id: sensor.all_data_cupra_electric_range
actions:
  - action: mqtt.publish
    data:
      topic: openWB/set/mqtt/vehicle/1/get/range
      retain: true
      payload: "{{ states('sensor.all_data_cupra_electric_range') | int }}"

Limitations / known pitfalls

• Vehicle linking is enough — no Intelligent tariff required for SoC telemetry; smart charging only makes sense on Flex/Intelligent — otherwise disable it
• Germany only — octopus_germany is for Octopus DE; UK users need the UK integration by BottlecapDave
• VW Group + Octopus — known smart-charge issues with VAG vehicles (incomplete charge schedules); usually fine for SoC display only
• Values may differ — Octopus SoC and EU Data Act SoC can temporarily disagree (different sources and update cycles)
• Not a replacement for EU Data Act — range, consumption, mileage, temperatures, etc. remain on the portal integration

Recommendation

Use case	Source
Dashboard, history, energy dashboard	EU Data Act
Current SoC for charge automation / openWB	Octopus Germany
Range, charge power, vehicle status	EU Data Act
Charge control	openWB / EVCC / wallbox — not Octopus (unless you deliberately use a Flex tariff)

Summary: EU Data Act for vehicle data, Octopus for fresher SoC. Linking your vehicle in the Octopus app also works on Relax — just keep smart charging OFF if you are not on a Flex tariff.

Has this worked for you too? Happy to hear experiences with other VAG models or tariffs (Relax, Dynamic, Intelligent Go).

[vbherodes (Marc)]

ID.7 (DE) works.

[Micha59 (Michael Hofmann)]

Hello TommiG1, thank you very much for your excellent work. I drive a VW Tiguan 1.6l plug-in hybrid. According to Connect, there are 120 entities. As I previously only used VW Connect to retrieve data and not to control functions, this programme is a perfect replacement for me. If you still need testers from my end, I’d be more than happy to help.

[TommiG1 (Thomas Graf)]

Hi @Micha59 — yes please, that would help a lot. Your Tiguan PHEV is a test case we don’t have much real data for yet.

Could you send one redacted portal ZIP (All Data, real content, VIN removed from filename + JSON) via GitHub issue or PM — not in this thread? One snapshot is enough.

Bonus: which entities you use, and anything that looks wrong (units, PHEV range fields). Thanks!

Tommi

[poldekch]

Hi, Cupra Terramar owner here, had some issue creating data request - either the page has changed or it's a bit different for cupra. Eventually got it so the integration started but I have only 11 entities - only related to the integration, no vehicle data.
After some time I can see I have 4 files in the portal but after downloading there are only 3 data fields: "boardnetBatteryVoltageIndication", "inspectionDistance", "outsideTemperatureIndication" and they appeared as disabled entities in HA. Based on that I reckon the integration works but cupra not sending more data (or maybe a need some drive - for now only started ignition).
Thanks! Looking forward to seeing more data (and offering help on debugging that @TommiG1 !)
Edit:
So far I found some strange unit for temperature: 20 (°C) BTW that value is also off but it comes like this in json, at the moment it's 14°C outside

[poldekch]

Update: Overnight I have received all data - 120 entities in total. So far I have only one suggestion - edit the strange temp unit and perhaps remove brackets around units in Diagnostic section. Thanks @TommiG1 !

[jnehrk]

Hi @TommiG1,
first of all, great work! Tested with a Volkswagen ID.7.
Some observations:

• Range missing: There appears to be no range-related data field in the json
• Two "Batterie" entities in Homeasistant, one with one decimal value, the other one without. Not sure what the difference is

[TommiG1 (Thomas Graf)]

Hi @poldekch — thanks for testing with the Terramar, and great that you now have the full 120 entities overnight.

The slow start (11 entities, then only 3 fields in the ZIP) is expected: the portal often delivers minimal snapshots at first (ignition on, no drive yet). The integration was working — it was waiting for richer ZIPs. A short drive or charging session usually unlocks the full All Data payload; your overnight update confirms that.

Temperature 20 (°C): The strange unit comes from the official VW data dictionary bundled with the portal — it stores (°C) (encoding glitch) and our raw diagnostic sensors pass that through as-is. That’s on us to normalize to proper °C (and strip parentheses like (km) → km on diagnostic entities). I’ll fix that in the next release.

If the value 20 still looks wrong vs. real outside temp, that’s what the portal sent in that snapshot — check car_captured_time / last_vehicle_update for how old the reading is. The curated Outside temperature sensor (if present on your device) may use a different field than outsideTemperatureIndication.

If you’re happy to help further: one redacted Terramar ZIP via GitHub issue would help us map Terramar-specific flat fields — especially useful now that Cupra is delivering full datasets.

Thanks again!

Tommi

[TommiG1 (Thomas Graf)]

Hi @jnehrk — thanks for testing with the ID.7, and glad it’s working overall.

Range missing: On ID.x/MEB cars the portal often does not use a plain range.value field. Range is frequently delivered as battery_state_report.cruising_ranges.0.range (and siblings) with a separate engine_type. The integration currently exposes Electric range only for range.value and value_of_the_primary_range — not yet for the cruising_ranges array. So you may have range data in the JSON under cruising_ranges without seeing a curated range sensor in HA.

Could you search your portal JSON for cruising_ranges or range and share (here or via GitHub issue) whether those fields are present? That would tell us if this is a mapping gap we need to fix vs. the portal not delivering range yet for your car.

Two “Batterie” sensors: Most likely these are two different fields:

• battery_state_report.soc — main SoC (usually integer, e.g. 72 %)
• battery_level_HV.value — HV battery level (often one decimal, e.g. 72.5 %)

Both are battery-related but not identical readings. Please check the entity IDs in Developer tools → States — if that matches, we can improve the German names so they’re easier to tell apart (e.g. “HV-Batteriestand” vs. “Batterie”).

If both IDs point to the same field name, let me know — that would be a duplicate we should fix.

Thanks again — ID.7 feedback is very helpful.

Tommi