Popp/Danfoss TRVs become unresponsive with CC2652P

[moster11]

What happened?

I have a setup with several Popp-TRVs (identical to Danfoss Ally TRVs), lots of Aqara sensors and two routers, all connected to a Sonoff USB Dongle 3.0 Plus. I run Home Assistant and have automations that send temperatures measured by the Aqara sensors to the external_measured_room_sensor endpoint of the TRVs.

Everything runs smoothly for some time - until the TRVs stop reacting to any command sent to them. They still report their states without any issue, it's just that I cannot send any command to them any more. Most notably this ONLY happens to TRVs which are connected directly to the coordinator, never if connected to a router.

Looking at the devices tab shows recent "Last seen" values. I highlighted "Thermostat Badezimmer Fenster" as that's the one that's unresponsive (did an initial re-pairing of all devices this morning):

Looking at the map gives me a clear sign that this TRV will not react to my commands anymore. LQI is shown as 0 here, while the previous picture showed LQI 72:

I tried Z2M versions 1.27.0 and 1.26.0. The Sonoff dongle was on ZStack 20220219, now upgraded to dev branch 20220726. I resetted and repaired all devices numerous times, even changed to position of the coordinator to the other side of the house. Nothing helps, it's always the devices connected to the coordinator that stop reacting after some hours, at max one or two days. Only way to make them react again for some time is to take the batteries in and out.

I completely reinstalled Z2M 1.27.0 and connected all devices to the coordinator directly. The result is the same - after some hours the first TRVs become unresponsive but happily send their states.

In the debug log can see some "data confirm errors" which might give a clue.

What did you expect to happen?

I expect the devices always react to the commands I send to them and not become unresponsive.

How to reproduce it (minimal and precise)

Just setup the TRVs, make sure they are connected to the coordinator, and wait some hours.

Zigbee2MQTT version

1.27.0

Adapter firmware version

20220219 and dev 20220726

Adapter

Sonoff USB Dongle 3.0 plus

Debug log

2022-08-09T22:17:35.975Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2022-08-09T22:17:35.975Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2022-08-09T22:17:35.975Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2022-08-09T22:17:35.975Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:37.682Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,205,1,13,6]
2022-08-09T22:17:37.682Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,205,1,13,6]
2022-08-09T22:17:37.684Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [205,1,13] - 6
2022-08-09T22:17:37.684Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":205,"endpoint":1,"transid":13}
2022-08-09T22:17:37.684Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:37.685Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0xb4e3f9fffedf0571:10453,205,2)
2022-08-09T22:17:37.685Z zigbee-herdsman:adapter:zStack:adapter Request network address of '0xb4e3f9fffedf0571'
2022-08-09T22:17:37.686Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - nwkAddrReq - {"ieeeaddr":"0xb4e3f9fffedf0571","reqtype":0,"startindex":0}
2022-08-09T22:17:37.686Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,10,37,0,113,5,223,254,255,249,227,180,0,0,43]
2022-08-09T22:17:37.701Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,0,0,100]
2022-08-09T22:17:37.701Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,0,0,100]
2022-08-09T22:17:37.701Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 0 - [0] - 100
2022-08-09T22:17:37.701Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - nwkAddrReq - {"status":0}
2022-08-09T22:17:37.701Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:40.813Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,23,68,129,0,0,32,0,113,235,1,242,0,87,0,126,88,7,0,0,3,9,96,0,113,235,29,0]
2022-08-09T22:17:40.814Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,23,68,129,0,0,32,0,113,235,1,242,0,87,0,126,88,7,0,0,3,9,96,0,113,235,29,0]
2022-08-09T22:17:40.814Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 23 - 2 - 4 - 129 - [0,0,32,0,113,235,1,242,0,87,0,126,88,7,0,0,3,9,96,0,113,235,29] - 0
2022-08-09T22:17:40.815Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":32,"srcaddr":60273,"srcendpoint":1,"dstendpoint":242,"wasbroadcast":0,"linkquality":87,"securityuse":0,"timestamp":481406,"transseqnumber":0,"len":3,"data":{"type":"Buffer","data":[9,96,0]}}
2022-08-09T22:17:40.816Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":96,"manufacturerCode":null,"commandIdentifier":0},"Payload":{},"Command":{"ID":0,"parameters":[],"name":"checkin"}},"address":60273,"endpoint":1,"linkquality":87,"groupID":0,"wasBroadcast":false,"destinationEndpoint":242}'
2022-08-09T22:17:40.818Z zigbee-herdsman:controller:device:log check-in from 0x0c4314fffe45317c: declining fast-poll
2022-08-09T22:17:40.818Z zigbee-herdsman:controller:endpoint Command 0x0c4314fffe45317c/1 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2022-08-09T22:17:40.818Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x0c4314fffe45317c:60273/1 (0,0,2)
2022-08-09T22:17:40.819Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":60273,"destendpoint":1,"srcendpoint":1,"clusterid":32,"transid":14,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[1,6,0,0,0,0]}}
2022-08-09T22:17:40.819Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,16,36,1,113,235,1,1,32,0,14,0,30,6,1,6,0,0,0,0,158]
2022-08-09T22:17:40.819Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:40.835Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2022-08-09T22:17:40.835Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2022-08-09T22:17:40.835Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2022-08-09T22:17:40.836Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2022-08-09T22:17:40.836Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:41.170Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,233,1,14,33]
2022-08-09T22:17:41.170Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,233,1,14,33]
2022-08-09T22:17:41.170Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [233,1,14] - 33
2022-08-09T22:17:41.170Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":233,"endpoint":1,"transid":14}
2022-08-09T22:17:41.170Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:41.171Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0x0c4314fffe45317c:60273,233,0)
2022-08-09T22:17:41.171Z zigbee-herdsman:adapter:zStack:adapter Wait 2000ms
2022-08-09T22:17:43.173Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x0c4314fffe45317c:60273/1 (0,1,2)
2022-08-09T22:17:43.173Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":60273,"destendpoint":1,"srcendpoint":1,"clusterid":32,"transid":15,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[1,6,0,0,0,0]}}
2022-08-09T22:17:43.174Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,16,36,1,113,235,1,1,32,0,15,0,30,6,1,6,0,0,0,0,159]
2022-08-09T22:17:43.190Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2022-08-09T22:17:43.190Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2022-08-09T22:17:43.190Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2022-08-09T22:17:43.190Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2022-08-09T22:17:43.190Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:43.414Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,233,1,15,32]
2022-08-09T22:17:43.414Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,233,1,15,32]
2022-08-09T22:17:43.414Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [233,1,15] - 32
2022-08-09T22:17:43.414Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":233,"endpoint":1,"transid":15}
2022-08-09T22:17:43.414Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:43.415Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0x0c4314fffe45317c:60273,233,1)
2022-08-09T22:17:43.415Z zigbee-herdsman:adapter:zStack:adapter Discovering route to 60273
2022-08-09T22:17:43.416Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - extRouteDisc - {"dstAddr":60273,"options":0,"radius":30}
2022-08-09T22:17:43.416Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,4,37,69,113,235,0,30,224]
2022-08-09T22:17:43.430Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,69,0,33]
2022-08-09T22:17:43.431Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,69,0,33]
2022-08-09T22:17:43.431Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 69 - [0] - 33
2022-08-09T22:17:43.431Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - extRouteDisc - {"status":0}
2022-08-09T22:17:43.431Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:46.433Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x0c4314fffe45317c:60273/1 (0,2,2)
2022-08-09T22:17:46.433Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":60273,"destendpoint":1,"srcendpoint":1,"clusterid":32,"transid":16,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[1,6,0,0,0,0]}}
2022-08-09T22:17:46.433Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,16,36,1,113,235,1,1,32,0,16,0,30,6,1,6,0,0,0,0,128]
2022-08-09T22:17:46.450Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2022-08-09T22:17:46.450Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2022-08-09T22:17:46.450Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2022-08-09T22:17:46.451Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2022-08-09T22:17:46.451Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:46.674Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,233,1,16,63]
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,233,1,16,63]
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [233,1,16] - 63
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":233,"endpoint":1,"transid":16}
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0x0c4314fffe45317c:60273,233,2)
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:adapter Request network address of '0x0c4314fffe45317c'
2022-08-09T22:17:46.675Z zigbee-herdsman:adapter:zStack:znp:SREQ --> ZDO - nwkAddrReq - {"ieeeaddr":"0x0c4314fffe45317c","reqtype":0,"startindex":0}
2022-08-09T22:17:46.676Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,10,37,0,124,49,69,254,255,20,67,12,0,0,125]
2022-08-09T22:17:46.682Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,101,0,0,100]
2022-08-09T22:17:46.682Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,101,0,0,100]
2022-08-09T22:17:46.682Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 5 - 0 - [0] - 100
2022-08-09T22:17:46.682Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - nwkAddrReq - {"status":0}
2022-08-09T22:17:46.683Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:47.703Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xb4e3f9fffedf0571:10453/1 (0,3,2)
2022-08-09T22:17:47.704Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":10453,"destendpoint":1,"srcendpoint":1,"clusterid":32,"transid":17,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[1,5,0,0,0,0]}}
2022-08-09T22:17:47.704Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,16,36,1,213,40,1,1,32,0,17,0,30,6,1,5,0,0,0,0,229]
2022-08-09T22:17:47.720Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2022-08-09T22:17:47.721Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2022-08-09T22:17:47.721Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2022-08-09T22:17:47.721Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2022-08-09T22:17:47.721Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:49.165Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,205,1,17,26]
2022-08-09T22:17:49.165Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,205,1,17,26]
2022-08-09T22:17:49.165Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [205,1,17] - 26
2022-08-09T22:17:49.165Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":205,"endpoint":1,"transid":17}
2022-08-09T22:17:49.165Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2022-08-09T22:17:49.165Z zigbee-herdsman:adapter:zStack:adapter Data confirm error (0xb4e3f9fffedf0571:10453,205,3)
2022-08-09T22:17:49.166Z zigbee-herdsman:adapter:zStack:adapter Wait 2000ms

[TheLongAndOnly]

I can second this. Similar issue, Danfoss Ally, Popp and Eurotronic TRV stop communicating after a while of flawless operation. I'm using a ConBeeII. Only way top fix I found so far is to rejoin the Zigbee network again. At least in my case the connections also run through routers.

[wormiedk]

I have the same problem. I was hoping it was a cc2652 problem so that I could solve it by switching adapter. I might have to go back to zha instead then

[moster11]

I found a solution for my use case. I had Zigbee2MQTT installed in Home Assistant OS which runs on a VM on my Synology NAS (DSM 7).

No matter if I used a Conbee II or the Sonoff Dongle I encountered the bespoken dropouts. As soon as I installed Zigbee2MQTT as a Docker image and set up my TRVs from there everything suddenly started to run without any flaws. Rock solid setup for more than 4 weeks already.

Seems to me that the USB passthrough to the VM was the root cause.

[TheLongAndOnly]

Interesting, but I'm running z2m directly installed on a Raspi4. Maybe I should try docker or check, if there are options to improve USB behavior. Figured out that removing batteries from the devices also fixed the problem.

[TheLongAndOnly]

I have a ZigBee sniffer available, but I'm not very familiar with the protocol. Is there anything I should watch for?

[DonDonatello]

Experienced this as well with both the Sonoff and Conbee II stick. Newest (1.28) stable Z2M running in Docker on RPi4 and all devices connected directly to the coordinator.

Happy to produce any relevant logs if needed.

[lukas-mc]

I see the same here. SonOff Coordinator with lates firmware. I have Popp and Danfoss Ally TRV which should be the same inside.
Some of the TRV are connected over Routers (ledadvance and lights) others are directly connected to the coordinator.

I see the ,,pubish" event in logs but npo communication to or back from the device. Poer off the device for some time (10 to 15 min) and it will be responive again.

Regards Lukas

[xeri-sk]

I have same problem with Danfoss Ally TVR. After some time (hours, days) TVR still reporting states, but not responding for any command sent to TVR (through openhab or Z2M frontend).

When this happened to TVR i have to remove it from Z2M, factory reset TVR and re-join.
I hope that somebody will fix it soon couse i bought 3 TVR devices and are not usable with Z2M now.

My enviroment: OS Linux (Debian), Sonoff USB Dongle 3.0 Plus (with USB extension) FW 20220219, Z2M 1.28.0, openhab 3.3.0.

[nikolai5slo]

Also happening to me. I have two Ally TRV and both stop responding after few hours. Restarting Z2M doesn't help. Only factory reset of TRV + re-join helps. I am not having any connection or signal issues with any other devices (around 20 devices on the network).

[wormiedk]

I switched to ZHA and I don't have the problem there

[stachjankowski]

In my case, it helped removing the external antenna (reduce the range of the coordinator).
Now all TRVs connect through routers (IKEA bulbs, TUYA Smart plug, etc).

My enviroment: QNAP (docker), Sonoff ZBDongle CC2652P FW 20220219, Z2M 1.28.0.

[TheLongAndOnly]

I did some more research. I sniffed the network while the Danfoss Ally (0x4d8e) did not work anymore. I see data requests from the device reaching out to 0xd1ac, which is a GLEDOPTO GL-C-009 (Low Voltage LED Driver)

1118 251.639075 0x4d8e 0xd1ac IEEE 802.15.4 12 Data Request
1138 258.690621 0x4d8e 0xd1ac IEEE 802.15.4 12 Data Request
1167 265.741399 0x4d8e 0xd1ac IEEE 802.15.4 12 Data Request
1185 272.792932 0x4d8e 0xd1ac IEEE 802.15.4 12 Data Request

When I try to change a value through HA, I see a lot of route requests, but there is no success to reach the device

1195 275.161548 0xe6ae Broadcast ZigBee 51 Route Request, Dst: 0x4d8e, Src: 0xe6ae
1196 275.177605 0xe6ae Broadcast ZigBee 51 Route Request, Dst: 0x4d8e, Src: 0xe6ae
1197 275.184444 0xe6ae Broadcast ZigBee 51 Route Request, Dst: 0x4d8e, Src: 0xe6ae

I removed the battery and restarted the Danfoss (leaving everything else untouched) and it started to communicate again (just a short snippet:
1928 195.633365 0x4d8e 0xda68 IEEE 802.15.4 12 Data Request
1930 195.652961 0x0000 0x4d8e ZigBee 49 APS: Ack, Dst Endpt: 1, Src Endpt: 1
1932 195.656802 0x4d8e 0xda68 IEEE 802.15.4 12 Data Request
1934 195.669037 0x0000 0x4d8e ZigBee 49 APS: Ack, Dst Endpt: 1, Src Endpt: 1
1936 195.673227 0x4d8e 0xda68 IEEE 802.15.4 12 Data Request
1938 195.684501 0x0000 0x4d8e ZigBee HA 56 ZCL: Default Response, Seq: 14

The biggest obvious difference seems to be the router which is used. It is now device 0xda68, which is an OSRAM Zigbee socket.

My suspect is that the GL-C-009 claims to be a router as it is permanently power with 24V, but does not do the job. Sometimes the TRV switches the router to the GL-C-009 and then it is disconnected as the router does not work. I will verify next time the TRV disconnects.

Question: IS there a way to exclude nodes from routing?

Update:
One additional observation: When looking at the network map in zigbee2mqttassistant, I can see only outgoing arrows from the GLEDOPTO device. No inbound connections as other routers show.

[xeri-sk]

I tried to add two routers (Sonoff S26R2ZB) to my Zigbee network and now all of my 3 Danfoss TVRs still working for 5 days.
Before i had only endpoint devices connected directly to coordination and Danfoss TVR works for 1 - 3 days.
Now 2 TVRs are connected through routers and 1 still directly to coordinator.
I will continue with monitoring and share results here.