Zigbee network optimization: a how-to guide for avoiding radio frequency interference + adding Zigbee Router devices (repeaters/extenders) to get a stable Zigbee network mesh with best possible range and coverage by fully utilizing Zigbee mesh networking

Community Guides
, , ,
60

Thank you very much for your feedback and the useful links. Now I still have a lot to read.

61

Thank you for this amazing write up! I’m new to home assistant and I’m currently awaiting my zigbee dongle to be delivered so anxiously I jump everytime I hear my phone chime or doorbell ring hoping for an update on it arrival! I will definitely be referring back to this :heart: AMAZING!!

62

I think this point is missing from your great post (or I missed it):

An underestimated source of errors are routers/repeaters that are connected to a physical switch. Typically this happens when someone (like me) replaces their non-smart bulbs with zigbee bulbs. When the light switch is on, everything works, the zigbee bulb can be controlled via the home assistant. When the light is turned off at the physical switch, the light goes out. But in the background the Zigbee network loses one (or even several) routers/repeaters.

The only option is to always power the zigbee bulbs (which act as routers/repeaters) and to replace the physical switches with zigbee switches.

Is it possible to configure the Zigbee network so that it does not use Zigbee bulbs as routers/repeaters? As far as I know, no.

From here the content no longer fits the topic, so I have created a new topic here.

Off topic stuff...

My goal is that I can turn the light on and off with a switch (zigbee or physical). When it’s on, it dims depending on activity and sun.

Now my special request:
I would like to be able to turn the lights on and off even when my home assistant rapberry pi is unplugged or not available.

I currently have this setup with wifi bulbs and physical switches. When the WiFi bulbs are turned on with the physical switch, they immediately light up as when they were turned off (or a preconfigured value).
As soon as the WiFi bulb is registered in the WiFi network, this triggers an automation that tells the WiFi bulb how it should light up. I think this is not possible with zigbee bulbs? At least not without disrupting the network by adding and removing routers/repeaters…

All hints and advice are welcome!

63

Nope.

WiFi is definitely the winner here. However, there are Zigbee devices that still operate with a relay and no connection to a mesh. Aqara rockers and the T1 I think both operate this way. I know the rockers do (unless configured to be decoupled), but I’m not sure about the T1. Personally, for my setup, all my switches are either Aqara single/double gang rockers or Shelly Plus 1s. I use the Aqara rockers where I don’t have a neutral wire (old house and only some of my switch boxes have neutrals) and the Shelly’s pretty much everywhere else. I do have a couple of Leviton voice dimmers as well (which are also WiFi), but I’ve never tested their disconnected behavior.

Some Zigbee bulbs will retain their last state (router config, last power status, etc). Hue, Ikea, Innr and Innovelli all do for sure. But, the damage has already been done to the mesh and that just takes time to heal (as you stated). Personally, I never recommend people buy Zigbee bulbs for use in places where there is a physical switch connected unless they have upgraded that switch already (smart switch, hard wiring, etc).

1 Like
64

Ignoring the fact that no matter the tech smart bulbs are designed to be always powered on unless otherwise specified on the box…

You CAN Use Zigbee bulbs that are KNOWN not to route. (see next) Or use lighting controls that support ‘smart bulb mode’ (do not disconnect the load end of the control)

Sengled made an engineering decision to NOT route any of thier zigbee bulbs for THE EXACT reason stated. Basically - they got tired of answering that question on thier support desk. Sengled, by doing this is basically saying - Smart bulbs should ALWAYS be powered and don’t use them as the main routers in your mesh.

That said it’s the exact reason I ONLY use Sengleds when a Zigbee smart bulb is required… I treat it like a battery device and make sure the mesh is strong without it. Good on them for that decision.

1 Like
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