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.
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.
I’m a little over 18 months into my Home Assistant journey, and now have 54 integrations set up. This includes standard integrations set up in the Home Assistant interface, some added using YAML, and custom integrations added via HACS.
When I first set Home Assistant, I went out of my way to set up as many integrations as possible, regardless of whether I needed them. Home Assistant scales quite well, but some integrations take longer to load than others. If you’ve ever logged in whilst Home Assistant is restarting to see a dashboard with many missing entities, you’ll know what I mean.
There’s a panel hidden away in Home Assistant’s Lovelace interface that tells you how long each integration takes to load. Open Settings, scroll down to System, and select Repairs. Then, click on the three vertical dots at the top right, and choose ‘Integration Startup Times’.
The list will be sorted with those taking the longest at the top. The vast majority of mine take less than a second to load, but there are some outliers. My worst offenders are:
Google Nest (24 seconds). Taking three seconds longer than a famous So Solid Crew song, this is the integration for my Nest Thermostat. I use this quite a bit in Home Assistant, so I’m stuck with it.
Wyoming Protocol (21.5 seconds). This is the bridge between Home Assistant’s Assist chat bot, and Homeway Sage. To be honest, I don’t use this, so this is an easy one to turn off. It’s an auto-discovered integration.
Meross LAN (21 seconds). This is a custom integration from HACS for my Meross smart plugs, and I need this for energy monitoring. Whilst the smart plugs also support Matter, the energy monitoring is only available via this integration. Theoretically, I can convince the smart plugs to use MQTT and that might negate the need for this integration, but I haven’t fully investigated it.
DLNA Digital Media Server (17 seconds). Another auto-discovered integration, courtesy of my router. I’m not using this, so this is another good candidate to disable.
Spotify (15 seconds). This allows me to control Spotify playback in Home Assistant. In reality, I don’t really use it, but it is on my dashboard.
Home Connect (14 seconds). This is for my smart Bosch dishwasher. I use this for a dashboard badge to see if the dishwasher is on at a glance. Our dishwasher is built-in and almost silent so this is useful.
Fitbit (14 seconds). Another dashboard badge to see how much charge is left in my Fitbit Versa 3.
Of these, there were two obvious candidates to remove – Wyoming and DLNA, saving a combined 30 seconds of startup time.
Ignored integrations
As they’re both integrations which are auto-discovered, I have had to tell Home Assistant to ignore them. On the Integrations Settings page, if you click the filter icon on the top right, you can then show the integrations that are ignored. I’ve added Wyoming Protocol there; it joins Philips Hue (since I’m using Bifrost) and ZHA (since I’m using Zigbee2MQTT)
Last year, I wrote about using a tool called tuya-convert to replace the firmware on my Tuya smart plugs. The firmware in question is Tasmota, which is an open source replacement firmware for devices with Espressif ESP chips. All my Tuya smart plugs have an ESP8266 chip, which can take custom firmware.
There are two ways of flashing Tasmota onto Tuya devices – an easy way, and a harder way.
There’s also a kind-of third ‘super-easy’ way, that I’ll mention towards the end.
tuya-convert – the easy way
I mentioned tuya-convert, which is a command line tool that exploits a vulnerability in older Tuya firmware to install Tasmota. You’ll need a computer such as a Raspberry Pi that has both Wi-Fi and Ethernet, and a smartphone. The tuya-convert tool then creates a hotspot that your Tuya devices can connect to when in pairing mode, and deploys the firmware wirelessly.
The key thing to emphasise here is that it only works with older firmware. Tuya patched the vulnerability in an update that came out some years ago, and indeed I’d already installed this on my smart plugs. That meant that tuya-convert could see the smart plugs, but couldn’t deploy the Tasmota firmware. So, I had to do it the hard way.
Using a UART converter – the hard way
As you may have guessed from the photo above, the only way I was able to flash Tasmota onto these smart plugs was by taking one apart, and using a USB to UART converter with some jumper cables. If tuya-convert doesn’t work, then this is what you’ll need to do. You’ll need the following:
Some Dupont Jumper cables – again, I bought these from AliExpress for £2.40. I picked up a big bag of male-male, female-female and male-female cables, but you only really need male-female cables if you want to save a few pence.
A computer with a USB port
I would also recommend the following:
Some electrical tape to hold things down
A USB extension cable
For the plugs that I was working with, I didn’t need a soldering iron, but some others may require it.
Disassembly and what’s inside
Firstly, it is very, very important that your smart plugs are not plugged into the mains while you do this, unless you want to burn yourself and/or your house down. We’ll be providing power via a different method, so make sure your device is not plugged in via the usual method. With my smart plugs, the positioning of the screws means it’s impossible for them to be plugged into the mains anyway.
Next, remove the screws from the plug. There were five on mine – the central one had to be removed first, and then the remaining four. Once that was done, I carefully separated the top and bottom of the housing.
The bottom part includes the high voltage AC circuitry. We’re not concerned with this and can leave it alone. What we’re interested in is the ancillary circuit board in the top part. It’s held in place by two small screws – you can remove these if you wish, but you can easily access the five pin holes that we need with the board still screwed in place.
The pin holes are as follows, with the first closest to the edge:
RX – data in
TX – data out
GND – ground
GPI00 – the pin hole that puts the smart plug into flashing mode
5V – the 5 volt power input pin hole
Normally, ESP chips work at 3.3 volts, but there’s a converter chip elsewhere on the circuit board for these specific smart plug. Yours may be different, so check first to see if it’s 3.3 volts or 5 volts. The UART to USB converter that I have offers both, so we’ll use five volts for this.
Connecting the wires
Firstly, make sure your USB to UART converter is not plugged in to the computer. You’ll need to get your Dupont cables and connect them from your converter to the board. The pins on the converter should be labelled, so you need to connect them as follows:
From RX on the board to TXD on the converter
From TX on the board to RXD on the converter
From 5V on the board to 5V on the converter
From bothGND and GPI00 on the board to GND on the converter
For this last one, I used three cables – two male-male cable from each of the GND and GPI00 ports on the board, and one female-male cable from the GND port on the converter – and then taped the pins at the end of the wires together. If it helps, there’s a standard wiring diagram on the Tasmota Getting Started page – although we’re connecting one additional wire (GPI00).
Getting read to flash Tasmota
Now that we’ve linked the converter to board, we can do the fun bit – flashing the device. There are several ways you can do this, of which I would recommend two:
Tasmotizer – this is a simple Windows program for flashing. The key advantage is that it can optionally download and backup the previous firmware, just in case you want to restore it later.
Tasmota Web Installer – this allows you to install Tasmota through your web browser, using WebSerial. As it stands, only desktop versions of Chrome, Edge and Opera support it, so you can’t use Firefox or Safari.
Personally, I had a better experience with the Web Installer, so this is what I used. Once you’ve opened your flashing tool, plug the USB to UART converter into your computer and then click ‘Connect’. Your browser will ask for your permission to link the web page with the COM port created by the converter, so you’ll need to grant permission.
Note: sometimes the COM port wouldn’t show for me in the browser. If this happens to you, try opening Device Manager, if using Windows, to ensure that the driver has installed correctly. If not, asking Device Manager to simply update the drivers should be enough. I had the most success if I opened the web page, connected the USB to UART converter and then clicked ‘Connect’ in that order.
If all is well, the web flasher will connect to your device, erase the existing firmware and then upload Tasmota. It’s a quick process – the binary file for Tasmota version 15 is only 655 kilobytes, so it’ll only take a couple of minutes at most.
If you get a connection error, try swapping the RX and TX cables over and then try again, and make sure that the light on the circuit board isn’t on or flashing. If the light is on, it’s a sign that you’ve not connected the GPI00 pin correctly.
Assuming that the flashing worked, you can take the jumper cables out and reassemble your device and plug it back in to the mains.
Configuring Tasmota
So, now that your device has been flashed, you need to configure Tasmota on the device. Get your phone out, and go to Wi-Fi settings. You should see a new Wi-Fi hotspot called ‘tasmota-something-something’, where the somethings are an alphanumeric string – connect to it. A hotspot login box should appear – if not, go to http://192.168.4.1/ in your phone’s web browser.
The first step is to connect Tasmota to your Wi-Fi network. Choose the network, or type it in, and provide the password. Tasmota will then connect, and, if successful, will redirect to its new IP address which it’ll display on screen. I suggest making a note of this.
You’ll now need to navigate to Tasmota’s new IP address in a web browser – you can do this on any device, not just your phone. The first thing we need to do is tell Tasmota what kind of device it has been installed on. The easiest way to do this is with a Template, and there are a huge range of templates listed here. I couldn’t find an exact match for mine, but the closest was this one, which gave me the following template code:
To paste this template into Tasmota, I used this guide. From the Tasmota home screen, I clicked ‘Configuration’, then ‘Configure Other’, and pasted the whole string into the ‘Template’ field at the top. Tick the box that says ‘Activate’, and then the green Save button at the bottom. Tasmota will restart, and then you’ll find that your smart plug now works. Huzzah!
Integrating Tasmota with Home Assistant
If you want your newly Tasmotised smart plug to appear in Home Assistant, then there are a couple more steps that we need to take. Tasmota communicated with other devices using MQTT, so if you don’t already have MQTT set up in Home Assistant, you’ll need to do this. The easiest way is to install the Mosquitto addon; this will then suggest the MQTT integration for you.
Next, we need to create a user account for Tasmota to use with MQTT. In Home Assistant, open Settings, and then People. At the top, select ‘Users’, and then click the blue ‘add user’ button. Give them a username and password, and then save these details somewhere safe for the next step.
Back to Tasmota. Firstly, we need to change a setting to allow Home Assistant to automatically discover your new Tasmota device. From the Tasmota home screen, choose ‘Console’, and input the following command:
SetOption19 0
Press enter. Next, go back to the Tasmota home screen, and into ‘Configuration’ again. Select the ‘Configure MQTT’ option. In the first box, you’ll need to enter the IP address or local hostname for your Home Assistant installation. If you use Home Assistant OS, this is most likely to be ‘homeassistant.local’.
Next, we’ll need to enter the username and password for the MQTT account we created earlier. The rest of the fields can be left with their default values, unless you want to customise the name.
Back to Home Assistant. If this is your first Tasmota device, then you should receive a notification that a new Tasmota device was found, and that you need to install the Tasmota integration. Do this, and your device will now be available. If you add any further devices, these will automatically appear in the Tasmota integration once their MQTT settings have been configured.
And that’s it. You should now be able to control your devices without needing to use Tuya’s cloud services.
The super-easy way – pre-flashed Tasmota devices
If you don’t already own a suitable smart plug, but want to use Tasmota, my advice would be to buy a smart plug with Tasmota already flashed. Local Bytes sell pre-flashed Tasmota smart plugs, so you can skip the disassembly and flashing sections of this guide. Alternatively, try eBay, where these plugs can also be bought pre-flashed.
That being said, I’m pleased to have been able to flash Tasmota on these smart plugs. I’m currently only using one of them, but I’ve been able to give them a new lease of life with about £5 of materials and an hour or so of my time. Indeed, the spare ones may well end up on eBay in due course for someone else to use. It’s far better than letting them become yet more e-waste.
What’s next
Last year I bought a Sonoff Wi-Fi RF Bridge, but was disappointed that it wouldn’t work the way that I expected it to. And getting it to work with Home Assistant was a bit of a pain, requiring a custom integration from HACS or an addon. I’ve already installed Tasmota on it, so it too has local control, and I’m looking at flashing the RF chip with a different custom firmware to make it more useful. That will probably require soldering and is for another future blog post, however.
If you have a Solax inverter attached to your solar panels, and get your energy from Octopus, then you can now calculate your earnings using live tariff data in the Solax app. I gather this feature has been there for a few months, but I’ve only recently found out about it. Here’s how to set it up.
Firstly, open the SolaxCloud app. On the home screen, tap the Earnings section. At the top right, you should see an icon that looks like a calculator with a lightning bolt on it, so tap that. You’ll now see two tabs – ‘To Grid’ and ‘From Grid’.
Get your Octopus API key
Before we continue, you’ll need to generate an API key. Log into your online Octopus Energy account (on the web, not on the app). At the top, it should say ‘Hi, [your name]’, display your account number, and then show a link called ‘Personal Details’. Click that link.
You should now see several boxes, one of which is called ‘Developer settings’. Click the ‘API access‘ button.
Scroll down a bit, and you’ll see a box labelled ‘Your API key:’. Copy this key, and preferably save it in a password manager. You can only have one API key, but you can use it for multiple things – I use my key for the Octopus Energy integration for Home Assistant, for example. You can regenerate your key, but it’ll invalidate your previous key, and you’ll only be shown it once on the Octopus web site. That’s why it’s best to treat it like your password.
Whilst you’re on Octopus’ web site, make a note of your account number too, as you’ll need this in a moment.
Enable automatic tariff setting
Back to the SolaxCloud app. Below the ‘To Grid’ and ‘From Grid’ tabs, you should have two further tabs: ‘Customized’ and ‘Automatic’. Tap ‘automatic’.
A new box called ‘Tariff provider’ appears, so tap this, and select ‘Octopus’. There’s another option called ‘Nord Pool’ which may work if you use a different energy supplier. I don’t, so I’ve only tested this with Octopus.
Now, you’ll have two options: ‘API Key’ and ‘Select a package’. ‘Select a package’ lets you manually choose your tariff and region, but it won’t update automatically if you change your tariff. So, we’ll select ‘API key’. Here, enter your account number, and then the API key, and tap ‘Save’. You should find that your current tariff and meter point access number now appear in the app. Scroll down, and you’ll be able to see the underlying tariff data, both as a graph and the raw data.
I’m on a fixed tariff with Octopus, so at present there’s no fluctuation with my import and export prices. However, if you’re on a tariff such as Octopus Agile, you’ll now see this data in the SolaxCloud app. What’s more, any future earnings will be calculated using this tariff data, and so it’ll more accurately reflect how much money your solar panels and/or battery are saving you.
Join Octopus
Octopus is now the UK’s largest electricity supplier, with a market share of 22%. And, with features like API access, the chances are that if you’re geeky enough to read this sort of blog post, then you’re already signed up. However, if not, here’s my referral link – you’ll get £50 off your first bill if you sign up. Financial incentives aside, of all the energy companies that I have used, Octopus have had the best customer service by far.
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.
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.
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.
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:
Not all Zigbee devices support bindings
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.
Last week saw the release of Home Assistant 2025.4, and with it, a new type of dashboard called Areas. This is an automatic dashboard, managed by Home Assistant itself, which displays your devices sorted by room, or ‘area’. At present, it’s ‘experimental’, but I wouldn’t be surprised if it becomes the default in future.
The default dashboard in Home Assistant is also automatically managed, but if you have more than a few devices and integrations, it can quickly become overwhelming. Therefore, my default dashboard is one that I manage myself. I can decide what to show, and in what order. However, it’s taken me quite some time to build and tweak that dashboard, and at one point I had almost 30 different cards showing. I’ve reduced that somewhat, and now use badges to highlight information that I need to know, but it still represents a significant investment of my time.
The new Areas dashboard therefore sits somewhere in the middle. The first tab shows an overview of your home, with sections for each ‘area’ that you have defined in Home Assistant. Most people will make each room an area, but it’s up to you – you may define parts of a room as a distinct area, for example. Personally, I’ve gone down the room = area paradigm, but I also have areas for ‘roof’ (where the solar panels are) and ‘outside’.
Setting up your home’s areas
You can set up your home’s Areas in the Settings pane in Home Assistant. When you do so, you can also specify any entities that represent the temperature and humidity in that room. This is useful, as these entities will then show up on your Areas dashboard.
Once you have defined your areas, you’ll need to add your devices to these areas. Again, in Settings, navigate to the Devices section. You can sort your devices by Area, so you’ll be able to see which ones are not allocated. Some of these ‘devices’ will represent virtual things, like HACS integrations or web services, so you don’t necessarily need to allocate these to a room.
Adding the Areas dashboard
Again in Settings, you’ll need to open the Dashboards pane. Here you’ll typically see three dashboards there already. These will include your current default dashboard, the built-in energy dashboard and the built-in Map dashboard. At the bottom right, click ‘Add Dashboard’, and choose ‘Areas (experimental)’. Give it a title and an icon, and then enable to show in your sidebar. Once done, you’ll be able to access it at any time from the side bar.
Initially, every area that you have defined will have a section and a tab along the top. If you click the Pencil icon at the top right to edit, you can re-order the areas, and also make any invisible. You may want to do this if the dashboard doesn’t show anything useful for that particular area. If you click into each area, you can also hide any devices that you don’t want to see on the dashboard. For example, in my screenshot, each programme on my Bosch dishwasher shows as an individual entity; I can therefore hide all of those apart from the dishwasher’s power status if I want to.
The areas dashboard is still experimental
We’re only a week on from this feature having been made available in Home Assistant, and so it’s still ‘experimental’. In particular, you’ll only see a handful of devices on this dashboard. In my case, this includes lights, sockets, my dishwasher, my TV, media players, and thermostats.
But it’s a lot easier to set up and manage than it would to create a new dashboard from scratch. And it’s less overwhelming than the other default managed dashboard, which shows a huge amount of data. As time goes on, I hope that the Areas dashboard is developed further and becomes the new default. It’ll make Home Assistant feel more like other smart home apps like Google Home, and make it easier for new users to manage.
One feature of Home Assistant that I’ve only recently started using is Dashboard Badges. These are small widgets that appear at the top of your dashboard, and allow you to view information at a glance. There’s a screenshot above which shows the widgets that I currently have set up.
Badges have been part of Home Assistant for a long time, but they received a major overhaul last August in version 2024.8. In the (approximately) 18 months that I’ve been using Home Assistant, I’ve been gradually adding more and more data to my dashboard, to the point where I had to scroll through several screens worth of data to see what I needed. Which isn’t ideal. Badges are a potential solution, showing basic information at the top, where it’s most accessible.
Each badge widget can usually display the state of one entity. In the screenshot above, I’ve included:
The temperature in our dining room, as recorded by our Nest thermostat
The current weather (it was, in fact, not raining when I took this screenshot)
The current power output of our solar panels
How much charge our solar battery currently has
The current status of our dishwasher
The current status of the TV in the living room
The current status of the sun
The latest version of Home Assistant
There’s a moderate amount of customisation available. For example, as well as the status of the entity, you can include its name, and this text is also customisable to save space if needed. You can also tweak the colours and the icons.
Controlling visibility of badges
One great feature that badges have in Home Assistant is controlling when they’re visible. I actually have more badges than the eight mentioned above, but they’re not showing as I don’t currently need the information offered. For example, I have a badge that displays whether an update to Home Assistant is available. But I only want to see this when an update is available – if I’m running the latest version, I want the badge to be hidden. Here’s how I configured it:
Having selected the widget, I’ve gone to the ‘Visibility’ tab, selected the entity, and told Home Assistant to only display it when the ‘State is equal to’ and ‘Update available’.
I use this on some other badges too. For example, if there’s no power coming from the solar panels, that badge disappears. Similarly, if my solar battery is at 20% or below, which is its idle state, that’s hidden too. You can also control the visibility based on which user is currently logged in, or anything really – the state of one entity can control the visibility of the badge for another.
A useful badge is one that makes use of the custom Octopus Energy integration from HACS, and will display if I haven’t used my Octopus Wheel of Fortune spins that month. Last month, I won 800 Octopoints, which was nice, and it’s helpful to have a reminder to use them.
By using badges, and setting their visibility, I’ve reduced the number of cards on my dashboard significantly. It makes the dashboard less overwhelming, and prioritises the most important information that I need to see quickly.
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.
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.
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.
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.
