I’d agree that as ZHA controls a mesh network, the range of an individual device is totally irrelevant. What is important is that there are enough mains-powered routing devices to give more than one path between nodes - a mesh.
You’d think 123 devices would be enough, but my suggestion is to move more mains powered routers close to your Yellow. Cheap IKEA TRÅDFRI mains switch sockets work well.
The Yellow has one of the best Silicon Labs chipsets, but with a small PCB antenna rather than the larger monopole on the likes of a Sonoff USB.
I’ve posted before that he Yellow PCB does have unpopulated J9 IPEX / U.Fl connector bottom left , but I doubt there’s a simple way to switch the coordinator antenna inputs even if your SMD soldering is up to the task. If this helps, this post!
FYI, the Sonoff ZBDongle-E and the SkyConnect are both based on the exaxt same EFR32MG21 SoC chip, and either will handle around 200 Zigbee 3.0 devices (or many more older Zigbee devices) as long as you just add enough Zigbee Router devices. So lack of memory should not be a problem for you if you add many more Zigbee Router devices. Read and follow the original post above.
I’m a bit confused by the numbers you quote. As I understand, the physical limit if a single zigbee network v3.x or older is 64,000 nodes. Why would you think that you could have more devices with firmware older than 3.x attached to the coordinator you cite as compared to 200 zigbee 3.x devices attached?
‘200 Zigbee 3.0 devices (or many more older Zigbee devices)’
Below is a video of a group claiming to show over 10 years ago, to have 1,000 devices connected to a single coordinator. I have no deeper knowledge of this example or it’s layout.
It it because of the much larger security overhead of Zigbee 3.0 compared to older Zigbee protocols such as Zigbee Home Automation 1.2 and Zigbee Light Link 1.0 which does not have overhead when adding more devices. So you have to understand the different RAM footprint overhead between Zigbee 3.0 devices and older devices.
The main bottleneck is the RAM memory on the SoC and Zigbee 3.0 devices connected to a native Zigbee 3.0 Zigbee Coordinator will use higher security level (encryption, etc.) which takes up a larger footprint in RAM per device.
So the fact is that if you only connect newer Zigbee 3.0 devices then the Sonoff ZBDongle-E and SkyConnect baded on EFR32MG21 will run out RAM after connecting abond 200 Zigbee 3.0 devices, but if you instead use older Zigbee devices (i.e. Zigbee Home Automation 1.2 and Zigbee Light Link 1.0 devices) then you can connect several thousands of such devices as they do not use much RAM, and obvoisly a mix of newer and older devices will result in a number in between.
Future SoCs such as the EFR32MG24 feature more RAM and faster CPU so they will be able to handle more Zigbee 3.0 devices than EFR32MG21 that have less RAM.
Alternativly if you are willing to sacrifice security then you can get around this by connect your Zigbee 3.0 devices to a older Zigbee Home Automation 1.2 Coordinator (like example ConBee 2) as then all devices will connect in backwards compatible mode and not use the Zigbee 3.0 security.
So yes, you can connect thousands of Zigbee devices, but not if they are native Zigbee 3.0 devices connected to a native Zigbee 3.0 Coordinator like EFR32MG21 based adapters are.
That is a theoetical limitation if you had unlimited RAM and CPU resources on the Zigbee Coordinator SoC, while in practice with newer Zigbee 3.0 security overhead you will run out of RAM and CPU (especially RAM) on even the latest Zigbee Coordinator SoC.
To futher clearify, you will run out of RAM on the SoC long before you reach that limit and after that you run out of CPU on the SoC. Thus the RAM and CPU on the SoC is the bottleneck if want to connect more Zigbee 3.0 devices, which is why we can look forward to newer Zigbee Coordinator adapters based on example the new EFR32MG24.
Yeah, those are not Zigbee 3.0 devices connected to a Zigbee 3.0 Coordinator. Zigbee 3.0 devices only started to become available on the marked in 2016 by early adopter manufactuers and most other companies did not start to release Zigbee 3.0 devices until around 2019. So chance is that if you have a Zigbee device that was released more than 5-years ago then it is not a Zigbee 3.0 devices.
Alao note that the popular ConBee 2 and RaspBee 2 are not Zigbee 3.0 Coordinators so all devices will connect to them in backwards compatible mode and that is why you can connect more Zigbee 3.0 devices to them than you would expect to a older Zigbee Coordinator, but again you sacrifice security when you do so. (It is like connecting an newer WiFi device to an old WiFi router / access point where they can only connect to the newest protocol version that share).
Unfortunately my NUC only has USB 3 ports. Therefore, I bought a multi-shielded USB 2 extension cable with a length of 3 meters and removed my Sonoff Dongle-P from the range of the NUC.
Is this USB 2 cable enough, or is it better to use an additional USB 2 hub in between to exclude possible interference from USB 3? I previously thought the cable automatically reduced the signal and therefore possible interference?
The second question concerns the antenna of the Sonoff dongle. I have read that it can be helpful to connect another alternative bigger external 2.4Ghz antenna to this to improve network range and stability. Are there any suggestions for such an alternative antenna? There are so many antennas on the www that I lost track.
I understand that people have tested and report less interference via USB 2.0 ports on a USB 2.0 hub. Since the radio adapter dongles are only USB 2.0 capable it will never connect with USB 3.0 speed regardless.
You can and it will improve transmission but can also make reception worse since it can also recieve more interference, though interference is primarly close sources. Personally I recommend just buying more known good Zigbee Router devices instead since that will do a better job at improving you network mesh which is most important.
So you think I could leave it like that for now? So in my case, is the dongle far enough away from the USB 3 port to minimize interference?
You can and it will improve transmission but can also make reception worse since it can also recieve more interference, though interference is primarly close sources. Personally I recommend just buying more known good Zigbee Router devices instead since that will do a better job at improving you network mesh which is most important.
OK. So more and bigger (antenna) is not automatically better. Hmm? Maybe the routers mentioned. In the same coordinator’s room, it’s actually just an IKEA driver. In the next room and in the hallway next to the coordinator’s room (maybe 4-5 meters away) there are two HUE bulbs each and then in other rooms there are HUE bulbs and HUE ceiling lights. I thought I was already well stocked with routers. Maybe I should additionally install a router or range extender in the coordinator room?
The LQI of the IKEA driver in the same room about 2 meters away from the coordinator is just about 130. With the two HUE bulbs mentioned nearby it is only 60-80. And so on in the next rooms less and less.
As long as you already taken basic actions to avoid interference then adding enough ”known good” Zigbee Router devices is the key to success.
Also make sure that you never power off a Zigbee Router devices, which is why it is not recommend to Zigbee lightbulbs in lights if you have not removed the dumb switch.
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 AMAZING!!
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…
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).
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.
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:
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!
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.
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.
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.
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).
this post!