TL;DR: On fw 1.00.63 (current via ZHA OTA), the Door Sensor will recover from a network orphaning if it’s woken early (8 h in), but somewhere before the 22 h mark it stops attempting any network activity at all — reed events and button presses produce zero RF — and only a battery pull revives it. The Water Leak Sensor line got “optimized network joining and reconnecting algorithms” plus an SDK update in v1.00.73 (Jan 2026). Requesting the same treatment for the Door Sensor line.
Environment: Home Assistant 2026.7.3 on HA Yellow (built-in Silicon Labs radio, EmberZNet), ZHA. 13× 3RDS17BZ, all on 1.00.63 (0×0000003F), in a 46-device mesh with 14 routers. Roughly weekly, one sensor (rotating among units) drops off and stays off until battery-cycled. Battery is ruled out — the unit I instrumented last night failed at 2.9 V / 84.5% (cluster 0×0001, attrs 0×0020 / 0×0021).
What I observed on last night’s failure (coordinator-side):
- Last RF contact Monday 22:12. The sensor had been evicted from its parent router’s child table (12 end devices listed that router as their last relay while its table held only 2 — classic child-table pressure).
- 22 h after the drop: operated the reed switch several times — nothing received at the coordinator, zigpy last_seen frozen, no packets relayed. Short press of the reset button — same, total silence. Two healthy routers were in range, including one with an empty child table less than a foot away.
- Battery pull — rebooted and rejoined within seconds.
- A drop five days earlier on the same unit recovered the instant the window was operated, 8.5 h into the outage. So wake-triggered rejoin works early in an orphaning; somewhere between 8 and 22 h the firmware appears to give up entirely.
One more behavior worth fixing while you’re in there: on reboot the sensor performs a targeted rejoin to its remembered parent instead of scanning. Last night it re-latched onto a marginal router across the house (inside a metal fan canopy) while ignoring the freshly powered, empty-table router one foot away. There is currently no way to steer recovery placement short of cutting power to the old parent.
Requests:
- Never stop trying — keep periodic rejoin attempts indefinitely (a slow duty cycle is fine for battery life), and always attempt a rejoin on any wake event (reed or button), no matter how long the device has been orphaned.
- On rejoin failure or reboot, fall back to a best-LQI parent scan rather than only redialing the previous parent.
Happy to provide coordinator logs or sniffer captures. I’m also glad to beta test a candidate build — I have 13 units and monitoring that catches a drop within 30 minutes, so I can turn feedback around quickly.
