Zigbee- Amount of devices

@simon.stuerz Thank you very much for the Zigbee network explanation.
I am still wondering that the end-device declaration I see in the logs is from the device itself. I started my old Z2M setup again and there a hue bulb is correctly listed as router device. In Nymea the same bulb is an end-device. So I guess somewhere the device type is turned into the opposite. What does the RxOn true/false mean in the logs behind the device type?
By the way, a network map would be great to have for problem solving.

Hey @s05 , sorry for the slow progress on thisā€¦ Weā€™re somewhat busy with testing and preparing the 1.4 releaseā€¦ Anyhow, Iā€™ve just read a bit through the zigbee code to answer your question:

The node type is set in the ā€œparseNodeDescriptor()ā€ method, here: nymea-zigbee/zigbeedeviceprofile.cpp at master Ā· nymea/nymea-zigbee Ā· GitHub
That one is called by Node::initNodeDescriptor(), here: nymea-zigbee/zigbeenode.cpp at master Ā· nymea/nymea-zigbee Ā· GitHub
Which again is called by ZigbeeNetwork::onNodeAnnounced, here: nymea-zigbee/zigbeenetwork.cpp at master Ā· nymea/nymea-zigbee Ā· GitHub

So that means, when a device joins the network, nymea immediately reads the node descriptor from the device. Itā€™s literally the first message nymea sends to a device when it joins the network and should be visible in the ZigbeeDeviceObject logging category. Havenā€™t had the time yet to set up a testing network and evaluate all of this with a hue lamp.
That said, I do have the same observation as you. My Hue devices are marked as end devices but I am actually reasonably sure that they are in fact routing devices (as the TI backend, which Iā€™m using, prints the routing of nodes to the debug log and I see various devices being routed through my office hue lamp).
Perhaps you can already spot a mistake somewhere here, Iā€™ll try to verify this myself asap too.

Okayā€¦ I did the effort to look into this in depth by comparing the debug output and code of zigbee2mqtt, deconz and nymea and the result is that indeed, the device type flag is wrong. In fact it pretty much means that all the router/end device icons in nymea are swapped the wrong way round, except the coordinator one (which is hidden in the app ui) is correct.

So, the good news, Iā€™ll be fixing this now and then then symbols will work properly.

The bad news though, this really just is a displaying issue and will not affect the 50+ devices instability problem. Anyhow, one issue down, now we can move on to the next one.

Itā€™s building in experimental now.

Hi @mzanetti thank you very much. I am very happy with the progress and the feedback concerning this problem.
I hoped the first mentioned code, where the device type is determined, has also an influence on the whole Zigbee network and not just on the symbols.
Will this change in code also change the device type in the log output?
Currently I have only the most important 31 devices in my network and its working with little delays here and there (compared to before), but generally ok.
I can easily join more devices anytime for testing. Just tell me what you are looking for, so I can try provide the needed information.

Yes, it will also fix the device type in the console log output. This change doesnā€™t make any difference in terms of functionality because zigbee builds the network (and the routes in the network) on its own. Nymea doesnā€™t really do anything about that.

Iā€™m currently in the process of writing some code (based on Simons branches above) for requesting the routing information from the network so we can build a network map from it and see how the devices are routed.

I am looking forward to be able to evaluate the current routing, add more devices to the network and compare this to previous experiences.

@s05 , so, Iā€™ve spent some time to investigate about the routing in the zigbee networkā€¦ So far I canā€™t spot any obvious issue still. The nodes seem to move around in the network as they shouldā€¦ This is an example network Iā€™ve set up with a a Deconz stick, a Hue Light (LCT001), a Hue remote (RWL021), a Tradfri remote and a tuya button:

As you can see, the Hue remote is a child of the Hue light, so the Hue light does indeed act as a router as it should. If I put my laptop to suspend for a while, all the remotes will move over to the Hue lamp. When the laptop comes back up, after a while the Tuya and the Tradfri remotes moved over to directly connect to the deconz stick again.

Anyhow, I havenā€™t ran this on my production ZigBee network yet, which is about the same size as yours (some 50 devices). The required branches for nymea:core are currently building in experimental. Feel free to upgrade and turn on logs for ā€œZigbeeNodeā€. Youā€™ll see messages like this coming by repeatedly.

  I | ZigbeeNode: LQI neighbor for node: "0x0000": NeighborTableListRecord("00:17:88:01:00:D6:8A:B7", NWK address: "0xfb5f", Extended PAN ID: 15987178197214944733, Node type: ZigbeeDeviceProfile::NodeTypeRouter, RxOn: true, Relationship: ZigbeeDeviceProfile::Sibling, Permit join: true, Depth: 1, LQI: 252) 

This would mean that node with the address 0x0000 (the coordinator) has a neighbor with the address 0x0xfb6f which is of type Router and has a Link Quality Index of 252 (ranges from 0 - 255).

To conclude this.

There was a bug in the deconz backend which indeed prevented devices to roam in the network properly. This will be fixed with the next update (1.4.1 or 1.5.0).

Thank you very much! I am looking forward to the next releases.

I currently have 65 Zigbee devices connected to Nymea 1.5. The mentioned problems in the original post are solved by now. Additionally a network map was implemented, which is great for problem solving and gives you a very nice network overview.

1 Like