[VW EU] VW ID.3 stopped working

[Ra72xx]

Unfortunately, this integration has no longer been working for my id.3 (German model) for quite a few days. Most sensor have wrong or stale values, but some seem to update regularly (e.g. odometer, target charge level, work reliable, battery level is stuck since days, parking lights claim to be on all the time, etc.)
The VW.de additional channel can't be added at all, it only produces authentication errors each time I try to activate it.
I also removed and added the integration numerous times, it stays the same all the time.
Logs do not contain any special information (only the VW.de channel throws an authentication error), so a bug report is useless.

I just manually downloaded the EU data act portal and seems that the error is already there; E.g. the battery state is wrong even in the latest package.

Any ideas what I can do?

[its-me-prash]

Thanks for the detail about the portal package, that is the important part of your report.

If the battery state is already wrong in the export you downloaded yourself, that part is not something the integration can correct. We do not alter values, and we cannot produce a fresh one when the portal stops sending it. A field that stops updating stays visible at its last value, which is deliberate so that a partial response does not blank your whole dashboard, but it does mean a frozen field still looks current. It also explains the odd mix you are seeing: each field is taken from its own newest sample, so the battery can stall while the odometer keeps moving.

The volkswagen.de channel is a separate problem and one I can act on. Until now every failure there was reported as a wrong password with nothing written to the log, so an expired session, a redirect loop and an actual typo all looked identical. v2.24.1 logs the reason. Please try adding the channel again after updating and send me what shows up in the log.

On the parking lights I would rather not promise you a fix I cannot back up. There is a related bug I did fix in v2.24.1, where a flag that only means "this section is present" was being read as the state itself. But going by your earlier report your car sends the per-side values directly, so that particular fix probably will not change what you see. If the lights are still stuck on after updating, please enable the raw_api_fields attribute (it is off by default) and send me what your car actually reports for them.

One question that decides a lot: do you have the continuous 15 minute data request running, or a one time export? The two arrive in different formats and it changes what we are able to read.

[Ra72xx]

I had an continuous 15 min data report job running and that had worked in the past. Yesterday I deleted it after all the problems because I wanted your integration to create a new one (as I understood it would do with the corresponding switch turned on), but that was 12h ago and up to now nothing has been created.

However, that messy VW EU data portal currently does not really work for me also as an human user. Endless loading of the page, no more navigation after a few clicks, only to be cured by closing the browser tab, so something might be broken there.

Also, the other HA integration (Volkswagen connect) has the same problem, but it also has some other fields working.

[Ra72xx]

I re-setup everything including the login for the EU data portal. This was working since yesterday, now stuff like this happens:

Without any charging process, my battery level jumps up to 76%, which seems to be some old value. The same happens e.g. for the mileage, which should never ever decrease:

The only error I get is something old:
VAG Connect: supplementary vw.de channel could not silently resume: Website authproxy: SSO session expired — full re-login required — re-add it from the integration options; the primary channel is unaffected.
However, the supplementary channel never really worked for me, the login was always rejected immediately...

[its-me-prash]

Thanks for sticking with it, and sorry it got worse rather than better. What you describe (the battery jumping back to an old value, and mileage going down, which it physically cannot) is a known and nasty failure mode of the portal export, and it is worth being precise about the cause because the obvious fixes do not work.

The export can carry the SAME field more than once in one file, with different values and no reliable way to tell which one is current. Two other projects working from the same feed hit this and dug into it: one proved that pairing a value with a timestamp is impossible because the entries arrive in an unstable order with no link between them, and another tested four different tie-breaking strategies against real files and none of them held up. So this is not something I want to guess at, because guessing produces confidently wrong values, which is worse than none.

What would let me fix it properly is one of your actual export files. If you can:

1. In Home Assistant, open the integration, three dots, Download diagnostics.
2. If you can also grab the raw ZIP from the VW data portal from around a time you saw a jump, that is the most useful piece.

Redact the VIN and any coordinates before posting. With a file that actually contains the duplicate, I can see which entry your car considers current and build the rule around evidence instead of a hunch.

Separately: v2.26.2 fixed a problem with resuming the volkswagen.de session that produced the "could not silently resume" line you have in your log. That is likely a second, independent issue you were hitting, so it is worth updating regardless.

[Ra72xx]

I use your integration because for VW it seems to be the last one actively developed.
Currently the values seem to be correct again. I'll look into the logs when there is an error.
Could you add some sensor which data source is currently used? If I see it correct, currently you have to look in the logs which data source has failed to guess which one is used, maybe even per-entity?

[its-me-prash]

Good news: this is fixed in v2.29.0, and I did not need your file after all. An owner of an affected ID.3 published their raw export on another project's tracker, so I could work from real data.

What was happening: the export sometimes carries the same reading more than once inside a single snapshot with different values. When both copies share one capture time there is nothing left to tell them apart except their position in the array, which is not evidence, so the value flipped between them.

The obvious idea, deciding by whether the car is charging, does not work: in that real export the charge mode arrives as both DEFAULT and STOPPED and the charge state as both READY and NOT_READY, so the referee is contested too.

What the file cannot corrupt is the previous poll. The integration now records every candidate and keeps the one closest to the reading it already had. A car that is genuinely charging is followed rather than frozen, and only the impossible jump is dropped. On the real file the wrong value 50 was published before and 71 is published now, which is what the car and the app show.

Your mileage going backwards is the same mechanism and is covered by the same change.

[its-me-prash]

@Ra72xx — circling back on your idea of "a sensor that shows which data source is currently in use." It landed: v3.0.5 adds a probe_outcomes block to the diagnostics, and the per-field source tracking (field_sources) already records which channel each reading came from. It's diagnostics-first rather than a live sensor for now, but the plumbing to surface "this value came from EU-DA vs vw.de vs BFF" is there — a user-facing source sensor is a natural next step on top of it. Thanks for the suggestion, and for being one of the people keeping this pushed forward.

[its-me-prash]

Hi @Ra72xx — closing the loop here. The original fault (battery snapping back to an old value, odometer stepping backwards) was the EU-Data-Act export's duplicate-field problem, fixed back in v2.29.0 by keeping the candidate closest to the previous reading. And the idea you raised in this thread — a sensor that shows which data source is actually feeding the car — just shipped for real in v4.4.0: the "Data source channel" sensor now reads in plain language (e.g. "EU Data Act portal + Car-Net"), lists every active source under a channels attribute, and stamps the same friendly name on each reading's source attribute, so you can see at a glance which login produced what. Thanks for pushing this one along — I'll mark it resolved, but shout if the ID.3 misbehaves on v4.4.0 and I'll dig back in.