CarConnectivity Connector for the Volkswagen EU Data Act Portal

A CarConnectivity connector that reads vehicle data from the VW Group EU Data Act portal (eu-data-act.drivesomethinggreater.com). It supports every VW Group brand on the portal (Volkswagen, Audi, Škoda, SEAT, Cupra, Bentley) and models pure EVs, combustion and PHEV drivetrains.

Why this connector exists

Volkswagen has blocked WeConnect API access for all 3rd-party integrations, which breaks the carconnectivity-connector-volkswagen connector. For personal use, the EU Data Act portal is the remaining access path. Its data has important limitations:

• Read-only. No commands are possible (lock/unlock, climatization, charge start/stop, etc.).
• ~15-minute cadence. Data is delivered as batch datasets roughly every 15 minutes, not live.
• Partial data. Some WeConnect data points are absent (e.g. GPS location; estimated range is often missing). Only the data points present in a dataset are exposed.

This connector authenticates against the portal (OIDC login, reusing the proven flow from the homeassistant-vw-eu-data-act integration), downloads the newest dataset per vehicle, and maps the available data points onto native CarConnectivity attributes as read-only values.

Prerequisites — enable continuous data on the portal first

Before adding the connector, you must enable a continuous 15-minute data request for your vehicle on the EU Data Act portal. The connector only downloads the datasets the portal generates — it cannot create the data request for you, and without an active request there will be nothing to fetch.

1. Open https://eu-data-act.drivesomethinggreater.com/ and log in with your Volkswagen ID (the same email/password you'll use in the connector config).
2. Go to Data clusters → Vehicle overview.
3. Connect your car to the site if it isn't already listed (follow the on-screen pairing/consent steps for your VIN).
4. Click Get customised data for the vehicle and follow the instructions to configure a continuous data request with a 15-minute frequency.
5. Wait until the portal starts producing datasets (you'll see ZIP files appear in the vehicle's data delivery list, roughly every 15 minutes). The first file can take a little while to show up.

Once datasets are being generated, continue with the installation below.

The connector polls at most every 15 minutes because that is how often the portal publishes new data — a shorter interval cannot produce fresher values.

Installation

pip install -e .

Requires carconnectivity>=0.11.9.

Configuration

Add a connector of type vw_eu_data_act to your carconnectivity.json:

{
  "carConnectivity": {
    "connectors": [
      {
        "type": "vw_eu_data_act",
        "config": {
          "username": "you@example.com",
          "password": "your-portal-password",
          "interval": 900,
          "country": "si",
          "language": "sl",
          "brand": "VOLKSWAGEN_PASSENGER_CARS"
        }
      }
    ]
  }
}

Supported brands

Set brand to the canonical key (or a friendly alias) for your vehicle. Matching is case-insensitive; an unknown value falls back to Volkswagen Passenger Cars.

Drivetrains (EV / combustion / PHEV)

The connector detects the drivetrain from the data points present (battery vs fuel) and promotes the vehicle to electric, combustion or hybrid accordingly, following the same conventions as the official carconnectivity-connector-seatcupra:

• Pure EV — a single primary (electric) drive.
• PHEV — the primary drive is the combustion engine and the secondary drive is the electric one (so the petrol range is no longer assigned to the electric drive).

Exposed data points (read-only)

Both the dotted (nested) and flat portal field names are accepted. Drive slots follow the drivetrain (see Drivetrains above): on a PHEV the electric drive is the secondary slot and combustion is primary; on a pure EV the electric drive is the single primary slot.

A dataset is a merge, not a moment. One portal delivery flattens several vehicle reports, each captured at its own time, into a single unordered array. The official data dictionary defines a capture timestamp per report group, but the flat export drops the grouping: nothing ties a field to the report it came from. Two fields of the same dataset must therefore not be read as simultaneous (spreads from minutes to several hours between report groups have been observed on real exports). The failure mode is quiet: a charging state captured before a scheduled charge can sit right next to a charge power captured during it, and both are correct. The two payload formats age differently: flat-format vehicles stamp (nearly) every entry with its own timestampUtc ("when the car last reported this field"), while dotted-format (MEB) exports carry no timestampUtc at all, only report-level car_captured_time entries that nothing references.

A new delivery is not a new measurement. The vehicle reports on events (ignition, charging steps, warnings) and goes quiet when parked; the portal publishes on its own cadence regardless, so a delivery can carry values captured many hours earlier. connector.last_update is the delivery time and the vehicle's captured_at the newest measurement time of the merged dataset: the delivery is the postman, captured_at is the date on the letter. Automations acting on momentary values (such as charging.power) should check captured_at before trusting them.

A repeated capture time is not re-stamped. While the car sleeps, most deliveries carry the same newest capture time as the previous one (63 of 74 consecutive deliveries on a real flat-format run). The connector then leaves an unchanged attribute alone rather than writing it again: the core would otherwise replace the stored measurement time with the wall clock, after which every later real capture, always older than that clock, is refused as "Value from the past" until the car reports something newer than the clock itself (#44). A value that does change under an unchanged capture time is still taken, with its measurement time kept. When a dataset carries no capture time at all, the delivery's createdOn is used as the measurement time rather than leaving it to the clock.

Vehicle

Maintenance & climatisation

Electric drive (secondary on PHEV, primary on EV)

Combustion drive (primary on PHEV)

Charging

During a charging session the dotted battery_state_report.* / charging_state_report.* fields also arrive as copies carried by the charging-job reports, under their own keys and sometimes contradicting the live reading. The live key is read first; a copy is only used when the live reading is missing.

Not exposed (and why)

These portal fields have no native CarConnectivity model, so they are left as the connector's "unmapped sensor" log entries rather than forced into an ill-fitting attribute:

• Tyre pressures (tyre_pressure_actual/required/differential_*) — no tyre-pressure model.
• Instrument-cluster warnings (active_warnings_in_instrument_cluster_*) — no warning model; the value is also a latched hex bitmask that does not clear reliably.
• Oil level extras (oil_level_additional_oil_level, oil_level_dipstick_indicator_function, oil_level_total_max) — VW-specific quirks with no native model; the actual oil level (oil_level_actual_level) is mapped to drive.oil_level (see above).
• Trip statistics (short_/long_term_data_*: average speed, trip mileage, travel time, recuperation, aux/gas consumption, zero-emission distance) — no trip-statistics model.
• "Safe" / secured states (safe_state_*), state_spoiler, state_service_hatch, state_of_hood, bem_level, energy_flow — no attribute.
• Exact window opening percentage — used to derive the window open_state (closed / ajar / open), but the Window model has no numeric position attribute, so the percentage itself is not stored.
• Raw HV SoC (hv_soc) — the displayed SoC is already mapped to drive.level.
• Diagnostics / triggers (echo, trueness, charging_state_error_code, window_heating_error_code, charging_reason_trigger, led_state / led_color, cng_gas_level, fuel_level__accuracy, …).

License

MIT