Home Assistant

How to: Connect a Rolec EVO car charger to Home Assistant

by
Screenshot of the Monta HACS integration in Home Assistant showing a Rolec EVO charger

Back in May, ahead of buying our electric car, we had a Rolec EVO electric car charger installed outside our house. Since then, we’ve been using the standard Rolec EVO app that comes with it, but recently I’ve switched it to using the Monta app and its Home Assistant integration. Here’s how,and why I did it.

Why I needed to change to Monta

As I write this, there doesn’t appear to be a public API for Rolec’s charge point back office system. The Rolec EVO charger in particular is relatively new to the market, and so I’m not aware that anyone has found a way to integrate this with Home Assistant through other means.

However, like many chargers, the Rolec EVO charger supports OCPP. This means that you can change which back office system your charger talks to, and I’ve specifically chosen Monta because it offers a public API. And, because someone has developed a custom Home Assistant integration that can be installed from HACS.

Aside from this, the Monta Charge app is better, in my opinion – it supports Live Activities on iOS, so you can monitor your car’s charging progress on your phone’s lock screen. You can also make your charger public and allow people to pay to use it, if you wish.

Changing the OCPP provider

Part of the reason why it’s taken me until now to do this, was because I couldn’t work out how to change the OCPP provider. There’s no option to do so on the standard Rolec EVO app, and I tried setting it up using the app in the Monta integration guide, but that didn’t work either.

However, I came across a thread on the SpeakEV forums that made me aware of a third Rolec app. Confusingly, this is called ‘Rolec Connect’ (with a black icon) rather than the ‘Rolec EV Connect’ app (with a green icon) that I was using previously.

Once you’ve installed the Rolec Connect app, it’ll ask for your name and email address. This needs to be a valid email address, as you’ll be sent a link that you need to click on, but you might be able to get away with using Sharklasers.

You then choose the type of charger, and then need to place yourself within Bluetooth range of it. I apologise in advance if you’ve got this far and it turns out to be cold, dark and raining when you read this, but you can’t do this over Wi-Fi. You’ll be asked for a PIN code; mine was printed in the manual.

Once connected, on the second tab, you can change the provider. The good news is that you can simply select ‘Monta’ from the drop-down list, and continue. Leave every other field blank, but make a note of your charger’s serial number – mine was in the format of Rolec_XXX12345. You’ll need this later.

Add your Rolec EVO to Monta

Your charger should now be talking to Monta’s servers, rather than Rolec’s. Next, you’ll need to create a Monta account; I already had one, as Monta has a network of public chargers including the one we used at Portmeirion in Wales.

The guide to follow is here; I found that I had to enter the serial number manually, but hopefully it’ll read the QR code on the outside. If all goes well, the app will be able to connect to your Rolec EVO charger, and you’re done. From now on, you’ll need to use the Monta Charge app to manage your charger; the Rolec EVO app will now only work via Bluetooth as you’ve severed its internet connection to Rolec’s OCPP server.

Install the Home Assistant integration

Finally, you need to install the Monta integration from HACS. Whilst it’s not an official integration, it is linked from the Monta API documentation, and it’s regularly updated with a major new release just a few weeks ago. As with all new integrations from HACS, you’ll need to restart Home Assistant before you can add your charger.

Once you have restarted, add the Monta integration as you would any other. It’ll ask for a Client ID and Client Secret, which you can get from this page. I would leave the rest of the values as is, and that should be it. Your Rolec EVO charger now appears in Home Assistant!

This means you can use Home Assistant to start and stop charges, view the charging status, and have the energy usage appear on your Energy Dashboard. That also means you can build in automations; for example, if you’re able to access your car’s charge status, you could stop charging at, say 80%. I use the Nissan Connect integration from HACS for this.

Going fully local

The great thing about OCPP is that it’s an open standard, and so it’s supported by a range of back office suppliers with Monta being just one. Should Rolec or Monta go bust, then I can easily switch my charger to a different OCPP server and carry on using it. That’s not an unfounded fear: another EV charger manufacturer, Simpson & Partners, were in administration last year, although they seem to be running again.

If I wanted, I could self-host my own OCPP server and have everything running locally at home, with no dependencies on third-party cloud services. Again in HACS, there’s a OCPP Server for Home Assistant, and it supports the Rolec EVO charger amongst a range of others from other manufacturers. I’m not quite at that stage yet, as it would mean I would have to manage charging solely through the Home Assistant app. Although I did come across this ESPHome project for a hardware control using an m5stack Dial (looks a bit like a Nest thermostat) which could be something to consider.

A bigger project would be to build a new integration that allows communication between Home Assistant and the Rolec EVO charger via Bluetooth. That would require me learning Python, and another Bluetooth proxy, but it would at least work without needing to change the OCPP server.

PowerCalc for Home Assistant

by
Screenshot of the energy dashboard in Home Assistant with some data provided by PowerCalc

One of the features I like about Home Assistant is its Energy dashboard. It can analyse and display various data about power and energy usage in your home – provided that you have the correct sensors available. As we have solar panels, our inverter provides lots of live data via a local API that we can use.

We also have a number of energy monitoring smart plugs that track energy usage. We have a couple of Meross plugs, and a couple of cheap Tuya Zigbee plugs. Home Assistant can then display the power usage of these devices, and so you can see where your energy is going.

But we can’t fit these onto every device. For example, devices like our oven, hub and dishwasher are all built-in, and don’t use standard 3-pin plug sockets. We could have smart relays fitted, but that would be a paid job for an electrician. So, instead, there’s a potential software solution, in the form of PowerCalc.

PowerCalc is a custom integration that you can install from HACS. Once set up, you can use PowerCalc to estimate the power usage of your devices, or use its extensive library where other users have provided this data already. Indeed, when I installed PowerCalc, it automatically added entries for our various Google Home smart speakers. Once added, these appear as additional entities attached to your existing devices, which is nice – they don’t appear as separate devices.

You can then add these entities to your energy dashboard, to see where your electricity usage goes. Here’s a Sankey graph from last week from our house; it was quite a dull day with little solar generation. There’s a lot that we can’t track, but you can see that a significant amount of our energy usage was spent drying clothes.

PowerCalc gets regular updates, with new devices being added all the time. And, of course, you can add these yourself, if you have the means to record the energy usage. The energy usage data also updates in realtime, so you could add the data to a dashboard and see how changing the brightness of a bulb affects its calculated energy usage.

Setting WPA mode on ESPHome

by
The YAML code for ESPHome to specify the WPA version

If you’ve upgraded to last month’s release of ESPHome 2025.11, you may start seeing this warning message about WPA when validating your YAML scripts, or compiling new versions:

WARNING The minimum WiFi authentication mode (wifi -> min_auth_mode) is not set. This controls the weakest encryption your device will accept when connecting to WiFi. Currently defaults to WPA (less secure), but will change to WPA2 (more secure) in 2026.6.0. WPA uses TKIP encryption which has known security vulnerabilities and should be avoided. WPA2 uses AES encryption which is significantly more secure. To silence this warning, explicitly set min_auth_mode under ‘wifi:’. If your router supports WPA2 or WPA3, set ‘min_auth_mode: WPA2’. If your router only supports WPA, set ‘min_auth_mode: WPA’.

The warning message is pretty self-explanatory, but it concerns upcoming changes to Wi-Fi Protected Access (WPA) in ESPHome that are due to be introduced in June next year.

A bit of a history of WPA

Honestly, if you’re using ESPHome, you’re probably sufficiently tech-savvy to know what WPA is, but if this blog post is less than 300 words, it’ll probably be largely ignored by search engines. So, you can skip this bit if you like.

WPA is what makes a secured Wi-Fi network secure. The ‘Wi-Fi password’ you put in when connecting to secure Wi-Fi networks is the WPA security key. It replaced Wired Equivalent Privacy, dating from the earliest days of Wi-Fi, which is so weak that you can probably crack it with a standard laptop nowadays in a few minutes. It used 64 or 128-bit RC4 keys.

There are three versions of WPA:

  • The original version, which uses 128-bit keys with TKIP
  • WPA2, which replaces TKIP with the more secure AES
  • WPA3, the newest version, which improves the security of the key exchange and mitigates against easily guessable Wi-Fi passwords

Many devices that were originally designed to only support WEP could be upgraded to support WPA through software. At the time, this was a good thing – plain vanilla WPA was (and is) more secure than WEP. But as more security research has taken place, and computers have become more powerful, WPA is now also no longer recommended. WPA2 was ratified over 20 years ago, and so there are very few devices still in use that don’t support it. WPA3, meanwhile, is still quite new, having been ratified in 2018.

ESP devices and WPA

So, to bring this back to ESP devices and ESPHome in particular. At the moment, ESPHome defaults to the following WPA versions:

  • Original, plain vanilla WPA on ESP8266 chips
  • WPA2 on ESP32 chips

Remember, ESP32 is newer than ESP8266, despite the numbers. ESPHome has long supported YAML variables, that over-ride these defaults, to specify a specific WPA version to use when compiling.

What has changed with ESPHome 2025.11 is that, where you don’t specify the WPA version, you’ll see the above error when validating or compiling ESPHome for ESP8266 devices. Remember, these default to standard WPA at present.

Next June, when ESPHome 2026.06 is due for release, support for WPA will be dropped. So, if you don’t specify the WPA version, then from around June 2026, your ESP8266 devices will start using WPA2 the next time you re-compile them. This shouldn’t cause any issues, unless your Wi-Fi router is really old and doesn’t support WPA2. To which, I would say that replacing your router should be your priority, rather than amending your ESPHome configurations.

As for WPA3, this is only supported by the newer ESP32 family of chips. That means that, from June 2026, WPA2 will be the only option for ESP8266 chips.

How you can make the WPA warning go away

If you want, you can edit your YAML configuration files for your ESPHome devices to specify the WPA version to use. In the ‘wifi:‘ block, add ‘min_auth_mode: WPA2‘ underneath the network name and key, as so:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  min_auth_mode: WPA2

That will ensure that ESPHome always uses WPA2 on your devices, and will hide the warning. If your devices have ESP32 chips, and your router supports WPA3, you can add ‘min_auth_mode: WPA3‘ instead; this will offer better security. For more information, see the guide to the ESPHome Wi-Fi component.

Will ESPHome eventually phase out WPA2 support as well? Perhaps, but WPA3 is still pretty new – if your router is more than five years old then it may not support it. Maybe it will in another 15 years or so.

Converting a Tasmota smart plug to ESPHome

by
A photo of a Coosa smart plug, originally running Tuya firmware, and a USB to UART converter. This now runs ESPHome firmware.

Back in June, I flashed some old Tuya Wi-Fi smart plugs with Tasmota firmware. I’ve now re-flashed one of them with ESPHome, an alternative firmware by the Open Home Foundation who are the same people as Home Assistant. In this blog post, I’m going to outline:

  • Why the change from Tasmota to ESPHome
  • How to build a YAML file for ESPHome
  • The flashing process

This is a longer blog post, so if you want to skip the explanations for each section of the YAML file and just want to go ahead and do this yourself, you can download my pre-made YAML file from GitHub, and then follow these instructions.

Why the change from Tasmota to ESPHome

If you’re starting out with custom firmware for your existing devices, then I would still recommend Tasmota. It’s much easier to set up, as you install it first, and then configure it. There’s also a much more extensive repository of supported devices, so you shouldn’t need to do much manual tinkering once Tasmota is installed.

ESPHome, by contrast, requires you to configure it first, and then install it. Furthermore, rather than offering a web interface for configuring your devices, instead you have to do this in a YAML file. And then you have to compile the firmware specifically for your device and upload it.

That being said, ESPHome is much more powerful. You can build automations into it that run on the device itself, rather than through, say, Home Assistant. And as each firmware binary is compiled for each device, it’s much smaller, which allows for easier updates. On some Tasmota devices, you have to install a ‘minimal’ version of the firmware before you can upgrade. By contrast, with ESPHome, your device should be able to update directly to new firmware versions.

As you would expect, ESPHome integrates better with Home Assistant. Indeed, one reason for me changing to ESPHome is that the Tasmota integration takes a while to start up and is one of those slowing Home Assistant down. Firmware updates are also offered through Home Assistant, so you don’t need something like TasmoAdmin to manage firmware updates for multiple Tasmota devices.

Building the YAML file

I’m going to go through each section of the YAML file, to explain what it does, and why it’s necessary. Some of these are specific to the plugs that I’m using, and may not transfer to other devices.

Firstly, with Tasmota still running, open the Configuration screen and choose Template. This will give you a list of the GPIO pins, and what they currently do in Tasmota. You’ll need to note these, so that you can tell ESPHome what pins to use. On mine, these were the ones in use:

  • GPIO4 – LED
  • GPIO5 – Relay
  • GPIO13 – Button

The LED is the light on the smart plug, the relay is what controls whether the power is on or not, and the button is the physical button on the smart plug that controls the relay. Whilst the relay is the most important, to preserve the device’s full functionality, we need to tell ESPHome about all of them.

The ESPHome section

Here’s the first bit of the YAML file:

esphome:
  name: $name
  friendly_name: $friendly_name

esp8266:
  board: esp01_1m

If you use the wizard in the ESPHome Device Builder, then these will have been created for you and filled out with whatever name you’ve chosen. The second block tells ESPHome that the device has an ESP8266 chip, and it’s a generic board. This was the default selection and seemed to work fine for me.

Logging, API, OTA, Wi-Fi

Next, we have the following:

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: $key

ota:
  - platform: esphome
    password: $password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "esphome-smartplug"
    password: $fallbackpassword

captive_portal:

The logger means that the device will keep logs. It’s up to you whether you keep this in, but as I was coming up with this myself, I decided it would be best to help debugging.

Because I’ll be using this smart plug with Home Assistant, we need to include the ‘api:‘ section. Again, the ESPHome device builder should have filled out an API key here.

The ‘ota:‘ section allows for ‘over the air’ updates. This means that your device can update to new versions of ESPHome without needing to be plugged in to a device, either over USB or a UART connection.

In the ‘wifi:‘ section, this includes references to the ESPHome Device Builder’s secrets file which should have your Wi-Fi network SSID and password. If the smart plug can’t connect using these details, then, as a fallback, it’ll create its own access point. This is where we also need the ‘captive_portal:‘ section, which allows the user to select a Wi-fi network if the one we’ve pre-programmed can’t be found.

Web server

Next, we have this section:

web_server:
  port: 80

This is optional, but it creates a Tasmota-like web app that you can connect to. This will allow you to press the button on the smart plug, view the logs, and upload firmware. We don’t need it, but it partially replicates the functionality of the previous Tasmota firmware, and helps with debugging.

Binary sensor

This is the section that enables the hardware button on the smart plug to work:

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO13
      mode: INPUT_PULLUP
      inverted: True
    use_interrupt: True
    name: "Power Button"
    id: "smartplug_button"
    on_press:
      - switch.toggle: "smartplug_relay"
    disabled_by_default: True

We’re telling ESPHome that the button is attached to GPIO pin 13, and, when the button is pressed, to toggle the relay on or off. I’ve also added the ‘disabled_by_default: True‘ line so that it doesn’t show in Home Assistant.

Switch

Now, we need to configure the relay, and make it available to Home Assistant:

switch:
  - platform: gpio
    name: "Switch"
    id: "smartplug_relay"
    pin: GPIO5
    on_turn_on:
      - output.turn_on: led
    on_turn_off:
      - output.turn_off: led
    restore_mode: RESTORE_DEFAULT_ON

So, we’re telling Home Assistant that the relay is connected to GPIO pin 5. We’re also telling it to turn on the LED when the relay is turned on, and off again when it’s turned off. The ‘restore_mode: RESTORE_DEFAULT_ON‘ tells ESPHome what to do when the device boots up, perhaps after a power cut. I’ve set it to try to restore the status that it had before, but if it can’t, to turn the relay on.

LED

Here’s our final block, to tell ESPHome that there’s an LED

output:
  - platform: gpio
    pin: GPIO4
    inverted: true
    id: led

Again, we tell ESPHome that it’s connected to GPIO pin 4. The YAML code in the Switch section tells ESPHome when to turn the LED on or off.

So, now we have a YAML configuration file. This should be added as a new device in the ESPHome Device Builder.

The flashing process

The good news is that switching from Tasmota to ESPHome is easier than from the original Tuya firmware. You probably won’t have to get out a UART converter and cables, unless you accidentally brick your device. Instead, you just need to follow these instructions, which involve manually downloading the firmware binary, and then uploading it to Tasmota. When the device restarts, it’ll be running ESPHome instead.

Energy monitoring over Matter

by
A photo of a Meross energy monitoring smart plug in a UK plug socket

Back in April last year, I bought a pair of Meross energy monitoring smart plugs (sponsored link). I’d chosen them because they supported Matter, and so could be easily added to Home Assistant, Google Home and Apple Home all at the same time. However, I lamented that their Matter support was limited to turning them on and off; the energy monitoring data wasn’t available through Matter. That has now changed.

If you have these plugs, or are looking at buying them, here’s how to get energy monitoring over Matter into Home Assistant:

Step 1: Update the Firmware

Firstly, you’ll need to open the Meross app on your phone, and ensure that the smart plug is linked to the app. Next, you’ll need to do a firmware update – this is located on the user tab, for some reason. The firmware update should take a couple of minutes.

A screenshot of the Home Assistant interface, showing the settings for the Meross energy monitoring smart plug and the 're-interview device' option.

Step 2: Re-interview your smart plugs

Originally, the way I found out that this was working was because one of my plugs had stopped working, and needed a factory reset. I then had to remove and re-add it to Home Assistant, Google Home and Apple Home. When I re-added it to Home Assistant, that was when I found that it now supported energy monitoring over Matter, as the power, wattage, voltage and current for the smart plug now appeared in the device settings.

The good news is that you don’t need to remove and re-add the device. Instead, you can ‘re-interview’ the device. Open it up in Home Assistant’s device settings, and then click the three dots next to ‘Share device’, and then ‘Re-interview device’. Home Assistant will then attempt to find out what capabilities the device has, and should add the new entities for you.

Step 3: Uninstall the Meross LAN custom integration

Now that Home Assistant can receive the energy monitoring data over Matter, you shouldn’t need the Meross LAN integration from HACS anymore. You’ll need to amend any existing automations that use the Meross LAN entities (I use this energy monitoring blueprint), and then remove the devices before uninstalling it through HACS. This was one of the integrations that was causing the biggest slowdowns in my Home Assistant, and it seems to be more responsive now that I’ve removed it.

The key advantage of using energy monitoring over Matter is that the data remains local to your home network. Otherwise, you’re sending and receiving data to Meross’ servers (unless you’ve managed to reconfigure them to use a local MQTT broker like Mosquitto). That also means that, if those servers go down or Meross withdraws support, you would no longer get energy monitoring data. Switching to Matter should therefore give your smart home system more resilience.

How to disable go2rtc in Home Assistant

by

Home Assistant includes support for go2rtc, a streaming video application, which can be used to monitor and store footage from CCTV cameras. Since the November 2024 (2024.11) release of Home Assistant, go2rtc has been included in Home Assistant’s Default Config, which means that integration is loaded automatically on startup. If you don’t have any cameras to monitor in Home Assistant, this can mean some warnings appearing in your logs, and potentially slow Home Assistant down.

There are two ways to disable go2rtc if you don’t need it – a hard way and an easy way.

Hard way: Disable Home Assistant’s Default Config

You can tell Home Assistant not to load the Default Config. This gives you more control over which built-in integrations are loaded when you boot Home Assistant up, however, it means editing your configuration.yaml file. You’ll need to delete the ‘default_config:‘ line, and then create new entries for all the parts of the default configuration that you want to keep. This may be fine for simple installations, but for most users, this will add more complexity. I wouldn’t recommend this personally.

Easy way: Using HACS integrations

There are two HACS integrations that you need to install:

  1. Early Loader
  2. Default Config Exclude

These are not in the standard HACS repository, so you’ll need to open HACS, click on the three dots in the top right, select ‘Custom Repositories’ and then add the Github URLs in turn. You’ll need to install Early Loader first, restart Home Assistant, and then install Default Config Exclude next.

Once installed, you’ll still need to edit your configuration.yaml file, but instead you’ll only have to add a small block. Here’s mine:

default_config_exclude:
  - go2rtc
  - stream
  - cloud
  - my

What you’ll notice is that I’ve added some other integrations – stream, Home Assistant Cloud, and My Home Assistant. If you don’t have any cameras, then not only do you not need go2rtc, you probably don’t also need stream either. I don’t use Home Assistant Cloud or My Home Assistant, so I’ve disabled these too. As well as starting up a little quicker, Home Assistant also now uses slightly less RAM than before.

Home Assistant Green review

by
A photo of a plugged-in Home Assistant Green

Since I started using Home Assistant in October 2023, I’ve been running it on a Raspberry Pi 4, first in ‘Container’ mode and more recently in ‘Supervisor’ mode. I’ve now bought a Home Assistant Green, and I’m using this to run Home Assistant.

The Home Assistant Green is one of the two dedicated hardware platforms that come pre-installed with Home Assistant. The other, the Home Assistant Yellow, deserves its own section later on. By buying one of these devices, you’re also helping to financially support the Home Assistant project.

Why I bought a Home Assistant Green

As someone who has previously gone down the DIY route, it may seem surprising that I’ve decided to buy a Home Assistant Green. My decision came down to the following:

  • Price – the Home Assistant Green costs around £90 in the UK, which isn’t much more expensive than a bare bones Raspberry Pi 5. Once you’ve added a case, power supply and SSD to a Raspberry Pi, the Home Assistant Green is actually cheaper.
  • Cheap to run – I had considered some kind of mini PC, which would offer me more power, but with both a higher upfront cost and ongoing electricity cost. The Home Assistant Green runs on up to three watts; it comes with a 12 volt, one amp barrel plug power supply. As it’ll be on all the time, I don’t want a power-hungry device.
  • The need for a dedicated Home Assistant device. In May, it was announced that the ‘Supervised’ install method would be deprecated along with ‘Core’; only a tiny fraction of people use these methods. This dovetailed with me wanting a dedicated device for Home Assistant, rather than trying to run it on the same little Raspberry Pi as Plex and some other services. In other words, I was in the market for an additional device to run Home Assistant, and the Home Assistant Green fitted the bill. Meanwhile, my Raspberry Pi 4 can be dedicated to Plex.
  • No longer needing to worry about compatibility. According to Home Assistant Analytics, over a third of people install Home Assistant on a Raspberry Pi and so I don’t expect it to become unsupported. However, as the Home Assistant Green is the closest thing to ‘official’ hardware, I know it’ll be well-supported in future releases. As I’m coming to rely on Home Assistant more, I need it to run on a reliable platform.

What the Home Assistant Green can’t do

Coming from a Raspberry Pi, it’s worth noting what features the Home Assistant Green lacks. These include:

The Home Assistant Green does have two standard USB-A ports for you to plug in dongles and hubs, so I have my Thread and Zigbee dongles connected. Not having Wi-Fi or Bluetooth on board may reduce interference on the 2.4 GHz band, I suppose.

The box that the Home Assistant Green comes in

Home Assistant Green hardware

The Home Assistant Green is actually bigger and heavier than I expected it to be – certainly, it’s larger than a Raspberry Pi. It has a very sturdy base, which is designed to act as a heat sink – it’s passively cooled so there’s no fan noise. Inside, there’s a quad-core 1.8 GHz ARM processor, placing it between the Raspberry Pi 4 and 5 in terms of computing power. There’s 4 GB of RAM, and storage comes courtesy of a 32 GB eMMC (embedded multimedia card).

You’ll also get an AC adaptor with a variety of plugs (including a UK 3 pin plug) and an Ethernet cable.

Optionally, you can install a CR2032 battery inside. It doesn’t come with one, but if you add a CR2032 battery then the system clock will remember the time between reboots. It’s mostly only needed if you’re using it somewhere with poor or no internet access, as otherwise the clock synchronises with the internet on startup.

There’s also an HDMI port and a slot for a micro-SD card, but these are only for system recovery purposes and not for general use.

I would tell you more about how it is to use, but to be honest, it’s just like using Home Assistant on any other platform. All I had to do was restore a backup from my Raspberry Pi 4, and I was up and running.

Home Assistant Yellow

If the Home Assistant Green doesn’t meet your requirements, consider the Home Assistant Yellow. It’s more advanced and upgradeable, but also requires some assembly as it ships without a logic board. That’s provided by a Raspberry Pi Compute Module, the idea being that you can upgrade this incrementally over time without needed to buy a whole new device. It’s a nice idea, but it also adds to the cost – the base Home Assistant Yellow costs around £120 with the Compute Module adding £30-40 on top, and it arrives in kit form rather than pre-assembled. However, long term, it could be cheaper due to it being upgradeable.

There are other differences: The Home Assistant Yellow is available with Power over Ethernet (PoE), meaning that it doesn’t need a separate power supply. However, you’ll need a router or a switch which supports this. If you don’t, then you can buy a Home Assistant Yellow with an AC adaptor.

The Home Assistant Yellow also has an 802.16 radio, meaning that it can support Zigbee devices without an extra dongle. This can also be re-programmed to support Thread, but not both Thread and Zigbee at the same time. Additionally, there’s a 3.5mm audio port, and inside, there’s an expansion port for installing an SSD if you need one.

Whilst I have the technical knowledge to get a Home Assistant Yellow up and running, once you’ve factored in everything, it costs about double the price of a Home Assistant Green.

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.

ESP Firmware alternatives

by

Building on last week’s post about flashing smart plugs Tasmota, today I’m going to talk about other custom firmware that you can install on devices with an Espressif ESP chip. Tasmota is the most well-known, but whilst researching how to do the flashing, I’ve come across some others.

Tasmota

Obviously the first one I should mention is Tasmota. It seems to be the most well-used, with active development and lots of features. It’s designed to be used only on ESP32 and ESP8266 boards. Tasmota incidentally is an acronym which stands for Theo-Arends-Sonoff-MQTT-OTA and to this day Theo Arends remains the primary developer.

Recent Tasmota releases have included Matter support, albeit only on ESP32 chips which have more storage than ESP8266.

ESPurna and ESPEasy

I’ve grouped these together, as I found out about them from this blog post by HomeOps which compares them to Tasmota. ESPEasy is actually the oldest, having been around for almost 10 years, but Tasmota and ESPurna both started up around a year later. There’s an update to the blog post which also includes ESPHome, and compares them in a more quantitative way.

Notably, ESPurna only works on ESP8265 and ESP8266 chips, whereas Tasmota and ESPEasy also work on ESP32 chips, such as the one in the m5stack Atom Lite that I turned into a Bluetooth Proxy. Both ESPurna and ESPEasy use MQTT to communicate with other devices.

ESPHome

ESPHome is part of the Open Home Foundation, along with Home Assistant, and as such integrates well with Home Assistant. Unlike the other firmware tools here, ESPHome doesn’t use MQTT by default, although if you build your own firmware with ESPHome then you can add it as an optional extra. Instead, it communicates via Home Assistant’s API. This offers some advantages – it allows Home Assistant to install firmware updates for ESPHome devices. But if you were to switch from Home Assistant to another smart home platform, then you would either need to recompile the ESPHome firmware to add MQTT, or switch to one of the other firmware platforms listed here.

Another thing I’m less keen on about ESPHome is that you use a YAML configuration file to configure devices. I found Tasmota’s web-based interface much more user-friendly.

It’s worth noting that, as well as Espressif chips, ESPHome also works on RealTek RTL8710 and Beken BK7231 series chips too.

OpenMQTTGateway

OpenMQTTGateway is a more specialised firmware designed to make existing non-smart products work over MQTT. It’s best used with BLE (Bluetooth Low Energy), RD, Infrared and old fashioned Serial (RS232) devices. You can buy devices from Theengs which have the OpenMQTTGateway firmware already flashed.

As far as I can tell, OpenMQTTGateway just works on ESP32 chips.

OpenBeken

OpenBeken started out as a way of implementing a Tasmota-like experience on Beken BK7231 chips, but now supports a huge range of chips including ESP32 (but not some other Espressif chips like ESP8826) and RealTek RTL8710. It apparently works in a similar way to Tasmota, but I’ve yet to try it. I have one Tuya device with a BK7231 chip, but I haven’t yet been brave enough to try to flash it. Again, it uses MQTT to communicate with other devices.