-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error while sending frame: TXStatus.NWK_ROUTE_DISCOVERY_FAILED #169
Comments
I have not running My RaspBee I under ZHA but is having it in native deCONZ so i cant saying its right or wrong. But i think the |
I tested moving from ConBee to ConBee II using Phoscon long ago and is confirmed to be working. You did everything correctly. NWK_ROUTE_DISCOVERY_FAILED could be normal some times, other times it indicates too much RF noise. 1st and foremost: USE AN USB CABLE EXTENSION for ConBee. Then leave the ConBee running for 1-2 hours, after power cycle the lights and try controlling those lights again. |
If you have any Ikea mains powered devices, powercycle those too |
1 similar comment
If you have any Ikea mains powered devices, powercycle those too |
Link and network keys are the same, the JSON from the Phoscon UI backup is not changing on this. I noticed the frameCounter counter is growing over time. So, I backup/restore before every migration attempt.
I read this recommendation on various threads about the Conbee so I used a 0.3m USB extension cable very early but to be sure RF noise was not significant I tried 2 things:
I didn't let the test running for so long. When I rollback to the Raspbee2 after a migration failure, all devices reconnect in less than a minute, so I didn't imagine there is some time magic. I waited everyone was asleep to run a 2-3h test as you suggested. I rebooted several lights (not all). After few minutes, some Aqara sensors starts reporting values and temperature/illuminance/humidity get populated on HomeAssistant. Then I tried to pair a new device, and I was successful. This new device works immediately, while all others not. It was a remote I used to trigger automation. Here is the logging when the button was pressed.
This led me to ask why this new paired remote doesn't get NWK_ROUTE_DISCOVERY_FAILED errors and works immediately? I finally roll-backed to the Raspbee2, where all devices get recognized in few minutes. |
Did you changing the MAC address of the CornBee II to the of the RaspBee II ? I dont knowing if you can see / edit it in the backup from deCONZ of you must do it in deCONZ GUI. The security frame counters can not going down only incensing and if its being negative (from that last OK frame) the device is silent ignoring the frame. I dont knowing how but Rasp/CornBee have one logic for rolling it forward after hard reboot of the coordinator but how its working is one secrete but shall being transparent in the firmware and it have working then you was putting the backup back to the RaspBee II. I have no perspective of you system is behaving if the you is getting NWK_ROUTE_DISCOVERY_FAILED for all treys communicating with devices on the network or only some devices like sleeping end devices. |
Yes, the MAC is part of cloning process and I checked it was correct several time as stated in the in my first post. Here is the diff of the zigpy-deconz read parameters at the HASS startup with the Raspbee2 and the cloned Conbee2. DEBUG (MainThread) [zigpy_deconz.api] Command Command.read_parameter (1, <NetworkParameter.protocol_version: 34>, b'')
-DEBUG (MainThread) [zigpy_deconz.api] Read parameter protocol_version response: [268]
+DEBUG (MainThread) [zigpy_deconz.api] Read parameter protocol_version response: [267]
DEBUG (MainThread) [zigpy_deconz.api] Command Command.read_parameter (1, <NetworkParameter.mac_address: 1>, b'')
DEBUG (MainThread) [zigpy_deconz.api] Read parameter mac_address response: [00:21:2e:01:23:45:67:89]
DEBUG (MainThread) [zigpy_deconz.api] Command Command.read_parameter (1, <NetworkParameter.aps_designed_coordinator: 9>, b'')
@@ -25,6 +25,6 @@
DEBUG (MainThread) [zigpy_deconz.api] Command Command.read_parameter (1, <NetworkParameter.current_channel: 28>, b'')
DEBUG (MainThread) [zigpy_deconz.api] Read parameter current_channel response: [15]
DEBUG (MainThread) [zigpy_deconz.api] Command Command.read_parameter (1, <NetworkParameter.protocol_version: 34>, b'')
-DEBUG (MainThread) [zigpy_deconz.api] Read parameter protocol_version response: [268]
+DEBUG (MainThread) [zigpy_deconz.api] Read parameter protocol_version response: [267]
DEBUG (MainThread) [zigpy_deconz.api] Command Command.read_parameter (1, <NetworkParameter.nwk_update_id: 36>, b'')
DEBUG (MainThread) [zigpy_deconz.api] Read parameter nwk_update_id response: [0] So from a zigpy point-of-view, except the protocol_version they are equal.
I got NWK_ROUTE_DISCOVERY_FAILED for End and Router devices. Only newly paired devices works. @Adminiuga I tried a second time to powercycle all mains devices and wait 3-4 hours. No magic happens.
while others devices still have issue NWK_ROUTE_DISCOVERY_FAILED.
Is zigpy_deconz should log errors if there is a key decryption error? |
If reading the deCONZ error code https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log#0xd0-no-route-to-the-receiver-exists all your "old routers" is not playing in the network. |
This is likely too late to be helpful, but I had a similar issue with a Conbee II not actually accepting a frame counter write. The migration seemingly "worked" but the frame counter was never actually updated, causing outgoing requests from the device to be rejected by routers on the network. If you still have both devices and want to try this again, upgrade them both to the latest firmware and try migrating once more with zigpy/zigpy-cli#2. If your Conbee has the same bug as mine, in theory performing a backup with the Conbee still plugged in will yield nearly identical network settings to the Raspbee (+/- a few hundred for the frame counter), but unplugging it and plugging it back in will cause the frame counter in a new backup to "reset" to its old value. |
Hi I have a similar problem with my Conbee II and ZHA. my log are floud with thos error:
|
@claudegel Try the latest Home Assistant beta. There have been a lot of changes to the Conbee radio library that may help. |
I just notice that my Conbee is at firmware 0x264a0700 which is an old one I think. How could I upgrade it to latest firmware in HA |
I've flashed the dongle and same result in the log. But since last HA update, 2024.1.1 it's gone. back to normal I hope. |
The last HA update fix it. no more error message in log. Thank you |
The background context is a migration from a Raspberry Pi 4 ZHA setup with a Raspbee2 radio to a Conbee2 radio module. There is around 100 Zigbee devices paired.
The Raspbee2 zigbee parameters has been cloned to the Conbee2 via the Phoscon UI.
MacAddress, TC Address, Network Key, TC Link Key, NWK Update ID and Channel Mask are equals after cloning.
I triple checked this via the zigpy-cli (nb. do not display the Network Key), debug output of homeassitant and Phoscon Restore/Backup JSON.
This is the JSON exported as backup for both keys:
So both radio modules should be equal and there are threads123 about success stories with this method using the deconz plugin.
The Conbee2 path is
/dev/ttyACM0
while the Raspbee2 path is/dev/ttyAMA0
, so after the path being adjusted in the.storage/core.config_entries
and HomeAssistant restarted, I get these errors :The NWK_ROUTE_DISCOVERY_FAILED is defined in https://github.com/zigpy/zigpy/blob/468b533eda9216dfc679acd6d542849206daa87d/zigpy/types/named.py#L474 and the comment says:
I'm a bit stuck by this error message as I don't know where to look next to fix a routing issue.
Footnotes
https://community.home-assistant.io/t/deconz-please-help-rpi-raspbee-nuc-conbee/193111 ↩
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2742 ↩
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1441 ↩
The text was updated successfully, but these errors were encountered: