v0.6.33 — Setup without portal identifier (#40)

Fixes setup failing with Could not connect to the EU Data Act portal after login and vehicle selection when the portal has no active continuous data request yet (#40).

Credentials and vehicle discovery were already fine; the config flow blocked on a missing data-request Identifier and surfaced a misleading connect error with no log lines.

Config flow (#40)

• Finish setup without Identifier — the config entry is created; the coordinator waits with a clear delivery not ready / waiting for portal data status instead of aborting setup.
• Setup logging — metadata and login failures during setup are logged at warning/info level.

Coordinator (#40)

• Empty identifier — on first refresh, re-fetch the Identifier from portal metadata before listing datasets; persist it when it appears.

After upgrading

If setup previously failed at vehicle selection, add the integration again (or update via HACS and retry). Complete the portal subscription (continuous 15-minute request, All Data preset) if you have not already — the integration will pick up the Identifier automatically once the portal is ready.

v0.6.32 — Flat PHEV charge power & charge rate scaling (#27)

Fixes Charge power and Charge rate reading ten times too high on flat-format PHEVs (e.g. VW Tayron, Passat) when the portal sends integers with one implied decimal place (#27).

Examples from Tayron charging sessions: charging_power: 99 → 9.9 kW (not 99 kW); actual_charge_rate: 740 with km_per_h → 74 km/h (not 740 km/h). Same encoding pattern as flat charged_energy, which already used a /10 transform.

Flat PHEV scaling (#27)

• deci_kw_to_kw() — converts flat charging_power portal integers to kW.
• actual_charge_rate — same /10 transform on the flat charge-rate sensor.
• Dotted BEV unchanged — battery_state_report.charge_power and battery_state_report.charge_rate still pass through as delivered.

After upgrading

Reload the integration or restart Home Assistant. Charge power and Charge rate should show sensible values on the next charging session.

v0.6.31 — Flat remaining charging time for PHEV (#31)

Fixes Remaining charging time staying Unknown on flat/PHEV vehicles (e.g. VW Tayron) even when the portal JSON contains values like remaining_charging_time: 75 (#31).

The value was parsed correctly but hidden by an overly strict “actively charging” gate that only recognised dotted BEV companion fields, not flat charging_state.

Remaining charging time (#31)

• charging_time_is_applicable() moved to data.py and extended for flat payloads: charging_state values charging / conservationCharging count as active; off / completed / etc. suppress the reading.
• Fallback now trusts the portal value when no explicit inactive signal was found (instead of requiring all companion fields to be absent).
• Dotted BEV behaviour unchanged: scenario _OFF and charge power ≤ 0 still hide the sensor.

After upgrading

Reload the integration or restart Home Assistant. Remaining charging time should show minutes during the next charging session when the portal sends the field.

v0.6.30 — Distance registry sync after portal data (#11)

Follow-up for miles vehicles still showing km after v0.6.29 (#11).

The sensor logic in v0.6.29 was correct, but Home Assistant locked the static default km into the entity registry during setup — before the first dataset arrived — and kept overriding the resolved native unit afterwards.

Changes

• async_sync_distance_registry_units() runs on every coordinator update once portal data is present. When a companion *.unit field maps to mi or km, the entity registry is updated to match (and stale sensor.private unit overrides are cleared).
• Silent datasets (no mileage.unit / range.unit) are left alone so kilometre vehicles keep km.
• Removed the ineffective setup-time blind km → None migration from v0.6.29.

After upgrading

Reload the integration or restart Home Assistant. Miles vehicles should show mi on the next coordinator refresh.

Full notes: RELEASE_NOTES.md

v0.6.29 — Distance unit resolution for miles vehicles (#11)

Fixes mileage and range sensors showing km on vehicles whose portal dataset reports mileage.unit = MILES (e.g. UK ID.4), even though the odometer value is already in miles (#11).

The integration never converted values — only the unit label was wrong.

Changes

• First-poll adoption for distance sensors: when mileage.unit / range.unit resolves to mi or km, that unit is shown immediately instead of falling back to the static default km while sticky confirmation is pending.
• Entity registry migration clears a stale km override on mileage.value, range.value, and value_of_the_primary_range so native_unit_of_measurement can drive the label again on upgraded installs.
• Charge-rate sticky unit behaviour is unchanged.

After upgrading

Reload the integration or restart Home Assistant; the migration runs on startup. Vehicles that genuinely use kilometres are unaffected.

Full notes: RELEASE_NOTES.md

v0.6.28 — Tyre pressure 0/1 sentinel for all families (#29)

Summary

Widens the tyre-pressure validity filter to all tyre_pressure_* families (actual, required, differential). Thanks @Pulpyyyy for the data-dictionary analysis and empirical snapshots in #29.

Tyre pressure

• 0 / 1 are now unavailable on required and differential sensors too.
• Fixes misleading 1 bar when the portal sends the invalid status code.

Test plan

• On vehicles with indirect TPMS: required/differential sensors show unavailable instead of constant 1 bar
• Actual tyre pressure sensors unchanged when live scaled values arrive (e.g. 24)

v0.6.27 — Climate time, combined range & maintenance due dates

Summary

Integrates community PRs from Pulpyyyy: flat Remaining climate time in minutes (#32), combined cruising range fallback for PHEVs (#30), and maintenance due date sensors with preserved interval sign (#35).

Flat remaining climate time (#32)

• Flat PHEVs deliver remaining_climatisation_time as minutes, not seconds.
• Entity registry migration resets stale s → min overrides on existing remaining_climate_time entities.

Combined cruising range (#30)

• When cruising_range_combined is empty but per-engine components are present, the sensor sums primary + secondary range. A usable portal value always wins.

Maintenance intervals (#35)

• Drops abs() so negative = remaining, positive = overdue.
• Adds Inspection due and Oil change due timestamp sensors.
• Raw day counters disabled by default; distance counters keep raw sign.

Test plan

• Flat PHEV: Remaining climate time shows minutes (e.g. 10 min, not 10 s)
• PHEV with empty combined range: Range (combined) equals primary + secondary
• Maintenance: due-date sensors show future/past dates; day counters show signed values when enabled

v0.6.26 — Corrupt cache no longer blocks setup (#33)

Summary

Fixes a startup crash when the newest local dataset ZIP is unreadable (truncated download or portal error body saved as a .zip). Reported for a VW ID.3 after HA restart (#33).

Cache restore

• async_restore_from_cache now walks cached ZIPs newest-first, drops unreadable files, and tries the next older dataset instead of failing setup.
• Corrupt cache entries are deleted automatically with a warning in the log.

Download path

• Portal ZIPs are parsed before they are written to the local cache, so invalid bytes never poison /config/cupra_eu_data_act_cache/.

Test plan

• Update to v0.6.26 and restart HA (or reload the integration)
• With a corrupt newest cache ZIP: integration should start, log a warning, delete the bad file, and use the next readable cache or fetch fresh data
• After a successful download, verify /config/cupra_eu_data_act_cache/ only contains valid ZIPs

v0.6.25 — Passat PHEV flat charge rate (#27)

Summary

Adds a curated Charge rate sensor for flat-format PHEVs (e.g. VW Passat, Golf) that expose actual_charge_rate and charge_rate_unit instead of the dotted battery_state_report.* fields (#27). No scaling change — raw portal values are shown as delivered.

Charge rate ≠ charge power. For wallbox power in kW, use Charge power (charging_power on flat PHEVs, battery_state_report.charge_power on ID.x/MEB). Charge rate is range gained over time (km/h or mi/h).

Flat PHEV charge rate (#27)

• actual_charge_rate — curated flat sensor with mdi:speedometer, unit resolved from companion charge_rate_unit (km_per_h, miles_per_h, etc.).
• resolve_charge_rate_unit — maps flat unit strings in addition to existing CHARGE_RATE_UNIT_* enums; invalid yields no unit.
• Unit gating — same invalid/unusable-reading rules as the dotted charge-rate sensor apply to actual_charge_rate.
• Translations — actual_charge_rate entity name in EN/DE/FR/IT/NL.

Legacy helper: Monthly electric consumption

If you upgraded from v0.6.22 or earlier, you may still have a utility_meter helper named Monthly electric consumption. The integration no longer creates this helper (removed in v0.6.23, #24) — it summed driving-efficiency readings (kWh/100km) and produced meaningless monthly totals.

• Delete the old helper under Settings → Devices & services → Helpers if it is still present.
• Use instead: Monthly charged energy (kWh) for monthly charging totals.

Test plan

• Reload integration after update (or restart HA)
• On flat PHEV payloads: verify Charge rate (actual_charge_rate) appears with correct unit (km/h / mi/h)
• Compare Charge power vs Charge rate during charging — power in kW, rate in km/h or mi/h
• Delete legacy Monthly electric consumption helper if still present; use Monthly charged energy instead

v0.6.24 — Tyre-pressure curation, distance units & source_dataset

Summary

Addresses the remaining sensor-mapping gaps from upstream mikrohard#33 and completes per-entity provenance from mikrohard#31.

Sensor mapping (#33)

• tyre_pressure_required_* (5 wheels) — curated as bar with device_class: pressure instead of the ambiguous portal unit "10kPA / Bar / PSI/ kPA".
• tyre_pressure_differential_* — now also bar + device_class: pressure.
• Zero-emission / range-gain distances — short- and long-term fields convert portal 100m hectometers to km (÷10).
• Sentinel filtering for tyre validity codes (0/1) is limited to tyre_pressure_actual_* so required-pressure readings around 1.0 bar are not treated as invalid.

Source dataset attribute (#31)

Every curated sensor, binary sensor, and raw diagnostic now exposes source_dataset (portal ZIP filename) alongside the existing data_captured_at / age_minutes freshness attributes.

Test plan

• Reload integration after update
• Check a curated sensor (e.g. Battery) for source_dataset attribute
• On PHEV/Passat payloads: verify tyre_pressure_required_* and distance sensors if portal delivers those fields