Zigbee networks: how to guide for avoiding interference + optimize using Zigbee Router devices (repeaters/extenders) to get a stable mesh network with best possible range and coverage

Community Guides
, , ,
65

Indeed. That is also a common user error as most users do not know that you should not power off and on Zigbee Router devices. Zigbee Router devices should really always be always-on, i.e. always have power.

The best options is either to buy Zigbee lightbulbs that are not Zigbee Router devices, (such as the Zigbee lightbulbs from Sengled), or use dumb lightbulbs in combination with a smart switch instead.

In my option the real problem is that manufacturer should not make Zigbee lightbulbs that are Zigbee Router devices, as that way it is not possible for the user to make this mistake. Sengled is for example aware of this and do therefor not sell Zigbee lightbulbs that are Zigbee Router devices → -> Is Sengled's decision to not implement zigbee routing asinine?

No, it is not possible to disable routing.

FYI, there is something called “source routing” that does alleviate quirker re-routing a little bit but it usually causes other issues such as long latency/delays and is therefor disabled by default.

I recommend use dumb lightbulbs with smart dimmer switches instead. The smart dimmer switch control the dumb lightbulb and works even when the Zigbee Coordinator is not available.

That can be possible via Zigbee binding, by binding a Zigbee light that support Zigbee binding to a Zigbee remote. Zigbee binding works even when the Zigbee Coordinator is not available:

3 Likes
66

This discussion was moved here!

This! This is exactly what I’m looking for! Thank you so much!

I plan the following steps:

  • Zigbee switches/dimmers and zigbee bulbs that support multi-destination binding. This way I can bind them to each other and to ZHA at the same time.
  • All Zigbee bulbs are wired directly - always powered
  • When a light is on, it is controlled by HA depending on activity/sun.
  • When a light is off, the startup behavior of the bulb is controlled depending on activity/sun. When I turn on the light, it immediately lights up to match the activity/sun. There is no longer any need to wait for the bulb to come online to adjust to the activity/sun (like in my current wifi bulb setup).

Expected limitations:
I expect that once it is bound to a light I will only be able to use the zigbee switch to turn the light on and off. Changing the scene by pressing several times in a short time or something similar is probably no longer possible because the switch switches the light on and off directly.
I will definitely test how it feels when HA turns the light back on in another scene after a quick on-off (or off-on) at the switch (and the bulb). On the other hand, there may also be manufacturers who recognize a double click or long click in the switch itself.

Lots of new ideas come to mind…

Unfortunately, I have to put this exciting project and the interesting research on hold for the time being because I have to finish another project that actually pays me by the summer… But I now have one more reason to look forward to my summer vacation; ).

Ultimately, I should have read the documentation more carefully from the beginning… In any case, thanks again for the tip about the binding!

67

Thank you very much for your answer. I will first try to achieve my desired setup using binding (see Hedda’s answer). If I missed something, I might use the Sengled bulbs mentioned.

68

I assume this is a binding between the switch and the bulb. If I understand binding correctly, a direct connection to the HA coordinator and the bulb can exist at the same time if multiple binding destinations are supported:

From ZHA integration docu:

Also, by default ZHA binds remotes to the coordinator, so the coordinator can receive ZCL commands from the remotes and originate zha_events. However, some remotes, for example, the Philips RWL021 can only be bound to a single destination and it is not possible to make this switch to bind to other destinations like a device or groups unless you first unbind the remote from the coordinator.

1 Like
69

You can do it through bindings and/or you can use a loaded relay that will physically toggle the power on/off to the lights. For instance, I have 3 Wiz WiFi lights and a ceiling fan attached to an Aqara single gang double rocker ← love this switch.

The rocker’s top switch is left by default in relay control mode. The bottom switch is set to be decoupled (acts as a zigbee button). The top relay will work to turn on and off the fan and lights, even with no connection. The bottom switch is bound to a zigbee light strip and will also work without a connection.

1 Like
70

Please start a new separate thread about that as binding and type of switches as those do do have anything directly to do with the original topic as thus this discussion is getting way too off-topic. So not to highjack this thread.

I will however leave you with the tips that you can create a Zigbee group in ZHA or Zigbee2MQTT and then create a binding for that Zigbee group, (but note that all devices in that Zigbee group must support binding, which most light devices do but not all Zigbee devices do).

Update: New thread here → Use binding as a stopgap/backup solution if HA is not available

1 Like
71

Oh, I now understand how the zigbee relay switch works. Thank you for the clarification!

The topic is being discussed here.

1 Like
72

New Zigbee Router tip; ITead has released a “SONOFF Micro Zigbee USB Smart Adaptor” (ZBMicro based on EFR32MG21) spec say doubles as a Zigbee Router device when powered via USB-charger:

“Besides, ZBMicro can work as a Zigbee router to help transmit the Zigbee signal to ensure a stable connection when multiple Zigbee devices are used for your home. Elevate your network capabilities with Turbo Mode, featuring advanced technology that boosts signal range and strength but also provides a seamless and stable connection for your devices.”

https://sonoff.tech/product/diy-smart-switches/zbmicro/

image
image1303×839 68.6 KB

Note! I have not tested it so have no idea if it works well if used as a dedicated Zigbee Router device.

1 Like
73

I need this! H0w did I survived without turbo mode till now?

We hope you didn’t got anything in exchange for copying the marketing material from sonoff here :joy:

74

Nope, I did not, I have not accepted anything, I also post marketing materials from all manufacturers to stay unbiased :stuck_out_tongue_winking_eye:

2 Likes
75

Fwiw after nearly two years of zigbee mesh network issues here are my experiences. I hope this helps others avoid the immense frustration I’ve felt wasting time managing this god awful network instead of, you know, building helpful automations and making my life easier :smiling_face_with_tear:.

Aqara
Aqara battery devices repeatedly fall off the network. In particular, those devices that use a single 3v battery (contact or temp sensor) fared worse than those that use two batteries / are Zigbee 3.0 devices (TVOC / TRV E1 / motion P1 sensor). One exception, with my recent switch to Z2M the motion P1 has become a disaster, falling off the network all the time.

IKEA
After a year of using the IKEA signal repeater with no issues they have started to drop off my network and show as unavailable every week or so. This has also occurred with my IKEA LED drivers so it could be IKEA devices aren’t built to last although I’ve has zero issues with my IKEA tradfri bulbs (although the GU10 bulbs do get extremely hot, though that’s a separate concern).

IKEA battery devices repeatedly falling off the network, although not as frequently as the Aqara devices.

Sonoff
Sonoff battery devices were rock solid on ZHA, in particular the SNZB-02 temp sensor and SNZB-03 motion sensor, but with my recent switch to Z2M I’ve started to experience issues with the SNZB-01 button falling off the network.

TuYa
TuYa ZG-204ZL motion sensor and TuYa contact sensor have been rock solid

Not device specific issues

  • Physical zigbee button presses OR clicking on entities in the Home Assistant app failing to result in a device executing an expected action e.g. opening blinds. In ZHA this was often accompanied by the log Failed to deliver message: <EmberStatus .DELIVERY_FAILED: 102>
  • Light groups in Home Assistant responding inconsistently to commands after switching to Z2M, e.g. only 2 of 3 bulbs turn on or off

Steps taken
The issues I’ve described with zigbee have remained consistent across the following steps taken to address my network:

  1. Move from ZHA to Z2M
  2. Moving my zigbee channel from 15 to 25 and moving my 2.4 ghz wifi to channel 1 (none of my neighbours seem to use wifi channel 11)
  3. Changing my coordinator device from the Home Assistant Yellow to the Smlight SLZB-06 and moving it to a room away from my router (the router and Yellow are both in my understairs cupboard)
  4. Getting rid of all my 2.4 ghz wifi Ring cameras, having a separate SSID for 5 ghz wifi and connecting laptops, mobile phones, tablets and media devices to 5 ghz wifi
  5. Gradually building up the number of router devices to over 50 in a 140 m2 two story house plus garden, as well as using four dedicated repeater devices (2x IKEA repeaters, 1x Tuya TS0207, 1x Sonoff Dongle Plus P)
  6. Using a multimeter to test battery voltage and replacing all batteries that dipped below 2.9V in my 3V battery powered end devices
  7. Removing all ZHA groups and using Home Assistant groups instead so as to minimise zigbee broadcast signals

I’m now in the process of either (a) adding more Sonoff Dongle P repeaters and moving over to TuYa battery devices or (b) giving up entirely on my zigbee mesh…tbh I keep switching back and forth daily…it’s been two years of one zigbee issue after another and I’m beyond frustrated.

Fwiw, in contrast I’ve had zero issues with my zwave and bluetooth devices although to be fair I have very few of those devices.

(Just to clarify if anyone is wondering, my zigbee light bulbs are hardwired and all router devices are permanently on.)

76

FYI, using ZHA or Zigbee2MQTT does not affect if a device will drop of the network more or not if usibg the exact same Zigbee Coordinator chip model and firmware version as the Zigbee network is managed by the Zigbee stack running on it.

What will affect connection other that the device that that have problems is amount, type and location/placement of Zigbee Router devices as well as EMI/RMI/EMF interference (which also includes Zigbee channel uses).

If you use the exact same Zigbee Coordinator and Zigbee devices in the exact same location then the mesh network topology and stability of the connections would be exctly the same in ZHA or Z2M.

So that should not be reason for moving from the ZHA integration to Zigbee2MQTT or vice versa. See:

Zigbee

1 Like
77

I am adding here some info I found by testing. Maybe it will be useful to someone.

It seems you can directly connect 32 end devices to the adapter. And you can connect 6 additional end devices for each router you add to the network. For example in my circumstance, I cannot add any more end devices as the adaptor and all routers are full. I have to add another router so I can add other end devices.

I don’t know if this is a limitation of zigbee devices or just the limitation of the Ikea devices I am using as routers.

Screenshot 2024-09-05 233627
Screenshot 2024-09-05 2336271403×781 200 KB

78

Good callout. It’s standard design philosophy

… and actually smaller (16 I think? ) on some older Zigbee coordinators. Some incorrectly read that direct connect limit as ‘device limit’ where it’s much higher per yojr notes. Hedda would know the specifics.

Its only a mesh device limit if you don’t have routing devices :rofl:

1 Like
79

Limits depends on products used. Regardless, the easiest way to resolve that scenario is by first temporary removing a few of your (older) Zigbee devices and then adding a few newer Zigbee Router devices products that you know allow more devices to connect to them (like example the dedicated Zigbee Router devices that are recommend in my original guide post above), and only af6er that can you add more devices to your Zigbee network mesh (including the older Zigbee devices that you temporary removed). You can alternatively also get a better Zigbee Coordinator and/or firmware configured to allow more child devices to connect directly (but that is less ideal as you do not want too many devices connected directly to the Zigbee Coordinator, instead you want most of your devices to be able to connect to multiple Zigbee Router devices as that will give you better performance as Zigbee Router offload the Zigbee Coordinator). The best solution is to just add more “known good” and/or “known great” Zigbee Router devices.

Anyway, both of those are not limitations in the hardware or Zigbee Gateway application but they are instead limits configured and set on purpose by the firmware developers of every Zigbee product, with the firmware developers decision on what that limit should be on each device being based on a compromise how powerful SoC (chip component and its Zigbee stack) it uses and the intended purpose on the product itself. So those are limitations on each specific device that you are using, or more specifically, they are limitations set by the firmware developers of each specific device.

So for a newer ”dedicated Zigbee Router device” (as described in the original first guide post above) the firmware developers will on purpose have configured that product’s firmware to allow more devices connected to them than what th same developer would configure a “non-dedicated Zigbee Router” product like for example a mains-powered Zigbee power-plug or wall-switch which can act Zigbee Router too but was really designed to mainly service another function. This is as well partially due to “non-dedicated Zigbee Router” products usually using less expensive Zigbee SoC chips which have less resources and should therefor not be configured to route as many devices, For example for the CC2652P based dedicated products by TubeZB the firmware developers have set the limit to support up to 50 devices to connect and routed via it (which is around 10-times more than most common non-dedicated Zigbee Router devices). See → Zigbee Router/Repeater – TubesZB

Similar scenario if you have a Zigbee Coordinator based on an older SoC chip (which is also likely to be based on an older Zigbee stack / firmware version) as then the firmware developer might have set the limit of direct children to 20 (or even lower like for CC2530/CC2631 or the older ConBee/RaspBee), however if you have a newer Zigbee Coordinator adapter that is based on a newer and faster SoC (like the EFR32MG21 or CC2652P) then the firmware will have more likely configured the limit of direct children devices to somewhere between 32 and 64 (or even higher if using the even newer EFR32MG24 or later). See the example table here for the community Z-Stack Zigbee Coordinator firmware → Z-Stack-firmware/coordinator at master · Koenkk/Z-Stack-firmware · GitHub

Another thing that affects this is if your connecting devices are using the Zigbee 3.0 specification as that has a much higher security overhead than devices that connect using older Zigbee specifications. Fact is that while you can in practice connect practically an unlimited total amount of older Zigbee Router devices to a Zigbee network with a CC2652 or EFR32MG21 based Zigbee Coordinator, even those have a soft limits of around 200 Zigbee 3.0 devices simply because their SoC will run out of onboard RAM-memory (due to the higher security overhead of the Zigbee 3.0 protocol). Thus if you ever want to have a total amount of devices higher than 200 connected to your Zigbee network at the same time then you will need to upgrade to an even faster Zigbee Coordinator that uses a newer chip like the EFR32MG24 or EFR32MG26 because those SoCs more RAM-memory. See example → TubesZB EFR32 MGM24 PoE Coordinator 2024 – TubesZB

As such you might now better understand why having a newer Zigbee Coordinator adapter in combination of newer dedicated Zigbee Router devices and/or non-dedicated Zigbee Router devices where at least some are based on the higher performing SoC chips (with more onboard RAM) that have been configured by the firmware developers to allow you to connect more total number of devices to them. Only some of this is by the way explained in simpler terms in the ZHA integration here so please feel free to improve that text → https://www.home-assistant.io/integrations/zha#using-router-devices-to-add-more-devices

80

Yeap. I read somewhere that the actual limit is 16 000 or smth ;))

81

But it seems I can add more routers even in this situation where I am full. I can’t add end devices though without adding new routers. But for sure I don’t have to delete any end devices to add new routers. I don’t know the limit with routers. It probably goes towards the 1000s. :slight_smile:

82

Note! Due to new higher security requirements in the Zigbee 3.0 specifications, Zigbee 3.0 coordinators can only support a limited amount of Zigbee 3.0 devices. For older Zigbee Coordinators that uses the older Zigbee Home Automation 1.2 there is is no limit on the max number of Zigbee 3.0 devices that can join because they will connect in backwards-compatible mode (e.i. not use the higher security).

As I tried to explain above, while the theoretical limit for total amount of devices you can add to your Zigbee network if they use older Zigbee specifications is 64,000 nodes per network, but you will unfortunate hit the bottleneck of the Zigbee Coordinator running out of RAM (i.e. data memory) much sooner if you have a Zigbee 3.0 network and connect Zigbee 3.0 devices that use that newer protocol. Meaning that it will in practice not be possible to connect more Zigbee 3.0 devices than your Zigbee Coordinator has computational and data memory (RAM) to handle.

Again, the newer Zigbee 3.0 protocol have much better security which as a downside adds much higher overhead as each device you takes more RAM-memory, especially for the onboard RAM (i.e. data memory) of the Zigbee Coordinator, and in practice your Zigbee Coordinator will run out of much RAM sooner that you will hit any theoretical limits what the Zigbee specification can handle.

For reference, the most popular “modern” MCU radio SoCs used in Zigbee Coordinator adapters today are EFR32MG21 (running EmberZNet Zigbee stack/firmware from Silicon Labs) and CC2652P (running Z-Stack Zigbee stack/firmware from Texas Instruments) which both feature up to 96 kB of RAM depending on the specific SKU model uses, and those have been proven by members in the ZHA and Zigbee2MQTT community to at most handle around 200 Zigbee 3.0 devices in total on the same Zigbee network (note that is in total including those connected via Zigbee Routers and not only directly connected devices.

The newer generation’s of Silabs Zigbee MCU radio SoCs are; EFR32MG24 which can up to 256 kB RAM data memory, while the even newer EFR32MG24 can up to 512 kB RAM data memory. Similarly goes for TI’s CC2674 (CC2674P/CC2674R) and CC1354 (CC1354P) which can have up to 296 kB RAM data memory. I do not think it has been proven by members in the ZHA and Zigbee2MQTT community, but at least in theory if your existing Zigbee Coordinator is a CC2652P with 88 kB of RAM data memory can handle a maximum of 200 Zigbee 3.0 devices in total then is logical that the newer CC2674P with 296 kB RAM data memory should have no problems handling 500 Zigbee 3.0 devices in total.

So again, it is only OK to add more devices if and when you just add older Zigbee devices that use the now old Zigbee Home Automation 1.0 (or Zigbee Light Link 1.0) protocol specifications that you can connect 1000+ devices (probably only a few thousands of older Zigbee devices as the adviced workable limit). But would want to only use older devices today?

Summery; if you already have a EFR32MG21 or CC2652P based Zigbee Coordinator today then there should not be any need for you to replace it with a newer model until either you reach that approximate 200 Zigbee 3.0 device limitation when it runs out of RAM or until the MCU SoC manufacturers stop maintaining your old MCU SoC model and thus you can not get firmware updates with bug-fixes/security-patches.

83

Hedda,
There are some devices that “pollute” the network with a lot of information, making it unstable. Some MMW and Tuya energy meters, for example.
In these cases, do these devices end up consuming a lot of the coordinator’s RAM memory or do they cause other types of problems?

1 Like
84

Those kinds of problem devices usually cause by other problems as they either flood the Zigbee network (basically jaming it so no other devices get a free alot in to send their messages) or in the case of some Tuya, Aqara, and Xiaomi Zigbee Router devices they will not router/fordware messages that are not using the same brand (essentially creating a black-hole that swallow and kill messages from other brand devices that connect to them). This is why it is usually ok to buy battery-powered devices from those companies but you should be extra careful before buying any mains-powered devices from those companies if they are meant to act as Zigbee Router devices, (nothing that you can not disable the routing feature on Zigbee Router devices).

2 Likes