Well, it appears not. Or at least, newer Wi-Fi devices seem to be faster and more reliable, to the extent that I have dismantled our Powerline network. In November, we upgraded to a Fritz!Box router and repeater which both offer Wi-Fi 6. When I’ve tested our speeds on both Powerline and Wi-Fi, Powerline seems to max out at 80 Mbps, which is less than our incoming broadband speed of 105 Mbps. Meanwhile, I’ve also had some issues with flaky connections when watching streaming video on our TV over Powerline, which went away when I unplugged it and used Wi-Fi instead.
As someone who has been using networking equipment since the turn of the century, to have Wi-Fi outperform a cabled connection just seems wrong. But the performance just is better all round. And, as a bonus, not having Powerline frees up several plug sockets to use for other things, and uses very slightly less power.
In any case, there is only one device that we own which doesn’t support Wi-Fi, and that’s our Home Assistant Green. For that, I’m just using one of the Ethernet ports on the back of our repeater. Everything else that we own which has an Ethernet socket, also supports Wi-Fi. At some point, I’ll get around to tidying away all of the now redundant cables.
Almost exactly a year ago, I reviewed Bifrost, which emulates a Philips Hue Bridge in software. I’ve recently replaced Bifrost with diyHue, which does the same thing, but with support for more devices.
Note: I was part-way through writing this when I had my fall, so consider it to be moderately cursed.
Comparing Bifrost with diyHue
There’s a useful comparison table between Bifrost and diyHue here, from Bifrost’s developer. Indeed, Bifrost was developed because of the developer’s shortcomings with diyHue, but the two work differently. Bifrost only works with Zigbee2MQTT, and so can only support Zigbee devices. By contrast, diyHue can work with a much wider range of devices, including any that connect via MQTT and Home Assistant. That opens up support for Govee, WLED and Matter/Thread based lights as well.
diyHue is also easier to set up – there’s no YAML file to configure. Instead, it can run as Home Assistant app, and offers its own web-based interface. This allows you to control which lights are exposed to the Hue app, should you not wish all of them to show up. This is especially useful if you have set up both its Home Assistant and MQTT links, as otherwise you’ll end up with duplicates.
You can also easily configure how each light appears to the Hue app, by selecting a model number to emulate. In my experience, diyHue gets this right most of the time, so that light controls in the Hue app match the features of the bulb, but you can tweak it if needed.
Benefits of using the Hue app
I touched on the main benefits of the Philips Hue app in my review of Bifrost, in that you can use its scene gallery to set multiple lights in the same room to complementary colours. At the moment, I only have one room with more than one colour changing light in it, so this isn’t so useful to me, but I’m planning to fit colour changing lightbulbs when we refurbish our bathroom later this year.
The other key benefit of having diyHue is that I can use the Hue app on my Fitbit Versa 3 smartwatch to control the lights. There are some situations where I want to turn lights on and off without using my voice, or having to reach for my phone in the dark. There isn’t really a good Home Assistant app for Fitbit devices (and Google is phasing out the Versa range anyway), so the Hue app is the next best thing.
WLED is custom firmware for controlling multi-colour LED lights. It’s designed for string lights, with lots of individual LEDs that can be controlled independently. I’ve recently given it a try for the first time.
ESP devices
WLED runs on Espressif’s ESP32 and ESP8266 chips (although the latter isn’t recommended for new installs). That means it’s like ESPHome, Tasmota and ESPurna, in that it is also open source and customisable. However, whereas these alternatives can be used on a wide variety of devices, WLED is designed just for controlling LED lights. Sure, you can probably configure ESPHome to do the same, but you would end up with a huge and unwieldy YAML file to be able to recreate WLED’s functionality.
You can build your own controllers with an ESP chip like those from Seeed Studio and m5stack, and there are wiring diagrams to help you. It’s recommended that you include some capacitors, fuses and level shifters, along with the MCU chip, and you’ll need to be good at soldering.
Or, you could do what I did, and buy a pre-built controller box with the WLED firmware pre-installed. Amazon will sell you one from Gledopto for £25 (sponsored link), however, I purchased mine from AliExpress for £10.79, which is less than half price. Whilst buying the individual components may be cheaper, a pre-built box doesn’t require any soldering. Gledopto offer a range of different units, and some more expensive models include a built-in microphone to allow the lights to synchronise with music.
Replacing Tuya with WLED
The lights that I wanted to use originally came with a Tuya Wi-Fi controller. I try to avoid Tuya Wi-Fi devices, as they require access to Tuya’s servers to work. WLED can work entirely locally, with no need to connect to cloud servers (apart from for firmware updates). I also found that, whilst the Tuya app offered lots of effects, these weren’t available on other smart home platforms.
The MCU in the Tuya controller looks like a Beken BK7231 chip, and so I may have been able to install OpenBeken or ESPHome on it, but not WLED as WLED is ESP-only. As mentioned above, WLED is designed to control LED lights, whereas OpenBeken and ESPHome would have needed a lot of configuration. Besides, I couldn’t seem to use the Tuya-Cloudcutter exploit, and couldn’t find the pins I would have needed to upload new firmware via UART.
So instead, I bought a replacement WLED controller, and then cut the wires from the old circuit board. Thankfully, the terminals where the wires connected were labelled, and so I could easily match these with the new WLED controller. Like I said, there was no soldering required – on the new controller, I just lifted the plastic pins to open the ports, fed the wires in, and then locked the pins. The controller needs a minimum of 5 volts, which is what you get from USB and so I just wired in the existing USB cable from the Tuya controller. It can accept higher, going up to 24 volts DC.
Once power was provided, the LEDs all light up with a bright orange glow. I then used my phone to connect to the WLED-AP hotspot that appeared, and used the hotspot login screen to give WLED my Wi-Fi network details. And that was it – after that, I could use the controller’s IP address to open a web page to control the lights.
Using WLED to control lights
WLED is very powerful. With LED lights like the ones I used, it can control the colour and brightness of each individual LED. That means each one can be a different colour, and you can have patterns as each one fades on and off and to different colours. It comes with lots of built-in effects, and you can save these as presets that come on as soon as the lights are turned on. Multiple presets can be combined into a playlist.
Whilst the main way to use WLED is using the web interface, there are official apps for iPhone and Android, that will detect your lights using mDNS. That being said, the iPhone app is mostly just a wrapper around the web interface. Third-party apps seem to exist which offer a more native interface, but I haven’t tried these myself yet.
Smart home integration
If you’re a Home Assistant user, then WLED has a built-in integration. New WLED devices should be detected automatically by Home Assistant, and you can control almost all of the features within Home Assistant. This includes setting presets and playlists, amending the speed of effects and the intensity.
Getting your WLED devices into other smart home ecosystems is a little more difficult. There is a Matter bridge, which needs to run on another device that has Docker installed. I tried this, but couldn’t get it to work; I gather from one of the bug reports on Github that it’s not compatible with newer versions of WLED.
With a bit of trial and error, I managed to get it working with Matterbridge. I had to hide some of the sub-entities as otherwise it wouldn’t show and caused errors in the logs. This allowed me to control it with Google Home and Apple Home. However, this control was limited to selecting a single colour and brightness for all LEDs, or switching on and off. Better than nothing, but not as granular as Home Assistant.
WLED isn’t for everyone – I found it easy enough to set up, and I like the high level of control it offers. But it is very much a DIY solution, that requires you to buy (or build) the controller and lights separately, so it’s not for everyone.
I’m planning another WLED project; this time to replace the non-smart controller for my ring light. I’ve seen a guide for replacing the controller; that guide involves building your own controller and 3D-printing a box for it. I think I’ll just buy another Gledopto box.
I’ve only recently come across Matterbridge, which allows you to add a wide range of smart home devices as if they supported the Matter smart home standard, even if they don’t. Once installed, it runs as a server that acts as a bridge between whatever devices you have, and your choice of smart home ecosystem using Matter.
Whilst I have a handful of Matter devices – some Wi-Fi and Thread smart plugs, and a smart light bulb, many of my devices don’t support Matter. They’re either older Wi-Fi devices, or use Zigbee. To make those devices available to Google Home, I’m currently using Home Assistant and Homeway, but Matterbridge offers an alternative.
If the Matterbridge interface looks familiar, it’s because it’s derived from Homebridge. Whilst Homebridge is designed just to work with Apple Home, Matterbridge will work with Google, Alexa, Samsung Smartthings and Apple Home, amongst others.
Installing Matterbridge
I’m using Matterbridge alongside Home Assistant, and so I’ve installed it as a Home Assistant App (formerly known as an add-on). If you run Home Assistant Container, then you can also install Matterbridge as a Docker image, or you can install it using Node Package Manager (NPM).
It’ll take some time to install and run the first time, but once done, you’ll be able to open the interface inside Home Assistant and will get a screen similar to that in the screenshot. However, it won’t do very much until you install some plugins
Install the Home Assistant plugin
If you want Matterbridge to see the devices added to Home Assistant, then you’ll need to install the Home Assistant plugin. This is true even if you install Matterbridge as a Home Assistant app.
Most of the default settings should be fine, but you’ll need to provide a ‘long lived access token’ for your Home Assistant user account. In Home Assistant, click your user profile at the bottom of the left hand menu, select the ‘Security’ tab, scroll to the bottom, and click ‘Create token’. Give it a name, like ‘Matterbridge’, and then copy the token text and paste it into the Home Assistant Matterbridge plugin settings. Then, restart Matterbridge using the restart button at the top right of the Matterbridge interface. You don’t need to restart the whole app for this.
Once Matterbridge has restarted, it’ll bring all of your Home Assistant devices in. On the right hand side, next to each device, is a tickbox, so you can untick them to hide those devices that you don’t available via Matter. If you have lots of devices, but only want to share a few, then the plugin settings includes a ‘Whitelist’ feature that may be quicker than unticking hundreds of devices.
One other thing I had to do for some devices was hide some entities. Otherwise, the device showed up as two (or more) separate devices in Google Home; Apple Home was a little better and grouped these per device. Again, this is done in the Home Assistant plugin settings.
Optionally install the Zigbee2MQTT plugin
Another of Matterbridge’s plugins supports Zigbee2MQTT. This is the app that I use to add my Zigbee devices to Home Assistant, however, Matterbridge can connect to it directly using MQTT. There’s a couple of good reasons to do this:
It means Home Assistant isn’t an additional intermediary. Say I want to use Google to turn on a Zigbee light: this request would go from Google, to Matterbridge, to Home Assistant, to Mosquitto (my MQTT broker), to Zigbee2MQTT and finally to the device. By connecting directly, you skip that third step.
The Zigbee2MQTT plugin is more mature, and pulls in data such as how the device is powered.
Pair Matterbridge to your other ecosystems
Once you have your devices set up, it’s time to scan that big QR code on Matterbridge’s home screen, using the smart home app of your choice. How this will work will depend on the app:
In Google Home, it’ll add all the devices in an ‘In Your Home’ section at the bottom, for you to then allocate to rooms
In Apple Home, you’ll be asked to configure each device in turn, including setting a custom name allocating them to rooms.
After this initial setup, any new devices added to Matterbridge will automatically appear in the other apps.
Advantages over other options
Using Matterbridge as a way of bridging your Home Assistant devices to other smart home ecosystems has a number of advantages. Previously, I was using Homeway, but by using Matterbridge:
It’s free – I don’t need to pay a third party for this.
It retains local control, so if I decided that I didn’t want Homeway any more, my devices would still work.
Once configured, devices work in both Google Home and Apple Home – you don’t need to configure them separately.
Whilst Homeway used to be really reliable, in recent weeks it has randomly disconnected from Google Home without warning. So far, I’ve been using Matterbridge for about a month, and have not had any significant issues with it.
To this end, I’ve disabled Home Assistant’s built-in HomeKit integration, and I’m just using Matterbridge now. So far, so good, although I don’t tend to use Apple Home very much.
In terms of disadvantages:
Not all types of device are supported. Some may appear as switches rather than their actual device type, such as a washing machine or dishwasher.
It will only work with Amazon Alexa if you have an Echo device with Alexa on it. Although I have the Alexa app on my phone, and use it on Fitbit Versa, Alexa requires a physical Echo device to manage Matter devices. It won’t use another vendor’s Matter server. However, Homeway’s Alexa support seems more stable than its Google Assistant support, so this doesn’t really affect me.
Other plugins
There are a number of other plugins available for Matterbridge. These include plugins for Shelly and Somfy devices, that allow Matterbridge to connect to these directly. In time, more of Homebridge’s plugins could be ported to Matterbridge, which would enable devices from the likes of Tuya/Smart Life or Philips Hue. But, for now, you can use these devices via the Home Assistant plugin.
I run a few services on my Raspberry Pi, such as Mealie and Calibre-Web, which I want to be able to access when I’m away from home. I therefore use Nginx Proxy Manager to act as a reverse proxy, to make them available outside of my home network. However, in doing so, I’m also exposing them to the whole world wide web, including potential bad actors. So, as a security measure, I’m using an access list in Nginx Proxy Manager to restrict access to certain IP ranges.
The screenshot above shows what I’ve set up. Essentially, I’ve put in the IP ranges that I am likely to use on an ‘allow list’, and then all other IP ranges are blocked. These IP ranges include:
My current ISP
My mobile provider
My workplace
192.168.x.x for local connections
Any other IP address will just receive a 403 error from Nginx when they try to connect, and the requests won’t be forwarded on to the underlying app (e.g. Mealie). In other words, Nginx acts like a web application firewall. This builds on Nginx Proxy Manager’s ‘block common exploits’ feature to protect the web services you have running on your system. It’s also much safer that simply opening a port on your router directly to the underlying app.
By using IP ranges, it means that I don’t have to manually specify lots of individual IP addresses, should the one I use change.
CIDR notation
You may have noticed the /16 on the end of each IP address. This is ‘Classless Inter-Domain Routing‘ notation, or CIDR, which is apparently pronounced ‘cider’. Take for example 192.168.x.x/24 – this means that I’m allowing anything from 192.168.0.0 to 192.168.255.255.
If I wanted to, I could narrow this down to 192.168.0.x by using 192.168.0.0/24. Using ‘/24’ rather than ‘/16’ specifies a narrower range of IP addresses. Getting my head around CIDR notation was probably the hardest part of this; I ended up asking ChatGPT to explain it to me as I couldn’t find an actual web site that explained it in simple enough terms. Annoyingly, we didn’t cover this sort of thing in my Computer Science degree.
How to set up an Access List in NPM
In Nginx Proxy Manager, go to the ‘Access Lists’ tab at the top, and click ‘Add Access List’. You’ll then be asked to give it a name – I’ve just called mine ‘Standard list’ but you do you. On the next tab, you can optionally set a username and password; this will mean users will have to authenticate using HTTP Basic access authentication in addition to any required login for your chosen web service.
The ‘Access’ tab is where you specify the IP addresses or ranges. As per the screenshot above, you need to list the IP addresses that you want to allow first, and then have the last line as ‘deny’ and ‘all’ to block all other IP address. Once you’re done adding, save the list.
Go back to your Proxy Hosts page, and edit each one in turn (if you have set up more than one proxy host). On the first tab, at the bottom, you should now be able to select your newly created access list. You can apply the same access list to multiple proxy hosts, if you want to apply the same restrictions to all of them.
Hopefully now, with huge swathes of the Internet blocked by nginx, I’ll be less at risk should someone find an exploitable vulnerability in Mealie or Calibre-web.
I’ve had a Gmail account since June 2004, back when it was invite-only, and, for the past ten years, I’ve been re-routing all my email through Gmail. Having all my email in one place makes things easier, and Gmail’s spam and management tools are better than the standard ones that you get from a generic IMAP server.
So what’s changed? Well, some time in the very near future, Gmail will no longer pull email from other accounts. Until now, email sent to any email address on this domain would be periodically picked up by Gmail using POP3, and would then appear alongside any messages sent directly to my Gmail address. There was a short lag time, which was annoying, but it made things easier overall. That POP3 email pickup is what is going away.
The Gmail apps for mobile devices will still support connections third-party email accounts using IMAP, instead of POP3, but the emails would remain on the original email server. This isn’t really what I want, as I’d then have to use my email server’s storage space and spam tools. Plus, those emails wouldn’t show in Gmail’s web interface.
Switching to Fastmail
A couple of weeks ago, Anil Dash kindly shared a referral link for Fastmail as an alternative. The key factors that I like about Fastmail are:
You can use your own domain relatively easily
You can easily import all your old emails from other major platforms
So, once I’d signed up, I amended the DNS records for this domain to point to Fastmail’s servers, and then imported 22 years of emails from Gmail. It also brings across your contacts, and has a Calendar which can maintain bi-directional synchronisation with Google Calendar. The import took just a few minutes overall, and although it did mean I had over 12,000 unread messages, it was easy to bulk-mark these as read.
Using Fastmail
Fastmail’s web app works well – it’s fast, clean, and offers a three-pane mode as pictured in the screenshot. Since I use Outlook for work, this feels the most comfortable for me. There are official apps for mobile devices, and there are setup guides for most common desktop and mobile email apps, if you want to use IMAP. There’s a lot of configuration options, including customisable gestures on the mobile apps.
You can also continue to have email from other accounts, like Gmail and Outlook.com, forwarded to Fastmail, and be able to send messages using these other addresses.
Something that is important to note is that Fastmail does not offer a free tier. If you sign up, you can get 30 days for free – and Fastmail won’t demand any card details upfront if you do. After that, an individual plan is normally £4.50 per month, or £54 if you pay for a year upfront. If you use my referral link, then you can get 10% off in your first year.
Moving away from American Big Tech
Fastmail isn’t an American company – it’s headquartered in Australia. That being said, many of its servers are still US-based. Recent events in the USA have meant that I have been reconsidering how much I rely on American companies – especially those that provide services to the US government. Moving my email away from Gmail is one way that I can take back control of my personal data.
Another option to consider is ProtonMail, which is based in Switzerland. ProtonMail offers a free tier, and you can also bring your existing domain over. Its cheapest paid plan is cheaper than Fastmail, at £3.19 per month, but only offers 15 GB of storage instead of Fastmail’s 50 GB. ProtonMail has a greater focus on privacy and encryption, but I’ve seen others comment that it’s not as easy to use.
Whilst I doubt Google would ever kill off Gmail as a whole, having my own domain means I can port my email to a new provider without changing my email address. Especially as I’ve had my primary email address for 23 years now. In the UK at least, we can port our mobile phone numbers between operators; having your own domain means you get the same flexibility for email too.
Do you sometimes feel like AI features are now just foisted upon us, whether we want them or not? It feels like almost every app now has some kind of AI feature added – even Notepad on Windows 11 isn’t immune, with Microsoft adding its Copilot to it.
The good news is that most of these features can be disabled in these core browsers, and this is where Just the Browser comes in. You can download a script that will automatically disable these features in Edge, Chrome and Firefox for you. It works on Windows, Mac OS and Linux, and it’s open source. If the script doesn’t work, there are other options available for each individual browser. It’s also worth noting that, at least under Windows, your user account needs to be a system administrator to run these scripts.
If you’re curious, you can see which exact features are disabled by Just the Browser in each browser. The list is longest for Edge, and shortest for Firefox, which does at least attempt to care for its users’ privacy. It isn’t just AI features that get disabled; it includes any kind of sponsored content or telemetry. But it means that you can carry on using your preferred browser and not need to switch.
Suppose you have two entities in Home Assistant, and you want to multiply them together to produce a third entity that always shows the product of these two entities. Here’s how I went about it.
One of Home Assistant’s built-in integrations is Template. These Template entities derive their status from other entities in Home Assistant, and appear in the Home Assistant web interface as Helpers. You can do some fancy things with these, but all I want to do is multiply the value of one by the other.
Calculating export income
In my case, I wanted an entity that shows how much I’m earning from exporting excess energy generated by my solar panels, once our home battery is full. The amount exported is available as an entity in the SolaX Modbus integration that I use, expressed as a value in kWh. I also use the Octopus Energy integration with Home Assistant, and this has an entity showing my current export rate in £ per kWh. So, multiplying these together will show how much I should be making when I export.
This should be possible to set up as a Helper in the Home Assistant interface, but I personally found it easier to do so in YAML. Also, this is where I was able to ask ChatGPT to help write the YAML code. After tweaking its output to fit my needs, here’s what I’m using:
The name is a human-readable name that I have given to the entity. The unit of measurement is optional – Home Assistant will accept just about anything you type in here, but as the amount will be currency I’ve put in the £ sign.
The ‘state’ bit is where I needed help from ChatPGT, as this isn’t really standard YAML here. We specify the first entity, and add '| float(0)'. The ‘float’ is necessary to provide a floating point number. The * character represents multiplication, and then we repeat the same notation for the second entity. Finally, we specify ‘| round(2)‘ so that the resulting entity rounds to two decimal places. Which, when dealing with an amount of money, makes sense as 0.3333 of one pence isn’t really worth knowing about.
As with any changes to Home Assistant’s YAML configuration, you’ll need to restart Home Assistant after setting this up. You’ll then have a nice new helper, in my case ‘sensor.export_income‘ to plop somewhere on your dashboard. Personally, I have it as a badge which appears once the value is higher than 0. Which, at this time of year, isn’t very often, but we did have a nice enough day a couple of weeks ago to be able to export some electricity.
I recently bought a GeekMagic SmallTV Pro (sponsored link), which is a small, always-on desktop screen that runs on USB power. Out of the box, it can display the weather, a small range of photos, share prices and cryptocurrency prices. However, I’ve connected it up to Home Assistant to display a dashboard.
There are two varieties of the GeekMagic SmallTV – the ‘Ultra’ and the ‘Pro’. The ‘Ultra’ is actually the more basic model, and isn’t available to buy on Amazon. Both types are available on AliExpress, however. Inside, the ‘Ultra’ model has an older ESP8266 chip, whereas the ‘Pro’ has the newer and more powerful ESP32 chip. Both offer a roughly one inch square screen and connect using USB-C.
Setting up the GeekMagic SmallTV
Like many ESP-based devices, when you first plug the GeekMagic SmallTV in, it’ll create its own Wi-Fi access point. Connect to this on your smartphone, and it’ll pop up a captive portal where you can select your home Wi-Fi network and provide the password.
It’ll then reboot and connect to your home network, and will flash its new IP address whilst booting. You can then go to http://[IP Address]/ in your web browser to configure settings. Note that the cheaper ‘Ultra’ model doesn’t support stocks or cryptocurrency tracking.
Integration with Home Assistant: Method 1
There are two ways that you can integrate your GeekMagic SmallTV with Home Assistant. Method 1 is the method that I have used, as it’s less invasive and leaves the stock firmware intact.
Inside Home Assistant, open HACS, and add the above-linked GitHub page as a repository. You can then install the GeekMagic integration – once done, reboot, and then add your device on the Integrations panel.
How this integration works is by generating an image of several dashboard entities, which it then pushes to your device. You should notice a new ‘GeekMagic’ section on the main sidebar that allows you to open the dashboard editor – click this, and you’ll be able to create a new dashboard.
There are multiple layouts available, allowing you to display between one and nine entities. Theoretically, any entity in Home Assistant can be added. Personally, I’ve added the date and time, my solar battery status, the weather, my car’s charge status, how much energy is being generated by my solar panels, and my dishwasher’s progress through a cycle. Most of these are ‘gauge’ displays in the ‘ring’ style, so as well as showing the percentage, the ring gives a clearer visual indication of progress. This is good on such a small screen.
Once set up, the integration pushes a new image to the GeekMagic SmallTV device on a regular basis. I found that I had to remove all of the other images, and set it to change every 10 seconds, to keep the dashboard showing and updated.
Integration with Home Assistant: Method 2
If you clocked that these devices have ESP chips earlier, then it won’t surprise you that people have installed ESPHome on them. This involves replacing the stock firmware with ESPHome, which is easy to do – the web interface on the stock firmware has a firmware upload tool that should accept an ESPhome binary. I say should because I haven’t tried it personally.
If not, then the good news is that this device is easily dismantled – there are a couple of standard screws on the bottom. Inside, the printed circuit board includes GPIO pin holes for its UART interface. That may also help if you accidentally brick the device and need to replace the firmware manually.
I haven’t gone down this route as yet, as it takes more work. You would have to specify what to display on the screen in the ESPHome YAML configuration, and you’ll lose all the other functionality provided by the stock firmware. Also, be aware of various copycat devices with slightly different chips; they’ll almost certainly still run ESPHome but you may need to amend the configuration slightly.
I quite like my GeekMagic SmallTV Pro – it’s handy to be able to track key entities in Home Assistant without having to open my phone or look at the full dashboard. And it’s sufficiently low power that it can run all the time.
If you’re looking for custom firmware for your devices with an Espressif ESP chip, then two of your options are ESPHome and Tasmota. I’ve used both – first Tasmota and later ESPHome – on some smart plugs that used to run Tuya firmware.
I’m going to share my experience with both and highlight the strengths of each. Other ESP firmwares are available, but for this I’m just going to focus on comparing ESPHome and Tasmota.
Tasmota is easier to install
If you’re new to installing custom firmware, then Tasmota is the easiest to install. This is because you first install Tasmota on the device, and then configure it using a web interface on the device after installation.
With ESPHome, the configuration is done first, using a YAML file. You then have to compile a binary and install this on the device. This can mean some trial and error with getting the configuration right.
If you’re running Tasmota on an older ESP8266 device, then it can be a pain to update. This is because of the limited storage space on ESP8266 devices and the size of the Tasmota binaries – there isn’t enough space to store the current and new firmware side-by-side. Instead, you have to install a ‘minimal’ version of Tasmota, and then install the new full version as a two step process.
Because the ESPHome Device Builder compiles the firmware specifically for each device, it’s smaller and so can be updated over-the-air more easily.
This shouldn’t be an issue with newer ESP32 chips, as these have more storage and so updating Tasmota should be easier.
ESPHome is updated more regularly
It’s a good thing that ESPHome updates more easily, because updates are also more regular. Normally there’s a big update every other month, and smaller bugfix updates most weeks. It also has a much larger developer community.
Tasmota receives updates less often, and its development is largely led by just one lead person.
ESPHome supports more DIY devices
Whilst Tasmota is generally used to convert existing devices with ESP chips, ESPHome is more suited to DIY projects that you can make yourself. For example, you could build your own thermostat, a miniature weather station or control your blinds. With the right boards and cables, you can build and automate lots of things using ESPHome that Tasmota may not support.
ESPHome integrates better with Home Assistant
Being both projects of the Open Home Foundation, ESPHome has better integration with Home Assistant. You can run the ESPHome Device Builder as a Home Assistant add-on, and devices should show up without much additional configuration.
Tasmota works over MQTT, so you have to set up an MQTT Broker like Mosquitto in Home Assistant first, and then configure your Tasmota devices to use it. You also have to enable an option using the device’s command line to allow Home Assistant to discover the devices.
In summary
Whether you want to use Tasmota or ESPHome will depend on your use case:
If you’re relatively new to all this, or are replacing the firmware on an existing device, Tasmota may be best for you as it’ll be easier to install and configure.
If you’re a more advance user, or have built a DIY device that requires functionality not normally supported by Tasmota, then you should use ESPHome.
