Internet Things

So long, Solax local API

by
A screenshot of the Home Assistant web site showing the information page for the Solax integration.

If you’ve been reading this blog for a while, you’ll know that we have solar panels which are connected to an inverter from the Chinese company Solax. Recently, I asked for the firmware on our inverter to be updated, as part of some testing I’m assisting with for an app. Unfortunately, in doing so, it’s broken the Home Assistant integration.

As per the integration page:

Inverter models with newer firmware (and also those using devices like PocketWifi) no longer expose an API when connected to your wireless network, they do however continue to expose it on their own broadcasted SSID. To use this sensor in this case it is necessary to set up a reverse proxy with something like NGINX and use a Raspberry Pi (or similar) with two network connections (one being Wi-Fi that connects to the inverters SSID).

Home Assistant Solax Power integration
A screenshot of the Wi-Fi network selection screen on iOS 8, showing an unsecured network for the Solax inverter.

Sure enough, a scan of available Wi-fi networks showed a new unsecured SSID with my inverter’s serial number. Now I’m not beyond setting up a reverse proxy (I have Nginx Proxy Manager running) but this would require purchasing an additional Raspberry Pi, potentially with an additional USB Wi-fi adaptor or HomePlug adaptor.

Annoyingly, the inverter does still connect to my home Wi-fi network, and it’s possible to access a web-based portal by popping the inverter’s IP address into a web browser. But it no longer offers a local, real-time API over REST.

All aboard the Modbus

That’s the bad news. The good news is that it’s still possible to connect to the inverter using the Modbus protocol. Now, Modbus is old. Like, really old. Like, older than me old. Like, old enough to be a grandfather old. Like… well, you get the picture – it was originally developed in 1979 for use over serial connections. Thankfully Modbus can also work over TCP/IP on port 502, so I don’t need to run a very long serial cable and dig out my old USB to RS232 adaptor. Yes, I still have a USB to RS232 adaptor somewhere. I’m only a few years younger than Modbus.

Also, Modbus sounds like a bus full of really cool people wearing 1960s fashion and listening to The Who, although arguably they should be on Lambretta scooters. This is where I would ask Microsoft Copilot to create an image of this, but I’ll probably end up using the equivalent electricity to power a provincial English town trying to get it to generate what I’ve pictured in my mind.

Home Assistant natively supports Modbus, and if you have a spare half hour you can read everything on that page. Suffice to say, you have to set it up using YAML and know the Modbus specification of the device you’re communicating with. You probably don’t want to do this.

HACS to the rescue

The good news is that there’s a HACS integration for Solax Modbus. Once you have HACS installed, search for Solax and it’s (currently) the only one that comes up. Install it, restart Home Assistant, and then add the integration. There will be lots of input boxes pre-filled with default values – leave these be. The only thing you need to enter is the IP address for your inverter.

Once set up, the integration added loads of new entities for my inverter to Home Assistant. In fact, it seems like there were far more than before. The data isn’t strictly speaking ‘real-time’, but it polls every 15 seconds and so might as well be.

So that’s the good news. You can have the latest firmware on your inverter, and have it work locally with Home Assistant, without having to purchase another device to act as a reverse proxy. The bad news is that you’ll need to update any dashboards that you have set up to point to the new entities.

Looking to the cloud

The official way of accessing your inverter’s data and status is using the Solax Cloud, either online or through the official app. From there, there is an official API for interacting with this data. But it’s not real-time – updates happen every five minutes. And I can see why some people won’t want their data uploading to the cloud.

There isn’t a Home Assistant integration for Solax Cloud, either in the core product or through HACS. But someone has written their own YAML code to communicate with the Cloud API, should you wish to use this, although it also relies on the REST API which seems to have been deprecated from newer firmware versions.

Getting the latest Solax firmware

If you do want to update the firmware on your Solax inverter, there’s a handy guide here. The easiest and safest way is to contact Solax support and ask them to do it for you; they can log into your inverter remotely and run the upgrade. I hadn’t realised this until Home Assistant suddenly stopped being able to communicate with the REST API on my inverter. There are other ways of obtaining the firmware, and you can upload it yourself to your inverter’s local web portal, but it’s probably best for Solax to do this for you. Considering our solar panels, battery and inverter cost a five figure sum to install, it’s not something that I want to accidentally brick.

As for the app I mentioned in the first paragraph? I’ll talk about it once it’s released.

Wi-fi version numbers

by
The Wi-fi 7 logo

In recent years, it seems like the IT industry has changed how it names the various Wi-fi standards, with a move away from their IEEE names to a simplified version numbering system. This blog post is mostly me trying to get my head around what the old and new version numbers are, and the fact that Wi-fi 7 devices are starting to come onto the market.

Wi-fi version 1 (802.11b)

The first time I used Wi-fi would have been around 2003/4, and it was with a PCMCIA card that I slotted into my Toshiba laptop. 802.11b was the first version to launch in Europe, and offered speeds of up to 11 Mbps. By current standards, that’s really slow, but I was still using 56k dial-up in my university accommodation and my parents’ ‘broadband’ internet was only 512Kbps. A wireless, multi-megabit per second connection was pretty awesome.

Wi-fi version 2 (802.11a)

This would be a good time to note that versions 1, 2 and 3 of Wi-fi have never officially carried this designation, and would explain why standard A comes after standard B. IEEE 802.11a offered faster speeds – 45Mbps – but on the 5Ghz frequency band which wasn’t yet approved for Europe. Consequently, I never knowingly used any Wi-fi devices that used the 802.11a standard.

Wi-fi version 3 (802.11g)

The IEEE numbering jumped from B to G (standards C, D, E and F exist but aren’t relevant here) and this brought the 45 Mbps speeds of version 2 on the 2.4Ghz frequency band of version 1. This also saw me buy a new PCMCIA card for the same laptop, to be able to access the faster speeds, and use WPA encrypted networks rather than the weaker WEP security standard.

Some ‘Wireless-G’ routers offered ‘MIMO’ – multiple input and multiple output – which meant multiple antennae, and faster speeds, with up to 300 Mbps claimed. However, this usually required owning both a router and a Wi-Fi dongle by the same manufacturer and so wasn’t universal.

Wi-fi version 4 (802.11n)

With approval of the 5Ghz frequency band in Europe, 802.11n devices, first launched in 2009, could use both. The higher frequency band offers more bandwidth, but at the cost of shorter range and lower compatibility, hence the need to offer both 2.4Ghz and 5Ghz. The other big improvement came with mandating MIMO for all Wi-Fi 4 certified devices. Top speeds also jumped up as high as 600Mbps. This is the first standard to officially have a version number allocated by the Wi-Fi Alliance.

Wi-fi version 5 (802.11ac)

The IEEE numbering rolled over, and started back at A again with a second letter in 2013. I guess this may have been what prompted the Wi-Fi Alliance to start using its own numbering system, although it and Wi-Fi 4 were both named retrospectively. Interesting Wi-Fi 5 only works on the 5Ghz band (like Wi-Fi 2), and devices needing the 2.4Ghz band fall back to Wi-Fi 4. Again, there’s a boost in speeds, up to almost 7Gbps.

Both my Vodafone router and Google Wi-Fi system support up to Wi-Fi 5.

Wi-Fi version 6 (802.11ax)

This was the first version to launch with its version number from the Wi-Fi Alliance. It’s a much newer standard, from as recently as 2021, and boosts speeds up to almost 10Gbps. As with Wi-Fi 4, it operates on both the 2.4Ghz and 5Ghz bands, but there’s a sub-version called Wi-Fi 6E that introduces the 6Ghz band for the first time. The only device I have that supports this is my iPhone 13 Mini.

Wi-Fi version 7 (802.11be)

The 802.11be standard hasn’t been fully ratified by the IEEE but products supporting Wi-Fi 7 are already on sale, at the time of writing (October 2024). Therefore, if you’re willing to pay a premium to get a Wi-Fi 7 certified device now, make sure it’s from a well-known manufacturer, and that you update its firmware once the standard is fully ratified. Top speeds are now up to a theoretical 23Gbps which is just mind-blowing.

Wi-Fi version 8 (802.11bn)

In 2028, the next Wi-Fi version is expected to be ratified by the IEEE. We can potentially expect speeds as high as 100Gbps, and as with Wi-Fi 6E and 7, it’ll use the 2.4, 5 and 6Ghz bands.

Hopefully if you’re an old school techie like me, this will help you work out how the branded Wi-Fi Alliance numbers correlate with the IEEE standards.

My chosen HACS integrations

by

Last week, I wrote about HACS, the Home Assistant Community Store, which allows many additional community-provided integrations to be installed into Home Assistant. This week, I’m going to list those that I use.

DVLA Vehicle Enquiry Service

The DVLA Vehicle Enquiry Service allows you to monitor the publicly-available data about any UK car. When you set up the integration, you input a registration number, and it’ll download the data from the DVLA’s database. This includes useful information like when the car’s MOT is due, or when the car tax expires – these can be automatically added to a calendar widget on your Home Assistant dashboard.

HASS Agent

The HASS Agent integration allows you to use HASS Agent, a Windows desktop utility for managing Home Assistant. Once set up, you can configure automations to shut down your Windows computer, receive notifications, or monitor its state.

Nest Protect

We have a Nest Protect smart smoke alarm, which isn’t supported by the built-in Nest integration in Home Assistant. Google hasn’t made a public API for it, and so to integrate it with Home Assistant, you need to use this HACS integration. This is a good example of why an integration is in HACS and not Home Assistant core; setting it up requires you to log in to your Nest account in a private window, and then use Google Chrome’s developer tools to essentially ‘steal’ the cookies so that Home Assistant can hijack the same browser session.

Google has talked about adding the Nest Protect to its Google Home app for years, meaning that the standalone Nest app can be retired. But it hasn’t happened yet. When it does, perhaps there will be a proper API, and this will be available in Home Assistant core.

Timer Bar Card

This is a new card for your dashboard, which creates a progress bar for sensors that have a countdown. I use this for our Bosch dishwasher, so that as well as showing how long it has left, it shows visually how complete the washing cycle is.

Meross LAN

We have a pair of Meross energy monitoring smart plugs, and although they support Matter, to be able to do more than just turn them on and off, I need to use the Meross LAN integration. It supports both HTTP and MQTT communication, and will work both using Meross’ cloud MQTT servers and your own local MQTT broker, if you have one. Once set up, you can use the energy monitoring sensors in Home Assistant.

Octopus Energy

We get our gas and electricity from Octopus Energy (referral link, you’ll get £50 off your first bill if you sign up), and they have an API that any customer can use. The Octopus Home Asssitant integration lets you bring your meter data into Home Assistant, and you can set up automations to opt you in automatically to any energy saving sessions. The data is updated daily, unless you have a Octopus Home Mini which can provide realtime data for electricity, and half-hourly data for gas.

As well as offering some of the best unit rates for energy export, the fact that Octopus offers an API means that just about every UK geek that I know uses them. They also seem a lot easier to deal with than other energy suppliers we’ve used in the past.

HACS – community components for Home Assistant

by
A screenshot of the HACS web site

Whilst Home Assistant is already the most flexible smart home platform, with hundreds of built-in integrations, HACS is an optional additional tool to add even more integrations.

HACS stands for ‘Home Assistant Community Store’, and it allows you to download and install custom components from the wider Home Assistant community. It’ll also keep them updated for you. Home Assistant has long supported so-called ‘custom components’, which allows functionality beyond the standard built-in integrations, but HACS makes finding, installing and updating these much easier.

A couple of weeks ago, version 2.0 of HACS was released. This includes a new addon for those using Home Assistant Operating System or Supervised mode, which makes it easier to install. Updates are now handled via Cloudflare for improved performance.

As well as additional integrations, HACS also allows you to install different cards for your dashboards, and different themes. For example, Mushroom is a set of replacement cards which some prefer the look of.

Compared to the built-in integrations, which are maintained by the Home Assistant project, those in HACS are maintained by the community. This means that they may not be tested as rigorously as the official integrations, and so it’s important that you have regular backups in case things go wrong. Also, expect more bugs.

As for why integrations are only in HACS and not Home Assistant itself, there are a few reasons:

  1. It’s a niche service that may only apply to one country, or is of limited wider use.
  2. It uses scraping – this is where there isn’t a publicly available API for the service and so it scrapes the contents of web pages to work. These aren’t permitted in core Home Assistant integrations.
  3. It’s still in active development and not ready to be merged into the main Home Assistant release.
  4. It duplicates the functionality of a core Home Assistant integration but does so in a different way.

I’m currently using eight custom integrations through HACS, and I’ll discuss these in a later blog post. If you’re a Home Assistant user and haven’t already checked out HACS, have a look to see if you can extend its features even further.

Creating a Bluetooth proxy with ESPHome

by
A photo of an m5stack Atom Lite which has been flashed with ESPHome firmware to act as a Bluetooth Proxy for Home Assistant

My latest Home Assistant project has been creating a Bluetooth Proxy – a device that essentially extends the range of my Raspberry Pi’s Bluetooth signal. To do this, I’ve purchased a small device with a ESP32 chip on, and flashed it with firmware from ESPHome.

Okay, so that introduction has a lot of jargon. Allow me to break it down a little.

What is a Bluetooth proxy?

Because Bluetooth connections are point-to-point, you can’t use range extenders like you can with Wifi, Zigbee and Thread networks. That means that any Bluetooth devices that you want to connect to Home Assistant need to be in range of the device that you’re running Home Assistant on. I recently moved my Raspberry Pi to a different location, which meant that it was out of range of one of my Bluetooth thermometers.

A Bluetooth proxy acts as a kind-of bridge between Bluetooth and Wi-Fi. You place the proxy device within range of the Bluetooth devices that you want to connect to Home Assistant, and connect it to your home Wi-Fi network. Once set up, Home Assistant should see your Bluetooth devices as if they were in range.

If you’re running Home Assistant Container, then a Bluetooth proxy may also be easier to set up than a USB Bluetooth dongle. Passing USB devices into a Docker image doesn’t always work well.

It’s worth noting here that Bluetooth proxies are just a Home Assistant ‘thing’. They won’t help you connect a Bluetooth speaker to, say, a smartphone that’s out of range. Also, you can’t buy a device that works as a Bluetooth proxy out of the box. Seriously, if you go onto Amazon and search for ‘Bluetooth proxy’ (sponsored link), all you will get is results for Bluetooth adaptors and development boards with ESP32 chips.

The M5Stack Atom Lite

Whilst there are lots of boards that you can buy, a good option is the M5Stack Atom Lite (also available from AliExpress, where I got mine). This is because it comes with a plastic case, and connects easily using a USB-C cable. You could buy a different board and make your own case for it, but I don’t have a lot of time right now and don’t own a 3D printer. Besides, it costs less than £10 delivered.

The device is tiny – about the size of a 50p piece, and less than a centimetre thick. Because it’s a development board, it also comes with several pins to connect to other devices, but these aren’t necessary if you’re just using it as a Bluetooth proxy. Inside, is the Espressif ESP32 chip.

There are other ESP32-based products in the M5Stack Atom range, that add (for example) a microphone or GPS chip, but again, we don’t need these for a simple Bluetooth proxy.

Installing ESPHome

ESPHome is a sister project to Home Assistant, as they’re both managed by the Open Home Foundation. It’s similar to Tasmota, which I’ve blogged about before, in that they’re both custom firmware packages that you can flash onto ESP devices. Whilst Tasmota and ESPHome can do many of the same things, if you want a Bluetooth proxy then you’ll need to use ESPHome as Tasmota doesn’t support it.

Probably the easiest way to install ESPHome is using one of the ready-made projects. These can be flashed directly from your web browser, as long as you’re using Chrome or Edge (Firefox doesn’t yet support WebSerial so won’t work). You’ll need to connect your Atom Lite to your computer using a USB-C cable that supports both data and charging. You may also need to install the USB drivers – on my Windows 10 machine, the ‘CH9102_VCP_SER_Windows’ download worked. You should then be able to install the firmware, which will take a couple of minutes. Once done, you’ll be prompted for your home Wi-Fi network name and password, and then you should be good to go. Home Assistant will hopefully detect your new Bluetooth proxy automatically.

Managing your Bluetooth proxy in ESPHome

I used ‘hopefully’ in the previous sentence, because this didn’t happen in my case. As I used Home Assistant Supervised, I was able to install the official ESPHome addon; if you use Docker, you can just run docker pull ghcr.io/esphome/esphome to install it. Once installed, the ESPHome addon/docker image should detect your Bluetooth proxy and allow you to ‘adopt’ it.

This will let you view the hostname of your Bluetooth proxy device, which will be something like ‘atom-bluetooth-proxy-wibble.local‘. You can then add the ESPHome integration to Home Assistant, specifying the hostname, and you’ll be good to go. As soon as the integration was working, Home Assistant was able to see a new Bluetooth device and allowed me to configure the integration.

Going forward, you should find that Home Assistant is able to automatically update your ESPHome devices whenever new firmware is available – this is a new feature from the 2024.07 release. But you can also use the ESPHome addon/docker image to add or change features on your device. You could, for example, allow your device to act as an iBeacon as well (I think).

One thing to bear in mind is that Bluetooth and Wi-Fi both use the same 2.4 GHz frequency band. So, if you’re comfortable building your own board with a wired Ethernet connection instead of Wi-Fi, then you may get better performance.

Comparing different smart home protocols

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

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

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

Wifi (and Ethernet)

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

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

Bluetooth

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

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

Zigbee

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

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

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

Thread

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

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

Z-Wave

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

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

RF and Infrared

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

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

Displaying CPU temperature in Home Assistant

by
CPU temperature screenshot in Home Assistant

Earlier in the week, I mentioned that I’d bought a new case to keep my Raspberry Pi cool. So that I can keep an eye on the CPU temperature, and hope that it doesn’t overheat again, I’ve added this as a sensor in Home Assistant.

Adding a CPU temperature sensor to Home Assistant isn’t as straightforward as most other integrations. It’s not included in the System monitor integration, for example. When I was searching for solutions, I found all sorts, including one which required installing several packages from Aptitude, a script, and an MQTT broker. To be fair, that was designed to monitor multiple Raspberry Pis remotely; all I needed was just to poll the CPU temperature of the device that Home Assistant was running on.

Command line integration

Whilst not as straightforward as adding an integration, there is a relatively simple way of adding a CPU temperature sensor using the Command line integration. Indeed, it’s one of the given usage examples, which I’ve copied below:

# Example configuration.yaml entry
command_line:
  - sensor:
      name: CPU Temperature
      command: "cat /sys/class/thermal/thermal_zone0/temp"
      # If errors occur, make sure configuration file is encoded as UTF-8
      unit_of_measurement: "°C"
      value_template: "{{ value | multiply(0.001) | round(1) }}"

You’ll need to add this to your configuration.yaml file, and then restart Home Assistant. You should now have a ‘CPU Temperature’ entity, which you can add to a card to display on your home dashboard.

As well as running the command, the example code also adds the relevant units, and also reformats the numbers. If you open a terminal window and run the cat /sys/class/thermal/thermal_zone0/temp command on its own, you’ll get a value like ‘36511’. So, the value_template line divides the number by 1000 (or specifically multiplies it by 0.001, but the result is the same), and rounds it to one decimal place.

Once you’ve got the entity into Home Assistant, you can log your CPU temperature over time, and even display it as a graph if you want. You can also build automations, so that you can receive notifications when your CPU temperature is too high. For a Raspberry Pi, ‘too high’ is 85°C.

A temperature-controlled fan using Generic Thermostat in Home Assistant

by
A screenshot of the description of the generic thermostat integration in Home Assistant

So earlier this month, in my review of the ThermoPro Bluetooth Thermometer, I mentioned some ‘additional functionality’ in Home Assistant that I would write about. Well, later is now, and I’m going to talk about how I have a temperature-controlled fan in our bedroom, powered by Home Assistant and its Generic Thermostat integration.

Generic Thermostat is one of the older Home Assistant integrations, having been around for several years. It allows you to take any temperature sensor, and any smart switch, and automatically turn the switch on and off in response to temperature fluctuations. In essence, Home Assistant itself provides the thermostat functionality.

The switch should power something that can either heat up or cool down a space – for example, a plug-in heater, or an air-conditioning unit. In my case, I’ve hooked it up to a standard pedestal fan, and used a smart socket to turn the fan on or off at the plug.

Enabling the integration

Note: within days of publishing this blog post, Home Assistant 2024.7.1 was released, which allows you to configure the Generic Thermostat through the Lovelace UI, so you don’t need to add the YAML code anymore.

I mentioned that it’s an old integration, and sadly it’s not one that has been updated much since it was implemented. This means that you can’t add it using the Home Assistant interface (Lovelace), and instead you’ll need to add it to your configuration.yaml file.

Here’s mine:

# Generic thermostat
climate:
  - platform: generic_thermostat
    name: Bedroom thermostat
    heater: switch.bedroom_fan_socket
    target_sensor: sensor.tp357s_55ab_temperature
    min_temp: 15
    max_temp: 30
    ac_mode: true
    target_temp: 19
    cold_tolerance: 0.5
    hot_tolerance: 0.5
    min_cycle_duration:
      minutes: 20
    away_temp: 19
    precision: 0.1

Here’s what each variable refers to:

  • Platform specifies the integration, and the Name is the friendly name of the device.
  • Heater is the name of the entity that controls the smart socket that the fan is attached to.
  • Target_sensor is the name of the thermostat entity that provides the temperature.
  • Min_temp and Max_temp set the minimum and maximum temperatures that you’ll see on the Climate card in Lovelace – I’ve set these to 15°C and 30°C respectively.
  • AC_mode is set to ‘true’ because we’re using a device that’s supposed to cool down the room. If this were a heater, I would leave this line out.
  • Target_temp is the temperature that I want the thermostat to achieve, which is 19°C.
  • Cold_tolerance and Hot_tolerance mean that Home Assistant will only turn on the fan when the room reaches 19.5°C, and will only turn it off when it reaches 18.5°C.
  • Min_cycle_duration means that if Home Assistant turns the fan on, it should stay on for at least 20 minutes, and vice-versa, so it’s not constantly cycling on and off.
  • Precision is how much precision I want when setting the temperature; at 0.1, this means I can set it to 1/10th a degree.

Once you’ve added or amended the settings for your thermostat, you’ll need restart Home Assistant.

How it works in practice

So, once set up, if the temperature in our bedroom reaches 19.5°C, the fan will come on. It’ll then stay on until the room reaches 18.5°C, or 20 minutes, whichever happens first.

You can also control the thermostat like you would with, say, a Nest thermostat through Home Assistant. It will create an entity which you can add a card for on your dashboard. So, although you may have set a target temperature in the initial configuration, you can change this without editing your configuration file. However, if you re-start Home Assistant, it may forget this.

If you also use Google Assistant or Alexa, then you can also make them see and interact with your generic thermostat, if you have integrated these with Home Assistant.

Whilst I use a fan and a smart switch, if you have an air conditioning unit with an RF control, you could use an RF bridge to allow General Thermostat to control it.

Fans vs air conditioning

If you do use a fan with Generic Thermostat, you’ll notice that your fan may stay on for a long time. That’s because fans don’t actually cool the air; they move air around which helps sweat evaporate more quickly. That makes you cooler, but not the air around you. It’s a bit like a hot day at the seaside, where the breeze takes the edge off the heat.

Air conditioning systems actually cool the air down, but are much more expensive and need an outlet for the hot air to be pumped out. Most British homes don’t have air conditioning, including ours – most of the year, it’s too cold, and our houses are designed to retain heat.

Sonoff Wi-Fi RF Bridge review

by
A photo of a Sonoff Wifi RF bridge

I’ve been thinking about my doorbell, and knowing when someone rings it. Obviously it chimes when I’m at home, but I was hoping that with this Sonoff Wi-Fi RF Bridge, I can get notifications on my phone and a log of when people call when I’m out.

We don’t have a smart doorbell, like Ring for example. Ours is a Koopower Wireless Doorbell that I was sent to review six years ago. The Koopower doorbell doesn’t need a battery – the act of pressing the button generates sufficient power to send a RF signal to the receivers.

What I was hoping with this Sonoff RF bridge is that it could also listen out for doorbell pushes, and send me a notification. I could also integrate it into Home Assistant, which could handle logging. As you can probably tell from how I have written this blog post so far, I haven’t been able to achieve this.

Setting up

The Sonoff RF bridge is pretty small – about 2 inches (5 cm) square. In the box is the bridge, a quick start guide and, erm, well, that’s it. You need to provide your own micro-USB cable and a power source capable of 5 volts and 1 amp – so most phone chargers, or even many batteries. The bridge just has two LEDs – a blue one indicating the Wi-Fi status, and a red one the RF status. The only other thing of note on the bridge is a hole for poking a paper-clip in to reset it – there’s no other buttons.

Once you have hooked it up to a suitable power source, you can use the eWeLink app to set it up. This allows you to connect the bridge to your home Wi-Fi network, and pair RF devices.

Pairing devices

In the eWeLink app, you put the RF bridge into pairing mode, and then have 60 seconds to perform an action on your RF device. When it detects a signal, it’ll save the codes transmitted using RF, and will give you a button in the app. By pressing that button in the app, the RF bridge will mimic the action on your remote. So, you can ‘teach’ your bridge to turn an air conditioning unit on and off, rather than using its remote.

The fun comes when you link your RF bridge to a smart home ecosystem, like Google Assistant, Amazon Alexa or Home Assistant. Your bridge will appear as a device, and so you can use your voice to control appliances that are not ‘smart’ and are not on your home network.

That’s the theory anyway

As I write this, I haven’t been able to get my RF bridge to detect my doorbell, even though they both use the same 433.9 MHz frequency band. Even with the doorbell receivers switched off, and me holding the RF bridge next to the doorbell (did I mention you could run it from a battery?), it doesn’t detect a signal.

Now, to be fair, there’s no mention of compatibility with wireless doorbells in Sonoff’s marketing. Indeed, pairing RF devices can be hit-and-miss; you won’t, for example, be able to use an RF bridge to unlock your car, as the codes are changed each time you lock and unlock your car. Trust me, this is a good thing; otherwise, devices like these could be used to break into people’s cars.

If you have RF remotes, then this should work; it should also work with RF window opening detectors, alarms and curtain controls. Note, however, most remote controls use infrared, rather than RF – if your remote requires you to point it directly at the device, then it’s probably infrared, not RF.

RF bridge Home Assistant integration

I mentioned that you can get the Sonoff RF Bridge to appear in Home Assistant. There isn’t an official integration, but there are several ways you can achieve this:

  1. Flash it with custom firmware from ESPHome or Tasmota
  2. A custom integration available in HACS
  3. An addon which uses Home Assistant’s API

My initial searches only led me to option 1, and I didn’t fancy taking apart my brand new device to install custom firmware on it. Thankfully, there’s a Sonoff integration in HACS which allows you to log into your eWeLink account, and seems to work well. The addon is something I only found whilst writing this blog post, and it looks like this is actually the official way of integrating eWeLink with Home Assistant as it’s in the same GitHub account. You can use a Docker image instead if you’re running Home Assistant Container.

The alternatives

It’s possible that I have a dud unit, and so I have ordered a different model from AliExpress which uses Tuya. At the time of writing, this cost less than £1, which is clearly some kind of introductory offer as it’s normally £17. This Tuya model also supports infrared, and the 315 MHz RF band. I’ll let you know how I get on with it, when it arrives in a few days.

There’s also the option of building your own. The main components inside the bridge are a standard ESP8285 chip for Wifi and Bluetooth, and a EFM8BB1 chip for RF. You can therefore buy these yourself, solder them onto a board, and use the ESPHome or Tasmota firmware to achieve the same thing. I’m not yet that far down the home automation rabbit hole to build my own devices, but you could consider it.

ThermoPro TP357 Bluetooth thermometer review

by
A photo of a ThermoPro TP357 thermometer showing the current temperature of 17.5℃ and humidity of 59% on a LCD display.

I have an upcoming project for Home Assistant which means that I need to be able to measure the temperature in our bedroom. As part of this, I’ve bought a couple of ThermoPro TP357 Bluetooth thermometers from Amazon (sponsored link). One is for our bedroom, and the other is for our eight-year-old’s bedroom which tends to get a bit cold in winter.

I specifically went for these thermometers because they’re:

  • Cheap – I paid £19 for the pair last week, but they’re £16 for the pair as I write this.
  • Supported by Home Assistant – there’s an official integration.
  • No extra hardware required – because they’re Bluetooth, and I run Home Assistant on a Raspberry Pi with a supported Bluetooth chip, there’s no additional hardware required to get the two to talk to each other.
  • Probably good battery life – Bluetooth is quite energy efficient when compared with, say, Wifi, and so the batteries should last longer.
  • No need to use the cloud – all the data can be stored locally on Home Assistant.

ThermoPro TP357 look and feel

The ThermoPro units are smaller than I expected. They’re about as tall as a credit card but roughly square, so they’re narrower than a credit card. Each one runs on one AAA battery which is provided. On the back is a flip out kick-stand, a magnet and a hook, so you can wall-mount it, stick it to your fridge or have it free-standing on a shelf like I do. There’s also a button on the back that switches it between Fahrenheit and Celsius.

On the front, there’s an LCD screen which shows the current temperature and humidity level. There’s also a face pictogram – it’ll smile when the humidity is between 30-60%, frown when it’s less than 30% or show a neutral expression if it’s over 60%.

Home Assistant integration

If you have Bluetooth enabled on your Home Assistant device, then a few minutes after you put the battery in, Home Assistant should pop up a notification to say it’s discovered a new ThermoPro device. You’ll just need to confirm that you want to set it up and allocate it to an area, and you’re done.

As you would expect, the ThemoPro integration reveals entities for temperature and humidity, but also the battery level. I’m not sure how accurate this is, as both provided AAA batteries just show 50%. I’ve added these to my Home Assistant dashboard, and have set up some additional functionality that I’ll blog about later. Mainly because, despite allegedly being ‘summer’ in the UK right now, it’s not been warm enough for me to test.

The range seems quite good on these. ThermoPro claim that there’s an 80 metre range in direct line of sight. There’s a few thick walls between my Home Assistant device and the thermostats, and one that is around 5 metres away doesn’t have great signal strength but it’s enough.

ThermoPro app

Of course, ThermoPro expect you to use their app for iOS and Android. This includes logging of up to a year’s data, and you can set notifications based on events related to the humidity and temperature. Well, that’s what it says – I haven’t actually installed the app. I’m not yet sure if it’s possible to have the app and Home Assistant communicate with the thermostat at the same time. But theoretically, anything the app can do, Home Assistant can do too.

Alternatives

I’ve had various Facebook adverts for alternatives to these. Some have e-ink displays, which are more readable at a distance, or use different protocols to Bluetooth. But they’re all more expensive. These two seem to do the job well and are small and cheap. Plus, it should be quite a while until I need to replace the batteries.