I’ve previously posted here and there about my forays into home automation. Things have progressed quite a lot since then and I’ve built out some more substantial infrastructure to control the various devices installed around the house, all coded from the ground-up and designed to integrate with smlkjns_assistant.
Now I’m due to have a baby next month, which I imagine may slow the pace of development for a while, so this seems like a good point to take stock of what I’ve built so far.
smlkjns_assistant provides a chatbot interface for controlling any device from wherever Soph or I are. Typing out a request to turn the heating on can take a comparatively long time though, so the most heavily used interface now is the web dashboard.
The Home page shows at a glance all available devices according to the permissions granted to the logged in user. It reports on/off statuses, along with light levels and colours for bulbs and current power consumption for energy metered devices. Each device widget is a button and tapping will instantly turn the device on or off. Thanks to a command relay running on a Pi Zero in my boiler cupboard that has been subject to a lot of piecemeal optimisation work over the course of last year, response times are now always under a second.
Tapping on a room name will take you to a room specific screen, with these room screens being designed to serve wall-mounted control panels at some point in the future. Unlike the Home screen, room screens also show the latest readings from sensors – more on those later.
Tapping onto the title of a device will lead to that device’s control screen. For lights, that’s a large toggle button followed by a sliding dimmer control and finally a colour picker.
Using the slider to select a new dimmer setting for the light will also be reflected through dimmed interface elements.
Similarly, for bulbs with RGB functionality, choosing a different colour will be reflected in the interface.
The device screen for a device that isn’t a light will just show a standard status toggle, though energy metered devices will also show the amount of energy consumed so far today.
Energy metered devices with defined run cycles will show a calculated cost for their last run.
As an aside, I use the same method of calculating run costs to include this figure in smlkjns_assistant notifications.
For each device, you can view recent energy consumption history, collected every 10 seconds or so by the same boiler cupboard Pi Zero.
Total energy consumption by day, or aggregated to weeks, months or years, can also be calculated and reported for any device.
Back to sensors – tapping on any sensor will show a similar value history reporting screen.
Devices can be automated using any number of rules enforced according to the active scene. These rules can be based on time of day, a sensor value, the current electricity price or any custom stored variable, such as a variable containing a weather condition. In the example below you can see some rules for my office light are based on whether I’m working from home or not on that day.
I mention current electricity price because I’ve recently switched my electricity supply to Octopus, who offer several energy tariffs in which the price per KWh varies according to the time of day and a convenient API for integrating pricing data into your own systems. Their better known Agile tariff, in which a different price is set for every 30 minute block, hasn’t been too favourable lately so I’m currently on an alternative tariff that offers set blocks of cheap pricing overnight. Regardless, my systems will automatically determine the currently active tariff and provide a report on upcoming prices to help plan when to set the dishwasher etc.
Thanks to this same API, I also collect data on total household electricity consumption reportable at half hour blocks or aggregated to any larger period.
Putting tariff and consumption data together allows me to also report on electricity spend over any period and, of interest when comparing tariffs, the average price per KWh paid. Thanks to a much less sophisticated setup with my gas supplier, I can also report on gas spend over any period in the same way, though there’s no variable pricing to contend with here.
smlkjns_assistant was the original control method for devices and whilst tapping a button on the dashboard is often the easier option these days, it does retain some advantages. Thanks to improved command parsing, it can accurately capture commands scheduled with a delayed start and that have a specified duration, as in the below.
Whenever I have time to spend on such things again, my next ambition will be increasing the number of sensors around the house, now that I’ve got a working sensor setup using Pico Ws and BME280s. I’d love to be able to have much more sophisticated rules based on data from these sensors controlling heating in order to maintain a temperature within a target range. There’s bigger priorities on the horizon for now though, so that’s likely a 2026 goal.