Zigbee- Amount of devices


just started with Nymea. I am currently using a Raspberry 4 together with a Conbee II in order to integrate my Zigbee devices. After an really easy start integrating the first devices, I experience difficulties adding more after I reached the amount of 50. Currently 62 devices are connected, but the last ones took many attempts in order to join the network. Right now, I cannot add the remaining ones.

I also have a Raspberry 3 with a Raspbee II attached, those problematic last devices and remaining ones join again without problems to this Nymea instance.

Range should not be a problem, as I have several routing devices in the network and my setup worked with other solutions without problems.

Is there maybe a limit on the amount of devices you can have in a Nymea Zigbee network?

Indeed I have seen the same with the Phoscon adapter. Networks larger than 40 devices start getting somewhat unstable. This doesn’t really seem a nymea Problem though as googling the internet reveals the same Problem for zigbee2mqtt and even the deconz software has some comments in its code where they limited the amount of devices to 20 in earlier versions (now they allow more, but not sure when it becomes unstable).

Also, it doesn’t seem to be a Phoscon issue only, as for example the zigbee2mqtt documentation states that TI CC1532 dongles have too poor CPU power to handle more than 20 devices, the newer CC2351 chips though are said to be able to handle up to 100.

I for one even use 2 ZigBee adapters on a single nymea instance exactly because I ran into the same Problem with a single RaspBee2 module.

That said, I am not denying that there may be room for improvement in nymea, for example in reducing polling on some devices or stopping to “ping” devices if they’re reachable.

I’m wondering, do you use any power plugs with Energy metering? If so, there maybe some low hanging fruit to reduce the transmission interval when the power measurements change.

Thank you very much for your reply.

Before using Nymea I had a stable Zigbee2MQTT enviroment with all my 65 Zigbee devices and the Conbee II stick running without problems.
I guess generally the amount of supported devices in a Zigbee network is quite individual according to the devices used in that network.

I just have an Aqara Smart Plug as a metering Zigbee device. Other routing devices are mainly lightbulbs (Hue, Tradfri) and End points/Sensors are mainly from Aqara and Frient/Develco.

My general goal is to reduce the amount of bridges and also make use of a larger Zigbee mesh network. If anything can be done from my side to investigate this case further and maybe increase the device limit, please let me know.

I see… On which platform are you using nymea? I can build you a package of the zigbee module which does not ping the devices and with that should take away a considerable amount of load from the network. If that helps I could perhaps make that a setting.

Also the Aqara smart plug, is that handled by the Tuya plugin? You can see that in the Main menu → configure things → then open the smart plug → Thing class → and then press on the Type number to copy/paste the id. That’s what I’m interested in.

My main system is using a Raspberry Pi 4 Model B (8GB) with a Conbee II attached and using the Nymea image provided by Nymea. I am really happy to test this out and see if that makes a difference. Is a clean fresh Nymea image preferable for this task?

Here is the requested Type Number:
Power socket

Where on that number could I see if it is using the Tuya plugin?

Ok, here’s the package which has the device pinging removed: https://downloads.nymea.io/tmp/libnymea-zigbee1_1.3.1+202208101953~3dc344d~bullseye_amd64.deb

It’s build from this branch: TESTING ONLY: Disable reachable refresh timer by mzanetti · Pull Request #27 · nymea/nymea-zigbee · GitHub

The Thing Class ID is from the Lumi Plugin. That one sends power info values reasonably rarely, so that shouldn’t be the problem… To answer your question, you could see that by searching the plugin repos for this id, in this case it’s here: nymea-plugins-zigbee/integrationpluginzigbeelumi.json at master · nymea/nymea-plugins-zigbee · GitHub (I suppose it could make sense to make this a bit easier tho…)

Anyhow, so yes, please try the above package (sudo dpkg -i nymea-zigbee...deb ) and please let me know if that improves things.

Whoops. I built an amd64 package accidentally. Here’s the armhf package for the RPi: https://downloads.nymea.io/tmp/libnymea-zigbee1_1.3.1+202208102005~3dc344d~bullseye_armhf.deb

Ok, thank you very much.
So in order to install that package I need to enter on the command line the given command together with the correct libnymea-zigbee…deb-filename?
So the original zigbee package get overwritten in that case. Is that correct?

yes… ssh into the raspberry pi (user nymea, password nymea, unless you’ve changed it) and do:

wget https://downloads.nymea.io/tmp/libnymea-zigbee1_1.3.1+202208102005~3dc344d~bullseye_armhf.deb
sudo dpkg -i libnymea-zigbee1_1.3.1+202208102005~3dc344d~bullseye_armhf.deb

This will replace the nymea zigbee stack package with this patched one (note that on the next update it will install the one from the official release again)

Thank you for your explanation how to install the package. Unfortunally no additional devices could be added.

Could it be, that this might be a routing problem? I noticed in the logs, that there are some unhandled broadcast elements and some Hue lamps are labeled as end device (although in Nymea they are shown with the router symbol).

I also have some Frient devices which normally update their values quite regulary. The ones close to the Conbee II do so, the ones further away do not. With the same distribution of devices, this was no problem prior. I moved one sensor closer and it is now updating regulary.

Normally not having routers will limit the amount of devices in a Zigbee network.
Do you have any suggestions what could be done to check this out?

Making the Ping behaviour a setting might still help anyways.

Shortened log examples:
I | ZigbeeNetwork: Received unhandled broadcast ZDO indication APSDE-DATA.indication

W | ZigbeeDeviceObject: Unhandled ZDO indication ZigbeeNode(…), …End device, RxOn:true)

Ok. That sounds like we need to dig in deeper… I am certainly interested int getting this sorted out. If you say the very same setup worked with zigbee2mqtt there probably is something we can improve here. Thing is, I’ll be traveling for a week now and can’t look into it before end of next week.

Seeing that you seem to have some knowledge about ZigBee and are motivated to look into it, if you want to investigate further in the meantime, here’s some Info that may help you:

If you edit /etc/nymea/nymead.conf you’ll find a section named [LoggingRules] (if not, create it). In there you can enable extra log information about the ZigBee network with such entries:


where “Category” can be one of:

ZigbeeAps: All APS layer traffic
ZigbeeNode: Information about node joining/leaving etc
ZigbeeNetwork: General network information
ZigbeeCluster: Clusters on nodes etc
ZigbeeClusterLibrary: More ZCL information
ZigbeeEndpoint: Information about endpoints on nodes/devices
ZigbeeInterface: Communication with the Adapter (ConBee hanlding)
ZigbeeController: Also Adapter related, one layer above
ZigbeeDeviceObject: Everything related to the ZDO layer
ZigbeeAdapterMonitor: Plugging in/out and detecting the USB device
ZigbeeInterfaceTraffic: Each and every data packet sent to/received from the deconz.

So, for example:


To get extended logging information about ZDO and the APS messages.

After saving, restart nymea with sudo systemctl restart nymead

I am happy to help and try to look into it in the meantime. Is the output of the additional activated logging categories also listed in the log screen of the debug server activated by the developer settings in Nymea?

Yes, the output is either in the debug Webinterface or in the terminal with sudo journalctl -u nymead . Add -f to follow the live log.

An addition to one of my posts above. I misinterpreted the router/end-device symbol that is shown next to the connected devices on the Zigbee network screen. So actually, my router devices (bulbs, power sockets) show an end-device symbol and battery powered end-devices show a router symbol and a sleeping symbol.

Hey. We’ve added the confirmation question when removing or resetting the Zigbee network. Thanks for pointing this out.

As for the actual problem, the amount of devices… I’ve been thinking how to tackle this. I suppose one thing we could do is to implement something that allows getting the information of how the devices are routed in the network, so we can see the hops of each device and then evaluate if there’s an issue maybe.

Thank you very much for the implementation of a confirmation question.

I guess, looking into the routing would definitely help here and I am happy to help.
But prior to that, my interest would be, why a device that normally acts as a router, is showing up as end-device in the log and in the Zigbee network panel? Where does this come from? So if the routing capable devices are also declared as end-devices in the network and vice versa, I probably just have the coordinator left and therefore are limited in the amount of devices.

The node type is shown as reported from the device itself in the node descriptor. A routing node type has the capability of adding nodes into the network and also act as security trust center. Also neighbor table and stuff is the responsibility of a router node.
A quiet accurate description of node types can be found here:

and here:


If you see the sleeping router node, in most cases it is a remote switch or similar since a remote must be able to add a device using touch link into the network, also without the explicit permission of the coordinator. Unfortunatly those nodes sleep most of the time du to energy saving, and they cannot perform the routing operations as they should. If an enddevice tries to send a message trough a sleeping router, the message normaly must be chached until the router wakes up, and then forward the traffic, but that is not working well in real life.

What I already tried to do is when a new node joins the network, i just allow a specific router to add new nodes into the network (trying to make a constantly up router to be the parent), unfortunately I was not able to do that with de deconz stick so far, there is already a branch in the nymea-zigbee repository where I experimented with that (without success so far). Also in the app there is a branch where I started showing all neighbors and the link quality to the neighbors with the plan to draw a network topology…but I never finished it. Since that is quiet a work to do, the information could be shown in the meantime in the logs, maybe helping to understand what the issue with the network setup is. I will check the branch since this was quiet some time ago :slight_smile:

@mzanetti have a look at these PR, it is a early stage, but we can get the neighbor information in the logs and request individual nodes about their neighbors and LQI between them.

The plan of these features was to debug exactly this situation and also give a nice picture of the local network topology…for now we should get the information of the network in the logs with this code.

I re-based them to current master maybe you can try them in your network since you had the same issue…

Yes, I’ve read through them before I left last week. I think this would make a good starting point for printing the network topology.

Probably wouldn’t expose the lqi request through the API but instead do that implicitly somehow but I suppose this was just done for easier testing.

Yes, only for testing as mentioned in the PR: also some controls are just hacked in for testing…this is only a experiment, maybe leading to a nice feature of the stack…