Nowadays I’m running deCONZ on a RPi with Raspbian (Raspbian Buster Desktop),
Version 2.13.04 / 2021-12-18 (stable).
ConBee 1, firmware 26400500.
Using USB extension cable: Yes.
Some years ago I run deCONZ on the same RPi as my HA as an add-on. One day I noticed that I did no longer have any links between my devices in deCONZ when watching it through VNC. After I had issues with channel changes (I have always run channel 25 but suddenly I was on channel 11 and could not change it back) I decided to leave the HA deCONZ add-on and migrated to a separate RPi (as today). I restored a backup and added some new devices and it worked pretty well, except from the fact that I was still not able to see any links between the devices. Another strange thing I encountered was that I could not create any new backups. It failed every time. After reading other threads I managed to change my network settings so today I’m able to create new backups. I’m also running channel 25 as I wish.
But, I still don’t see any links between the devices in deCONZ!
Since the links disappeared already when I used deCONZ as a HA addon, and didn’t get them back when migrated to a stand-alone platform, I don’t know where to look as I didn’t change anything manually back then and still avoid manual changes as I’m no advanced user on deCONZ nor Raspbian/Linux.
I think the network is doing fine and the devices are meshing as they should, I presume. However, the GUI links were very helpful when establishing the setup and I want to have that possibility back of course.
What should I do?
Sorry for the wall of text, I’m only trying to share any information that could be of interest to solve this.
I attach the network setting. Please let me know what other information you might need to help me out. Thanks in advance.
The links are still there but there is a display filter to not show too weak links.
Under “Panels → Source Routing” you can adjust the settings of the bottom checkbox Minimum LQI display to a lower value like 15.
Note if you don’t see any links with the default settings that’s usually an indication that the mesh is pretty weak due interference or too much distance between routers.
Thank you for your quick reply, @manup
Actually, when I took a look at the Source Routing panel, the “Enable Source Routing” checkbox was unchecked. I did check it now and I also entered the maximum hops as 3 and minimum LQI as 119, just as shown in your picture. However, still no links between the devices.
I assume the system might need some time to establish the links (?) but could there be other settings that I need to review in order to have the correct settings for this?
Obviously, there were some at least, but the “Enable Source Routing” is nothing I have ever unchecked.
No, still no links
I also tried the lowest value for LQI, but still no links.
Ah no that’s the wrong setting see my comment above.
You don’t need to enable source routing, only set the Minimum LQI display filter on the bottom:
I think, I have similar problem, but i can see only 2 neighbor links (btw, its few hours since reboot):
Same version of Deconz as OP.
That’s strange, can you please check that when you click on the CRE button in deCONZ Toolbar “Routers and Coordinator” checkbox is checked (this needs to be enabled to query the Neighbor tables).
Sorry but I have to contradict this statement.
I regularly see devices which loose their connection lines to their repeater/coordinator. They are fully functional and “minimum LQI display” is set to 0, 1 or 2 - there are no lines.
So it’s a GUI issue in deCONZ I believe
Here’s mine, everything’s set correctly.
Maybe this is useful too?
What else do you need?
Neighbor tables are very dynamic, they can change for many reasons. The UI logic here is very basic to only show links
below above the threshold and if both nodes see each other (synchronous links in Zigbee speak).
What might bring more insight are debugs logs with only ZDP logging enabled. Here the raw neighbor table responses of nodes can be seen.
I’m sorry but I don’t understand that. Is that an explanation, an excuse, …?
I can only add: the nodes not showing links they that way, there´s no “on and off” what your dynamic explanation would suggest.
The debug log window can be found under “Help → Debug view”
With ZDP logging it looks like the screenshot, the lines with * are neighbor table entries received from an router (incl. coordinator). The logs contain MAC address of devices but no keys.
Found this already. But how can I provocate a log entry for one node affected by this issue? I tried reading basic cluster to initiate some noise on the mesh but there’s nothing to the mac of that node in the logs.
deCONZ queries the tables on it’s own periodically there should be some lines visible after a few minutes.
OK. Until now I only found active components (repeaters).
- And it’s very hard when you have > 50 nodes to find/spot the node you’re looking for. It needs to be linked to one specific repeater (next and strongest in that area).
- Unfortunately I can’t copy paste the log output to search for the mac node because I’m running deCONZ in the official deCONZ addon for Home Assistant. No copy/paste from/to those VNC sessions…
By the way: I have 8 out of 64 nodes being affected by this.
- All sensors of different types (no powered devices of course). More precisly:
8 out of 47 sensor devices (rest is ConBee 2 coordinator and powered devices/repeaters).
- That makes a 17 % rate in my cause. I’d like to name that “significant”…
Ah yes I think unfortunately it’s not possible to get the logs out the VNC session.
But do I understand the the issue right that this is about the end-devices connected to a router?
In this case the LQI filter isn’t applied (it’s only for connections between routers), only the raw parent-child link is shown, if found in a routers neighbor table.
Well it would if deCONZ would provide some way of save function. I think there’s a way the other way around (for firmware updates there’s a documented way to add the update files to the docker container and load them from deCONZ).
Ah I see. If I set it to a very high value the lines immediately start do disappear. But yes, that only affects the coordinator/repeaters, not end-devices.
So yes you’re compelely right: it’s all about end-devices. Which are connected to a repeater in most, to the coordinator in some cases.
Saving to a file is on the todo list
Here is an example how it looks in my network, the filter is set to 220 which affects the routers (here Ikea) and the end-device parent-child links are shown although below the threshold.
If links of end devices go away over time, usually this means that the end-device has switched to another parent and the new link is only shown after the new parent is been queried for it’s neighbor table.