Closed cunode closed 1 year ago
Similar story here. It behaves strange. In my case, it is possible that the device "hangs" too far away from the coordinator (linkquality ~7 when it sends movement updates) but I am not sure. It sometimes receives commands from HA but usually not. I even temporarily brought a Zigbee socket outlet (linkquality ~56) 3m away from it (to work as a mesh repeater) but it does not help.
Zigbee2MQTT:error` 2022-06-11 19:37:09: Publish 'set' 'state' to '0xa4c138f39ace9565' failed: 'Error: Command 0xa4c138f39ace9565/1 closuresWindowCovering.stop({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
Zigbee2MQTT:error 2022-06-11 19:37:21: Publish 'set' 'state' to '0xa4c138f39ace9565' failed: 'Error: Command 0xa4c138f39ace9565/1 closuresWindowCovering.upOpen({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
Zigbee2MQTT:error 2022-06-11 19:37:33: Publish 'set' 'state' to '0xa4c138f39ace9565' failed: 'Error: Command 0xa4c138f39ace9565/1 closuresWindowCovering.stop({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))
I flashed my old CC2531 with router firmware and put it 2m away from my Lonsonho QS-Zigbee-C03. I also flashed my SLAESH coordinator with CC2652RB_coordinator_20220219.hex. No improvements. For a moment the linkquality jumped from 7-14 to 130-140 and the curtain could be operated remotely but my happiness did not last longer than 5 mins. It went back to linkquality 5-15 even if a router (CC2135) is hanging 2m away from the curtain module. Let me stress that the router is reporting linkquality 130-140 so quite good. Lonsonho QS-Zigbee-C03 located 2m away from it reports linkquality which is 10 times smaller.
Same issue here...
System:
I get the 'No network route' (205))' on all seven of the devices, but it happens more often on the ones with lower LQI. The only way to fix the problem is by resetting the device (manually hit the UP switch 5 times).
What's interesting is that Z2M receives state events, even when it can't send commands. The following is a combination of the Z2M Log and MQTT Log. You can see MQTT is aware that I manually closed and opened the cover, even though it's not working from HA:
Zigbee2MQTT:error 2022-06-19 18:18:56: Publish 'set' 'state' to 'P2 Habitacion Matrimonio Persiana' failed: 'Error: Command 0xa4c138d5c1078887/1 closuresWindowCovering.downClose({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
Zigbee2MQTT:error 2022-06-19 18:19:08: Publish 'set' 'state' to 'P2 Habitacion Matrimonio Persiana' failed: 'Error: Command 0xa4c138d5c1078887/1 closuresWindowCovering.stop({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
Zigbee2MQTT:error 2022-06-19 18:19:20: Publish 'set' 'state' to 'P2 Habitacion Matrimonio Persiana' failed: 'Error: Command 0xa4c138d5c1078887/1 closuresWindowCovering.upOpen({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
18:19:27 - P2 Habitacion Matrimonio Persiana moving changed to DOWN
18:19:56 - P2 Habitacion Matrimonio Persiana moving changed to STOP
18:19:57 - P2 Habitacion Matrimonio Persiana was closed
18:38:00 - P2 Habitacion Matrimonio Persiana moving changed to UP
18:38:01 - P2 Habitacion Matrimonio Persiana was opened
18:38:29 - P2 Habitacion Matrimonio Persiana moving changed to STOP
Zigbee2MQTT:error 2022-06-19 18:41:23: Publish 'set' 'state' to 'P2 Habitacion Matrimonio Persiana' failed: 'Error: Command 0xa4c138d5c1078887/1 closuresWindowCovering.upOpen({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
Zigbee2MQTT:error 2022-06-19 18:41:34: Publish 'set' 'state' to 'P2 Habitacion Matrimonio Persiana' failed: 'Error: Command 0xa4c138d5c1078887/1 closuresWindowCovering.upOpen({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
There have been a few issues posted with 'No network route' (205). There's even a report (#12468) of the issue being fixed by switching from a Sonoff to a Slaesh stick. However, we can rule that out based on @torwanbukaj's experience.
Just a little update from my side. I dismantled my module and switched to a WiFi-driven which I tasmotized. So far so good. In the meantime, out of curiosity I "hanged" my QS-Zigbee-CP03 a few meters from the coordinator and everything was working fine for a few hours (linkquality good>140, the device fully communicative, no lags etc). Then I disconnected it and it's waiting for better times. So for me, it looks like the device struggle in a scenario with routers, hanging far away from the coordinator. I do not know if you noticed, it sends (when it sends something) some "backlight" attributes. This initially integrated even in my Home Assistant but disappeared after HA image update. It suggests that the firmware may be coming from some other device (most likely Tuya in this case). Maybe something was wrongly ported by the manufacturer (firmware)?
I still have hope in my QS-Zigbee-CP03. And as you can see above, the problem is intermittent which could indicate poor signal quality despite the reasonably high LQI. I would love to debug the communication between the coordinator or any router and the CP03, I suspect the problem could also be a timeout which kicks in too early. Any help on how to debug would be appreciated.
I still have hope in my QS-Zigbee-CP03. And as you can see above, the problem is intermittent which could indicate poor signal quality despite the reasonably high LQI. I would love to debug the communication between the coordinator or any router and the CP03, I suspect the problem could also be a timeout which kicks in too early. Any help on how to debug would be appreciated.
Yes, I'd also prefer not to replace the 10 devices I bought. Unfortunately I'm not much of a programmer, so I can't help with the debugging. I was thinking about testing the devices with ZHA instead of Z2M to check if the problem persists. At least that would help narrow down the issue. I'll see if I can make some time over the weekend.
I turned on debugging in my configuration.yaml
log_level: debug
and amended some device parameters (retain, qos, and retention):
'0xa4c1385b260f0939': friendly_name: Store SZ Sued description: '0xa4c1385b260f0939' retain: true qos: 2 retention: 60 homeassistant: {} legacy: false
Unfortunately, no significant improvement. When I do a network scan, the log file shows:
warn 2022-06-23 20:45:03: Failed to ping 'Store SZ Sued' (attempt 1/1, Read 0xa4c1385b260f0939/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205)))
debug 2022-06-23 20:45:06: Active device 'Store SZ Sued' was last seen '67.50' minutes ago.
warn 2022-06-23 20:45:09: Failed to ping 'Store SZ Sued' (attempt 1/1, Read 0xa4c1385b260f0939/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205)))
Without any change in the configuration or the setup, an hour later, the device is seen again:
debug 2022-06-23 21:41:50: Received Zigbee message from 'Store SZ Sued', type 'read', cluster 'genTime', data '["localTime"]' from endpoint 1 with groupID 0
debug 2022-06-23 21:41:50: Device 'Store SZ Sued' reconnected
info 2022-06-23 21:41:50: MQTT publish: topic 'zigbee2mqtt/Store SZ Sued/availability', payload 'online'
info 2022-06-23 21:41:50: MQTT publish: topic 'zigbee2mqtt/Storen/availability', payload 'online'
I have the same problem.
Same here
I found a trick, start a map creation, the device start to work again. If you attach a physical button it also works.
I'm observing similar issues on my smlight-slzb-05, if that is at all helpful.
Publish 'set' 'position' to 'Living Room Main Curtain' failed: 'Error: Write 0x04cf8cdf3c7396f2/1 genAnalogOutput({"85":{"value":75,"type":57}}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
I found a trick, start a map creation, the device start to work again. If you attach a physical button it also works.
What do you mean with "attach a physical button"?
I found a trick, start a map creation, the device start to work again. If you attach a physical button it also works.
What do you mean with "attach a physical button"?
I connected a switch to the device, so if you press the button (open or close) it works like a charm.
Connecting a switch to the device is like a passive open/close button and yes, this of course works. But this has nothing to do with automation. I don't want to activate a manual switch whenever my automation triggers the device.
Same issue here with TS0011_switch_module. The problem appears when it is connected through TS110E_1gang router. I receive status updates but I cannot set states ('No network route' (205) error). When it is connected directly to the coordinator it works fine.
Made the same observation: when connected directly to the coordinator and having an acceptable link quality (LQI) all works fine. But if only a router device with good link quality connects to the PC-03 I cannot send shutter commands, it then always gives the 'No network route' (205) error.
Could someone make a sniff of this starting from the point where it works (control it a few times) until it stops working? https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531
Could someone make a sniff of this starting from the point where it works (control it a few times) until it stops working? https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531
I don't have a CC2531. Is it doable with a SONOFF ZigBee 3.0 USB Dongle? If so, I could give it a shot. I have a couple of devices that seem to fail very consistently...
@galambert75 currently there is no sniffer fw available for the sonoff stick.
Same issue here with TS0011_switch_module. The problem appears when it is connected through TS110E_1gang router. I receive status updates but I cannot set states ('No network route' (205) error). When it is connected directly to the coordinator it works fine.
Another clue: If I connect TS0011_switch_module through TS0505B router it works without issues. I think TS110E_1gang is not working properly as a router.
@galambert75 currently there is no sniffer fw available for the sonoff stick.
So... is there anyone out there who owns a CC2531 and could provide the requested "sniff"?
I' afraid my CC2652RB cannot be used instead of a CC2531 as sniffer.
Want to summarize my observations so far:
i have now the same problem, I had problems to pair a ikea fyrtur, than I connected and disconnected a few times a ikea signal repeater, than this routing problem was starting at my side :/ i also deleted now the database, but have also problems to repair the sensors, they don't pair or interview is not working, (SONOFF ZigBee 3.0 USB Dongle) now I get the error: Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby
Started to get this error also a couple of days ago. Tried updating things and still doesn't work. My temperature and humidity sensors are reporting data but I can't control lights and switches any more.
Having same issue. Updated firmware on zzh!, updated HA, updated Zigbee2mqtt, moved router away from my rasp. Pi, restart, reboot everything - not working. Unplugged my IKEA socket, plugged in again. Everything works.... Wierd.. If you still havin problem, try to unplugg something and plug in again and see if it helps.
Again, since days have no connection to the QS-Zigbee-CP03 even it is in the same room as my CC2652RB coordinator. Persistently getting the 'No network route' (205) error. Have some additional information in the log file:
debug 2022-08-01 13:25:10: Error: Command 0xa4c1385b260f0939/1 closuresWindowCovering.downClose({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205)) at ZStackAdapter.sendZclFrameToEndpointInternal (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:414:23) at Queue.executeNext (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/utils/queue.ts:32:32)
Also noticed that even all my QS-Zigbee-CP03 are shown as Routers, none has a network connection to its neighbor QS-Zigbee-CP03 even they are separated a few centimeters only.
I‘m seeing the same problem. Adding QS-Zigbee-CP03 to the network works as long as they are connected directly to the coordinator (SONOFF ZigBee 3.0 USB Dongle), once they are only connected to other routers I get 205 errors.
I started getting this a couple of weeks ago. CC2652R. Devices won't respond under HA but work fine on Node-RED automations. Walk into the bedroom, one light comes on instead of 2. 'No network route' (205)) on the one that doesn't work. Walk out. Both lights go out as they should. Walk back in. The other light works this time. This is on a system that's been working fine for 18 months. Checked wifi last night and no overlaps.
I have the same problem with Tuya TS0001 and TS0002. I spend many hours on looking the problem.
Publish 'set' 'state' to 'Tuya Hall Relay 1' failed: 'Error: Command 0xa4c138522e49c56c/1 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
But I can read a state of light, when I am used physical button connected to the device. Its working like one direction. Problem is only when are two devices on network. With one devices working without problem. I thinking that problem is when few devices make a connection between two routers. Maybe its a Tuya problem or Zigbee2Mqtt.
I will change this zigbee devices to WiFi module - Tasmota.
I'm having the same random problem from Moes MS-104BZ and Lonsonho QS-Zigbee-S05-LN. What I noticed is that when this error occurs the device is not directly connected with the coordinator (they don't have any end device connected since they are connected with IKEA and Aqara routers). If I repair the module again it start working again for a random amount of time, it can be hours or days. Unfortunately it's not easy to find any other 2 gang switch with the same dimesions (or smaller) that are know to always work..
Actually I'm using the SONOFF USB 3.0 plus with the lastes zstack firmware and Z2M is the 1.27.2-1
After much messing about removing devices and adding them back, I bit the bullet and changed ZigBee channels from 11 to 25. Everything is 100% stable now.
Would it be more useful if it was NOT ch11 by default?
I changed channel too from default 11 to 25. Problem still exists, but it's little better. On 11 channel I had communication lost after 1 day. On channel 25 working about 2 days.
I used ch25 since day one because before setting the ZigBee network I've scanned multiple times the WiFi AP around me and the channel 25 seemed the best for my environment. I had a pretty stable network for about a month than the error started to occur once every 1 or 2 days with different devices, mostly tuya switch modules (Moes and similar) and osram/lightify RGB bulbs, very occasionally with one Ikea socket. I've routed the network triyng to keep as much "good" routers as possible connected with che coordinator and to link every end devices with the nearest and most suitable router available (for example aqara sensors with aqara smart plugs and Ikea buttons with Ikea bulbs)
After some further testing, I wanted to report some findings to the round. Yesterday I stopped the Z2M service and added all 7 of my QS-Zigbee-CP03 devices via ZHA. They have now been running for > 24 hours with no interruptions, which is longer than I had observed with Z2M.
Since all other components are unchanged (coordinator device & firmware, router device & firmware, ZigBee devices, location, etc.) it would seem the 'No network route' (205))' issue is specific to either Z2M or MQTT.
OTOH, I am experiencing an issue with ZHA which I will report there. On some of the devices (apparently the ones connected via router and not directly to the coordinator), the position of the shutters seems to be reset to "closed" after a few minutes (~10).
Has someone tried to switch to conbee and see if things gets better?
I came from deconz with conbee II and I switched to zigbee2mqtt and sonoff coordinator after one year because the network was way too unstable. It's way more stable with z2m even with this error that occurs from time to time
I switched to QS-Zigbee-C01 devices and still see the issue. At the moment, I have 3 devices connected - one works , the other two show the 205 error when I try to control them. All three devices still publish status updates, i.e. if I raise/lower the blinders manually I can see their state in the Z2M web UI.
I noticed that contrary to @sk8er000's comment, the two devices which DO NOT work are connected directly to the coordinator, albeit with a horrible link quality. The one connected only to other routers is the one which works without issues:
So you're able to use AZi Rolladen rechts but not Azi Rolladen links, right? It's definitely weird.
I've since rebuilt my network (forgot to change the network key when I originally set it up). The problem still exists in the "Bad Rolladen" actor. BUT: I've tried the workaround described in https://github.com/Koenkk/zigbee2mqtt/issues/9249#issuecomment-1004037749 and it seems to apply here as well. I've added the actor to a group (while it was responsive) and I can now control (open/close/stop/go to percentage, etc...) the group INCLUDING the "Bad Rolladen" actor even when accessing it directly yields 205 errors.
4 days since the change to ZHA and no connectivity issues at all. There was even a blackout and once power was restored all seven devices were immediately visible.
After some further testing, I wanted to report some findings to the round. Yesterday I stopped the Z2M service and added all 7 of my QS-Zigbee-CP03 devices via ZHA. They have now been running for > 24 hours with no interruptions, which is longer than I had observed with Z2M.
Since all other components are unchanged (coordinator device & firmware, router device & firmware, ZigBee devices, location, etc.) it would seem the 'No network route' (205))' issue is specific to either Z2M or MQTT.
OTOH, I am experiencing an issue with ZHA which I will report there. On some of the devices (apparently the ones connected via router and not directly to the coordinator), the position of the shutters seems to be reset to "closed" after a few minutes (~10).
Same problem here with Lonsonho devices (_TZ3210_wdexaypg) on CC2652P
The wifi (2.4) is moved to the upper channels, so no frequency overlap. The dimmers losing connectivity very often (several times a day). Tried different availability settings - with no effect. After repair - they work for some time, but the problem returns in couple hours.
Today I have noticed the following : if you turn on/off 3-4 times, the dimmer wont turn on after couple retries, however, the zigbee2mqqt says it turned on. I managed it to solve by send turn on command different different brightnes values in a loop.
However, the connectivity loss is ruining this trick :)
I checked the map, the problem is : both theese dimmers (3210) don't have direct connection to the coordinator. They connected via routers only. Probably this is the reason. Nonetheless, I can sniff traffic/send sum debug info, just point me to the instructions what to collect.
Got same problem with some TS130F (TZ3000_4uuaja4a) and Coordinator sonoff zigbee 3.0 dongle plus (with latest firmware)
I noticed, that sending the connection issue is unidirectional, for example sending command from zigbee2mqtt
app I get the "No network route" error, but if I click physically in the button it immediately updates the value back the zigbee2mqtt
dashboard..
So it means that in fact there is connection between the TS130F
and the Coordinator but from Coordinator to the TS130F
not.
Another fun fact, doing a reset it comes immediately back on but after after a couple hours it starts with this connection issue again, and if you guys see the historic below from the home assistant app, you can notice that it disconnects for some time then it comes back on for few minutes and goes off again repeatedly:
Network link is not the issue because I have next to this device more zigbee devices and they work just fine, I also tried adding more routers (more sonoff zigbee 3.0 dongle plus) but no success
I've been running the workaround I described above (single device groups) for a week now and it has been stable. I therefore strongly believe this is the same issue as #9249
Some more context from my end:
- I am using a Sonoff 3.0 with latest firmware
Any help appreciated - I'm going a bit crazy having to physically unplug my devices at night to go to bed.
Welp, zigbee channel 11 interferes with WiFi 2.4Ghz channel 1, didn't realize they were labeled differently. Ignore me
My CP2102/CP2109 also stopped working. Error: "No network route". I see LQI status on some devices other showing nothing anymore. Seems to be a general problem.
Without a sniff I cannot do anything: https://github.com/Koenkk/zigbee2mqtt/issues/12774#issuecomment-1177633964
I have the exact same problem. The devices always show in the Map with multiple routes but goes offline intermittantly. I would love to provide a sniff, but my units are at a remote site overseas.
Blind_Bedroom_left is the problematic one.
I can also confirm the devices respond to "Group" messages as per other comments on this thread.
I've just noticed that all my CP03 devices (even the ones that work) only ever show one number on the network map for connections other than to the coordinator. For example in the screenshot above;
Blind_utility has a 88/87 connection to the coordinator, but just 67 connection to the Plug_kitchen
Blind_bedroom_left has a very poor connection to the coordinator, reading 2 (which i would expect) but again showing just a 112 to the Plug_bedroom.
This pattern is repeated for all CP03 devices.
Also I noticed there is a never a connection shown from CP03 device to CP03 device (blind to blind), which is odd given I have some a few feet away from each other.
It strikes me these units only work when there is a strong connection to the coordinator.
Koenkk, i am more than happy to purchase a couple of these for you if it would help?
Koenkk, i am more than happy to purchase a couple of these for you if it would help?
It would be better if you buy a sniffer yourself, it is not guaranteed that the issue also occurs in my network.
What happened?
When communicating with a QS-Zigbee-CP03 curtain module I frequently get the following error message:
error 2022-06-10 07:01:34: Publish 'set' 'state' to 'Store SZ Sued' failed: 'Error: Command 0xa4c1385b260f0939/1 closuresWindowCovering.upOpen({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))'
Usually, when resubmitting the same command multiple times, the device finally executes it as expected. But there is a 50% chance to fail and hence my automation is absolutely unreliable.
Based on the finding in #11539 (QS-Zigbee-CP03) I switched on May 13, 2022 to the Zigbee2MQTT dev branch for Linux. I also use the latest firmware for my SLAESH coordinator (CC2652RB_coordinator_20220219.hex) together with a 3 dB antenna connected to a Raspberry Pi 4 running Debian GNU/Linux 11 (bullseye).
What did you expect to happen?
Communication should be reliable as there are short distances to the coordinator (~6 meter) or the next router (~3 meter). The link quality in the Zigbee2MQTT Map never shows zero and the device's Availability is shown as "Online". Any help is highly appreciated.
How to reproduce it (minimal and precise)
Problem is intermittent and hence cannot reproduce with clear steps.
Zigbee2MQTT version
Zigbee2MQTT version 1.25.1-dev (commit #bc5fd1a5)
Adapter firmware version
CC2652RB_coordinator_20220219.hex
Adapter
CC2652RB development stick
Debug log
No response