Working towards automating a few things in a home often seems simple on the surface, but it’s easy for these projects to snowball into dozens of sensors and various servos, switches, and cameras strewn about one’s living space. The same sort of feature creep sneaks into some of the more popular self-hosted home server platforms as well, with things like openHAB requiring so much computing power that they barely function on something like a Raspberry Pi. [Paulo] thought there should be a more lightweight way of tackling a project like this, and set about building his own smart home server with help from some interesting software.
The project is based around the Dirigera hub from Ikea, partially because [Paulo] is planning to use other smart home devices from Ikea as he can easily find them where he is, and also because these devices tend to use Zigbee, a non-proprietary communications standard. This means that if he ever wants to swap out the hub for another one in the future, it won’t be difficult to do. From here the major hurdle is that using the default software from these devices is fairly limiting, so [Paulo] reached for a Raspbee 2 Zigbee gateway for use with a Raspberry Pi and an extremely lightweight and customizable web server called Mako to make this happen. Using Lua as the high-level language to tie everything together he was able to easily deploy the server to control the Ikea hub and devices and automate them in any way he sees fit.
While it is true that software like openHAB and others already exists to do virtually any home automation task that could be imagined, if you’re looking to do something with a bare minimum of computing power something like [Paulo]’s solution is likely going to be the fastest and most reliable method of getting a few things automated around the home. If you’re looking for something completely open source and built from the ground up, though, we have seen a few alternative smart home solutions like this one which don’t rely on any proprietary hardware or software, but do take a little bit more effort on the user’s part.
Interesting idea! I have to admit that HA has annoyed me for a while, it’s just so heavy for what it does, and I don’t like running it in a VM with half of my Pi’s resources (the only reasonable way to do it if you don’t want to dedicate an entire SBC to it).
**Laughs in dual Xeon 2U server with 64Gb running nothing but a HA vm on proxmox.**
I ran my HA on an old i3 desktop from a floor mat roller I found in the trash for quite some time. I had intended to go to a rpi4 at some point but then decided to go for the gusto and bought a retired rackmount from amazon. It was cheaper than a pi at the time…
Yeah, I never intend to buy another pi. Some of the dedicated alternatives are now much cheaper and more open with similar performance and great software support (the old reason I would have stuck with the Pi). And that’s before, like you mentioned, you get into the secondhand market of rackmounts, thin clients, set-top boxes, etc.
Like what alternatives?
The Odroid N2+ (aka “Home Assistant Blue”) is readily available and quite potent. Runs HA well.
IDR if it’s *cheaper* than a Pi these days, but it’s available.
How long before the power consumption on that rackmount surpasses the cost of a box full of RPi?
This, plus the sound, keeps me out of the retired rackmount market.
I run my home server on an old HP thin client. 13 Watts idle with two 3.5 SATA HDDs.
I run my home server on an old HP thin client…. More detail please!
How about running it as docker container? This is how I’ve been running it for the past 3 years with basically no maintenance effort (using Watchtower to update it)
As a docker container you either have to sacrifice plugins, which in my mind is the only reason to use HA, or use supervised, which involves learning and maintaining a sizeable toolchain. I’ve read through the instructions, and to be honest it seems like more effort than rolling my own and writing my own plugins, and it sounds like watchtower is a layer on top of that.
I’ll only use HA if it’s easier than rolling my own for my relatively simple needs. It’s only easier for me, not a container expert, if it’s running as an OS. Running as an OS involves enough overhead that I’m inclined to switch away.
I think it’s an amazing project, and is the perfect fit for most smart homes (at least when people are willing to explore options beyond the commercial). It’s still the best fit for me, at least until I have to sink time into it again or I really want to use that half of my Pi’s RAM and cores for something else.
Generally, if you are entertaining the idea of going the docker container approach for HA, you’re already capable of handling most of the add-ons since they are simply additional containers. The upside of going the self-managed container route is that for the most part, I’m not stuck using HA for the benefits of the add-ons.
Yeah it doesn’t get much easier than spinning up containers to mirror any plug-ins.
Spot on
Agreed.
On the one hand, it is amazing what firmware like tasmota can pack into an ESP, on the other hand all the home automation software suffers from extreme bloat. Not just feature creep, but every available software stack the developers find cool. And unless the software fits on a small single board processor, I don’t want to have a dedicated server to turn my lights on and off, look at the outside temperature, or check whether the washing machine is done.
Last time I did a comparison of the different software was early 2021, and I gave up after that:
– HA: always cutting edge. – No thanks, that’s why I switched from ubuntu tio debian, I don’t need to
spend my time on constant updates. When I checked in 2021 HA python was ahead of debian stable, which mans, one either has to install it in a docker or on its own machine, just because of that.
– Openhab: More popular in Germany. losing to HA. Java makes it faster than HA which would be good on . But insists on newest Java, which makes it incompatible with older Pi or Pi Zero.
– iobroker: JS based, bad documentation, insists on newest NodeJS, which makes it incompatible with older or simpler hardware like Pi Zero.
– domoticz: C++ with Lua, just a few MB. Looked good and I tried it. Don’t remember why I gave up on it, I think it was some atrocious update policy which didn’t follow proper linux security.
For now I am running a couple tasmota devices with direct browser access. In the winter I had a plant light with a tasmota timer that calculated the local sunset. Impressive.
For a more automated setup, I am gravitating towards some lightweight scripts that react to events and offer a small local website. So far, I put mosquitto on my print server, and will try to put a little web server there too.
I’m using Domoticz, which is pretty lightweight. Supports IKEA Tradfri via a plug-in.
“The same sort of feature creep sneaks into some of the more popular self-hosted home server platforms as well, with things like openHAB requiring so much computing power that they barely function on something like a Raspberry Pi.” – Since when, I have an instance running on a Pi3 with more than enough headroom. Uses on average 4% cpu and 20% memory. I would venture to bet I have integrated more than the average Joe on mine as well.
Amongst REST, Home Assistant offers the ability to program in a lot of languages. It’s a menu on every GUI config page to edit in a well documented y’all format. Python plugins require a single line of config and then you drop your scripts in a directory. Arduino compatible system for esp32/8266 built in that can interact with HA entities or directly send webhooks..
Sure, there’s parts that aren’t documented perfectly, but it’s still a rapidly changing program so time documenting things that will be improved in a couple months isn’t always the priority.
An example of what I set up this afternoon:
5 ZigBee lights in one of those ugly 5 headed lamps that I want to slow fade between colors. I made №/hue/sat/brightness/transition speed as input_number variables. Then I made an automation that runs at transition/5 to increment № +1 & hue+72 and call 1 light. Then from an admittedly more complicated different automation I have it adjust saturation/brightness throughout the day while the colors keep changing.
HA isn’t perfect, but It’s plenty scriptable and it improves on the daily. I don’t know crap about programming and it’s still pretty easy.
Great tutorial! Now all I need to do is ACTUALLY BUY A RASPBERRY PI without being GOUGED by scalpers. Actually, there’s a bunch of alternate Raspberry Pi hardware out there in the wild already. Take a look at the DietPi homepage for plenty of suggestions.[1] Actually it would be nice if the Mako Server/Lua [2] solution described by [Renato Athaydes] was rolled up as a DietPi flavor to begin with. That way your choice of known compatible hardware instantly expands.
1. DietPi (Scroll down to see the hardware catalog.)
https://dietpi.com/
2. Mako Server
https://makoserver.net/
I’m kinda annoyed at how powerful hardware needs to be for this type of application… I got a fairly complex home automation setup and when I run it on something lightweight, suddenly there is a noticable delay between entering a room and all the lights coming on… should be trivial in principle, but interfacing with all the different hardware over different networking standards takes its toll. Yet the alternative would be even worse, tying oneself to one hardware ecosystem/manufacturer. Still, you got to save a LOT of heating power to outweigh added control hardware power consumption.
Yup, bloat and latency infests this home automation (HA) nonsense. The first step often taken by someone new to this HA trip is jumping though the cloud and using someone else’s MQTT box – just to control a lamp in the same room. Sheeeesh.
I ran HA on a Pi3 for a while and have only now changed because I can get more devices connecting to HomeKit directly now.
Many I build myself or convert using HAA. My Pi3 now runs Scrypted for just the cameras and doorbell as performance is much better than HA
What about using Frigate, double take and compare face?
Scrypted is ok but your video feed going to the cloud is not a good idea.
I’m running HA on my OpenWRT router (ZBT-WG1608 ~80 euros) together with a samba server (using USB SSD) and mosquitto broker.
The HA install is based on the https://github.com/openlumi/homeassistant_on_openwrt install script.
I don’t know what his problem was with Home Assistant. I’ve got about 40zigbee devices from varying vendors. I don’t have a hub, I just use a ZigBee stick and zigbee2mqtt. I have HA in a container on rpi4 running fedora 38 and have a total of no issues at all.
In terms of automations you can use the UI or use templating which is yaml, but you can also use bash scripts to run commands on remote hosts along with a multitude of other ways to get things done.
It’s each to their own, but I certainly disagree with his comments regarding HA.
Node red….point and click
The biggest issue I have with Home Assistant are the constant changes in the configuration of automations, add ons, and other aspects that require user input. If the user reviews the documentation on the Home Assistant website, the user will most likely fail as the documentation is not constantly updated.
A cheap way I found for home assistant and others is old chromeboxes. They can be had for $25 on ebay.
Use Domoticz on a Pi3 booting from USB stick. Rock solid for the last 4 years.
I came back to HA after running Webthings for years on a pi zero W (which pretty much maxed it out). The HA instance runs as a NixOS service on an existing multi purpose server, and the zero W just runs MySensor gateway and Mosquitto, works nicely (though my latency requirements are not that high, but i guess it stays within about a second). I only have home made MySensor based nRF24 stuff, but with mqtt it’s quite scalable.