Symptom
I cannot pair any new Zigbee devices to my ZHA network, regardless of device type, coordinator, or pairing technique.
Permit-join is issued correctly and acknowledged at the protocol level, but no device ever appears, no EndDeviceAnnceInd or TcDevInd is ever logged, and no new IEEE address ever surfaces in debug logs.
The bulb under test does not appear to be transmitting any association request that any router or coordinator can hear, despite being in confirmed factory-reset state.
This started gradually around January and has progressed to the point where no new device will pair under any conditions - Ive tried devices from different manufacturers and of different types. I someitmes manage to get previously paired devices to repair, but these have to be literally sat on top of the router!
Setup
Home Assistant OS 17.2, Core 2026.4.2, Supervisor 2026.04.0
Raspberry Pi (HAOS, Docker 29.3.1)
ZHA integration, currently on Home Assistant Connect ZBT-2 (Silicon Labs EFR32MG24, NCP firmware 7.5.1.0 build 0)
Migrated from Sonoff ZBDongle-P (TI CC2652P, Z-Stack) yesterday in case the previous coordinator was the issue. Migration succeeded cleanly; mesh is healthy.
bellows 0.49.0, zigpy 1.2.2, zha 1.1.2, zhaquirks 1.1.1
Channel 20, PAN 1045
97 devices on network, all mains routers and almost all battery devices currently available
USB extension cable in use, dongle well clear of WiFi router and any USB 3.0 sources
Device under test
THIRDREALITY ZL4 A19 colour bulb (E27, 2700-6500K, 810lm). Four different bulbs from a brand-new 4-pack tested independently, identical behaviour.
Reset performed using strict 1-second cadence, 5 cycles, with 30+ minute aging-mode timeout between attempts.
What I have ruled out
Coordinator hardware: tested both Sonoff ZBDongle-P and HA Connect ZBT-2, identical symptoms
Coordinator radio firmware: tested both TI Z-Stack and Silabs EmberZNet 7.5.1.0
Channel: was channel 15, moved to channel 20 weeks ago, no improvement
USB interference: extension cable in use
Mesh health: 97 devices, dense mesh, healthy LQI 92-204 / RSSI -49 to -77 dBm on existing devices
ZHA database: /config/zigbee.db is 2.4MB, healthy, no corruption indicators
HA software: fully up to date
HA process state: multiple restarts and a host reboot tried
Bulb hardware: four different bulbs, identical behaviour
Bulb reset procedure: confirmed 30-min aging-mode timeout, strict 1-second cadence, multiple attempts
Pairing path: tried via router (Innr plug, Hue bulb), via global zha.permit, and at touching distance to coordinator
Trust centre key/address table size: bumped from default 12 to 128 via ezsp_config (see below)
Trust centre table changes already applied
After noticing the default key_table size of 12 on a 97-device network, I applied:
yamlzha:
zigpy_config:
ezsp_config:
CONFIG_KEY_TABLE_SIZE: 128
CONFIG_ADDRESS_TABLE_SIZE: 128
CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE: 4
CONFIG_SOURCE_ROUTE_TABLE_SIZE: 200
The diagnostic confirms these values are passed to bellows on init. I have not yet verified from the bellows startup log whether the NCP firmware accepted them or capped silently — happy to grab the log if useful.
What logs show during a pairing attempt
13:23:17.814 Sent 'mgmt_permit_joining_req' to 00:17:88:01:09:2c:2e:f7 Status=SUCCESS
13:24:12.846 Sent 'mgmt_permit_joining_req' to a4:c1:38:5c:2a:6f:68:c6 Status=SUCCESS
Followed by nothing for the entire 4.5 minute window. No new IEEE addresses anywhere. No EndDeviceAnnceInd. No TcDevInd. No association requests. No errors. No rejections. The pairing window opens correctly, the routers acknowledge, and then absolutely nothing happens.
A small number of bellows send_packet errors with ZIGBEE_SEND_UNICAST_ROUTE_DISCOVERY_UNDERWAY and occasional TimeoutError are present in the log but only during the immediate post-migration window, not during pairing attempts. APS unicast failure rate is around 30% which suggests some routing churn but the mesh is functional.
Network counters of note (post-restart)
MAC_TX_UNICAST_FAILED: 69 / SUCCESS: 509 / RETRY: 397
APS_DATA_TX_UNICAST_FAILED: 122 / SUCCESS: 264
PHY_CCA_FAIL_COUNT: 116
NEIGHBOR_REMOVED: 32 / NEIGHBOR_STALE: 18
EZSP_FREE_BUFFERS: 251
So, thats where im at - I basically cant pair any new devices at all, but the current devices all seem to work more or less fine (occasional drop outs, but nothing horrific).
The diagnostic shows key_table and route_table as a count of current entries, not configured maximum. Is there a way to confirm from inside HA whether the NCP firmware actually accepted the increased CONFIG_KEY_TABLE_SIZE: 128, or was it silently capped?
Is there a known EmberZNet trust centre policy issue post-migration where joins are silently rejected at a layer below where bellows logs? I’m seeing MgmtPermitJoinReq Status=SUCCESS but I don’t know how to verify the NCP-level join policy is actually ALLOW_JOINS.
Has anyone else with a large (80+) device network on ZBT-2 / EmberZNet seen progressive pairing degradation? My symptoms are consistent with a gradually filling resource somewhere on the coordinator.
Are there any other ezsp_config values worth tuning for a network of this size — CONFIG_TX_POWER_MODE, CONFIG_END_DEVICE_POLL_TIMEOUT, CONFIG_PACKET_BUFFER_COUNT, etc?
Any suggestions for capturing what the bulb is actually transmitting? I’d like to confirm it’s broadcasting beacon requests at all
I have full debug-level ZHA logs from before and after migration, the diagnostic JSON, and the network visualisation if anyone wants to dig into specifics. Happy to provide them.
Basically can anyone suggest anything i can try? Ive been down a rabbit hole here, and then i enlisted claude who took me down several other rabbit holes and now im stuck!
Thanks 