ZHA: LDS ZB-ONOFFPlug-D0005 routers become one-way reachable and remain "available" while commands fail with APS_NO_ACK / NWK_NO_ROUTE

### The problem

### The problem

I am investigating a recurring ZHA reliability issue which is now strongly
concentrated around several LDS `ZB-ONOFFPlug-D0005` mains-powered Zigbee
routers.

This is separate from my existing Home Assistant Core issue #181409 concerning
a Home Assistant Connect ZBT-2 / bellows coordinator failure associated with
Home Assistant/ZHA backup activity:

https://github.com/home-assistant/core/issues/181409

I have since migrated the existing Zigbee network from the ZBT-2 to a Texas
Instruments CC2652P coordinator using ZNP/Z-Stack.

The current TI coordinator remains online and continues carrying large amounts
of successful Zigbee traffic. I am no longer seeing the old bellows/EZSP/ASH
NCP failure signature.

The remaining problem is different:

Individual `ZB-ONOFFPlug-D0005` routers become unreachable from the coordinator,
or effectively one-way reachable, while ZHA can continue to show them as
available because the coordinator is still receiving occasional inbound traffic
from them.

Several examples have now occurred.

---

### System

Home Assistant installation: Home Assistant OS

Home Assistant Core: 2026.9.1
Supervisor: 2026.09.0
Home Assistant OS: 18.2
Architecture: aarch64
Python: 3.14.6

ZHA: 2.2.1
zigpy: 2.1.0
zha-quirks: 2.2.1

Coordinator: SONOFF ZBDongle-P
Radio: Texas Instruments CC2652P
Radio stack: ZNP / Z-Stack
Coordinator firmware: 20240710

Zigbee channel: 15
Network size: approximately 85-90 devices
Approximately 26-28 routers

ZHA availability configuration:
- mains-powered devices unavailable after 2 hours
- battery-powered devices unavailable after 6 hours
- refresh mains-powered devices state on startup disabled

The coordinator was originally a Home Assistant Connect ZBT-2, but the network
was migrated using ZHA's supported radio migration process. Existing Zigbee
network identity/device records/entities were preserved.

The ZBDongle-P initially shipped with Z-Stack 20210708 and has subsequently
been updated to 20240710.

---

### Affected device family

Manufacturer: LDS
Model: ZB-ONOFFPlug-D0005
Device type: Router
Power source: Mains
Device firmware: 0x21186230

I have several of these plugs and multiple examples have now demonstrated
abnormal behaviour.

---

### Case 1: one router accounted for the majority of NWK_NO_ROUTE errors

Device:

Friendly name:
`Plug - BLUEIRIS PC - zigbee Power kill`

Manufacturer/model:
`LDS ZB-ONOFFPlug-D0005`

IEEE:
`EC:1B:BD:FF:FE:3F:88:FF`

Old NWK:
`0xB4FB`

During one ZHA/ZNP debug capture I counted approximately:

- 7,557 successful AF confirmations
- 1,263 NWK_NO_ROUTE
- 319 APS_NO_ACK
- 2 MAC_NO_ACK

Of the 1,263 NWK_NO_ROUTE results, 1,051 (approximately 83%) were attempts
to reach `0xB4FB`.

ZHA repeatedly performed route discovery/retries for this device.

However the device was not completely silent: traffic from it could still
occasionally reach the coordinator, meaning Last seen/LQI could remain current.

I then opened ZHA "Add device" and put the EXISTING physical device back into
normal join/pairing mode WITHOUT deleting it.

ZHA recognised the existing IEEE/device and preserved its Home Assistant
entities.

The network address changed:

`0xB4FB -> 0xB983`

After that rejoin, normal two-way communication resumed and the very large
`0xB4FB` NWK_NO_ROUTE error stream disappeared.

---

### Case 2: one-way communication while ZHA still reports available

Another device:

Friendly name:
`Plug - #5 - Lamp Under Stairs`

Manufacturer/model:
`LDS ZB-ONOFFPlug-D0005`

IEEE:
`CC:CC:CC:FF:FE:3A:0E:E9`

NWK while failed:
`0x2895`

This device became uncontrollable.

Attempting `switch.turn_on` from Home Assistant produced:

`Failed to perform the action switch/turn_on. Failed to send request: device did not respond`

However ZHA diagnostics still reported:

- available: true
- device type: Router
- recent Last seen
- LQI approximately 112-116

The debug log explains the apparently contradictory state.

The plug continued periodically transmitting towards the coordinator, including
Time cluster requests roughly every 30 minutes.

Those inbound packets were successfully received and therefore refreshed
the device Last seen value.

But replies/outbound traffic from the coordinator to the plug repeatedly failed
with `APS_NO_ACK`.

In other words:

device -> coordinator:
still works sufficiently for inbound packets / Last seen

coordinator -> device:
commands/replies fail

This can leave a device functionally unusable while ZHA still reports it
available indefinitely.

---

### Case 3: another same-model router failed while still shown available

Device:

Friendly name:
`Plug - #4 - Driveway Down LEDs`

Manufacturer/model:
`LDS ZB-ONOFFPlug-D0005`

IEEE:
`CC:CC:CC:FF:FE:3C:C4:E9`

NWK:
`0xA31F`

The device became unresponsive while Home Assistant/ZHA was still showing it
available.

Important: I later physically unplugged this device at approximately 21:00,
but ONLY because it had already failed.

Its failure therefore occurred before it was removed from mains power.

Earlier debug logging had already shown repeated route discovery /
`NWK_NO_ROUTE` behaviour involving `0xA31F`, while other traffic from the
device had previously still been observed.

---

### Additional same-model history

Another LDS `ZB-ONOFFPlug-D0005`, used as:

`Plug - #3 - Afan's PC`

has also previously been among the devices which became unresponsive.

This means several of the clearest router failures are now concentrated on
the same device model/firmware family.

I am not claiming yet that every `ZB-ONOFFPlug-D0005` is defective or that
these plugs explain every unrelated end-device failure.

However the repeated concentration is now significant.

---

### Availability problem

An important user-visible problem is that the ZHA availability status does not
necessarily reveal this failure.

My mains-powered availability timeout is 2 hours.

If one of these routers continues sending an occasional inbound packet, ZHA
updates Last seen and keeps the device available.

The device can therefore show as available even though coordinator-to-device
communication is repeatedly failing and Home Assistant cannot control it.

The top-level ZHA "X devices offline" count consequently understates the number
of functionally failed devices.

This is particularly concerning on a large automation network because a device
may appear healthy until an automation actually tries to use it.

---

### Recovery behaviour

The most reliable recovery so far is:

1. Do NOT delete the device from ZHA.
2. Open ZHA "Add device".
3. Put the existing physical plug into normal join/pairing mode.
4. ZHA recognises the existing IEEE/device.
5. Existing entities/automations remain intact.

On the Blue Iris plug this resulted in a new NWK address and immediately restored
normal two-way communication.

I am currently reproducing the same test with another failed plug.

---

### Why I do not currently think this is a coordinator-wide failure

During the current TI/ZNP failures:

- the coordinator remains connected
- normal Zigbee traffic from many other devices continues
- thousands of successful transmissions occur
- there is no bellows/ASH path because this is a TI CC2652P coordinator
- I have not observed the previous
`ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT` / NCP / watchdog failure signature

The failures appear concentrated on specific device/NWK destinations.

---

### Possibly related reports for the same device

There are independent Zigbee2MQTT reports involving the exact same
`ZB-ONOFFPlug-D0005` / SmartThings GP-WOU019BBDWG device:

https://github.com/Koenkk/zigbee2mqtt/issues/18315

and:

https://github.com/Koenkk/zigbee2mqtt/issues/32857

The August 2026 report is especially interesting because the device could remain
apparently healthy while its coordinator binding/reporting state had diverged,
and that system was also using a TI Z-Stack coordinator.

I am NOT claiming those reports prove the same underlying cause: their main
symptom was reporting/binding state rather than my `NWK_NO_ROUTE` /
`APS_NO_ACK` behaviour.

I include them because they may indicate persistent-state problems specific to
this device family.

---

### Questions

1. Is it expected that any inbound Zigbee traffic refreshes ZHA availability even
when repeated coordinator-to-device transmissions are failing with
`APS_NO_ACK` / `NWK_NO_ROUTE`?

2. Does ZHA or zigpy currently maintain any distinction between:
- device heard from recently
- bidirectional communication confirmed?

3. Is there a supported method to force route/NWK repair for an existing router
without physically putting the device back into join mode?

4. Is there any known compatibility/problem history for
`LDS ZB-ONOFFPlug-D0005` / firmware `0x21186230` involving routing,
network-address state, bindings or reporting?

5. Could ZHA electrical-measurement polling of an already-stranded mains plug
materially amplify route-discovery/retry traffic?

6. Is the change of NWK address after the existing-device rejoin significant
evidence of stale route/address state, or would that normally be expected
during a rejoin?

7. Would the maintainers prefer this investigation to continue in Home Assistant
Core/ZHA, the external `zha` library, zigpy, or zigpy-znp?

---

### Related Home Assistant issue

My original ZBT-2 issue is:

#181409
ZHA / Connect ZBT-2 radio failure associated with Home Assistant backups –
devices remain disconnected and require rejoin

https://github.com/home-assistant/core/issues/181409

I now believe that issue and this one describe two separate problems.

The ZBT-2 issue contains a captured bellows/EZSP NCP failure.

The present issue remains reproducible after migrating the network to TI/ZNP and
is focused on individual router reachability/routing/availability.

---

### Diagnostics available

I have preserved:

- ZHA/ZNP debug log containing the `0xB4FB` NWK_NO_ROUTE concentration
- before-rejoin diagnostics for the Blue Iris plug at `0xB4FB`
- after-rejoin diagnostics for the same IEEE at `0xB983`
- Plug #5 diagnostics while it was showing available at `0x2895`
- debug log showing inbound traffic from `0x2895` while outbound messages receive
`APS_NO_ACK`
- Plug #4 diagnostics at `0xA31F`
- earlier debug log containing route discovery / NWK_NO_ROUTE involving `0xA31F`

I can provide additional targeted logging/tests on request.

I have deliberately avoided deleting/re-pairing the devices or rebuilding the
Zigbee network so the failed state can be investigated.

### What version of Home Assistant Core has the issue?

core-2026.9.1

### What was the last working version of Home Assistant Core?

Unknown — the network was migrated from a different coordinator while investigating another issue.

### What type of installation are you running?

Home Assistant OS

### Integration causing the issue

Zigbee Home Automation (ZHA)

### Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha/

### Diagnostics information

Device diagnostics and ZHA debug logs available; see issue body.

### Example YAML snippet

```yaml

```

### Anything in the logs that might be useful for us?

```txt

```

### Additional information

Related but separate issue: #181409