Device becomes unresponsive after OTA update until ZHA is reloaded

[jintj]

After a successful OTA firmware update (upgrade_end with status=SUCCESS), the device reboots and rejoins the network. However, ZHA does not re-initialize the device after OTA completion, causing it to appear online but become functionally broken until ZHA is manually reloaded.

AI analysis：In zha/application/platforms/update.py, the async_install() method only clears _attr_in_progress after a successful OTA. It does not trigger device.async_configure() or device.async_initialize() to re-read attributes, re-establish bindings, and refresh the device's internal state.

Meanwhile, during the device reboot (~5-10 seconds), the coordinator's message queue accumulates DELIVERY_FAILED / MAC_INDIRECT_TIMEOUT errors for the target device. When the device comes back online, ZHA never calls async_device_initialized because no Device Announce is received (some end devices don't send one after OTA reboot), so the stale internal state persists.

[jintj]

log.txt

[zigpy-review-bot]

Thanks for the detailed report and especially for attaching the debug log — it made this straightforward to pin down.

The analysis in the issue body isn't what's actually happening, though: ZHA (via zigpy 2.0.0) does re-interview and re-initialize the device after a successful OTA, without needing a Device Announce. Your log shows the device confirming the new firmware (current_file_version = 24) just 20 seconds after upgrade_end, and the re-interview completing about a minute later. The DELIVERY_FAILED/MAC_INDIRECT_TIMEOUT errors around the reboot are transient and recovered by retries.

What actually breaks is the re-initialization itself. The ThirdReality Smart Filter Sensor (3RAP0149BZ) on firmware 1.00.24 reports an AnalogInput resolution attribute of 0.0, and ZHA hit an assertion while converting that into a display precision:

2026-07-13 12:06:07.003 WARNING (MainThread) [zha.application.gateway] Failed to configure/initialize device 4c:e1:75:52:6a:92:00:00 after reinterview
...
  File ".../zha/application/platforms/sensor/helpers.py", line 13, in resolution_to_decimal_precision
    assert resolution > 0
AssertionError

The post-OTA rebuild removes all of the device's entities before re-creating them, and this crash happened before any entity was re-added — so the device was left looking online but with no working entities, exactly the state you describe.

We will fix this on the ZHA side with the changes on the zigpy-bot/analog-input-zero-resolution branch (diff): ZHA then ignores a bogus resolution (the entity just gets no suggested display precision), and a failure in one entity no longer aborts initialization of the rest of the device.

One important note until the fix is released: the resolution = 0.0 value was persisted to ZHA's database, and device initialization runs from that database on every start. We've reproduced both halves of this in tests: the value survives the database round trip back into the attribute cache, and initializing the device from that cache hits the same assertion. So a Home Assistant restart (or ZHA reload) is expected to hit the crash during startup — likely failing ZHA setup entirely — rather than fix the device. If reloading ZHA really did bring the device back for you, a debug log of that reload would be very helpful. In the meantime, removing and re-pairing the sensor clears the cached value and restores it.

Firmware bugs to fix in a future 3RAP0149BZ OTA

Since this looks like a ThirdReality test network — if you're affiliated, the log shows three firmware issues in 3RAP0149BZ v1.00.24 that would be worth fixing in a future OTA:

1. AnalogInput resolution reads as 0.0. ZCL R8 §3.14.11.11 defines the attribute as "the smallest recognizable change to PresentValue", so 0 is meaningless. Report the actual measurement resolution, or don't implement the attribute. (This is what triggered the ZHA crash; ZHA will tolerate it going forward, but the value is still wrong. If you can check: does firmware ≤ 1.00.22 also report 0? The log doesn't show the pre-upgrade value, so we can't tell whether this is new in 1.00.24 — only that no bad value was cached before the update, since ZHA would otherwise have crashed on earlier restarts.)
2. The AnalogInput description read is answered with INSUFFICIENT_SPACE. That status is spec-legal for reads — ZCL R8 §2.5.1.3 says a device SHALL answer INSUFFICIENT_SPACE for a supported attribute whose value record doesn't fit into the remaining response-frame space, and the client may then re-read it (§2.5.2.3). However, the response here used only ~30 bytes, so this is only consistent if the description string is longer than roughly 50 characters. Could you check what a read of only description (attribute 0x001C) returns? If it succeeds, the behavior is fine (and issuing the follow-up read is an improvement we can make on our side — now tracked in read_attributes: follow up on INSUFFICIENT_SPACE records with smaller reads (ZCL R8 §2.5.2.3) zigpy#1855; today the failed batched read is why no AnalogInput entity is created for this device); if it still fails alone, that's a firmware bug.
3. The device answers ZHA's upgrade_end_response with DefaultResponse(status=FAILURE), i.e. it reports an error for a well-formed command it evidently processed — the update succeeded and the device runs 1.00.24 afterwards. (Sending a Default Response despite "disable default response" is fine for errors per ZCL R8 §2.4.1.1.4; reporting FAILURE here is the bug. Harmless in practice.)

Full timeline from the log (click to expand)

• 12:02:26 — device sends upgrade_end(status=SUCCESS, file_version=24); ZHA replies with upgrade_end_response(current_time=0, upgrade_time=0).
• 12:02:31 — that reply's first delivery fails (DELIVERY_FAILED, the device is rebooting) and is retried; the retry is delivered at 12:02:35, which the device answers with DefaultResponse(status=FAILURE) (see firmware bug 3).
• 12:02:46 — the device answers zigpy's read of OTA current_file_version with 24 — the new firmware is confirmed running; regular attribute reporting resumes by 12:03:20.
• 12:03:39 — zigpy's post-OTA re-interview completes (Discovered basic device information); ZHA tears down the device's entities and starts rebuilding ("Rebuilding device 0x6D1D:… after reinterview").
• 12:03:40–12:05:24 — reconfiguration succeeds ("completed configuration"; binds + reporting configured on PowerConfiguration, AnalogInput and PressureMeasurement — slow only because the sensor is a sleepy end device).
• 12:06:06 — initialization reads the AnalogInput attributes: description fails with INSUFFICIENT_SPACE, resolution returns 0.0 (and is written to the attribute cache in zigpy.db).
• 12:06:07 — AssertionError in resolution_to_decimal_precision() aborts async_initialize() before any entity is re-added (no "Discovered new entity" line appears for the device after the teardown) → "Failed to configure/initialize device … after reinterview".

Is `resolution = 0` spec-compliant? (click to expand)

Strictly speaking, the ZCL doesn't forbid it: ZCL R8 §3.14.11.11 only defines the attribute as "the smallest recognizable change to PresentValue", and the Analog Input (Basic) attribute table (§3.14.2, Table 3-78) puts no range constraint on it. So 0.0 isn't formally out of range — it's just semantically meaningless (a "smallest recognizable change" of zero isn't a change). That's why the ZHA fix tolerates the value instead of treating it as an error, but reporting a real resolution is still the right thing for the firmware to do.