Devices lose connections / Device removal not comprehensive

deCONZ General Support
1

Hi. This is a repost of a bug report which got closed on github since it’s apparently not “specific” enough. Maybe I’ve more luck getting support for a paid product like Conbee2 here:

The bug is in the context of pairing 3 qs-zigbee-c01 devices. On the surface of the problem space all three devices loose their connection, resulting in lost commands. Most of the time the devices still send status info to Conbee 2, but all commands to the devices are getting lost.

Steps to reproduce the behavior
Diving deeper, there are even more symptoms. I removed all three devices, reset one after another, and repaired them using Phoscon. What happened is one of the devices, after being removed, rejoined again using the old name it used to have before the removal. So that seems like kind of a failed delete out of database. In the notes printed below, this device is named “Rolladen Schlafzimmer Ost OG 2”. The same happened later to “Rolladen Schlafzimmer Sued OG 2”. For the rest of my repairing adventure please read my notes below. The end result was, out of a sudden, lots of connection simply got dropped, resulting in no connections for the 3 problem devices, but also lost connections for other devices.

17:13: Rolladen Schlafzimmer Ost OG 2 joined using OLD name!
17:27: Rolladen Kleiderschrank Ost OG 2
17:29: Rolladen Schlafzimmer Sued OG 2 joined using OLD name!
17:33: Remove Rolladen Kleiderschrank Ost OG 2 because manufacturer, model identifier not set and there are no
connections
17:35: 0xD7BF joins.
17:37: Renamed 0xD7BF to Rolladen Kleiderschrank Ost OG 2
17:37: Set and unset CRE Routers and end devices
17:40: Remove Rolladen Kleiderschrank Ost OG 2 because manufacturer, model identifier not set and there are no
17:40: 0xD7BF back there after searching for light but without resetting the device
17:43: Out of a sudden, lots of connections get simply dropped

This behaviour is perfectly reproducable. Normally I’m running deconz headless, so the attached logs describe the process from starting deconz GUI until the final state, where all connections of all 3 devices have been dropped (and bunch of connection drops for other, seemingly unrelated devices).

Expected behavior
The three devices should maintain good connections to the routers nearby, and a deleted device should really be deleted…

Screenshots and Logs

Environment

  • Host system: Raspberry Pi
  • Running method: Raspbian
  • Firmware version: 26660700
  • deCONZ version: 2.12.06 / 8/19/2021
  • Device: ConBee II
  • Do you use an USB extension cable: yes
  • Is there any other USB or serial devices connected to the host system? Yes, a cistern sensor, but this is very unlikely to be relevant

Additional context
55 end-devices, > 50 of them being routers
Brands:
“dresden elektronik”,
“LEDVANCE”,
“icasa”,
“3A Smart Home DE”,
“_TYZB01_qezuin6k”,
“_TZ3000_fccpjz5z”,
“_TZ3000_vd43bbfq”,
“_TYZB01_qezuin6k”,
“IKEA of Sweden”,

Also note, that the qs-zigbee-c01 devices which have connection to Conbee 2 work fine. The three problem devices have NO coordinator connection, so they have to rely on routers around them. And there are a bunch of routers around them, including Ikea repeater. All my other devices work pretty fine, even after that last big connection drop.

2

What do you think, is this a deconz or tuya firmware issue?

3

Hi, this appears to be a routing back to the device issue. Since the devices still send status to the coordinator this route towards the coordinator seems to work. But the way back not.

The first thing I’d suggest here is to update the ConBee II firmware to 0x26720700, and check if this already solved the routing issue.

Guide to Update Firmware

Then check if the problem still remains.

In this case we can move to the next step and use application based source routing. For this in deCONZ open the “Panels → Source Routing” and click the “Enable Source Routing” checkbox. (the new firmware is required for this to work).

Here are the settings I’d suggest to try with:

image
image650×577 41.5 KB

After a while you’ll see straight blue lines in the GUI. These are source routes and are independent of device based mesh routing and controlled by deCONZ.

image

(In this example the “Flur” light is reached via “Treppe” light)

4

Hi @manup,

thanks for your answer. I upgraded ConBee 2 Firmware successfully. After deleting and re-pairing devices the behaviour was the same. Tried source routing too, and I can see a bunch of new blue lines appearing. Waited 2 hours after activating it. Same behavior after that. These beasts send me their lift state when I hit the manual switches, but ignore my ZigBee commands.

Just deleted all of them again and re-paired just one. Deconz shows no connections to it yet, but it is already fully working. I’ll leave it in this state some time to see if it has anything to do with some interference between them. Maybe there is just one culprit, I don’t know.

If you have more ideas or need more data, please let me know.

5

Update: That single device is still fully working. That is already a big win :slight_smile: Will re-pair a second device and see what happens.

1 Like
6

Another Update. After the night passed all three devices were fully working. I couldn’t believe it. So we’re definitely on the right track. BUT, after testing them awhile, one of them started bad behavior again. Although the symptom now is a bit different, as the device is marked as not reachable. I’ll wait awhile and check if it can self-heal. Wondering if lowering minimum lqi could help here?

7

Ok, old state has settled again unfortunately. Seems like it really has to do with sending them commands. ATM 2 of them show described behaviour, Device => Coordinator communication is successful, but the reverse is not. One device is still fully working. The only connection I can see for this device is a source rooted one. So probably it wouldn’t work also without source routing.

8

image

Just deleted, re-paired and factory reset the beasts again. All three are working for the moment. Source routing does an incredible job. You can’t see it on the pic, but the connection is really to the nearest routers available. Proper respect to all of you who were involved in that source routing feature.

Just hoping when stopping deconz GUI and restarting deconz headless that this state will be reapplied. Crossed fingers.