2026.5.2

[Hankanman]

Hotfix for repair-panel spam introduced in 2026.5.1

If you upgraded to 2026.5.1 and started seeing recurring sensor_health_unavailable or pipeline_health_correlation_failures cards in Settings → Repairs — usually with empty descriptions and an Ignore button that didn't make them stick — this release fixes them. The issues were diagnostic, not behavioural: occupancy detection itself was working correctly the whole time.

Thanks to @Lavve for the detailed report in #455 — the screenshots and debug logs made every one of these reproducible.

What's fixed

1. Empty repair cards (no description, no "What to do")

The shipped translation file was missing the issues block, so Home Assistant rendered every health repair as title-only with just an Ignore button. The block is now mirrored from strings.json so cards show the full description and remediation advice.

2. pipeline_health_correlation_failures firing during warm-up

The correlation-failure check was treating expected "not enough data yet" states (no_occupied_intervals, too_few_samples, no_occupied_time, …) as hard errors. On a fresh install — or any time you add a non-motion sensor to an existing area — those states are normal until the integration has accumulated enough history to learn from. The check is now gated on PRIORS_TRAINING_GRACE_PERIOD (7 days), matching the existing warm-up behaviour for time priors and stale-cache checks.

3. sensor_health_unavailable startup race (the one in the screenshots)

The unavailability check measured outage duration from the persisted entity.last_updated, which can be days old and reflects the last evidence transition, not the current outage. When a source integration like Zigbee2MQTT or ESPHome loads slowly at HA startup — taking longer than the area-occupancy integration itself — every sensor in the area instantly tripped the 1h "unavailable" threshold, even though the outage was 30 seconds old. This also explains the misleading "occurred 2 weeks ago" timestamps some reporters mentioned.

The check now tracks outage start in an in-memory map keyed by entity_id, recorded the first time an entity is observed unavailable in the current session, and cleared on recovery. Pruning logic ensures the map doesn't leak when entities are removed, reclassified, or moved to the excluded list.

4. Slow-analysis threshold raised from 30s to 3min

Large installations (lots of correlatable sensors, deep recorder history) can legitimately exceed 30s on the first warm cycle. The threshold was producing false-positive pipeline_health_slow_analysis repairs on first install. We'll tighten this back down once we have a baseline distribution from real installations.

5. Misleading log line

_update_repair_issues was printing pipeline-scope events as New sensor health issues in area 'X': None (correlation_failures) — the None was the missing entity_id (pipeline issues aren't sensor-scoped). Sensor-scope and pipeline-scope new-issue announcements are now logged separately, so the message reads correctly for each.

Upgrade notes

• No restart required to pick up the translation fix; a frontend reload is sufficient.
• Existing repair cards will be re-evaluated on the next health-check cycle. If they were caused by any of the above bugs, they should auto-resolve within a minute or two of upgrading.
• The 7-day correlation grace period restarts from the area's creation date, not from the upgrade. Existing areas older than 7 days will still surface real correlation failures — only the warm-up window is now respected.

What's Changed

• fix(health): silence false-positive repairs from area_occupancy: sensor_health_unavailable #455 by @Hankanman in fix(health): silence false-positive repairs from #455 #459

Full Changelog: 2026.5.1...2026.5.2

---

This discussion was created from the release 2026.5.2.

[WebMeesters2]

The frustrating thing about the issue was, that I wasn't able to see from what area the messages came.
No information about the Area, or global setup that might have hinted at where to look.
Can you please make your messages more descriptive if they occur?

[G2740]

This is mine, it's not stuck.

We're both old, someone is always in the living room a lot and it's used for sleeping.

The sensor occupancy clears both PIR and mmWave after no detection for 90 seconds.

It's the Aqara FP300 mmWave/PIR sensor.

This error originated from a custom integration.

Logger: custom_components.area_occupancy.data.health
Source: custom_components/area_occupancy/data/health.py:807
Integration: Area Occupancy Detection (documentation, issues)
First occurred: 1:37:27 PM (2 occurrences)
Last logged: 8:00:56 PM

New sensor health issues in area 'Living Room': binary_sensor.living_room_fp300_presence (stuck_active)