Internet Things

Should you buy smart home tech from supermarkets?

by
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

by
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.

Just going wireless

by
A photo of our Fritz! Repeater 3000 AX

Back in 2017, I invested in a series of Powerline adaptors, which allowed us to use our household wiring as an Ethernet network. At the time, we were having issues with Wi-Fi speeds and coverage, and so having a wired connection seemed like a good idea. Because wired connections are usually more reliable – right?

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.

diyHue – Philips Hue Bridge Emulator

by
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

by

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.

Matterbridge – enable Matter for all your smart home devices

by
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.

Allowing IP ranges for a reverse proxy

by
A screenshot of an access list in nginx Proxy Manager

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.

Moving my email to Fastmail

by
Screenshot of the Fastmail interface

I’m now using Fastmail (referral link) for my email. My email address remains the same, but all email sent to it will go to Fastmail’s servers.

Fastmail isn’t a new company; as per Wikipedia, it’s been around since 1999. That makes it older than Gmail, which was founded in April 2004.

Moving away from Gmail

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.

Yet another feature killed by Google

13 years ago, Google killed off Google Reader, and over the years around 300 products and services have been killed off by Google. I shouldn’t be surprised that yet another feature has gone. There’s a summary post from jwz.org about other options, but this is what I’ve gone with.

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.

Just the Browser

by
Screenshot of the Just the Browser web site

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.

Most web browsers have some AI features now. Edge, being a Microsoft product, includes a quite number of AI features, as does Google Chrome. Even Mozilla Firefox isn’t immune, and there has been some pushback against this. Some people have been choosing alternatives such as Waterfox – a Firefox fork with these features removed. That being said, Firefox will have an AI ‘kill switch’ in future versions.

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.

How to: multiply two entities in Home Assistant

by
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.