zigbee

Ditching proprietary Zigbee bridges

by
A photo of two dongles, both Sonoff ZBDongle E devices, labelled 'Zigbee' and 'Thread'.

For my Zigbee devices, I use Zigbee2MQTT and a Sonoff USB Zigbee dongle as my co-ordinator. As I came quite late to the Zigbee party, I didn’t pick up a proprietary Zigbee bridge, but if I had, I wouldn’t use one. Today, I’m going to go through a few reasons why.

Examples of proprietary Zigbee bridges include the Philips Hue Bridge, the Ikea Dirigera Hub and the Tuya Zigbee gateway, but there are others. Here are my reasons why it’s best to go with a more open system, like Zigbee2MQTT or Home Assistant’s Zigbee integration. I’ve previously compared the two.

A map of my Zigbee network, showing the mesh connections between devices

Having all your devices on one Zigbee network

Zigbee is a mesh network. That means that, as more devices are added, the network actually gets stronger, as each device can communicate with each other. This is especially true with mains powered Zigbee devices like smart plugs and light bulbs. Therefore, if all of your Zigbee devices are on the same network, the connection between each device should be stronger. I’ve included a diagram of my network above, and you can see the multiple mesh connections between devices.

If you have multiple Zigbee bridges – say one for your Hue lights and another for your Ikea smart plugs – you risk causing interference between networks. Furthermore, Zigbee runs on the same 2.4 GHz frequency band as Wi-Fi, Bluetooth and your microwave oven. Having everyone on one network should reduce interference.

Better device support

Some Zigbee bridges are better than others, when it comes to supporting third-party devices. For example, you might be able to add an Ikea Tradfri bulb to a Philips Hue bridge, but possibly not another kind of device. Zigbee2MQTT has, arguably, the best device support and will work with just about any Zigbee device, regardless of manufacturer. You can check the Zigbee Device Compatibility Repository to see which devices work with which platform.

My Zigbee devices are a mixture of Tuya and Ikea, and they co-exist well within Zigbee2MQTT.

Cheaper

Most proprietary Zigbee bridges cost around £60. Meanwhile you can plug a USB Zigbee dongle into a spare PC, or a low-powered Raspberry Pi device that you may already have. The USB dongles typically cost £20-30 each (my Sonoff ZBDongle-E costs £27 at Amazon at present [sponsored link]), and you’ll only need one dongle and one computer rather than multiple bridges.

Easier to troubleshoot

With both Home Assistant’s ZHA and Zigbee2MQTT, you can look at the logs to see what’s going on inside your Zigbee network. Hopefully, that’ll help with troubleshooting any devices that aren’t working the way they should. As shown above, you can also get a diagrammatic representation of your network. This lets you see how your devices connect to each other and whether there are any weak spots on your mesh.

Not reliant on cloud services

There’s a risk that your proprietary Zigbee bridges could become expensive paperweights, if their manufacturers decide they’re no longer going to support them and turn off the cloud servers. They may continue to work locally, but if their cloud servers go dark, you may find that you can’t control your devices remotely any-more. By hosting your own Zigbee bridge, you can still have remote access but on your own terms. I use Homeway for remote access to Home Assistant, but you can also set up your own reverse proxy, for example.

Proprietary bridges may offer some convenience and a nice app, But, if you’re willing to put a bit of effort in to manage your Zigbee devices yourself on one single network, I think there are more advantages of going down the route of using Zigbee2MQTT or ZHA.

Zigbee PIR motion sensor

by
A photo of a Zigbee PIR motion sensor

Regular readers may be relieved to know that I’m done writing about my trip to Athens, and are back to the occasional series of ‘Neil reviews cheap Zigbee devices from AliExpress’.

Earlier this month, I reviewed Zigbee window sensors, and this time I’m reviewing a Zigbee PIR motion sensor. PIR stands for ‘passive infrared’, and senses changes in infrared light to detect motion. It’s used in most motion detectors for burglar alarm systems, but you can buy sensors such as these for home automation too. In my case, I’ve fitted one to the top of our cellar stairs, to turn on a light in the cellar when motion is detected.

It’s pretty small – about an inch across – and runs on a single CR2450 battery (provided). You also get a sticky pad to attach to surfaces, and a couple of tools for opening the battery flap and for resetting and pairing it. It’s compatible with Zigbee2MQTT.

In terms of configurability, you can adjust its sensitivity, and its keep time. The keep time means that it remains in the ‘occupied’ (i.e. motion detected) state for a given number of seconds after motion was last detected. If you have a motion activated light, this prevents the light constantly flashing on and off.

As with the window sensors, you can also buy these devices from Amazon (sponsored link) if you need them quickly, but again they’re significantly more expensive than AliExpress.

To make the light turn on and off, I have automations set up in Home Assistant. I also bought a Zigbee smart light bulb for the motion sensor. Ideally I would have just bought one that switches on and off, but the cheapest one I could find is a colour changing dimmable one. Which is overkill for a cellar light, but hey, it was cheap. Indeed, the motion sensor and light bulb collectively cost less than £9.

Tuya Zigbee Window Sensors

by
A photo of a Zigbee window sensor

I recently picked up a pair of these Tuya Zigbee Window Sensors from AliExpress. At £7.50 for two (plus VAT and shipping), they’re an absolute bargain; on Amazon (sponsored link), expect to pay more than double that for just one. The sensors detect when a window or door is opened or closed, and can both report the current status of the window or door, and be used to trigger actions when the window or door is opened or closed.

Wait, didn’t you rant about Tuya in February?

Why yes, I did rant about Tuya Wi-Fi devices, and I stand by what I wrote. However, you can get many Tuya-compatible Zigbee devices, which can be used with Zigbee2MQTT without having all your data go to servers operated by a Chinese company. So yes, I wouldn’t be keen to buy any new Tuya Wi-Fi devices in future, but I see little issue with Tuya Zigbee devices.

Installing the window sensors

The sensors come in two parts. One holds the batteries (two AAA batteries, not included) along with the circuitry, and the other, smaller part is what detects whether the door or window has opened. Each part comes with an appropriately sized piece of sticky foam, so you can just stick the small part to your window, and the larger part to the frame. You need to ensure that, when closed, the two parts touch.

To test whether they work, open and close the window or door – if you see a little red light flashing when this happens, then you’re good.

Zigbee devices need to be paired to your Zigbee mesh network. Once you’ve enabled pairing on your Zigbee controller (in my case, Zigbee2MQTT), you need to press and hold the reset button on the window sensor for five seconds. It comes with a little metal pointy thing to help with this – a bit like the pointy things for ejecting SIM cards on a iPhone. Once it has joined your network, you should be good to go.

Using the window sensors with Home Assistant

Any new devices in Zigbee2MQTT automagically appear as new MQTT devices in Home Assistant. Right now, I just have dashboard badges for the two window sensors, so I can see at a glance whether those windows are open. I’m planning to add an automation which switches the heating off when one or both of the windows are open, and potentially a notification at bedtime to remind me if I’ve left a window open as it’s getting dark.

You could add them to a door, so that when you open it, a light comes on, and then turns off when the door is closed, or after a certain time delay.

For now, I’ve only bought two of these. As mentioned, each one requires a pair of AAA batteries, and whilst I could fit them to every opening window, that’s potentially a lot of batteries to replace. At least they take standard AAA batteries which can be easily recharged. I’ve only had them a couple of weeks, and so I can’t yet give an estimate of how long the batteries will last, but they’re both still showing 100%.

Bifrost – a Hue smart light emulator

by
A screenshot of the Bifrost logo

Today I’m writing about Bifrost, which is software that emulates a Philips Hue bridge for controlling smart light bulbs. It works with Zigbee2MQTT, and is designed to replicate the core Philips hardware using open source software.

Bifrost allows you to control any Zigbee smart lights (bulbs, strips etc) using the Philips Hue app, without needing to buy the Hue Bridge. The Hue bridge normally costs around £50 on Amazon (sponsored link). Instead, Bifrost can run on the same hardware as, say, Home Assistant, or an old an PC.

Setting up Bifrost

I’ve recently installed Bifrost on the same Raspberry Pi that hosts my Home Assistant instance (there’s an addon to make it easier). As it stands, it’s relatively new software, and so it has to be configured manually using a YAML file. You also need to be using Zigbee2MQTT, and have Zigbee smart bulbs – non-Zigbee devices aren’t supported, and nor is Home Assistant’s built in Zigbee controller. Also, Bifrost only works with lights – for example, I have a Zigbee smart plug which controls a light, and Bifrost ignores this.

The other thing to be aware of is that Hue uses ports 80 and 443, so if you want to use Bifrost, there can’t be any other software acting as a web server on the same machine. I had to pause my use of Nginx Proxy Manager to get it to work; thankfully, I’m now using Homeway for remote access to Home Assistant so this wasn’t an issue. Whilst you can tell Bifrost to open other ports instead, most Hue apps won’t work if you do this.

Once Bifrost is running and has found your Zigbee devices, you should be able to use the official Hue app to set up your lights. You’ll need to tell the app that your bridge doesn’t have a QR code; if all goes well, it’ll detect the Hue mDNS packets that Bifrost broadcasts, and it’ll then work just as if you had a genuine Hue bridge.

Benefits of the Hue app

The official Hue app has some features that other smart home apps don’t have – mainly the ‘Scene Gallery’. If you have multiple multi-colour lights in a particular room, Hue can offer to set them to different, but complementary colours.

It should be noted that, with Bifrost, you can use the Hue app to control (theoretically) any smart lights, regardless of whether they were manufactured by Philips or not. The multi-colour lights I have were a couple of cheap Tuya Zigbee strips from AliExpress, and they work fine in the Hue app through Bifrost.

Other Hue emulators

Bifrost isn’t the only emulator in town. There’s also DIY Hue, which, like Bifrost, can be installed using Docker or as a Home Assistant addon. There’s a comparison between Bifrost and DIY Hue here.

Home Assistant itself includes a Hue emulator. It’s an older integration that has to be configured using YAML, and it’s more limited. It probably won’t work with the official Hue app – I haven’t tried it myself. It’s mainly there as an easier way to bridge devices in Home Assistant into Amazon Alexa.

How to use bindings in Zigbee

by
Screenshot of the Zigbee2MQTT interface showing a binding being set up

One advantage of the Zigbee smart home protocol that I didn’t mention in last summer’s comparison was Bindings. This is where you bind a function of one Zigbee device to another, allowing the first device to control the second device directly.

Zigbee, as you may be aware, is a mesh network protocol. That means that every Zigbee device will connect to every other Zigbee device in range. Now, every Zigbee network also has a Controller, which is a device that issues commands to the network. In my case, this is my Raspberry Pi running Home Assistant, with a Sonoff ZBDongle-E plugged into it.

The advantages of bindings

However, when you bind two devices together, they can issue commands directly, without needing to go via the Controller. This is useful, because it means that devices can still work, even if your Controller is offline.

For example, let’s say you have a Zigbee motion sensor in your bathroom. You can set up a binding so that, when the sensor detects motion, it’ll turn on the bathroom lights. Once the binding is saved, this will work regardless of whether your Zigbee controller is online.

The other key advantage of bindings is that they should be faster. We’re probably only talking micro-seconds here, but as commands can be sent directly from one device to another without a round-trip to the Controller, they should be a little more responsive.

If you’ve ever bought Ikea TrÃ¥dfri bulbs, these usually come with a remote that has already had a binding set up. That way, the remote will work with the bulb out of the box without an Ikea Dirigera hub (or other Zigbee controller). But both can also be paired with a Zigbee controller if you have one.

Setting up Zigbee bindings

If you use an off-the-shelf Zigbee controller like the aforementioned Ikea Dirigera hub, or a Philips Hue Bridge, then you may be able to set up bindings using these. I don’t, so I can’t advise, but bindings can be set up using Zigbee2MQTT (which I use) and Zigbee Home Automation in Home Assistant (which I don’t).

In Zigbee2MQTT, you need to select your device, and then go to the ‘Bind’ tab. It’ll then expose a list of ‘endpoints’ that can be bound. In my experience, these are just numbers, so you may need to experiment to see what, for example, ‘endpoint 242’ controls. You can then bind this to the endpoint of any other Zigbee device to control it.

It’s worth noting some key points here:

  1. Not all Zigbee devices support bindings
  2. Those that do may only allow expose limited endpoints for binding, so you won’t be able to control all aspects using bindings.

For example, I have some Zigbee colour lights (which I used in my grouping example). I can bind them to another Zigbee device to turn them on or off, but not to change the colour. That still requires communication from the Zigbee controller.

Other protocols

If you have more than one Z-Wave device, then you can set up ‘Associations‘ between devices which work in a similar way to Bindings in Zigbee. Home Assistant users can set these up using the Z-Wave JS UI addon. I’m not aware that Matter offers anything similar.

A tale of two dongles

by
A photo of two dongles, both Sonoff ZBDongle E devices, labelled 'Zigbee' and 'Thread'.

I now have two dongles – both Sonoff ZBDongle E devices – connected to the Raspberry Pi which runs my Home Assistant instance. One is for Zigbee, and the other one is for Thread.

Last January, I wrote about how I was using both Zigbee and Thread on the same dongle. This uses ‘multi-protocol’ mode, and requires a Home Assistant addon which can differentiate between Zigbee and Thread data packets. However, this is no longer recommended:

During the further development and testing of the multiprotocol firmware, we have concluded that while Silicon Labs’ multiprotocol works, it comes with technical limitations. These limitations mean users will not have the best experience compared to using dedicated Zigbee and Thread radios. That is why we do not recommend using this firmware, and it will remain an experimental feature of Home Assistant Yellow and Home Assistant SkyConnect. If you currently have the multiprotocol firmware installed but don’t actively use it to connect to Thread devices, we recommend that you disable multiprotocol.

For the time being, I have been operating a single ZBDongle E just with Zigbee firmware. However, now that I have some Thread devices, I decided to buy a second dongle and flash that with Thread firmware, using this web flasher.

Now, my Thread smart plugs can be reached by Home Assistant without its own Thread dongle – I have a Google Nest Wi-Fi system which also acts as Thread Border Routers. Therefore, having a Thread dongle isn’t necessary – Home Assistant can see and interact with the devices using Google Nest Wi-Fi. But having a dedicated Thread dongle for Home Assistant does offer some advantages:

  • Thread is a mesh network, so adding another Thread device extends the mesh and should improve resilience.
  • It gives Home Assistant direct access to the Thread network.
  • It enables another Thread Border Router, offering an additional exit node.
  • The Home Assistant Thread Border Router addon includes a web interface, allowing you to view your network’s topology and get a visual representation of how the devices connect to each other.

You may also notice that I’ve labelled the two dongles so that I know which one is which, using my trusty Bluetooth label printer.

If you’re looking to buy your own Sonoff ZBDongle E, you can, of course, buy one from Amazon (sponsored link), but (whispers: they’re cheaper on AliExpress).

Just a note: I was unable to flash any updated firmware on the newer dongle that I bought this month, using the Web flasher, so that’s now the Zigbee dongle. Apparently it may be an issue with the Windows drivers, as I was able to use Home Assistant’s Silabs Firmware Flasher addon to update it instead. If you specify this custom URL in the addon settings, it’ll use the latest (as of November 2024) Zigbee firmware. It’s also worth noting that, if you use Zigbee2MQTT, once you’re running the latest Zigbee firmware, you’ll need to tell Zigbee2MQTT to use the new ’ember’ driver rather than ‘ezsp’.

The older dongle seemed to happy to accept different firmware using the web flasher, having done so in the past. So, that’s the one with the Thread firmware.

Grouping devices together in Home Assistant

by
A screenshot of a Home Assistant dashboard showing a light group set to 50% brightness and a green colour

If you have several devices of the same type, and want to be able to control them all together, then it’s possible to group them together in Home Assistant. The integration is simply called ‘Group‘, and once configured, it creates a helper entity that will perform the same action on all grouped devices.

Last year, I picked up two Zigbee colour-changing LED strips from AliExpress. One was to go in our nine-year-old’s bedroom and the other in the living room – the idea being that we could set the colours depending on the time of year. Rather than having Christmas lights that we put up in December, and took down in January, these lights could stay up all year round. For example, they could be pink around Valentines Day, or green at Halloween.

That was the theory. However, despite ordering 3 metre long strips, they were too short. Our house is about 100 years old with tall ceilings, and consequently, tall windows. In the end, two LED strips together, totalling 6 metres, were long enough just for one window and so they’re both in our nine-year-old’s bedroom. Because they’re two separate strips, they appear and work as separate Zigbee devices.

Creating a group in Home Assistant

You can start the process of creating a group either on the Integrations or Helper screens of Home Assistant’s settings. First of all, Home Assistant will ask you what type of devices you are grouping – all the devices must be of the same type, so you can’t group a switch and a light together.

Well, actually you can – but first you need to create a ‘Change Device Type of a Switch’ helper. Say you have a smart plug controlling a light; you can then create a Helper that appears as a Light, and then that can be grouped with other lights.

Anyway, in my example, I selected Light, gave it a name, and then selected the entities that needed to belong to the group – i.e. the individual lights. There’s also a ‘Hide Members’ option, which will hide the devices you’ve selected from the list of entities in Home Assistant. If you’ll only ever want to interact with the lights as a group, then tick this. However, if you still want to be able to manage individual lights as well, then keep it unticked.

On my Home Assistant dashboard, the icon shows that the new group helper is for multiple lights. The good news is that, even with colour changing lights, all the lights in the group will respond the same way together once grouped.

I also make these lights available in Apple Home and Google Home, and again, I make sure that Home Assistant is exposing the group, rather than the individual lights. As such, when I use Google Assistant to turn them on and change the colour, both lights change simultaneously.

Comparing Bluetooth and Zigbee plant monitors

by
A photo showing a Zigbee plant monitor on the left and a Bluetooth plant monitor on the right

Search for ‘millennials house plants’ on Google and you’ll see lots of magazine articles about how people of our generation love our house plants. Alas, neither Christine or I are particularly good at keeping our house plants alive, apart from those in the already humid environment of our bathroom. So, I’ve been experimenting with electronic plant monitors to see if one will help us keep our plants thriving.

I’ve tried two different sorts of plant monitor: a Bluetooth Low Energy plant monitor from HHCC, and a Zigbee plant monitor from Haozee which works with the Tuya smart home platform. Both were bought from AliExpress.

A photo of the HHCC Bluetooth Smart Flower Monitor, inside a white plant pot and under the leaves of a basil plant.

HHCC Smart Flower Monitor

First to the HHCC model, which uses Bluetooth Low Energy. It’s sometimes known as ‘MiFlora’ and compatible devices are also sold under the Xiaomi brand. Of the two, it’s smaller, and offers more sensors; as well as detecting how much moisture is in the soil and the temperature, it’ll also try to measure how fertile the soil is, and the light intensity. It’s powered by a small CR2032 button battery which is replaceable. Officially, you should use the Flower Care app with it, but it also works with Home Assistant using the Xiaomi BLE integration.

The button battery should work for about six weeks before it needs replacing. Alas, these CR2032 batteries are not rechargeable, so you’ll need to take it to somewhere that recycles batteries and replace them when they run out of charge. At the time of writing, you can get 20 replacement CR2032 batteries for around £6, which should be enough to last you a couple of years.

Bluetooth Low Energy, as the name suggests, doesn’t have a long range. Therefore, if you are using this HHCC device with Home Assistant, you’ll need to have your device (or a Bluetooth proxy) in very close range.

A Zigbee plant monitor, which is white, oblong shaped and has light blue edging, sat in a white plant pot next to a basil plant.

Haozee Zigbee plant monitor

As you’ll see from the side by side photo at the top of this blog post, this Zigbee model is a bit bigger than the Bluetooth model. That’s because it takes two AAA batteries, rather than a CR2032 button battery. Consequently, battery life should be much longer – premium AAA batteries can typically hold up to 1100 mAh charge, compared to around 240 mAh in a CR2032 battery. Also, AAA batteries can be rechargeable.

The Zigbee signal should also be much stronger than Bluetooth Low Energy. I’ve certainly had fewer connection issues with this one compared to the HHCC model, even though the nearest Zigbee device is further away.

However, unlike the HHCC model, it doesn’t offer light or soil fertility sensors. You’ll just get the moisture level and temperature, as well as how much charge the battery has remaining. Also, if you’re planning to connect this to Home Assistant, be aware that it (probably) doesn’t support Home Assistant’s built-in ZHA integration. This was the reason why I set up Zigbee2MQTT.

The other disadvantage of Zigbee devices is the need for a hub or bridge of some sort. I use a Sonoff USB Zigbee dongle plugged into my Raspberry Pi running Home Assistant, but I imagine you’re supposed to use something like this Tuya Zigbee hub (sponsored link) and the Smart Life or Tuya phone apps. So whilst the Zigbee plant monitor itself was slightly cheaper than the Bluetooth model, there’s an initial setup cost if you don’t already have a Zigbee controller.

My recommendation

The HHCC Bluetooth plant monitor is fine if you just want to use the official Flower Care app, or have your plant very close to your Home Assistant device. The replacement batteries are cheap and you may not need any extra hardware to get it to work.

If you need a longer range, don’t want to replace batteries as often, and/or have other Zigbee devices already, get the Zigbee plant monitor. You can use standard rechargeable AAA batteries with it, and you’ll get a more reliable connection over long distances.

Comparing Zigbee2MQTT with ZHA

by
A screenshot of the Zigbee2MQTT home page

If you’re a Home Assistant user who is getting started with Zigbee devices, then you may be tempted to just use Zigbee Home Automation (ZHA), Home Assistant’s built-in Zigbee implementation. But you may also want to consider Zigbee2MQTT as an alternative, and this blog post will explain the differences.

I’ve recently started looking into Zigbee devices. Back in July, I wrote about the different smart home protocols, and Zigbee offers some useful features:

  • Low power, so battery-powered Zigbee devices shouldn’t need their batteries replacing too often.
  • It’s a mesh protocol, so every mains-powered Zigbee device forms a mesh with each other, allowing a network to span a house without necessarily needing multiple access points like Wi-Fi.
  • It works locally, so it’s more secure and private than Wi-Fi.

If you have Philips Hue bulbs, Ikea Tradfri devices or any Hive products from British Gas, then you’re probably already using Zigbee devices. You also have a private Zigbee network if you have a smart meter, although you won’t be able to use this with your own devices. I’m using a Sonoff USB Zigbee dongle (sponsored link), which is plugged into the Raspberry Pi which runs Home Assistant. Previously, I had flashed it with custom firmware to enable support for Thread and Zigbee, but I’ve reverted that now as multiprotocol support is experimental, and I have Google Wi-Fi devices which support Thread if needed.

Zigbee Home Automation (ZHA)

If you’re new to Zigbee and/or Home Assistant, my recommendation is to use ZHA, which is Home Assistant’s built-in implementation. If you plug your Zigbee dongle in, Home Assistant should detect it, and offer to configure the ZHA integration for you. Then, you just add devices using the ‘Add Integrations’ button on the Integrations Settings page, where a new ‘Add Zigbee device’ option will appear at the top.

Home Assistant should be able to recognise and offer to add any Zigbee device, but what you may find is that some devices won’t have any entities. This means that it’s not supported by ZHA. There’s a database of Zigbee devices which you can use to check whether they’re supported by ZHA or Zigbee2MQTT, and what you may notice is that there are quite a few which ZHA doesn’t support.

Zigbee2MQTT

One of the devices that I’ve recently bought seemingly fell into this latter category. To be fair, I never checked it with ZHA, but reading reviews online suggested that it would only work with Zigbee2MQTT and not ZHA. Zigbee2MQTT also maintains its own list of supported devices, which currently number nearly 4000.

Getting Zigbee2MQTT set up with Home Assistant is a much more involved process, however. You’ll need to install two addons and an integration:

  1. Firstly, you’ll need to install the Mosquitto addon, which is an MQTT broker – essentially a server which handles the MQTT messages. This is available from the standard Home Assistant add-on store. There are other brokers available, but this one is most recommended for use with Home Assistant.
  2. Next, you’ll need to install the MQTT integration. Once Mosquitto is running, Home Assistant may automatically detect it, and offer to install this for you, but if not you’ll need to install it manually.
  3. Finally, there’s the Zigbee2MQTT addon to install. This isn’t available from the standard Home Assistant add-on store until you add a custom repository.

Once all of these are installed, you’ll need to disable the ZHA integration if it’s enabled, and then open the Zigbee2MQTT web interface. Go into the settings, and ensure that it’s pointing at the Mosquitto MQTT server that you set up in step one above – you may need to enter its IP address.

You’ll then need to add devices using the Zigbee2MQTT web interface – there’s a button at the top right where you can enable pairing. Any devices you add will then show up automatically under the MQTT integration in Home Assistant.

Once set up, Zigbee2MQTT seems to work well, and I’ve seen others state that they’ve found it more stable than ZHA. But it’s a lot more difficult to set up, and ZHA will probably work for most users. If you’re new to all this, my advice would be to try ZHA first, and then re-pair your devices with Zigbee2MQTT if it doesn’t work out.

Comparing different smart home protocols

by
An AI-generated image of various smart devices connecting to a home

When I started acquiring smart devices for my home, my focus was on those that worked over Wifi (or Ethernet) – I wasn’t really aware of the likes of Zigbee, Z-Wave and other protocols that were out there. In particular, I avoided those that required the purchase of a hub or bridge, due to the higher upfront cost.

Now that I’m further along my smart home journey, I’m more open to considering a range of different protocols. They all have their advantages and disadvantages to consider.

Wifi (and Ethernet)

I’m grouping these together as devices that are visible to a standard home network and have their own IPv4 address. The majority of smart home devices use Wifi, as there’s usually no need to buy an additional hub or bridge. Therefore, set-up is usually easy (sometimes aided by Bluetooth), and their range is fine as long as they can pick up your home’s Wifi signal. It’s also very easy to connect these devices to cloud services.

In terms of disadvantages: Wifi primarily uses the 2.4 GHz frequency band, which is used by lots of things and so there’s a potential for interference. The ease of connecting these devices to the cloud can also be seen as a flaw; they’re more susceptible to being compromised by bad actors, and don’t offer as much privacy. Wifi is also quite power-hungry – devices that don’t plug into the mains will need their batteries changing more frequently.

Bluetooth

As mentioned, Bluetooth is often used with Wifi to initially provision devices, but some Bluetooth-only devices can be used in a smart home. For example, there’s my Bluetooth thermometers, which connect to Home Assistant. Compared to Wifi, power requirements are much lower and so Bluetooth is good for battery-powered devices. They’re also more private, as they can’t easily be connected to from the wider internet.

However, Bluetooth has quite a limited range – it’s designed to be a ‘personal’ area network and won’t reach across large houses. You can use a Bluetooth Proxy in Home Assistant to extend the range, and whilst these devices are cheap, you’ll need to be comfortable flashing custom firmware and will usually need to plug them in as they bridge to Wifi. Like Wifi, it uses the 2.4 GHz band and so interference is possible – especially with the lower signal strength. Bluetooth connections also tend to be between two paired devices.

Zigbee

Zigbee is a mesh protocol, and it’s used by a number of smart home brands such as Philips Hue and Ikea Tradfri, as well as UK smart meters. This means that all devices on the same network talk to each other, and so a network with lots of devices could theoretically be quite strong. Like Bluetooth, there’s additional privacy as these devices aren’t connected directly to the internet like with Wifi. It’s also more energy efficient than Wifi, so battery-powered Zigbee devices will last longer between charges.

The key disadvantage of Zigbee is that you need a bridge to link it to your home network. Manufacturers like the aforementioned Philips and Ikea will sell you a hub that does this, although you can also buy USB dongles. Therefore, there’s a higher initial cost as you have to buy a hub as well as your devices. And it’s another 2.4 GHz protocol, so could have the same interference issues as Bluetooth and Wifi.

Whilst Home Assistant has good Zigbee support, both natively and through the Zigbee2MQTT system, if you don’t have a separate hub then getting these devices into Google Home can be a very involved process. Alexa is a little easier thanks to the Emulated Hue integration.

Thread

Thread is based on the same 802.16 standard as Zigbee, but differs in a couple of ways. Firstly, devices on a Thread network have an IPv6 address. Secondly, Thread is a simpler protocol that focuses just on being a mesh network with Matter taking over the device APIs. The benefit of integrating with Matter is that, unlike Zigbee, you may not need a separate bridge for Thread devices. A number of smart speakers from Google, Amazon Alexa and Apple can also act as Thread Border Routers, so it’s possible that you’ll already have the infrastructure in place in your home for Thread devices. Like Zigbee, Thread is a mesh network, and by using Thread Border Routers, the devices have a degree of separation from the wider internet that should improve privacy and security.

The downside is that Thread is still pretty new, and so there aren’t many Thread devices out there yet. You may also find that each device that incorporates a Thread Border Router creates a separate Thread mesh network. Home Assistant can be configured to join a preferred network, but it can be a bit of a faff. Ideally, they should all make one big, strong mesh network across your home, but we’re not there yet. And, once again, we’re dealing with a 2.4 GHz protocol here.

Z-Wave

Z-Wave sets itself apart from the aforementioned protocols by being on the lower 800-900 MHz frequency range. These lower frequencies have a longer range, and so are more suited to larger homes, but also avoid the interference of the 2.4 GHz band. Like Zigbee, it’s a mesh network, and should have similar privacy and security benefits by not being connected directly to the internet.

This also means that Z-Wave has the same disadvantage as Zigbee in that you’ll need a bridge to expose these devices to your home network. Furthermore, Z-Wave devices tend to be more expensive, so the upfront cost is usually higher than other protocols mentioned here.

RF and Infrared

I’m including these for the sake of completeness, but they’re not ‘smart home protocols’ in the same way as the above. It’s possible to connect the likes of Home Assistant to bridge devices that can communicate over Wifi and 433 MHz RF or Infrared. These will typically be doorbells or remote controls for devices that don’t connect using any of the above. But setting them up can be trial and error, and involves detecting and interpreting codes to trigger automations.

If you’re building a smart home system, then a bridge may be useful to bring existing devices in that don’t support standard smart home protocols. But if you’re looking to buy new devices, stick with the ones above.