QS-Zigbee-CP03: intermittent error: 'No network route' (205)

[cunode]

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

[torwanbukaj]

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))

[torwanbukaj]

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.

[galambert75]

Same issue here...

System:

• Z2M: 1.25.2-1 (Home Assistant Add-on)
• Sonoff ZigBee 3.0 USB Dongle (CC1352P2_CC2652P_launchpad_coordinator_20220219)
• RaspberryPI 4 Model B 8GB
• Home Assitant: core-2022.6.6, supervisor-2022.05.3, OS 8.2
• 7x QS-Zigbee-CP03 - all connected directly to the coordinator (I think... When I try to load the Map, it's stuck searching). LQI on the devices ranges from 91 to 10 (list below).

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.

[torwanbukaj]

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)?

[cunode]

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.

[galambert75]

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.

[cunode]

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)))

[cunode]

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'

[magostinelli]

I have the same problem.

[kevinderek]

Same here

[magostinelli]

I found a trick, start a map creation, the device start to work again. If you attach a physical button it also works.

[nickles-lee]

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))'

[galambert75]

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"?

[magostinelli]

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.

[cunode]

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.

[fvillena]

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.

[cunode]

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.

[Koenkk]

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

[galambert75]

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...

[Koenkk]

@galambert75 currently there is no sniffer fw available for the sonoff stick.

[fvillena]

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]

@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"?

[cunode]

I' afraid my CC2652RB cannot be used instead of a CC2531 as sniffer.

Want to summarize my observations so far:

1. in the Devices list, the C03 is always reported as "Online" with a reasonable LQI (e.g. "20" currently). The LQI is changing frequently even though the physical configuration is not changing.
2. in the Map, the C03 is as always reported as connected to the Coordinator as well as to 2 Routers in my network. When getting the 'No network route' (205) error I usually have only 1 Link quality number (e.g. "16"), when it is working I have 2 Link quality numbers (e.g. "20/24")
3. When using the manual up/down buttons I have connected to the device, the Position information is always updated
4. a second C03 in the same room as the Coordinator works 100% reliable. To exclude a hardware issue I swapped this device with the one working unreliable in the room above (separated by a concrete floor). Result was the same: device in same room as Coordinator works now perfectly, the one in the room above is unreliable.

[mpuff]

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

[yavinmaster]

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.

[Brkie]

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.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[johnjoemorgan]

Hope this helps anyone with the 205 error. Had the same issue appear with a Zemismart Tuya light switch. Forcing removal and re-adding to the coordinator (Sonoff) didn't help. Still 205 No network route. It appears on the map but is orphaned. Forced remove again and re-added using a powered Zigbee router (wall docket in this case) . Added to network immediately snd workinh as usual. Guessing it is a bad database entry?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[toxic0berliner]

It keeps happening, I strongly believe there is something wrong in the firmware of the device that doesn't report on time and z2m decides to flag it offline and either z2m or the coordinator decides that the adress is unreachable.
Group workaround doesn't work for me anymore since z2m now flags the group as offline when all devices in the group are believed to be offline. Had to test with a group including a non faulty girier device and yes, the broadcast message for the group gets picked up by the faulty C03 and it revives it momentarily.
Now that I understand more I will try to play around with the reporting interval, either very short or very long to see if this improve the situation, but if anyone finds a firmware upgrade I believe that would be the most likely to fix it...

[toxic0berliner]

There isn't a lot useful that I could make the device report, I have 2 devices still frequently having the issue, I made them report zclVersion (endpoint 1 genBasic), one every 120seconds max the other every hour max, let's see how it goes. My theory is that by forcing them to speak the network won't believe that they are offline because it really looks like the issue is more that something intelligent like ZEPc or the coordinator believes the device to be unresponsive or unroutable more than the device itself being crashed or unresponsive as the group command shows it's listening on the network and acting accordingly...
Crossing my fingers, I still have 7 of those and even at 12€ a piece replacing them would be expensive

[toxic0berliner]

First report : adding a report for zclVersion with minResponseInterval=60 and maxResponseInterval=3600(1h) does not help.
Well, it does prevent the device from being seen as offline, but it became unresponsive nonetheless for me....
The other setting (minResponseInterval=60 but maxResponseInterval=120) did not crash and is still responsive, but the device itself was less prone to the issue, so I've added these settings to some more devices and will report during the summer if it holds... realy crossing my fingers here ;)

[toxic0berliner]

maybe @cunode can reopen the issue, stale or not I believe we are all still encountering it unless we've purchased other devices :D

[clementlamoureux]

I agree with @toxic0berliner as I have the same problem and changing device is not really a solution here.

[cunode]

Happy to reopen, but I'm afraid I cannot as "you cannot re-open your own issues if a repo collaborator closed them". Only a repo collaborator can reopen (whoever this is). Suggest you open a new issue and reference this one by mentioning #12774.

[toxic0berliner]

let's not loose all the history by opening a new one, I'm too lazy at least, feel free if you wish.
first report, so far so good, 12 hours without a single disconnect and the device is still responsive, already quite unusual, let's wait&see...

[magno-santos]

I'm also going to try the solution has usually it is the same devices that "disappear", without any apparent radio reason (farther work OK).

[toxic0berliner]

Sadly it doesn't seem to solve it for me even forcing the device to talk by adding a report every 120seconds :(
I think I'll give up and replace the devices...

[jonathh21]

So we have the TS110E_1gang_1 and are seeing similar problems.

Constantly setting to a brightness to 0 (which I didn't actually notice got ages as I have an automation that changed the brightness based on day/night so not much of an issue) - spotted when I increased the automation complexity and removed this..

But the biggest issue is with the routing now - very very often get the no route error and the sluggishness occured when I use the physical button too (- which might be because I use a momentary switch so guess that requires more thoughts and isn't just an off and on).

I've switched to HA from Tuya recently and this issue is causing it to fail the wife test - we had signal issues on TUI which was resolved by addin more nodes but we have loads of them (more!) So this is definitely new.

The switch on the wall or via automation fails more often than not.

I still have the Tuya bridges and use them for WiFi devices so likely switch back to validate where the issue is coming from.

[bepece1]

I have the same issue with Lonsonho QS-Zigbee-C03 devices (until 5 over my zigbee network with identical issue).

Works intermitently, but then:

(Data request failed with error: 'No network route' (205))

Zigbee2MQTT version: 1.32.2 commit 1ec1e57
Coordinator type: zStack30x
Coordinator revision: 20190425
Frontend version: 0.6.133

I don't know what to do anymore

[Dema]

I have a switch that is connected without neutral wire and it started to go offline and get "No network route 205" error. I managed to "fix" it by increasing availability timeout as it seems it's stopped to advertise itself as online.

  '0xa4c13888fb81296f':
    friendly_name: moes-1gang-switch
    availability:
      timeout: 1500

After I added this into configuration.yaml of zigbee2mqtt everything works like a charm for the last couple of days

[asbachb]

So do I get it right that the QS-CP03 modules are more or less useless if you want some reliable shutter actors?

[toxic0berliner]

depends how you define useless. I had 10 of those, I needed to replace 6 of them to get it stable, but still there lives 4 of them perfectly reliable in my setup.
Probably a coin-toss when you recieve your unit...

[asbachb]

depends how you define useless. I had 10 of those, I needed to replace 6 of them to get it stable, but still there lives 4 of them perfectly reliable in my setup. Probably a coin-toss when you recieve your unit...

4/10 I'd consider as quite useless... Which one you use as replacement?

[cunode]

I use 5 of them now over a year and never had to replace one. With the workaround proposed by tvdbroeck (see my earlier post ) everything works reliable, day by day. If I would have to control more shutters, I likely would buy the same module (and again apply the workaround).

[lucianojss]

Giving my update probably not the one you want but I have just migrated to ZHA and all my issues are gone away, my problematic devices were TS130F TZ3000_4uuaja4a.

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

[serviser]

My Tuya TS011F_wall_outlet has the same disconnection problem

[komloz]

Same issue with a MIBOXER E2-ZR after 3 days of flawlessly working.
The device was connected to the coordinator and two routers.
Examining the circumstances, it was noticeable that the lqi was considerably lower than at the time of installation
Replacing the short (quater wave?) antenna to a bigger (full wave?) antenna on the coordinator solved the issue.
No restart or any other intervention was needed.

[almirus]

Zigbee2MQTT version
[1.36.0](https://github.com/Koenkk/zigbee2mqtt/releases/tag/1.36.0) commit: [unknown](https://github.com/Koenkk/zigbee2mqtt/commit/unknown)
Coordinator type
zStack3x0
Coordinator revision
20230507
Coordinator IEEE Address
0x00124b0022810ef5
Frontend version
0.6.159
zigbee_herdsman_converters_version
18.42.0
zigbee_herdsman_version
0.35.1

BRT-100-TRV
2024-03-27 15:10:38Publish 'set' 'child_lock' to 'Гостиная радиатор' failed: 'Error: Command 0xa4c138c9bb96d5b8/1 manuSpecificTuya.dataRequest({"seq":155,"dpValues":[{"dp":13,"datatype":1,"data":[0]}]}, {"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))'

[bedgerotto]

depends how you define useless. I had 10 of those, I needed to replace 6 of them to get it stable, but still there lives 4 of them perfectly reliable in my setup.

Probably a coin-toss when you recieve your unit...

Hey @toxic0berliner, which modules did you get as replacement?
I'm facing the same issue with 4 of these CP03 modules and none of the solutions proposed in the thread solved the issue in my case

[bedgerotto]

I use 5 of them now over a year and never had to replace one. With the workaround proposed by tvdbroeck (see my earlier post ) everything works reliable, day by day. If I would have to control more shutters, I likely would buy the same module (and again apply the workaround).

Hey @cunode, almost 1 year later, does the group solution still work for you?

[cunode]

yep, everything works stable and reliable still. I'm not evaluating any alternatives as I'm happy with the solution (and workaround).
For my system's sanity, I also installed the latest firmware 'CC2652RB_coordinator_20240710.hex' 3 months ago.