Hass is the kind of software that has a lot of rough edges, but you use it anyway because there's very little direct competition. And every release feels like so much stuff has been finally polished, but then you deploy the new version and there's still a lot of stuff that feels or looks weird (the part-bad-UI-part-YAML automation). I have been using it for a couple of years now and I still haven't decided whether I like it or not.
But it's still a huge piece of work and deserves a lot of praise.
"HomeAssistant is the worst form of home automation, except for everything else." Eg the amount of work it takes to play a sound locally is upsetting. But once setup, it is rock stable - which is what really counts. And the number of integrations is impressive, it even detected my tea kettle which for some reason has bluetooth.
When I was designing APIs in this space that was our biggest issue.
How do we make this more easy to use. But still show everyone the things they need. You end up with a spaghetti graph to tie things together or some monster spreadsheet. How do you expose timers, locations, nodes, and comms together. Each with their own way of reading things. A modbus might have 64k locations to pick from more if you treat the spec in a weird way. Meanwhile that one off lightbulb from some rando Chinese company has 3 points but 60 hidden behind those 3. Then how do you get that in front of a user so it looks consistent.
When you do get it all working though it is usually fairly rock solid. You just have to keep an eye out for systems that think 'log the world and the past 3 years of data and sort it out later' that will obliterate a flash card. Some data if there is a missing hole it is not that big of a deal. Some is 'must keep'. Also logging should rarely be kept on the device except in very rare cases.
Then on top of all of that you have different market segments in home automation that all look the same on first glance. You have your early adopters. They have to change out their light switch every 6 months. They are totally down with it. Then you have pretty much the rest of the market. Which is that switch better last at least 10 years if not longer. Oh it fails because of some firmware update... garbage, toggle switch it is. They are not going to mess with it.
HomeAssistant is one of the better ones out there. Thera are much worse ones.
The tight integration with ESPHome is what tips the scale to the positive side for me.
Quite often I feel frustrated dealing with dozens of lines of YAML in HA's convoluted DSL and wish I could drop to a real programming language. However, for the ESP/embedded devices, it's usually the opposite. ESPHome makes it easy to avoid all the boilerplate and footguns of the C++ libraries for these devices
I really appreciate both HA and ESPHome. The only gotcha I have encountered with ESPHome involved lost data with higher sampling rates (1 sample/0.2 second). To this day I am not sure what the issue was. I had better results with arduino framework vs esp-idf. Apart from that, it really does make spinning up a new sensor so easy and the OTA updates are excellent.
I think the haas team have done remarkably well. Haas have some rough edges but rapidly improves with every release. Far better than some commercial software I use.
It's one of those pieces of software that was clearly designed by programmers for programmers. It's not user friendly in the slightest, there's no onboarding process, and it changes so quickly that half of the information you find is already out of date. It's very useful, but my god is it clunky
(And apparently destroys SD cards by design, but even that information may be out of date)
I compare it to something like RetroArch or Eclipse. Does everything you could ever need, but has 50 different menus to try and find it
> It's one of those pieces of software that was clearly designed by programmers for programmers. It's not user friendly in the slightest
Yet, as a programmer, I've never felt at home either. It's clearly designed by programmers, because for a long time it was just a messy collection of functionality, without design. This changed some years ago, and has now become that frankenstein-thingy that tries to cater to end users, but is not really there yet to be actually good enough, and continues to be something in between that works hard on finding its real form and identity.
And along the way it's break so often that it annoys everyone, yet still stays popular. Quite fascinating.
> It's not user friendly in the slightest, there's no onboarding process
> and it changes so quickly that half of the information you find is already out of date
Ironic: Could your impression be outdated? The last time I set it up it had a setup assistant and the core features (which are very narrowly defined) were super simple to use. Anything remotely advanced is still a bit annoying, though.
> It's one of those pieces of software that was clearly designed by programmers for programmers. It's not user friendly in the slightest, there's no onboarding process, and it changes so quickly that half of the information you find is already out of date. It's very useful, but my god is it clunky
I think this is an outdated view. for example:
Configuring integrations though a config file is depreciated, everything through the UI and it will convert any old yaml configurations for you.
> (And apparently destroys SD cards by design, but even that information may be out of date)
I think you're talking about hosting it on a Raspberry Pi.. It supports almost all hardware and even using the Pi you can boot from an SSD.
Would you be interesting in integrating with my project Willow[0]?
Willow supports Home Assistant, OpenHAB, and generic REST+MQTT endpoints today. With Home Assistant and OpenHAB we benefit from their specific API support for providing speech to text output and processing through things like the HA Assist Pipelines[1].
From our standpoint we handle wake word, VAD+AEC+BSS, STT, TTS, user feedback, etc. All we really do is send the speech transcript to the Willow command endpoint (like HA) and speak+display the execution result. Other than all of the wild speech stuff and our obsession with speed and accuracy Willow is really quite "dumb" - think of it as a voice terminal.
OpenHAB has something similar but it's significantly more limited.
STT is "just" a very heavily optimized (beyond even faster-whisper) Whisper implementation, so all of those languages[0].
For TTS we now use Coqui, which has a wide range of models with various voices, languages, etc. It even supports Meta MMS which has support for 1,100 languages[1].
I do feel like there's no point in making non-UI first home automation technology. It's not as though you'll be rolling it out across multiple environments.
> It's not as though you'll be rolling it out across multiple environments.
Definitely not for home use, but I could imagine a place for an open source server to manage a commercial property too. I'm admittedly a total outsider at property management, but I could imagine someone who operates several hotels, office buildings, or maybe even a school district wanting a building automation solution that doesn't lock them into a particular vendor. They'd have enough rooms and hallways with identical equipment that populating it via files, CLI, or an API might make sense.
Aside from easily rolling out (parts of) my home automation to multiple environments (like my parents home, office, etc). The real use case for non-UI first is that with home automation software you often have to roll it out on the _same_ environment very often. Be it a corrupted SD card, broken state after software update, database bit rot, hardware RMA, etc, there are many reasons state gets corrupted or lost. So you either need to rely on a backup (if possible and hope it's up to date and works with the version you have installed) or configure everything by hand, again and again and again, via the UI, step by step, hope you don't forget that one setting you didn't write down. I rather have my home automation setup be build and deployed reproducible from a (VCSed) source.
Ah yes agreed, but I was thinking more of an export/import mechanism, that can be version controlled, diffed, etc, than full on cli- or programming-first interactions.
I missed the manual config at first, and being able to quickly fix things, but it turns out it's not so bad, and I think because of:
1 - Most setups are done once
2 - Stability and quality has improved in recent years, and you don't have to fix or mess with it as much
That said, I very much like being able to edit the yaml for automations and the lovelace UI. I like being able to flip back and forth between visual and code from the UI itself. Best of both worlds, especially because there's a lot of automations that are like 60% copied from another one. Being able to use a text editor (that has autocomplete!) to change entity names as opposed to clicking through several layers of UI for each one is awesome.
My experience was the opposite. When I was first getting into home automation I tried OpenHAB first and just got frustrated, then Home Assistant and it clicked for me. I guess different software works for different people.
Competition is relative. You have mqtt, node red, ... You can piece together your own automations very easily using ready to use common components and some code.
I am sure most just use the components as they are and use their own automation stuff. Like my mqtt stick that has its own automation control built in. Mixed with Google home you nearly have full control (with many limitations I know)
IMO there is simply no need for a complex interface to control a few lights and power saving tricks.
I tried everything since arduino came out and HA is light years ahead of anything else, and as someone else mentioned HA works with ESPHome and let's you use all of the platform. For example creating a data collection tool that automatically integrates with Grafana HA has for data collection. Super useful and easy to setup.
I also have a love/hate relationship with HA. It has so many integrations I couldn’t imagine switching to some other controller, but I very much wish to only use it as a “backend”.
I’d rather code the actual logic in something that doesn’t take 20 clicks for a simple binary variable. I’ve been playing with Node Red and Pyscript which are both improvements but still not exactly what I want.
Yeah, I am perfectly capable of writing my desired logic in ten or more actual programming languages, but I'm stuck with writing imperative code in a serialization language.
Hass is the great equalizer of home automation, difficult to script for non-programmers AND programmers.
I'm still using my scratch built KaithemAutomation(Currently just finishing up a large cleanup of some of the almost 10yo code, new release soon) because the off the shelf stuff doesn't seem to support the Pi well on SD cards.
The core workflow is all about having scenes, which have a list of cues, each of which can have IFTT-like rules attached to it, among other things, like sounds and DMX lighting values, live mixing of multiple soundcards, and ESPHome integration.
I'm never quite sure if I should try to move to HASS or some other platform, or keep working on this project a few hours a week.... it's pretty much feature complete, just needing some cleanup to be sustainable and maybe a move to a proper CSS framework, so switching to something else always seems like it's not really worth it.
At the moment HASS seems like the big name in open automation, and I like using the standard big name for everything, but it doesn't seem like the best fit for what I want to do with it.
I wasn't a super big fan of Node Red, it gets messy in a hurry with ~30 nodes, and the data flow model isn't the best fit for things that are heavily state driven.
It's pretty nice for what it is, but it isn't quite a HA-alike.
I think fundamental problem of it is it being basically a monolith and is now hard to untangle that.
IMO better architecture for such "IOT HUB" would be a rule-engine that basically just takes code (embeddable language like Lua or outright WASM) and runs them against incoming events. Maybe add pluggable storage so the code can use some kind of persistency on top of it.
Then UI would basically be just a configuration interface for that rule engine. So to run high availability you'd just run the engine on 2 nodes and sync the configs, and configuration/dashboard/whatever else using it could run separately on "bigger" machines.
But it's still a huge piece of work and deserves a lot of praise.