v3.2.0-beta4

v3.2.0-beta4 -- fourth pre-release

Carries everything from v3.2.0-beta3 plus a fix for issue #217 (DWD device-name-prefixed entity IDs) and the PEU level-name cleanup tracked in #215.

Changes since beta3

DWD: handle device-name-prefixed entity IDs (#217 / #218)

Reporter @LightMaster001 ran into "No sensors found" on a fresh hacs_dwd_pollenflug v1.0.4 install with HA 2026.5.0. Home Assistant prepends the device-name slug to entity IDs when the integration's device has a friendly name, so on those installs the entity ID looks like

sensor.pollenflug_gefahrenindex_pollenflug_<allergen>_<region_id>

instead of the legacy bare shape

sensor.pollenflug_<allergen>_<region_id>

The autodetect chain found the entities, but the DWD adapter's classifier (greedy (.+)) captured gefahrenindex_pollenflug_ambrosia as the allergen segment, and the template fallback's startsWith missed entirely.

Fixed via a new shared regex anchor (^sensor\.(?:\w+_)*pollenflug_([a-z]+)_(\d+)$) used in classify, the regex fallback, the template fallback in resolveEntityIds, and the autodetect filters in pollenprognos-card.js and pollenprognos-editor.js. User-renamed devices with arbitrary prefixes are also handled. Six new contract tests cover the upstream-default prefix, user-renamed prefix, multi-allergen resolveEntityIds, fetchForecast end-to-end, the standalone template fallback, and the edge case where the device-name itself is "pollenflug". A regression test ensures non-sensor.* entities (automation, input_select) with _pollenflug_<token>_<digits> suffixes never enter DWD discovery.

This is the same pattern MSW handles in #214; the audit (noted in the issue thread) flagged that PEU, Kleenex, PLU, PP, Atmo and the MSW regex itself probably benefit from the same anchor. That's scoped for a separate PR after beta4 testing wraps so the change stays focused.

PEU: retire the legacy 0--6 level-name spread (#215 / #216)

PEU stretched its native 0-4 state onto the seven-bucket card.levels palette via a [0, 1, 3, 5, 6] runtime spread, originally to compensate for the lack of five-level locale strings. Now that card.levels5.0..4 lives in every locale (added for MSW in 3.2.0), PEU reads from the same five-level keys natively. Default user-visible labels are unchanged (the new keys are sourced from the same translations the spread used to surface). Legacy 7-length custom phrase configs are migrated by extracting entries at the historical [0, 1, 3, 5, 6] positions, so user-visible labels stay identical there too. SILAM's analogous indexToLevel spread is intentionally kept (its dual role across mixed-allergen chart geometry is documented inline in src/adapters/silam.js).

What to look for

Same scope as beta3, plus:

• DWD users on HA 2026.5.0 or fresh installs: the card should now find your sensors regardless of whether HA prefixed your entity IDs with the device-name slug.
• PEU users: card and editor should look identical to before; no migration step required. Custom 5-length or 7-length phrases.levels configs preserved transparently.

Reporting

Open an issue with the integration(s) you have, whether you're using the editor or YAML, a screenshot, and (if possible) debug: true console output.

Credits

Thanks to @LightMaster001 for the bug report (#217), @r3turnNull for the MSW adapter (#212), and @izacus for the upstream hass-swissweather integration.