A Bluetooth Dongle for Home Assistant

A photo of a Krisnorey USB Bluetooth Dongle

Last weekend, I wrote about turning a Tuya device into a Bluetooth Proxy. But if all you want is a USB device that plugs directly into your Home Assistant appliance to add Bluetooth support, then consider this Krisnorey Bluetooth Dongle from Amazon (sponsored link).

If you’re running Home Assistant on a Raspberry Pi, then your device will have Bluetooth support out of the box. But the official Home Assistant hardware, including my Home Assistant Green, doesn’t natively support Bluetooth. If you want Home Assistant to work with Bluetooth devices, then you’ll need a Bluetooth Dongle, or a Bluetooth Proxy.

A Bluetooth Proxy has a couple of advantages over a dongle:

  • If you run Home Assistant Container, or Home Assistant in a virtualised environment such as Proxmox, then you don’t have to bridge the USB Bluetooth Dongle through to Home Assistant.
  • Not all Bluetooth dongles are supported by Home Assistant, so there’s less risk of buying one that doesn’t work.

However, the distinct disadvantage of a Bluetooth Proxy is that it’s difficult to buy such a device ‘off the shelf’ – and not everyone wants to have to flash custom firmware onto a device.

By comparison, a Bluetooth dongle just plugs directly into your Home Assistant hardware. I picked out the Krisnorey Bluetooth Dongle specifically for the following reasons:

  • It supports Bluetooth 6.0. While it isn’t the latest version (which is 6.3 at the time of writing), it’s still a relatively new version of the standard.
  • It has a very long aerial, and so should be able to communicate with Bluetooth devices over a long range.
  • Someone else had previously left an Amazon review stating it worked with Home Assistant.

And indeed it does – I plugged it in, and it worked straight-away. Currently it’s selling for £17, or £15.33 if you have Amazon Prime (we don’t at the moment). There’s an older version which supports Bluetooth 5.4 which is cheaper, but I can’t confirm whether this will work with Home Assistant or not.

Turning a Tuya device into a Bluetooth Proxy

A Tuya IR and RF bridge that has been flashed with new firmware using tuya-cloudconverter and can now act as a Bluetooth Proxy

A couple of years back, I bought an M5Stack Atom Lite to act as a Bluetooth Proxy for Home Assistant. Last month, an update to the ESPHome firmware meant that more devices could become a Bluetooth Proxy, including Tuya devices, and so I’ve now got another Bluetooth Proxy in my home.

The device in question is a Tuya Infrared and RF bridge, which I bought cheaply from AliExpress. This runs on a Beken BK7231N chip, which I’ve been running ESPHome on for some time having used Tuya-Cloudcutter to flash it. Since April, it has been running as an Infrared proxy in Home Assistant, but as yet I haven’t got it working as an RF proxy. Although, to be fair, I haven’t got any RF devices that I need to bridge into Home Assistant, so it’s not a priority.

BLE on more chips

Bluetooth Low Energy (BLE) hasn’t been supported by ESPHome on Beken devices until last month’s update. Indeed, back in January, BLE was fully removed from ESPHome on these devices to save RAM and storage, as it didn’t work at the time. So this is quite the turnaround.

It’s not just Beken chips that have gained BLE support. By making BLE in ESPHome generic, devices with Raspberry Pi Pico and Lightning LN882H chips can also become a Bluetooth Proxy as well, making it available across most of the chips supported by ESPHome.

Better Bluetooth Proxy performance

Something else that’s worth noting about ESPHome’s Bluetooth Proxy support is that there has been a lot of optimisation work over the years. When I first set up my m5Stack Atom Lite two years ago, if you tried to add anything else in ESPHome to the device, such as a web server, you would get a warning when compiling the firmware. This is despite the Atom Lite having an ESP32 chip, which is amongst the more powerful chips that ESPHome supports.

That’s not a problem nowadays, and so an ESPHome device can comfortably act as a Bluetooth Proxy and something else. That means my device can be both an Infrared Proxy and a Bluetooth Proxy – and potentially an RF Proxy as well if I get that working. That means it’ll be capable of doing more with the ESPHome firmware than with the stock Tuya firmware that it came with, as well as no longer being reliant on the cloud.

The Bluetooth Proxy YAML code

If you use a recent version of the ESPHome Device Builder, then you just need to add these Components to your device:

  • Bluetooth Proxy
  • BK72xx Bluetooth Low Energy Tracker Hub
  • BK72xx Bluetooth Low Energy

That’s it – you don’t even need to set any Advanced Settings as the defaults will work fine. However, if you’re old school and want the YAML code, here it is:

bluetooth_proxy:

bk72xx_ble_tracker:

bk72xx_ble:

Then all you need to do is recompile your device firmware, and once it has restarted, Home Assistant should recognise it as a Bluetooth Proxy.

I’ll be keeping my m5Stack Atom Lite for now, but having a second Bluetooth Proxy at home means wider coverage of the house. I may even be able to do things like track the approximate location of BLE devices, based on which proxy/dongle they are closest to. And it’s great to be able to take an existing device that I already own, and give it new features.

Theoretically, if you have other Tuya devices like smart light bulbs with a Beken chip, and can use Tuya-Cloudcutter to get ESPHome onto them, then you could also make these act as a Bluetooth Proxy as well as being a light bulb. It certainly opens up some interesting possibilities.

Should you buy smart home tech from supermarkets?

A photo of several boxes containing Eveready smart light bulbs costing £3.99 at B&Ms

Look, it’s a blog post where the title is a question, and therefore, as per Betteridge’s law of headlines, the short answer is ‘no’. But that wouldn’t make for a very interesting blog post, and so I’ll attempt to offer some more nuance.

Most supermarkets, and many discount stores like B&M, have a hardware section which will have some smart home devices on sale. These are typically colour changing light bulbs, or smart plugs. They’re often relatively cheap too. So, should you buy them, and if so, what are you getting?

Firstly, what do we mean by ‘smart’?

I write a lot about smart home tech – my wife has decided that it’s my mid-life crisis, and, to be fair, I have a whole category of posts about Home Assistant. But I don’t think I’ve ever defined what I mean by ‘smart home tech’. So, for the purposes of this blog post, I’m defining smart home tech as devices that can be controlled using a phone, computer, smart speaker or a remote control.

A 24 button remote control for controlling a multi-colour light using Infrared

I’m including those with a remote because you often see colour changing lights in these sections in shops, but they don’t use a standardised smart home protocol like Matter or Zigbee. People may pick these up, expecting them to integrate with a smart speaker, to find that the remote control only works over infrared. It’s with this in mind that recent Home Assistant releases have added support for infrared bridges, so that you can use Home Assistant to control infrared devices. However, you’ll need to buy an additional device, such as a Seeed Studio Xiao IR Mate, flash it with ESPHome, and find an integration that supports your remote. It’s possible, but all of this is at an early stage.

So, it’s best to avoid devices that just have a remote if you’re buying new. I have one (remote pictured), and getting it to work in Home Assistant is a long-term project.

They’ll most likely be Wi-Fi or Bluetooth

The first smart plugs I bought were Tuya Wi-Fi devices, and I imagine these devices will be too. Buying smart home tech that uses Wi-Fi has its advantages:

  • Almost everyone already has Wi-Fi at home
  • You don’t need to buy a separate hub
  • They’re usually easy to set up

However, there are some disadvantages that it’s worth considering:

  • Most Wi-Fi smart home tech uses 2.4 GHz Wi-Fi, and not the 5 or 6 GHz bands, which may mean poor signal quality.
  • If you have lots and lots of Wi-Fi devices, then this can affect the performance of your network.
  • Wi-Fi devices need more power when idle than some other protocols.
  • Unless they’re Matter devices, and you have something that can act as a Matter hub, every command will be going via the internet.
  • Tuya devices tend not to work well with Apple Home.

That last point is why I disassembled my Tuya Wi-Fi smart plugs to re-flash them, initially with Tasmota and later with ESPHome. They now work without needing internet access, which is better from a privacy perspective, and means they’ll still work even if Tuya turns off its servers. Which, considering the likely billions of Tuya devices there are out there, is unlikely but not impossible.

Some of these smart home tech devices only use Bluetooth Low Energy. These can’t easily be connected to Google Home or Alexa, and for Home Assistant, you’ll need a Bluetooth proxy. And whilst you can control them with a phone, you’ll need to be in Bluetooth range to do so. Like with the infrared devices mentioned above, these are best avoided.

Better devices are available from elsewhere

Knowing what I know now about smart home tech, I wouldn’t have bought those Tuya Wi-Fi smart plugs. Instead, I would have probably invested in Zigbee equipment from Ikea with one of their hubs. But the need to pay extra for a hub was off-putting, as, at the time, I only wanted to control one device.

Nowadays, you can get Matter Wi-Fi devices, like these Meross smart plugs that I use. Most smart speakers include support for Matter so you don’t need to buy an additional hub. They work better with Apple Home, and don’t rely on a cloud service like Tuya. Matter is still a relatively nascent standard, but it’s improving all the time.

I’m less keen to recommend Matter over Thread to new users. For Thread devices to work, you need a Thread Border Router – a hub, in other words. Thread devices use less power, and form a mesh that avoids the performance issues of too many Wi-Fi devices, but the need for some kind of hub is a barrier to entry.

So, should you buy cheap smart home tech from supermarkets? If you’re careful, and stick to Wi-Fi devices, sure. Just be aware of the limitations, in terms of them needing internet access and the performance impact. You may be able to use something like tuya-cloudcutter to change the firmware to something that works locally, should you have the desire, technical knowledge and means to do so later.

Creating a bedtime button in Home Assistant

A photo of a Zigbee scene button that I am using to trigger a bedtime automation.

To help our ten-year-old get to sleep, we play some sleepy music in their bedroom each night. I’ve now automated this, using Home Assistant and a Zigbee scene button, so a single button press starts the automation and plays the correct Spotify playlist. Here’s how I went about it.

The button

I bought the button from AliExpress for a mere £2.60. I can’t find the exact same button on Amazon, but this is a close match at £8.99 (sponsored link). It has a single CR2032 button battery, and is easily paired with Zigbee2MQTT and then Home Assistant. There’s also a double-sided sticky tab to attach it to a wall.

The button I bought offers two modes: single press, and double press. You can therefore trigger different automations in response to whether the button is pressed once or twice. The more expensive button from Amazon also supports a third mode, which is a five second long press.

Installing Music Assistant

Whilst Home Assistant has a Spotify integration, in my testing I couldn’t get it to play the correct playlist on the Google Nest Mini smart speaker that is in our ten-year-old’s room. So, a workaround is to install Music Assistant, which is a related project that is also run by the Open Home Foundation. This can be installed as an App in Home Assistant; once installed, you’ll need to add Spotify as a source. Music Assistant quickly found all of my Google Cast devices.

Next, you’ll need to install the Music Assistant integration in Home Assistant – it may be automatically discovered for you. If you already have your Google Cast devices added in Home Assistant, then you will end up with separate Music Assistant entries for them too.

Creating a timer helper

So that the music doesn’t keep playing all night, we can create a timer that can stop the music after a given time period has elapsed. I did this by creating a Helper, using the type timer and the default time of 1 hour 30 minutes.

You can also simply put a time delay in your automation, but using a helper allows you to cancel the timer before it completes – handy if our ten-year-old falls asleep quickly.

Creating the automation

I set this up using the Home Assistant UI, but here’s the YAML code:

alias: Bedtime
description: ""
triggers:
  - domain: mqtt
    device_id: [device]
    type: action
    subtype: single
    trigger: device
conditions: []
actions:
  - action: music_assistant.play_media
    metadata: {}
    target:
      entity_id: [media_player.device]
    data:
      media_id: >-
        [playlist URL]
    continue_on_error: true
  - action: timer.start
    metadata: {}
    target:
      entity_id: [timer.bedtime_timer]
    data: {}
mode: single

The automation listens for the button press, and when it’s pressed once, it starts the music playing and starts the timer. The playlist URL is from Spotify – if you find the playlist you want, go to Share and then Copy URL, this is what you need.

I then have a second automation to trigger when the timer stops:

alias: Stop bedtime music when timer finishes
description: ""
triggers:
  - trigger: timer.finished
    target:
      entity_id: [timer.bedtime_timer]
    options:
      for: "00:00:00"
conditions: []
actions:
  - action: media_player.media_stop
    metadata: {}
    target:
      area_id: [bedroom]
    data: {}
mode: single

This actually works slightly differently, and tells Home Assistant to stop playback on all media players in a room, rather than the specific media player specified in the first automation.

Finally, I made use of the double-press mode of the button to cancel the timer early:

alias: Cancel bedtime
description: ""
triggers:
  - domain: mqtt
    device_id: [device]
    type: action
    subtype: double
    trigger: device
conditions: []
actions:
  - action: timer.cancel
    metadata: {}
    target:
      entity_id: [timer.bedtime_timer]
    data: {}
  - action: media_player.media_stop
    metadata: {}
    target:
      device_id: [media_player.device]
    data: {}
mode: single

Flourishes

As a little flourish, in my first automation I have an initial first step which uses Chime TTS to announce, via the speaker, that it’s time for bed. It then starts playing the music afterwards.

My version of the automation also turns on a nightlight, as well as starting the music.

Rationale

We’ve been playing bedtime music for our ten-year-old for many years, but what prompted me was the Gemini upgrade for our Google Home smart speakers. On the whole, post-upgrade, our speakers have been more capable and offer better answers, but where they’ve fallen down is asking it to play a specific Spotify playlist. We have one playlist that we have used for years, but when we ask Google Gemini to play it, it ends up playing something else (often a different one each time) which is similar but not the same. I’m sure any parent of a neurodivergent child has experienced what can happen when you try to pass off something that isn’t quite what the child is used to as being the same.

By building an automation, I can specify the exact URL of the desired playlist, so the correct playlist is played every time. And, having a button in their room means our ten-year-old can simply press it themselves when they’re ready for bed.

diyHue – Philips Hue Bridge Emulator

Screenshot of the diyHue interface

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.

Controlling multi-colour lights with WLED

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.

My new WLED controller (below) and the old Tuya controller (above)

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.

Screenshot of the WLED integration in Home Assistant

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.

Unblogged April

A photo of the ruins of Sheriff Hutton Castle in North Yorkshire by Mike Searle

As you read this, April is almost over. However, I started compiling this a full three weeks ago. Going to London last month has meant that I have had plenty to blog about this month, and there are some things that, in a quieter month, may have become full blog posts in their own right.

Sheriff Hutton Castle

On Easter Monday, we went to Nunnington Hall (the blog post for which is scheduled for Sunday), and on the way we went past Sheriff Hutton Castle to the north of York. We didn’t stop to take a photo, so I’ve the photo at the top is one that I grabbed from Geograph:

© Mike Searle (cc-by-sa/2.0) geograph.org.uk/p/4662987
Sheriff Hutton Castle (1), taken Monday, 7 September, 2015

There’s been a castle on the site since the 12th Century, with the beginnings of the current stone castle dating from the 14th Century. It had a major role during the Wars of the Roses in the 15th Century, however, it fell into ruins in the 16th Century and has remained that way since.

Alas, the castle isn’t open to the public; it remains privately owned and changed hands as recently as 2019. Which is a shame; it feels just like the sort of thing English Heritage would have taken on and opened up. At least its location next to the village of Sheriff Hutton means that you can admire it from a relatively close distance.

It’s been rather sunny, hasn’t it?

As I write this (which is last Saturday – this has been drafted in bits), we’re mid-way through a run of very sunny weather. Which is lovely, for several reasons:

  1. There’s blossom everywhere and it looks so much nicer in the sun
  2. Our solar panels have been working really hard

Indeed, they’ve saved us around £20 of electricity this week alone. I’ve been able to charge our car up without needing to use much grid energy at all. On Thursday, according to Sheffield Solar, UK national solar production peaked at 15.4 gigawatts, which I believe is a new record and accounted for about 40% of the UK’s energy mix. And we’re only in April – I’m hopeful that, come June when the days are longer, it’ll be even higher. The growth in solar in the UK is nothing short of remarkable – MCS states that over a quarter of a million domestic solar installations were brought online last year.

A better power monitoring Blueprint

I first wrote about power monitoring in Home Assistant a couple of years ago. Back then, I used a different power monitoring blueprint for my automations, but I’ve found a better one. This newer one has several benefits:

  • It’s easier to set up, as it doesn’t require you to create several helpers (although you can create a single helper if you want to be able to see the status, but it’s optional)
  • It supports a ‘Power Time Delay’ mode, that avoids the automation being triggered by short power spikes. For some reason, our washing machine occasionally has little power spikes when not in use, and these were triggering Google Assistant broadcast messages.
  • Sending notifications to multiple devices is easier.
  • You can also create additional helpers that get updated with how many cycles have run, their duration, and cumulative power consumption. These are all optional.

Firefox 150

Whilst I would argue that Firefox’s version numbers are largely meaningless nowadays, version 150 of Mozilla Firefox was released last week. Mozilla had early access to Claude Mythos, an AI tool for finding security flaws in software, resulting in 271 fixes being made in this version. I have my issues with generative AI, but this must be a good thing, right?

It’s also worth reading this interview with the new head of Firefox, Ajit Varma:

Mozilla’s PR team told me they want to be both the best browser for people who hate AI and the safest browser for people who love AI.

I’ve been using Firefox (almost) without a break as my main desktop browser, since before the 1.0 release in 2004. With every other web browser now basically the same underneath, it’s good to have another open source alternative, and one that isn’t trying to shove AI front and centre if you don’t want it.

Matterbridge – enable Matter for all your smart home devices

Screenshot of the Matterbridge main interface

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:

  1. 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.
  2. 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.
  • It’s a lot easier than setting up Google Assistant manually in Home Assistant.
  • 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.

Olsen & Smith 1800W Smart Ceramic Heater Review

A photo of the Olsen & Smith 1800W smart ceramic heater

My latest new smart home device is this little 1800W ceramic heater from Olsen & Smith (sponsored link). It’s only around 20 centimetres tall, but is able to output a decent amount of heat quite quickly.

We bought it because our ten-year-old’s room is consistently colder than the rest of the house. I suspect it’s because the radiator in there is under-powered, and hidden away behind a cover, but it’s typically 2°C colder than our bedroom next door. So far, our mitigations against this have been extra blankets on the bed and a hot water bottle, but I decided that we needed to do more than just keep the bed warm.

Using the ceramic heater

This ceramic heater is designed to be placed on a desk, or similar – it’s not really suitable as a free-standing heater as it’s quite short. It comes with a 1.5 metre cord.

There are a series of touch buttons on the top to control the heater. It has a digital thermostat, so you can set a target temperature and have it heat up to that level. There are four heat modes: low, medium, high and eco, which determine the power output. Low drops it down to 900 watts, and high uses the full 1800 watts of power. Meanwhile, eco mode automatically adjusts the power output to maintain the target temperature. It also includes a built-in timer, allowing it to automatically switch off after up to 12 hours.

It’s very quiet – it’s stated to run at between 28 and 56 decibells. I’m partially deaf, so I’m not the best judge of how noisy something is, but I could barely hear it. It’s certainly much quieter than our air conditioning unit that we use in summer, and quieter than a typical desk fan turned up to full speed.

In terms of its effectiveness, the heater seemed to warm the room up pretty quickly, as measured by its own thermostat. I have a separate ThermoPro thermometer in the room which measured a smaller but meaningful increase in temperature, but the heater isn’t pointing towards it.

Smart features

The ceramic heater uses Tuya as its smart home platform. As regular readers will know, I’m not a fan of Tuya, but I accept that it’s simple to set up, especially if you don’t have lots of other smart devices. Indeed, on opening the Tuya app, Tuya auto-discovered my new heater and asked to configure it. The app controls are easy enough to use, and mirror the controls on the unit.

The key reason why I wanted to buy a smart ceramic heater was to be able to automate it in Home Assistant. Our ten-year-old tends to only use their bedroom for sleeping, so the heater doesn’t need to be on much. Thankfully, when I reloaded the Tuya integration in Home Assistant, it appeared as a climate device. Home Assistant’s controls are limited to setting the target temperature, and turning it on and off; the controls for setting timers and heating power aren’t exposed. But being able to turn it on and off with an automation is possible, and so I have it come on around an hour before bedtime to warm the room up, and then switch off.

A peculiarity with this ceramic heater is that you can link it with Alexa via the Tuya app, but not Google Home. Which is odd; every other Tuya device I have owned supported both. Thankfully, I could add it to Google Home via Home Assistant, so our ten-year-old can use voice control with it.

A bargain

Finally, I want to highlight that this little ceramic heater cost just £20 from Amazon. There are a few cheaper ceramic heaters, some of which simply plug straight into the wall. But they tend to have lower power output, and aren’t smart. As much as I’d rather have something with local control, a smart ceramic heater for £20 is excellent value for money.

How to: multiply two entities in Home Assistant

A screenshot of a YAML Template Sensor in Home Assistant that multiplies the values of two other sensors.

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:

template:
  - sensor:
      - name: "Export income"
        unit_of_measurement: "£"
        state: >
          {{
           (
            states('sensor.solax_today_s_export_energy') | float(0) *
            states('sensor.octopus_energy_electricity_[mymeter]_export_current_rate') | float(0)
            ) | round(2)
          }}

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.

Creative Commons License
Except where otherwise noted, the content on this site is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.