https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us * Edition + Return to the Front page User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account A kernel developer plays with Home Assistant: general impressions [LWN subscriber-only content] Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! By Jonathan Corbet May 9, 2025 Those of us who have spent our lives playing with computers naturally see the appeal of deploying them though the home for both data acquisition and automation. But many of us who have watched the evolution of the technology industry are increasingly unwilling to entrust critical household functions to cloud-based servers run by companies that may not have our best interests at heart. The Apache-licensed Home Assistant project offers a welcome alternative: locally controlled automation with free software. This two-part series covers roughly a year of Home Assistant use, starting with a set of overall observations about the project. This is not the first time that LWN has looked at this project, of course; this review gives a snapshot of what Home Assistant looked like five years ago, while this 2023 article gives a good overview of the project's history, governance, and overall direction. I will endeavor to not duplicate that material here. Project health At a first glance, Home Assistant bears some of the hallmarks of a company-owned project. The company in question, Nabu Casa, was formed around the project and employs a number of its key developers. One of the ways in which the company makes money is with a $65/year subscription service, providing remote access to Home Assistant servers installed on firewalled residential networks. Home Assistant has support for that remote option, and no others. It would be interesting to see what would happen to a pull request adding support for, say, OpenThings Cloud as an alternative. The fate of that request would say a lot about how open the project really is. (For the record, I have bought the Nabu Casa subscription rather than, say, using WireGuard to make a port available on an accessible system; it is a hassle-free way to solve the problem and support the development of this software). That said, most of the warning signs that accompany a corporate-controlled project are not present with Home Assistant. The project's contributor license agreement is a derivative of the kernel's developer certificate of origin; contributors retain their copyright on their work. Since the 2024.4 release, the Home Assistant core repository has acquired over 17,000 changesets from over 900 contributors. While a number of Nabu Casa employees (helpfully listed on this page) appear in the top ten contributors, they do not dominate that list. Home Assistant is clearly an active project with a wide developer base. In 2024, overall responsibility for this project was transferred to the newly created Open Home Foundation. This project is probably here to stay, and seems unlikely to take a hostile turn in the future. For a system that sits at the core of one's home, those are important characteristics. Installation and setup Linux users tend to be somewhat spoiled; installing a new application is typically a matter of a single package-manager command. Home Assistant does not really fit into that model. The first three options on the installation page involve dedicated computers -- two of which are sold by Nabu Casa. For those wanting to install it on a general-purpose computer, the recommended course is to install the Home Assistant Operating System, a bespoke Linux distribution that runs Home Assistant within a Docker container. There is also a container-based method that can run on another distribution, but this installation does not support the add-ons feature. Home Assistant, in other words, is not really set up to be just another application on a Linux system. If one scrolls far enough, though, one will find, the instructions to install onto a "normal" Linux system, suitably guarded with warnings about how it is an " `advanced'" method. Of course, that is what I did, putting the software onto an existing system running Fedora. The whole thing subsequently broke when a distribution upgrade replaced Python, but that was easily enough repaired. As a whole, the installation has worked as expected. Out of the box, though, a new Home Assistant installation does not do much. Its job, after all, is to interface with the systems throughout the house, and every house is different. While Home Assistant can find some systems automatically (it found the Brother printer and dutifully informed me that the device was, inevitably, low on cyan toner), it usually needs to be told about what is installed in the house. Thus, the user quickly delves into the world of "integrations" -- the device drivers of Home Assistant. For each remotely accessible device in the house, there is, hopefully, at least one integration available that allows Home Assistant to work with it. Many integrations are packaged with the system itself, and can be found by way of a simple search screen in the Home Assistant web interface. A much larger set is packaged separately, usually in the Home Assistant Community Store, or HACS; it is fair to say that most users will end up getting at least some integrations from this source. Setting up HACS requires a few steps and, unfortunately, requires the user to have a GitHub account for full integration. It is possible to install HACS integrations without that account, but it is a manual process that loses support for features like update tracking. Most integrations, at setup time, will discover any of the appropriate devices on the network -- if those devices support that sort of discovery, of course. Often, using an integration will require the credentials to log into the cloud account provided by the vendor of the devices in question. When possible, integrations mostly strive to operate entirely locally; some only use the cloud connection for the initial device discovery. When there is no alternative, though, integrations will remain logged into the cloud account and interact with their devices that way; this mode may or may not be supported (or condoned) by the vendor. There are, of course, some vendors that are actively hostile to integration with Home Assistant. As might be expected, the quality of integrations varies widely. Most of the integrations I have tried have worked well enough. The OpenSprinkler (reviewed here in 2023) integration, instead, thoroughly corrupted the device configuration, exposing me to the shame of being seen with a less-than-perfect lawn; it was quickly removed. It is an especially nice surprise when a device comes with Home Assistant support provided by the vendor, but that is still a relatively rare occurrence. Home Assistant now is in a position similar to Linux 25 years ago; many devices are supported, but often in spite of their vendor, and one has to choose components carefully. Security Home Assistant sits at the core of the home network; it has access to sensors that can reveal a lot about the occupants of the home, and it collects data in a single location. An installation will be exposed to the Internet if its owner needs remote access. There is clearly potential for a security disaster here. The project has a posted security policy describing the project's stance; it asks for a 90-day embargo on the reporting of any security issues. Authors writing about the project's security are encouraged to run their work past the project "`so we can ensure that all claims are correct'". The security policy explicitly excludes reports regarding third-party integrations (the core project cannot fix those, after all). The project is also uninterested in any sort of privilege escalation by users who are logged into Home Assistant, assuming that anybody who has an account is fully trusted. The project has only issued one security advisory since the beginning of 2024. There were several in 2023, mostly as the result of a security audit performed by GitHub. There is no overall vetting of third-party integrations, which are, in the end, just more Python code. So loading an unknown integration is similar to importing an unknown module from PyPI; it will probably work, but the potential for trouble is there. The project has occasionally reported security problems in third-party integrations, but such reports are rare. I am unable to find any reports of actively malicious integrations in the wild, but one seems destined to appear sooner or later. Actually doing something with Home Assistant The first step for the owner of a new Home Assistant installation is, naturally, to seek out integrations for the devices installed in the home. On successful installation and initialization, an integration will add one or more "devices" to the system, each of which has some number of "sensors" for data it reports, and possible "controls" to change its operating state. A heat-pump head, for example, may have sensors for the current temperature and humidity, and controls for its operating mode, fan speed, vane direction, and more. It is worth noting that the setup of these entities seems a bit non-deterministic at times. My solar system has 22 panels with inverters, each of which reports nearly a dozen parameters (voltage, current, frequency, temperature, etc.). There is no easy way to determine which panel is reporting, for example, sensor_amps_12, especially since sensor_frequency_12 almost certainly corresponds to a different panel. My experience is that Home Assistant is a system for people who are willing to spend a lot of time fiddling around with things to get them to a working state. Dealing with these sensors was an early introduction to that; it took some time to figure out the mapping between names and rooftop positions, then to rename each sensor to something more helpful. The next level of fiddling around is setting up dashboards. Home Assistant offers a great deal of flexibility in the information and controls it provides to the user; it is possible to set up screens focused on, say, energy production or climate control. Happily, the days when this configuration had to be done by writing YAML snippets are mostly in the past at this point; one occasionally still has to dip into YAML, but it does not happen often. The interface is not always intuitive, but it is fairly slick, interactive, and functional. Another part of Home Assistant that I have not yet played with much is automations and scenes. Automations are simple rule-triggered programs that make changes to some controls. They can carry out actions like "turn on the front light when it gets dark" or "play scary music if somebody rings the doorbell and nobody is home". Scenes are sets of canned device configurations. One might create a scene called "in-laws visiting" that plays loud punk music, sets the temperature to just above freezing, disables all voice control, and tunes all of the light bulbs to 6000K, for example. The good news is that, unless the fiddling itself is the point (and it can be a good one), there comes a time when things just work and the fiddling can stop. A well-configured Home Assistant instance provides detailed information about the state of the home -- and control where the devices allow it -- to any web browser that can reach it and log in. There are (open-source) apps that bring this support to mobile devices in a way that is nearly indistinguishable from how the web interface works. All told, it is clear why Home Assistant has a strong and growing following. It is an open platform that brings control to an industry that is doing its best to keep a firm grasp on our homes and the data they create. Home Assistant shows that we can do nicely without all of these fragile, non-interoperable, rug-pull-susceptible cloud systems. Just like Linux proved that we can have control over our computers, Home Assistant shows that we do not have to surrender control over our homes. This article has gotten long, and is remarkably short on interesting things that one can actually do with Home Assistant. There are some interesting stories to be told along those lines; they will appear shortly in the second, concluding part of this series. [Send a free link] ----------------------------------------- [Log in] to post comments Automation madness Posted May 9, 2025 23:14 UTC (Fri) by gerdesj (subscriber, #5446) [ Link] If you find the built in automation thing a bit limiting you can always drop in the Node-RED integration and really go to town! It arrives nicely pre-setup with lots of handy widgets. You just have to follow some pretty simple instructions to add in the agent within HA itself and off you go. As big Jon mentioned, you can run HA "Supervised" which means you get to run it on a full OS which is very useful. He perhaps over-looked the bit about Debian current being the only supported option! They do get a bit forthright about this. I redeployed a couple of ill advised Ubuntu based VMs with Debian and restored from config backups. I have deployed quite a few of these beasties for customers. They are so handy for things like printer fleet management and monitoring. There is a card (in HACS) which will automatically gather up all entities and display statuses when a certain trigger is hit. Ideal for many batteries or toner statuses. At another customer, I set one up at the beginning of the pandemic so they could turn their work CAD boxes on and off using WoL and an integration that sends shutdown commands to Windows. The hardest part of that was sorting out MS's idea of power management for NICs. Grab a slack handful of ESP32 and the like and with minimal skills and perhaps a soldering iron, some wires, breadboard and a 3D printer, you can create all sorts of things. ESPHome is ready to do the programming with a pleasant webby IDE and does all the heavy lifting. Frigate and a Google Coral is ready to do security cameras and web cams. All covered with an add on and a GUI. If you get a microphone(s) sorted out then you can setup a wake word "OK computer" and do text to speech and speech to intents. You can, via a Nabu Casa sub, gateway Amazon Echos and the like to take advantage of them but insulate yourself from direct contact. The ZWave and Zigbee implementations are now very solid. Zwave was patchy in the past but now it is reliable, at least at the HA end. If you have a static IP or can use dynamic DNS and you can forward ports 80/tcp and 443/tcp, then grab the nginx proxy manager addon and use its Lets Encrypt feature. Or you could spin something up on the host OS (if you have one) HA is superb for turning loads of phone apps into a single pane of glass. For example my car (*sigh*, yes it has an app - Seic MG4), home power supplier (Octopus) and my car charger (Zappi) all have apps. They also all have integrations for HA. I don't bother with the phone apps much. Another very popular integration is automated rubbish/recycling scheduling. Grab "Waste Collection Schedule" via HACS. It will almost certainly support wherever you live or you can use an .ics file or a manual schedule. Recently someone added browsers for several discovery mechanisms (DHCP, SSDP and Zeroconf) into the web GUI - genius! The pace of development is insane but the core product is rock solid with a few wobbles along the way, just like Linux itself or any other huge and complicated software system. [Reply to this comment] Also: its own container OS! Posted May 9, 2025 23:39 UTC (Fri) by Cyberax ( supporter , #52523) [Link] (1 responses) One _really_ nice feature of HomeAssistant is its own image-based OS (HAOS). I was initially skeptical about it, and started hosting HA on my own server. But then I had a nightmare upgrade, after a year of not paying attention to it. I needed to manually update dependencies, unbreak my whole OS after accidentally running `chmod` in a wrong directory, etc. I decided that my time was more valuable, so I got an Intel NUC, set up HAOS on it, and... that was it! It updates perfectly on its own, I can install addons by clicking on them in the "HomeAssistant Store", and I can also firewall the whole home automation in its own VLAN. It also can back up itself onto my NAS. And it can restore itself! This was super-handy when the SSD in my NUC died last month. I just popped in a new SSD, installed the basic OS, and did a restore. This is about the most perfect example of a hassle-free "homebrew" IoT experience. [Reply to this comment] Also: its own container OS! Posted May 10, 2025 0:41 UTC (Sat) by gerdesj (subscriber, #5446) [ Link] HA is a proper job! Your comment is a classic HA experience. You want to take it seriously but didn't have the time at the time and something went wrong. It is engineered properly and hence you fixed your snag and moved on. I don't think I've ever seen you describe a product in such glowing terms! [Reply to this comment] Complex and bloated Posted May 10, 2025 12:15 UTC (Sat) by parametricpoly (subscriber, # 143903) [Link] (30 responses) It's a bit annoying how all these applications eventually became monstrously complex and bloated. It's really not a good sign that a application focusing on integration cannot integrate in any standard distribution. I don't want to run it in a KVM virtual machine. Modern day solution is to set up containers. Many services also support native installation. It's puzzling how a platform independent high level scripting language would break with minor updates to the host OS. [Reply to this comment] Complex and bloated Posted May 10, 2025 13:32 UTC (Sat) by khim (subscriber, #9252) [Link ] (6 responses) > It's puzzling how a platform independent high level scripting language would break with minor updates to the host OS. Why is it puzzling? They are using "easy to use" and "flexible" language which have zero guardrails that may help against breakages on upgrade. Why wouldn't it break randomly? For C we have LibAbiGail. For Rust we have Cargo Semver Checks, Crater and many other things... what do we have for Python? Wishful thinking and prayers? "High level scripting languages" are not designed to survive upgrades... and distros are very much built around the idea that everything have to be updated. They are fundamentally incompatible. > It's really not a good sign that a application focusing on integration cannot integrate in any standard distribution. It's not good sign. It's great sign. That's exactly how winner of these games should look like. When you start an integration project you, essentially, have two (and half) choices: 1. Nice set of rules, everything is done neatly, things are guaranteed. 100% guaranteed failure. 2. You have as few rules as possible, you invite non-professionals and embrace awful things in the hope that they would improved later. That thing may succeed. But... what is a success here? Success would be a state where that horrible mangled monster that is threatening to collapse and unravel at any moment have enough supporters to keep it going, somehow. Because if chaos, inherent in the approach needed to achieve success, overwhelms developers and the whole thing collapses and couldn't be salvaged... well, that's it, it's no longer a success, obviously. And if you impose enough rules to support proper upgrades, nice interaction with distros, and other things that may effect the desire of unprofessional contributors to join... you would lose to some other, more chaotic and more "forgiving", project. Only when certain niche if "fully filled", with many projects that do what one needs or wants, competition on quality begins (and former leader, closest to collapse, may be replaced with something nicer... think pile of SysVinit scripts vs systemd). And home automation niche is far from being "fully filled", even Home Assistant is very far from being at the stage where one may honestly say "you may buy whatever your want, any IoT gadget - and Home Assistant would support it". > It's a bit annoying how all these applications eventually became monstrously complex and bloated. That's how winners in these races look like, it's 100% inevitable. People like small and neat solutions... till they find out that something they want only works with a bloated monster... and then they switch. Bloated monsters win, everything else loses... it's inevitable. [Reply to this comment] Complex and bloated Posted May 10, 2025 15:33 UTC (Sat) by bferrell (subscriber, #624) [ Link] (4 responses) "People like small and neat solutions... till they find out that something they want only works with a bloated monster... and then they switch. Bloated monsters win, everything else loses... it's inevitable." Odd... the basic premise of *IX (UNIX, Linux and all the IX-alikes) is they are small and do one thing well; Then chain them together. And that premise has lasted from before the bloated monster began and shows ever sign of outlasting them. It's absorbed or insinuated itself into it's competition (windows subsystem for Linux and Mac OS). I strongly dislike subscriptions. I dislike dribbling my hard-earned dollars away. I know from looking at my budget that "small, micro payments" add up faster than grains of wheat on a chessboard. HA is damned near useless without that $65 subscription as far too many integrations require the Nabu Casa Cloud Service (also called HACS, for home assistant cloud service). I've got one hanging around just for giggles. I also have a Mycroft. It doesn't use ANY cloud service and has none of the hype or community. So I build it all myself in my copious spare time. [Reply to this comment] Complex and bloated Posted May 10, 2025 16:04 UTC (Sat) by khim (subscriber, #9252) [Link ] > Odd... the basic premise of *IX (UNIX, Linux and all the IX-alikes) is they are small and do one thing well; Never. Even very early Unixes are bloated, sprawling, monsters if you compare them with a well-designed systems. The premise was always "do one thing and do it well" for one program, not for the whole thing. > Then chain them together. Nope. Direct quote from Doug McIlroy: To do a new job, build afresh rather than complicate old programs by adding new "features". That advice doesn't reduce size of the mess, it just moves it from one place to another. > And that premise has lasted from before the bloated monster began Seriously? Need I remind you that the whole Unix project was a reaction to issues with that one "bloated monters" called Multics? > shows ever sign of outlasting them Oh, absolutely. But that's because Linux is much more bloated and monstrous. Multics kernel has 250k lines of code. Linux have near 40 million. That's two order of magnitude difference (as in: Linux is hundred times larger). Compared to Linux bloated monsters of yesteryears are not tiny, they are outright minuscule. Today we are discussing whether minimal install should be 40MiB or 50MiB... both would fill storage of monstrous system from yesteryear that was result of one of largest projects ever attempted by mankind. Both would leave some small amount of space for the users... that's something, I guess. > I also have a Mycroft. It doesn't use ANY cloud service and has none of the hype or community. So I build it all myself in my copious spare time. Well... as I have said: if there ever would be a time where the majority of devices would be supported by both competition on quality may start... till then the bigger mess wins. [Reply to this comment] Complex and bloated Posted May 11, 2025 0:45 UTC (Sun) by Mook (subscriber, #71173) [Link ] > HA is damned near useless without that $65 subscription as far too many integrations require the Nabu Casa Cloud Service (also called HACS, for home assistant cloud service). FWIW, Home Assistant Cloud (the Nabu Casa thing) seems to be unrelated to the thing that's usually abbreviated HACS -- that's the Home Assistant Community Store which is basically a listing of custom components created by random people (with the quality guarantees you might expect from that description). Also, I use HA without the cloud service, and it seems fine. But I don't really have a need to interact with things from outside yet; at least, I don't find it damned near useless. But then my major use case is pretty much "I'm too lazy to get up from the sofa to turn on the light"... [Reply to this comment] Complex and bloated Posted May 11, 2025 2:18 UTC (Sun) by Cyberax ( supporter , #52523) [Link] > HA is damned near useless without that $65 subscription as far too many integrations require the Nabu Casa Cloud Service That's completely incorrect. You can use HA without any subscription. Mobile applications for HA also support custom URLs, and mine is directly exposed with a public IPv4/IPv6 addresses. The only integration that is bothersome to set up without HA subscription is Alexa. You can _still_ do that, but you'll need to follow a somewhat convoluted process of creating your own private skill. [Reply to this comment] Complex and bloated Posted May 11, 2025 8:25 UTC (Sun) by mjg59 (subscriber, #23239) [ Link] I've a bunch of code in HA, I run three instances of it, I have a whole bunch of complexity tied into it from turning the yard lights on when it's dark, to running the fan in my bathroom when the humidity is significantly above the ambient humidity, to noticing that the cabin water supply pump is running but drawing too little current so there's probably a water leak and turning it off to stop it burning out. I've never paid anything. There are use cases where the subscription makes life easier (and yes the hoops to jump through for Google Assistant integration without using a maintained cloud service are annoying), but "damned near useless" is just not even slightly true. If you've ended up under the misapprehension that HACS (the community maintained integration distribution system) requires a subscription then, well, that's a misapprehension? [Reply to this comment] Python compatibility checks Posted May 11, 2025 23:12 UTC (Sun) by geofft (subscriber, #59789) [ Link] > For C we have LibAbiGail. For Rust we have Cargo Semver Checks, Crater and many other things... what do we have for Python? Wishful thinking and prayers? Now that Python has grown type support, something like https:// mypy.readthedocs.io/en/stable/stubtest.html would be a good way to do the sort of thing libabigail does to check that a new version of a package exposes the same interface as previous versions. (Of course, in both cases, whether it has the same semantics is a different question, but there are a wide variety of tools for writing tests, and no real substitutes to doing so.) [Reply to this comment] Complex and bloated Posted May 10, 2025 14:32 UTC (Sat) by dskoll (subscriber, #1630) [ Link] (19 responses) Yes, I'm also put off by the complexity of HA (and ESPHome, for that matter.) I don't understand why IoT devices can't just have simple REST-based interfaces. That's all I want. I want to control my devices from scripts using curl or equivalent. I don't need all the MQTT nonsense or fancy UIs. Sure, have the IoT devices also support that for people who want it, but give us old-school scripters a simpler option, please! [Reply to this comment] Complex and bloated Posted May 10, 2025 15:44 UTC (Sat) by felixfix (subscriber, #242) [ Link] (4 responses) Ditto. I have a couple of smart plugs for outside devices, controlled from my phone, and it annoys me I can't write my own interface to them. I had a thermostat which connected via RS-422, another which connected by PoE, both talking directly to my home computer. I could ssh to my home computer, telnet to the thermostat, and that was good enough. Echo and cronjobs worked too. This all sounds way too complicated for any benefit. If all I want to do is tinker, I have enough of my own projects. [Reply to this comment] Complex and bloated Posted May 10, 2025 18:35 UTC (Sat) by dskoll (subscriber, #1630) [ Link] (3 responses) I have a couple of Sonoff smart plugs running ESPHome, and I can control them with curl, so they work fine from scripts and cron jobs. ESPHome has an optional REST-based API. However, installing ESPHome on the plugs and configuring it to my liking was a major hassle. I had to do it from within a Docker container, and I've somehow misplaced the YAML configuration files for the devices, so I'd have to reverse-engineer what I did if I want to change anything on the devices. And given the state of ESPHome documentation, that's not appealing. There's reference material, sure, but no easy tutorial to introduce you to the concepts and help you get up and running. [Reply to this comment] Complex and bloated Posted May 12, 2025 14:57 UTC (Mon) by leromarinvit (subscriber, # 56850) [Link] (2 responses) If all you want to do is expose a REST endpoint for toggling a switch, then ESPHome might be overkill - e.g. for your Sonoffs, you could use Tasmota. That's configurable via a built-in web ui, so it's harder to lose the config there (but not impossible, so keeping a backup is still wise). It doesn't have an API that could reasonably be described as RESTful, but you can execute arbitrary commands via HTTP GET - so switching with curl will work. Where ESPHome really shines is for running complex custom automation code close to the target. E.g. I have a smart plug for my coffee machine which (among other things) detects the pump running (via reactive power) and resets a turn-off timer accordingly. Best of all, you can write all this custom logic in a real programming language (C++) - anyone who's tried to implement similarly complex things with Tasmota will probably attest to its limitations in this regard. In general, I always aim for having as few involved parts as possible for automation (so as to not introduce unnecessary failure points), so being able to run custom code right inside the actual actuator device is nice. I also run HA, but for this reason, I only use its automations when there is no other option (Zigbee, I'm looking at you). I mostly use it as a dashboard and for occasional manual control. It also servers as a home for my ESPHome configs (via the ESPHome Builder addon), mostly out of laziness. [Reply to this comment] Complex and bloated Posted May 14, 2025 22:34 UTC (Wed) by dskoll (subscriber, #1630) [ Link] (1 responses) Thanks for recommending Tasmota. I took a look and converted one of my plugs over. It's much simpler and more straightforward than ESPHome, and better documented too. And the silly little HTTP GET invocation to control the plug works fine for my purposes. So again, thanks! I'll be converting the other one over soon. [Reply to this comment] Complex and bloated Posted May 15, 2025 0:39 UTC (Thu) by mjg59 (subscriber, #23239) [ Link] esphome is great for more complex setups (I use it for an air sensor monitor that has different sensors on SPI and I2C and needs to be able to report multiple results in different units), but when all you want to do is toggle a GPIO then Tasmota is almost certainly preferable. [Reply to this comment] Complex and bloated Posted May 10, 2025 17:25 UTC (Sat) by khim (subscriber, #9252) [Link ] (12 responses) The problem with IoT lies with the fact that goal of their creators is "buzzword-complicance". The fact that you may actually do something useful with them is, essentially, an afterthought, the main reason to add all that stuff is to then sell all these capabilities to various kinds of buyers. And "old-school scripters" tend to be least buzzword-triggerable and least lucrative group... thus their desires are often ignored. If they get anything at all it's usually because design of fancy buzzword-compliant UI was done by sensible people who simply did nothing to prevent such use... but some bosses are smarter than others and they demand solutions which would exclude nerds from the loop. The hope is, usually, to [try] to sell you some extra service for extra money. Usually that doesn't work, but apparently even few percents of buyers for all that crap are enough to justify the whole game. Makes sense, actually: margins with all these gadgets are so thin that even few percents of users who pay for addon that's 99% pure profit... it's enough to treat everyone else as "unimportant". [Reply to this comment] Complex and bloated Posted May 10, 2025 19:14 UTC (Sat) by parametricpoly (subscriber, # 143903) [Link] (11 responses) Right, another complaint I can think of is that all vendors are building their own IoT ecosystem. I'm basically buying gear that best serves its purpose (technical aspect) and has a good price. Each of them has a different middleware. I even bought two robot vacuum cleaners from the same vendor (Dreame). Both have different software (Dreame & Xiaomi home). My cat feeder has an app that also advocates buying their stuff and has a concept of rooms and scenes etc although I only needed it to set up the feeding schedule. It fails to perform its main function. The schedule needs to be fixed twice a year due to daylight savings. The UI also displays weather forecast for this location etc. which are totally useless in this app. My air purifier has its own app but does not show these infos. Yes there's Google Home integration but the air purifier is a perfect example. Its own app shows the wear status of the filters, displays air pollution levels, can adjust fan speed, schedules etc. The Google Home integration only allows turning it on or off. [Reply to this comment] Complex and bloated Posted May 10, 2025 19:27 UTC (Sat) by khim (subscriber, #9252) [Link ] (7 responses) > It fails to perform its main function. How do you know? > My cat feeder has an app that also advocates buying their stuff That seems to be the main function... and it only needs to bring few percents of users to buy some high-margin thingie from them... how do you know it fails at that? > I'm basically buying gear that best serves its purpose (technical aspect) and has a good price. The problem is that we live in a world where making gear that best serves its purpose and has good price is not sustainable. You need something else to survive. Something high-margin. And that's why all that move is even happening: it's all an attempt to find that "something high-margin". If not in a real reality then, at least, in imaginary reality that can be shown to investors. Take a look on what's happening from that angle... and things, suddenly, would become much more sane if sad: you would realize that things are happening in the way they are happening because people that are doing them are intelligent and sane and not sadistic and insane... but that doesn't give you "a way out" in a world where you are consumer, not a product (with eyes, ears and wallet that are on sale). [Reply to this comment] Complex and bloated Posted May 13, 2025 5:33 UTC (Tue) by rgmoore ( supporter , #75) [ Link] (6 responses) The problem is that we live in a world where making gear that best serves its purpose and has good price is not sustainable. You need something else to survive. Something high-margin. I don't think that's quite true. High margins are necessary for relatively new businesses that are selling to a small market of early adopters, which is where most smart devices are today. Over time, though, manufacturers will figure out how to make those same general kinds of goods into low margin, high volume items that will sell to everyone. I think a really good home automation server will be a key part of that happening. Once lots of people have home automation servers with a standardized device interface, smart devices will become commodities, and low cost rather than high margins will be the name of the game. [Reply to this comment] Complex and bloated Posted May 13, 2025 10:55 UTC (Tue) by pizza (subscriber, #46) [Link] (5 responses) > Once lots of people have home automation servers with a standardized device interface, smart devices will become commodities, and low cost rather than high margins will be the name of the game. Look no further than the rapid enshittification of televisions to see how well that theory has worked out -- In practice, those "smart devices" are already being reduced to selling at zero or negative margins, with any profits being made by monetizing collected user data (including injected advertising), subscription fees, or both. If you don't control the server backend and/or the user client, none of that is possible. [Reply to this comment] Complex and bloated Posted May 13, 2025 18:35 UTC (Tue) by Cyberax ( supporter , # 52523) [Link] (4 responses) Data collected from smart devices is largely worthless, except for TVs. There are scores of dead companies attesting to that. [Reply to this comment] Complex and bloated Posted May 13, 2025 19:44 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses) > Data collected from smart devices is largely worthless, except for TVs. There are scores of dead companies attesting to that. That conveniently ignores the companies that didn't die, many of whom bought up the assets (including the data!) of those failed companies. ...So I take it you have no problem with everyone+dog having access to always-on microphones (and sometimes cameras -- Roomba taking photos of people on toilets, anyone?) in your home, along with detailed data on room occupancy (including schedules) and location data? And that's just the devices; factor in the truly awful state of individual apps (and every device has to have their own app, because $reason) which all seem to require access to fine location data, phone state, and usually far more? So "worthless" or not, I have a major problem with the fact they're all doing it anyway,... and making their products shittier in the process. [Reply to this comment] Complex and bloated Posted May 13, 2025 20:23 UTC (Tue) by Cyberax ( supporter , # 52523) [Link] (2 responses) > ...So I take it you have no problem with everyone+dog having access to always-on microphones I don't really care, yes. What are you going to do with this data? For ad-tech, you need to tie it to a browser user somehow, and that's not trivial. You can also (try to) sell the aggregate data for market research, but there's a very limited amount of valuable information in day-to-day life of regular people. That's also why TVs are the only major area where privacy violations make commercial sense, they have a closed loop for ads. The data from a TV can be used to calibrate the ads that are shown on the same TV. Basically, if you have a device with a screen that shows you ads, then be afraid. Otherwise, you're likely fine. Companies like Lowe's tried to jump on the "smart home" bandwagon (IRIS) and get access to all those tasty, tasty data. And it failed entirely, they got nothing but losses. [Reply to this comment] Complex and bloated Posted May 13, 2025 20:46 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses) > Companies like Lowe's tried to jump on the "smart home" bandwagon (IRIS) and get access to all those tasty, tasty data. And it failed entirely, they got nothing but losses. I'd posit that has more to do with folks simply not *purchasing* this crap, because the value-add for "smart home" to non-gear-fetishists is approximately zero. [Reply to this comment] Complex and bloated Posted May 14, 2025 6:48 UTC (Wed) by Wol (subscriber, #4433) [Link] > I'd posit that has more to do with folks simply not *purchasing* this crap, because the value-add for "smart home" to non-gear-fetishists is approximately zero. Companies forget that the "value add" can easily be NEGATIVE to the consumer. We want a BASIC phone service with OUR choice of add-ons. If our phone company isn't careful they might find I try to bring the weight of disability charities down on them because we can't turn off unwanted extras. Last time this happened we got refunded three months of phone charges because the service was - to put it bluntly - life threateningly bad! Then we recently upgraded and the mess has come back ... Cheers, Wol [Reply to this comment] Complex and bloated Posted May 11, 2025 0:13 UTC (Sun) by willy (subscriber, #9762) [Link ] (1 responses) > The [cat feeder] schedule needs to be fixed twice a year due to daylight savings Why would you do that? From the cat's point of view, it has to wait 13 hours rather than the usual 12 (assuming you're on an every-12-hours schedule). And then five months later, all of a sudden it only has to wait 11 hours. The cat's schedule isn't tied to yours. Just ignore DST (I do this for the clocks in my house which aren't easy to change and don't control anything I care about). [Reply to this comment] Complex and bloated Posted May 11, 2025 11:01 UTC (Sun) by parametricpoly (subscriber, # 143903) [Link] > The cat's schedule isn't tied to yours. Just ignore DST (I do this for the clocks in my house which aren't easy to change and don't control anything I care about). I've set it up to serve 3 proportions during the night so that the cat won't wake me at 4 or 5 am. This is really for my comfort. [Reply to this comment] Complex and bloated Posted May 12, 2025 8:36 UTC (Mon) by leromarinvit (subscriber, # 56850) [Link] > I even bought two robot vacuum cleaners from the same vendor (Dreame). Both have different software (Dreame & Xiaomi home). If you haven't already, you might want to look into Valetudo (https:/ /valetudo.cloud/). Its main feature is that it lets you control your vacuum without being connected to the manufacturer's cloud service, so you can stop worrying about the privacy and security implications. It has a nice, local web GUI, and can optionally integrate with HA (or other systems) via MQTT. I've been running it for years on a Roborock and a Dreame vacuum cleaner, without any issues. [Reply to this comment] Complex and bloated Posted May 10, 2025 20:36 UTC (Sat) by Cyberax ( supporter , # 52523) [Link] The HA core is actually not that big. You can feasibly read and understand all the core code in a weekend, at least that's how long it took me. I have my own integration for Somfy RS-485 controlled shades: https://github.com/home-assistant/core/compare/dev...Cybe... If you're interested in details, you can actually check out this subtree: https://github.com/home-assistant/core/tree/dev/homeassis... , all the core code is contained in this folder only. As an experiment, you can delete most of the `components` content, and the core will work fine. `components` is where individual integrations live. There is more than a thousand of them now, and that's where the bulk of code is. This is entirely like Linux. The core code is fairly compact, and the components^W drivers take up most of the actual LOC count. [Reply to this comment] Complex and bloated Posted May 10, 2025 20:51 UTC (Sat) by Cyberax ( supporter , # 52523) [Link] > It's really not a good sign that a application focusing on integration cannot integrate in any standard distribution. You can package the core HA easily. The problem is that by itself it's not that useful. It needs integrations for that, and they are not really package-able in their entirety. You'll end up depending on hundreds of Python libraries that you need to individually package. But wait, there's more! Suppose you want to use ZWave or ZigBee. Well, for ZWave you have two options: a NodeJS-based server, or a crusty old C++ library that internally downloads does random firmware based on DNS lookups (not kidding). Suppose you go with the NodeJS server. So now you have to connect it to your home automation suite, and this means setting up dependencies, access control, etc. It's also not packaged by the OS, as it has 1000-s of its own dependencies. And suddenly, you find yourself writing container orchestration code. Can this all be made simpler? I don't think so. [Reply to this comment] Complex and bloated Posted May 11, 2025 8:57 UTC (Sun) by MortenSickel (subscriber, # 3238) [Link] (1 responses) "Modern day solution is to set up containers. " Which is actually the way of running HA if you do not want to run it on a stand alone box. My HA runs in a docker system on one of my debian servers at home. All of the large components are running their own.container, everything working.nicely as soon as I had the general docker setup.right. [Reply to this comment] Complex and bloated Posted May 11, 2025 11:47 UTC (Sun) by VersedBook0 (subscriber, # 172894) [Link] In fact even if you setup a Virtual Machine running Home Assistant OS like I have it's still a basic Linux install that.. wait for it.. runs docker containers for all the major bits [Reply to this comment] A different perspective Posted May 10, 2025 19:53 UTC (Sat) by warrax (subscriber, #103205) [ Link] (12 responses) > Those of use who've spent our lives playing with computers naturally see the appeal of deploying them though the home for both data acquisition and automation. I have spent my life using and programming computers (and I'm late middle age at this point) and I honestly don't. It seems, largely, like a waste of time to me. I promise I'm not being flippant or anything... I just really don't see the "value add". Life without random things happening (and having to debug them!) with heating/ lighting or whatever seems a lot simpler to me. Is turning a knob really that much effort? It's like people are chasing a fantasy of an automated environment that doesn't actually do that much, ultimately. I'm sure there's some satisfaction that can be derived from "i programmed this", but that's an illusion... just like IKEA furniture gives you the feeling of having built the thing yourself. (Or for an older example... those cake kits, where you just mix 2 or 3 things together and bake for a while...) [Reply to this comment] A different perspective Posted May 11, 2025 1:37 UTC (Sun) by dskoll (subscriber, #1630) [ Link] (1 responses) I agree. I can't see the value of "home automation" except in some very limited circumstances: 1. I have a couple of smart plugs that I use to power-cycle two important Raspberry Pi servers remotely if all else fails. 2. I like to have something to turn lights on and off if I go away for a few days so it looks like someone's in my house. But an electromechanical timer and a lamp take care of that quite nicely. Everything else seems to me like gadgetry for gadgetry's sake. [Reply to this comment] A different perspective Posted May 15, 2025 7:10 UTC (Thu) by AdamW (subscriber, #48457) [ Link] The main value for me is doors. Being able to allow access for the catsitter, or a friend who shows up unexpectedly with something to drop off, or whatever. Being able to check whether I remembered to lock the doors when I'm in bed, without actually getting up and going to look. Being able to open/close my garage door if I don't have the dedicated remote with me, without using the godawful MyQ cloud thing (thanks, ratgdo). But the other stuff is, honestly, just fun. Have I actually used the ability to control my heat pumps from HA much, since I set it up? Well, nah. Was it fun? Well, yeah. Is it world-changing that I can use it to auto-shutoff my ebike battery charger once it gets close to full capacity, and not have to do it manually or worry about the battery burning the house down if it overcharges? Nah. Is it kinda neat? Sure. YMMV, but I've found HA extremely well built and designed in just such a way that fiddling around with it feels like *fun*, not a chore. [Reply to this comment] A different perspective Posted May 11, 2025 1:57 UTC (Sun) by felixfix (subscriber, #242) [ Link] (4 responses) I'm with you. Tinkering with computers is fun, but my employer provides enough of that. Automating my house does not interest me. My robo vacuum is pretty much useless; it can only keep floors clean if I rearrange my furniture and lifestyle. Maybe those $2000 ones are better, but I'm not interested in finding out. I can vacuum a room in 5 minutes with my old-fashioned manual vacuum cleaner, shuffling furniture and rugs as I go, rather than take as much time shoving them aside in the morning so the robo vacuum can spend hours during the day, and then shoving everything back where it's useful when I come home. And last thing I want on a day off is to have to tell the vacuum and everything else to simmer down and switch off the automatic work day stuff. And if there were still kids around, there's more disruptions. So it goes with just about everything. Automated blinds? I open and close them based on where I am sitting and what the weather is like; I'd spend years fine-tuning any program to match my needs. Automated lights? Same problem, and sometimes I want them lower, sometimes higher, and I can reach a light switch faster than I can unlock my phone, open an app, and tap through several menus. As for tinkering with computers at home for home use, the projects I have provide all that I want. [Reply to this comment] A different perspective Posted May 11, 2025 4:19 UTC (Sun) by corbet (editor, #1) [Link] All I can suggest is ... wait for part two. I have no "smart plugs", no "smart speakers", no automated blinds, no robot vacuums. But HA has turned out to be quite useful anyway. [Reply to this comment] A different perspective Posted May 11, 2025 5:59 UTC (Sun) by wtarreau (subscriber, #51152) [ Link] (2 responses) I'm a bit like you but can imagine some use cases. For example in my home, the central heating control was very basic when I arrived, essentially often heating too much for no reason. Since I'm rarely at home I found it a waste of energy. I hacked my heaters in the rooms where I usually go to install ESP8266 modules to apply an offset to the temperature control. They also embark a LDR to detect light and infer my potential presence and share that info with other ones. With all of this I managed to cut my energy consumption by about a third, because the heating is completely stopped when I'm not at home, automatically restarts strong when I arrive, and it restarts at some hours late in the evening before I'm supposed to get back. I can even do a "touch /tmp/returning" remotely when leaving office if I get back earlier so that it restarts heating, planning for my return. Then I realized that if one day I move to a new house, it will be particularly difficult to explain that stuff to a potential buyer, explaining that I'm running Mosquito on an old WRT54G running a 2.4.37 kernel and controlled by bash scripts running on one of my servers... I've thought several times that HA might be an option to re-integrate all of this in a more standardized way. I have not yet made the jump because I expect it will be a lot of work for little short term gains, but that's definitely one use case I do envision. [Reply to this comment] A different perspective Posted May 11, 2025 7:42 UTC (Sun) by Wol (subscriber, #4433) [Link] > Then I realized that if one day I move to a new house, it will be particularly difficult to explain that stuff to a potential buyer, explaining that I'm running Mosquito on an old WRT54G running a 2.4.37 kernel and controlled by bash scripts running on one of my servers... Dunno where you live, but in a sense I'm lucky. We have a shortage of housing so a lot of houses get completely revamped by a purchaser as a matter of course. So telling someone they need to modernise the heating isn't a problem - there are enough bidders that it won't affect the price much. But I'm with most people here - so much of this is "tech for tech's sake" and I don't have the incentive to work out how it works. Plus, of course, so much is online and gets updated every six months - if it take me a year to work it out I'll just give up. Things need to "just work" and that's a description that can't be applied to a lot of today's tech. Especially if you NEED a smartphone - a full half of the people close to me (be it physical, family, emotional) can't cope with a smartphone. It's bad enough trying to get them to use a dumb phone! Cheers, Wol [Reply to this comment] A different perspective Posted May 11, 2025 10:54 UTC (Sun) by parametricpoly (subscriber, # 143903) [Link] Having a custom system is less of a problem if you expose a "dumb" hub that only exposes access to the devices in a somewhat similar way as Firmata. If your dumb hub provides access via serial, USB/serial, MQTT, HTTP, HTTPS, telnet etc. those are all standard protocols and it doesn't take that long integrating it with a smart hub. I mean most devices only do on/off. Sensors often just do simple triggers. Sometimes you want to provide adjustments 0-100% (e.g. brightness, curtains, sound volume etc.). Heating and PID (https:// en.wikipedia.org/wiki/Proportional%E2%80%93integr...) stuff is a bit more complex [Reply to this comment] A different perspective Posted May 11, 2025 3:07 UTC (Sun) by VersedBook0 (subscriber, # 172894) [Link] (4 responses) Actually I find that getting up in the middle of the night for a toilet break and having lights under the bed just come on and the toilet light on very dimmed and it all just turns off when getting back into bed to be really really nice, and no fiddling trying to find switches and stuff :) [Reply to this comment] A different perspective Posted May 11, 2025 10:56 UTC (Sun) by parametricpoly (subscriber, # 143903) [Link] (3 responses) Agreed, but for this you don't necessarily need a full blown smart home. A single adjustable light with motion/presence detection and/or RTC for adjusting the brightness level is sufficient. [Reply to this comment] A different perspective Posted May 11, 2025 11:40 UTC (Sun) by VersedBook0 (subscriber, # 172894) [Link] (2 responses) While I agree, at least in part, there is also the matter of the plumbing to achieve the required results. Continuous monitoring of said sensors, checking time of day then doing something, etc. All that does require an amount of scripting or programming of some sort. The Home Assistant system and its ilk provide all that at an easy high level. While maybe a bit much for this one example, In terms of my time spent getting this going I think smart home for the win. [Reply to this comment] A different perspective Posted May 11, 2025 21:49 UTC (Sun) by felixfix (subscriber, #242) [ Link] (1 responses) I have no problem getting up at oh-dark-thirty, walking ten feet to the bathroom, and flicking on the 4 watt night light. Muscle memory only takes a few nights to train. [Reply to this comment] A different perspective Posted May 11, 2025 21:56 UTC (Sun) by dskoll (subscriber, #1630) [ Link] I have a far easier hack. My bedroom window has a semicircular bit at the top that the curtain won't cover, so enough streetlight leaks in for me to see my way to the toilet. It does mean I need a sleep mask to sleep at night. [Reply to this comment] Debian Posted May 11, 2025 7:35 UTC (Sun) by pabs (subscriber, #43278) [Link ] I note that the Debian folks are working on HA packaging: https://wiki.debian.org/Python/HomeAssistant [Reply to this comment] Copyright (c) 2025, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds