But it's still a huge piece of work and deserves a lot of praise.
But it's still a huge piece of work and deserves a lot of praise.
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.
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
You can just write decorated functions in python.
(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
> 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.
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.
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 less "techy" than HA (no YAML files, no CLI), and UI first.
We have way less integrations for now, but are working hard on it.
Don't hesitate to try it and make us some feedback.
UI first means you have to build an awful lot of extra cruft to emulate parts of an already solid + flexible toolchain.
EDIT: I should mention that includes text + file based config too...
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.
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.
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.
[0] - https://heywillow.io
[1] - https://developers.home-assistant.io/docs/voice/pipelines/
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].
[0] - https://github.com/openai/whisper#available-models-and-langu...
[1] - https://about.fb.com/news/2023/05/ai-massively-multilingual-...
Last I looked, the industry was trying to roll out some protocols to block open source efforts.
Is there a plan to tackle that?
I generally look for OH mentions when discussions like this start up and am fascinated how it never seems to be mentioned.
In my experience it has its own rough edges, but its significantly more understandable, more stable and easier to get going.
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’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.
Hass is the great equalizer of home automation, difficult to script for non-programmers AND programmers.
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.
Making the UI is more involved but you have a lot of tools to get stuff to talk to each other.
It's pretty nice for what it is, but it isn't quite a HA-alike.
If you ever adventure yourself on robotics there's ROS. Without haven't ever used Hass I can guarantee you that ROS can make your hair turn green.
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.