We are making Gladys Assistant ( https://gladysassistant.com/ ), an open-source smart home software.
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.
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.
For technologists, DIY'ers and coders, CLI first or CLI parity means you can use common dev tools to build, integrate and track changes.
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...
Locking the ability to set up a smart home behind the ability to code and do a heap of DIY if a big part of the problem.
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.
> 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.
That would be fantastic, it's true.
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.
Very nice!
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/
Nice! What languages do you support? (for STT & TTS)
Thanks!
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-...
Ok! And what kind of hardware do your users run on? Do you get great quality of detection like Google Home/Alexa speakers?
Nice work
Last I looked, the industry was trying to roll out some protocols to block open source efforts.
Is there a plan to tackle that?
Is in packaged in Linux distributions?
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 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.
Oh you really don’t want to see HA’s code… to write even a basic plugin is insanely over-complicated and clunky.
> 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 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.
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.
For automations, check out pyscript, https://hacs-pyscript.readthedocs.io/en/latest/
You can just write decorated functions in python.
I ditched the built-in YAML automations for AppDaemon a while ago and have no regrets.
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.
Isn’t HA open source? I wonder if it would be possible to build an alternate automation running that runs in a given language.
There's AppDaemon/NetDaemon if you want to write automations in python or c#, but very few people use them, because it's massive overkill.
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.
node-red + mqtt + zigbee2mqt + tasmota is what I went with. Happy so far.
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 quite liked node-red for automating things. Though that's mostly because programming in yaml sounded like a red flag when it comes to automation.
Making the UI is more involved but you have a lot of tools to get stuff to talk to each other.
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.
OpenHAB?
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.
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.
"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.
> Hass is the kind of software that has a lot of rough edges
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.
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.
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.
There's a decent amount of friction for a European resident trying to use HA.
The landing page has two products with pricing in dollars and nothing else w.r.t. hardware. Click "Getting started" and there's still no sign of what to buy. Click "Installation" and then there are 9+ platforms (and multiple subplatforms) but no quick and realistic comparison of features or pricing. Is a NUC12WSHi3 a better deal, more energy efficient, and better equipped to handle wake words than an ODROID-M1 4GB/16GB-uSD/256GB-NVMe Addict? Will I need to buy an add-on microphone? Do I need just one box/bridge for multiple stories of a large house and then some supporting hardware? Can I finally throw my Amazon devices into the electronics trash bin at Penny?
Even among HA products... It looks like I can get a Green from the official German supplier for 110 euros, from a different European vendor that I search on Google Shopping or Idealo for 103 euros, or from Slovakia for around 100 euros.
It's all of the inconsistencies and friction that keep me from using HA. I have a solid theory on Linux distros: the landing page is a good indicator of how much of a pain it will be to install and use. I suspect that's also true with HA.
8fingerlouie mentioned Homey. When I go to that landing page, there's a flag to switch region and a big Buy button. It's only a few clicks to switch to their non-Pro bridge, and the pricing is consistent on the page and with any vendor I search online.
-----
In any case, I'm not using a Home device until they remove Google from the wake word. I'm not using Alexa for its invasive behavior (most notably Amazon Sidewalk) and because the Philips skill mysteriously broke a few days ago, confusing the hell out of family members accustomed to a house full of working Philips lights with customized Alexa phrases. I'm not using Siri or Cortana ever.
I'd love to move on to a better platform and would even pay a premium to get an industrial controller like my workplace. Such a platform either needs a dedicated installer-maintainer or exists only in my imagination.
I'm convinced Amazon is going to phase out Alexa because it's not making them money. After visiting the Home Assistant website and reading these comments, I have a mixed reaction. Can someone explain by examples what it is and how it works? I see some videos where people are raising desks and turning on lights. How does that work? Besides Green or Yellow (not entirely sure what the differences are), are there modules you have to buy? Can I control it from a phone? Can I control my Alexa outlets with it, or do I have to buy all new outlets? If there's a "cloud," how does that align with the goal of privacy and everything being stored locally? What is a "YAML" file and why would I need to mess with it?
And can I talk to it like Alexa? Half the site seems to say yes, the other half no.
I'm probably going to hold out for something more friendly that inevitably will come out just as Alexa is being lowered into the grave.
There are two main approaches to voice with Home Assistant:
1) Their native Home Assistant voice stuff combined with either their ESPHome project or their "voice satellite" software implementations that run on a Raspberry PI (or whatever) with any microphone attached. Either of these provide wildly different results. It turns out you can't just slap a microphone on something and get quality voice and speech recognition from 15 feet away (or even much less) under typical conditions. I learned this the hard way many many years ago.
2) My project Willow[0].
Our approaches could not be more different in terms of implementation and each has advantages and disadvantages. That said, between my 20 years of experience with the intersection of voice, networks, etc and thousands of users using Willow in the real world for six months I certainly believe our approach is substantially better in terms of a user experience competitive with the commercial big tech stuff.
HA voice is essentially at initial release and they will undoubtedly be making improvements but my experience (confirmed by initial user feedback and my own testing) tells me they will probably need a complete re-architecture at some point. Basically, I took my 20 years of experience with this stuff and combined it with "inspiration" from the big tech implementations and made it local and private.
I love Home Assistant and have very deep respect for the team but they clearly don't have much real-world experience with voice (which is a very unique animal). Their architecture and the end result demonstrates that.
I want to be very careful to not sound overly critical or harsh but decades of experience and the resulting accumulated knowledge makes a huge difference. They only just started learning voice and it's very painful process.
[0] - https://heywillow.io/
This is very helpful, thanks. I am grateful for your explanations of the voice aspect - Amazon has kept all of this under wraps so much so that I didn't understand all the difficulties until I read your site just now. I can guess at the difficulties based on how often I have to repeat simple commands to Alexa, or "normal people bread" (my fam's word for non-grain, non-healthy bread) gets changed to "normal maple bread," things like that.
Practical question - are there plans to commercialize a turn-key Willow setup? Basically, I want an Alexa setup without the dependence on (or financial expectations from) Amazon. Key features:
* Few terminals, maximum reach. I want to be heard without having a cube every 10 feet. I'm okay shouting if need be. The ability to whisper is nice, too.
* Reminders, timers, alarms, schedules. Alexa, set egg timer for three minutes. Alexa, remind me six months from now at 8pm to change the furnace filter.
* Cloud-based lists: shopping shopping shopping. Alexa, add milk to the shopping list.
* Home automation: plugs, lightbulbs minimum. Thermostat nice to have.
* Routines. Alexa, turn on the living room lights. Alexa, fix the TV (occasionally the HDMI splitter freaks out and quits working; "fix the TV" turns off the power plug, waits five seconds, then turns it back on again.)
* Music: ability to play Spotify. Nice to have is "play this everywhere" capability.
* Basic math/language capabilities: Alexa, what is one point oh three raised to the 30th power (e.g., for calculating inflation over 30 years)? Alexa, define opprobrium.
* Other integrations: bluetooth, especially for speakers.
As for the other Alexa features - I only "reorder" things from Alexa. I never shop for new things, because shopping requires me to read reviews, see alternatives, who else bought what else, visit websites, and so on. I think Amazon missed the mark here - or rather, the product team promised senior management that the shopping experience would be easy, but it's not. Fail.
(If they charged me a nominal fee for Alexa, I would happily oblige. Sssh, don't tell them that.)
I also am itching to try a Raspberry Pi temperature probe, and somehow tie it into my outdoor pool heater.
My pleasure!
If you have a lot of time and patience you can read my very long recent response[0] to a user asking about this where I go into arguably far too much detail. For context Wyoming is the fundamental protocol for the entire Home Assistant/ESPHome implementation.
In terms of commercialization, yes and no. Speaking of experience and background - the real genesis of Willow was three years ago when I was approached by a large publicly traded company in the healthcare space to implement a voice assistant for their use cases. The underlying and fundamental technology just wasn't there yet and it never got past PoC stage.
That failure really bothered me. Earlier this year everything seemed to really align and thus Willow was born. Our monetization strategy is where this all started three years ago - commercial and "enterprise" use cases. It's the only market I know and have experience with.
This is actually relevant to my comments about fundamental approach and architecture. Willow was designed for this market and their use cases which needless to say has substantially higher expectations than the more-or-less consumer/"tinkerer" market. I will NEVER monetize consumer/home users directly (again, I don't understand the market) but they get to benefit from our substantially better approach.
All of that said I'd certainly be interested in partnering with someone to bring Willow to the consumer market commercially. I've spent my entire career with the "sales cycle measured in months with a big customer for a lot of money" approach, not the "tons of consumers paying $5 a month" approach.
Everything you're describing is what we're currently focusing on. We feel we have the fundamentals of voice and audio pretty much nailed. Then the next question becomes "Great, I have performant and accurate speech in and out. What do I actually do with it?".
Taking the speech recognition transcripts and matching them with flexible grammar, functionality and application routing, etc is the next significant challenge. We have some of our own logic internally that we will be building out but at this early stage we heavily rely on the command processing and intent recognition from our supported command endpoints.
Nothing you're describing is impossible (of course) but Alexa (for example) has an eight year head start. It's going to take a while to reach feature parity with that. Our intention is to not only match Alexa functionality but also far surpass it by leveraging the entire open source ecosystem.
[0] - https://github.com/toverainc/willow-inference-server/discuss...
I know it's difficult, but is there a way to gather feedback from the user when a voice command is below a certain threshold of understandability? Or to build a context catalog, such as time of day specific types of commands are expected?
I think these two areas could be holding the commercial voice assistants back, since the majority of bug reports on the Google Home and Alexa subreddits are people complaining about being misheard.
I've been thinking about this a little recently. Raw brain dump incoming...
The problem with intent matching now (say with Home Assistant) is that the transcribed speech more-or-less needs to exactly (character for character) match the defined entities (names of lights, etc) as well as the grammar and structure expected by the intent definitions.
Something as simple as a hyphen in "turn-off" currently breaks the matching. That's an easy one to fix, I'm just providing it as an example.
In terms of addressing this, I've kicked around a few ideas:
With Home Assistant at least we can pull all of the entities and supported intents. We have a variety of options to do all kinds of fuzzy matching with these now known phrases. We'd fix the transcription based on something like nearest neighbor (more or less) and send the clean command to HA. There is also a way to handle this in the prompt to Whisper.
A literal text embedding model with nearest neighbor search seems kind of ridiculous but I've been curious about it. The same could be done at the audio level by essentially making an embedding of the Mel Spectrogram of the actual audio (which we could have available) and searching on that.
There are also approaches with a variety of NLP implementations, language models, etc that could be combined or used separately.
We've also considered some more manual approaches - things like an interface that logs sessions where you can (after the fact) find a session/command that went wrong, and basically map it to what you wanted. While this may seem tedious we get some reports that our speech recognition consistently mis-transcribes a given voice command. Implementing a lookup table to correct for this is simple. The biggest challenge to this is how to deal with the UI/UX aspects.
> Basically, I want an Alexa setup without the dependence on (or financial expectations from) Amazon
Amen.
+1 to timers, schedules, integration with a lighting bridge or even kitchen appliances e.g. Home Connect, custom routines, music (including Bluetooth and/or TuneIn), line out (so I can connect my own speakers), microphone relays that I can put all around the house instead of owning 5 or 6 RaspPis and the associated 15 to 30 watts
Better than math, for me, would be a Wikipedia summary readout that voices the first paragraph (or a reasonably defined "summary length") from simple.wikipedia.com, although metric/imperial conversions are also very handy.
Weather integration would also be delightful---including a way to tie this in to reminders e.g. "bring the plants indoors tonight", "remember rain clothes for riding home this evening", "tomorrow is probably the last good sled day until next winter"
Oh. And properly bilingual. We have a Philips light named "Turtle". Alexa absolutely cannot handle this name if the input is set to either German or German/English.
> microphone relays that I can put all around the house instead of owning 5 or 6 RaspPis and the associated 15 to 30 watts
I've always found this approach odd and this is one the reasons we primarily target the ESP-BOX-3 from Espressif[0]. For $50 you take it out of the box, flash from our web flasher, and stick it in your house. Given that it's ESP32-S3 based total power consumption is somewhere in the 100 milliwatt range. Once initially flashed all upgrades are done over the air (with < 5MB binaries) from our web management interface. All configuration changes are also centrally managed there. Make change, click "Save and Apply", goes live on any number of associated devices in seconds.
The thought of managing half a dozen full Linux machines (Pis) just to get audio for stuff like this boggles my mind. Additionally, the audio quality is significantly better with the ESP-BOX-3 vs Pi, etc because the entire device and software stack is holistically engineered for high quality far-field voice capture. Acoustically tuned enclosure, dual microphones, acoustic echo cancellation, blind source separation, voice activity detection, wake word, etc.
As I like to tell people - if you think you're going to slap a random microphone together with a Raspberry Pi and compete with Alexa you have another thing coming. I go into greater detail in this issue[1].
Getting high quality audio is step one. Step two is accurate transcription of that audio. Steps 3 - ? are what you're describing. We know what you said, now what do we do with it?
Now that we feel steps one and two are more-or-less nailed steps three and beyond are our next focus. The good news is the final step is of course user feedback and we have that handled with text to speech and output on the BOX-3 LCD display. It's just currently the wide gulf in between these that needs focus.
In short, our mouth and ears work well. It's the brain that needs work.
[0] - https://www.espressif.com/en/news/ESP32-S3-BOX-3
[1] - https://github.com/toverainc/willow/issues/317#issuecomment-...
If only you had a device that had access to like a giant library of knowledge. I don’t know what we’d call it, but for the sake of argument let’s say the world wide information library. If only you could then use that device to pull up a card catalog and go find the information you’re looking for.
The first thing you should do is learn to organize your thoughts into coherent questions.
Nonsense. HA is software not hardware. Get any pc, raspberry pi, whatever, install, follow the pretty interface instructions. I have no idea why you think European has anything at all to do with that.
> then there are 9+ platforms (and multiple subplatforms) but no quick and realistic comparison of features or pricing.
No. It is simply "what hardware or OS do you have? Click here".
I don't want to run HA on hardware I already have. I want to put a small box with new hardware on my bookshelf where my Google Home used to live until it was replaced with Alexa, which got removed three weeks ago. If HA is not hardware, why do they have multiple hardware platforms for sale? And what is actually the best value for a dedicated HA device? That is unclear. Why would you need more extensible storage or a variety of RAM possibilities for HA? That is not clear from the first few pages.
I'm sure I can take a spare RPi from my bottom desk drawer and get HA running before lunch tomorrow. I also know that's a waste of a RPi if there's purpose-built hardware (and by that, I mean power profiled, no useless Arduino-layout pins, no SSH configuration, ideally no manual installation at all). If I'm not around and HA stops running because RPis sometimes have weird clock issues or someone closes the power cord in a desk drawer (RIP old laptop) or a service was misconfigured or SD flash storage sometimes goes haywire, are my family members going to be in the dark, literally, while I'm away?
A site that doesn't spoonfeed you the step-by-step, dummy-proof onboarding (a la Hue) usually indicates that the product will require equally esoteric maintenance.
My partner only thinks of Raspberry Pi as a food, and I know of it as a collection of known and yet-to-be-discovered vulnerabilities that runs about 300 mA too much all the time. I have a NUC. It's a royal pain in my ass because it's my primary device and if you don't have a very precise combination of drivers and BIOS settings, it overheats and/or refuses to wake from sleep. (It's actually a replacement; the first overheated one too many times.) I will never, ever run HA on a NUC.
Same deal with Docker: Every time I touch containers, I discover the Who's Who? of certificate errors, "jessie/bionic were last in vogue 5 years ago; no version pin, no run" (yesterday's error), "No connection could be made because the target machine actively refused it", system clock is wrong, etc.
I'm not so cruel to subject my family to opening up a terminal or finding the right manpage anytime the smart home starts acting dumb.
-----
As far as residency mattering... Dollars are on the home page. Only after clicking a few links to buy can I find a variety of countries for buying a Yellow or Green, but the place where I live is not actually the best option, price-wise. Unless someone from mediarath is going to phone me up and walk me through the setup or throw in the perfunctory bag of Goldbären, there's no point in paying extra when the guy a few borders over will ship it for less.
People in Denmark seem to be getting screwed worse, at 126 euros per Green. It's one thing if this was an American or European product, but they're all COO China (and it's still not even breakeven to buy bulk from the Chinese vendor, it would be the U.S. price before tax and customs---ultimately more than the Danes).
I bought a headless computer from Amazon, installed Ubuntu, and added HomeAssistantOS. Been running for about 3 months with no maintenance.
I'm European as well but I fail to see what's preventing you from buying hardware and deploying HASS.
There's so many SBCs available now, in ARM or even x86 form (Zima Board).
Pick one and deploy HASS on it. Pricing in USD be damned.
_I_ can buy hardware and set it up. That does not mean it's easy to use for the whole family when I'm not there.
I'm in Europe and this hasn't been my experience _at all_. I recently started using HA. I bought a HomeAssistant Yellow box which was very easy and got delivered to me speedily from within Europe. I set up my device and the web interface allowed me to link it to their cloud offering, where I could subscribe to the plan in euros - because it knew I was in The Netherlands. But it also works just fine without the subscription.
Good to know. I wasn't aware there's a cloud. From what I can tell, Yellow wouldn't be necessary if I have a Hue bridge. I definitely don't need GPIO. Most important to me is usability by others, so what would be the most inconvenient failure modes?
> Even among HA products... It looks like I can get a Green from the official German supplier for 110 euros, from a different European vendor that I search on Google Shopping or Idealo for 103 euros, or from Slovakia for around 100 euros.
> It's all of the inconsistencies and friction that keep me from using HA.
Come on man that point is just bogus. Samsung TVs, Noctua Fans or any other conceivable good are also sold by multiple vendors with different prices, yet no one complains about that being "inconsistent". Especially not to Samsung/Noctua/whoever
I have to send a buggy audio interface from Munich to Czech Republic, because that's where I bought it for cheaper. For one, there's the environmental factor of sending shit from A to B to C. Second, it's a major hassle waiting a week instead of a day for each leg of shipping.
I'd rather buy local but not if it's costing 10% more. And I'm quite certain there are people who grumble that they need to buy a certain threshold of goods at Costco (perhaps the most prominent price discriminator) before a membership is worth it.
That's a feature not a problem. It's free software you can run it anywhere you like. And they give you some advice and "ads" which stuff to buy which it runs best one.
I just run it myself on an old laptop I had lying around, you don't need to buy anything.
HomeAssistant is software and is free. All the hardware that you see on that page are ads.
I gave up on Home Assistant, it required too much tweaking of configs between releases. I took inspiration from https://github.com/stapelberg/regelwerk instead
I don't know where all the frustration with HA is coming from. I've only started with it last year and so far the experience is amazing. Not only that everything just works with it, it's also so simple to create fun automations, and recently I've even built a little watering system with a Pi Pico, and integrating it with HA to show graphs and controls was a breeze.
Also, literally can't recall one time I had to update a config when upgrading HA. It's the one piece of software I'm never worried when pressing "update".
I've only recently (less than a month ago) started to use HA and I have polar opposite impression from you.
I gave up on updating because the 2 times i updated the HA Core package and the OS most of my integrations broke. The first time i bothered changing the config. The second time I decided to rollback and keep everything as is.
Maybe the issue is that you used the "Core" installation method which isn't a fully managed installation and only really there for "advanced" use cases. It has this warning above the installation steps:
> This is an advanced installation process, and some steps might differ on your system. Considering the nature of this installation type, we assume you can handle subtle differences between this document and the system configuration you are using. When in doubt, please consider one of the other installation methods, as they might be a better fit instead.
I use the container installation method and it's usually as simple as updating the version number in Docker Compose and restarting. I'd imagine the full OS image is even easier and more stable.
I use what they recommend: I installed Home Assistant Operating System on a Raspberry PI 3. Which still means there's an OS and there's HA Core.
> Home Assistant Operating System: Minimal Operating System optimized to power Home Assistant. It comes with Supervisor to manage Home Assistant Core and Add-ons. Recommended installation method.
I tried on purpose to do everything as 'basic' as possible because I don't want to spend time making sure it keeps working.
no idea why it's recommended to install manually; I'd recommend docker every time. currently running on docker and upgrading was indeed just pulling new images (didn't even have to tweak the compose file, just docker compose pull). There's been a few helpful UI messages about outdated integrations in the config (e.g. workday detection moved to UI config, used to be yaml).
Iirc Home Assistant Operating System does use Docker. It's a bare bones Linux distro built with buildroot that basically just runs Docker containers
I don't think the problem is how to update: it's easy enough in the interface, it just works. The problem is whether after the upgrade you suddenly don't see the heater anymore, or another device stops working.
Ah ok, I misunderstood then. I presumed if you used the OS installation method then the upgrade was done from within the web UI, but I maybe have misunderstood that too.
yep, through the UI. the update went fine, the system afterwards didn't work properly though.. :(
> I'd imagine the full OS image is even easier and more stable.
It notifies you when there's an upgrade, you just click "Install" in the GUI.
That said, every time I update it the disk image grows by like a full gig. Haven't figured out where that's going so I just don't update it anymore. It's running on a minimal headless computer and doesn't have enough space to keep doing that.
Yeah like others suggested, maybe it has to do with the installation method. I'm using a Home Assistant Blue. It all came configured, I'm clicking "update" a couple of times a month and never had the slightest issue.
I think it really depends on when you entered the ecosystem and the maturity of the integrations you're using. HA has some contribution standards but you can get plenty of "I made this in my freentime and upstreamed it" integrations that end up going through major renovations. Sometimes vendors take notice and also weigh in.
Additionally, if you got in ~5 years ago when it was pure yaml, it seems a couple times a year there's breaking changes where more yaml is ripped out and manual reconfig is necessary (it'd be nice if it just migrated the config for you)
> I don't know where all the frustration with HA is coming from
Because it's breaking all the time. They have a big surface, and integrations are changing fast, this is natural. But at the same time they are also eager to change and break things on their own software, and this all accumulates to a messy experience for many people.
It’s not natural. I use both hA and Openhab with about 20 integrations/addons and HA breaks more (hello zwave}. Openhab almost never breaks on an addon level. If it breaks at all it’s in the core and patched quickly.
How HA has handled ZWave is my only complaint with HA.
If you only had it for a year, you may not have seen it yet. I had lots of configs setup, then I did not have it running for a year or so. Trying to make it run again on the latest version was frustrating. I want to set up and forget to the largest extent possible.
I've been an HA used for quite a while. I used to maintain my own venv and religiously update my yaml with each release to keep up with the deprecations and changes. A year or two ago I finally decided to learn about Docker by moving my HA install into a docker-compose setup (and migrate my zwave config to zwavejs), and since it felt easier to rollback in cases of breakage, I have subsequently been updating whenever I feel like it and "just see." Surprisingly, while I get a lot of warnings in the logs, I find that my fairly complex setup (zwave, zigbee, mqtt, tasmota, ESPHome, custom 433 RF over GPIO, custom NRF24L01 over GPIO, BLE, webhooks, iOS, and a custom Alexa integration via fauxmo) continues to work flawlessly.
I realize that I'll eventually have to deal with the tech debt that I'm accumulating, but it's been really surprising how good hass has gotten at auto-migrating configs and dealing with neglectful users such as myself.
Once I switched to a docker-based setup, this has been the polar opposite of my experience. It really took away the pain of a manual setup, dealing with python etc.
My update process has been the following for about a year, with zero issues:
- Create a backup - Update all HACS add-ons - Update the docker image and restart
I've never had to restore a backup. I do wait about a week before updating to see if there are some really breaking issues, but so far I've experienced none.
I haven't really touched my YAML in a long while, especially not for anything release-related.
Case in point: I just did the update that TFA mentions, and is was as simple as running `docker-compose pull && docker-compose up -d`. This is on an install that has 20+ different integrations, 30-40 "devices" (some of them are virtual) and a lot of entities.
This has been the case for the last 2-3 years at least.
> it required too much tweaking of configs between releases
I’ve been using it for a long time, including one switch from rPI to a Proxmox VM. I had to manually change the config once or twice, and that was several years ago before they decided to clean up their userfriendlyness.
I want to use this space to instead praise publicly Home Assistant, it's IMO one of the biggest and most-useful opensource project out there, it's very professional and it let you do thing that are simply unthinkable with any other "smart hub" from a proprietary vendor. I can control a wifi device with a zigbee button, use an NFC and scan it with a mobile phone to execute some action in some software that doesn't even know what NFCs are etc etc etc.
It also permits you to build a real "local-first" home automation system, which is the only way a home automation system should be, ever.
Lots of negativity in here. So this is nice. I use HA at home and it's nothing short of amazing. I primarily use Zigbee devices and they all just work. I pay Nabu Casa for the external access and Google integration. I look forward to replacing my Google Homes with HA as well.
I don’t understand the negativity at all. HA rivals or exceeds commercial automation systems like crestron, RTI, etc. clearly those people don’t have any industry experience. I’ve generally never had an issue with HA beyond my own fault, like a buggy integration.
Home Assistant is an amazing project. I use it a ton, and I deeply appreciate what they've done.
HOWEVER, Lovelace specifically is pretty terrible. Having used Grafana extensively, trying to use Lovelace to arrange a UI is so far backwards that it's constantly grating to try to create or modify dashboards. I really wish there was a way to use Grafana as the UI and embed cards as panels. The ability to drag and drop, resize, and move UI elements would be a godsend, but instead it feels like I'm writing Tk-style UI arrangement in yaml, and it's awful, so I do it as infrequently as possible.
I agree the UI can be improved a lot but in my experience a truly well done smart home does not need a lot of UI. I have automated pretty much everything and only use Grafana to show some data. If you actually want to include Grafana panels in Loveloce... that actually works. I described how to do that on my blog here if you are interested: https://thesmarthomejourney.com/2021/05/30/add-grafana-to-ho...
Lovelace is pretty terrible, 1 hint I can give is to use vertical stacks, they're much easier to deal with for organizing where you want components in a given stack, then if you wanna move a component between vertical stacks go to the yaml view and cut it from source and paste it in the destination.
It's annoying to have to do a workaround like that but it makes it bearable at least.
On that I agree, giving what's possible with opensource UIs like Grafana's, it could be probably borrowed (I mean, the whole JS code) in Lovelace as well. But I guess there is some debt from early versions that makes that more complicated.
That’s true. Lovelace needs js and css to look pretty. Most dashboards are terrible. I hope they dump it
I’ve never seen Crestron or RTI used for commercial building automation, aside from Crestron lighting controls on a rare occasion. Crestron is mostly an A/V company with a lighting controls line as far as I’m aware.
Building automation is owned by Johnson Controls, Carrier, Siemens, and Honeywell. There are some smaller manufacturers around, but those four plus Trane sell the vast majority of commercial building automation systems.
I manage electricians that wire up building automation systems, for what it’s worth.
And to be honest, knowing what I do about commercial building automation, I don’t see why you’d want to automate your home. If I was going to upgrade the lightning controls in my home, it would all be local non-networked controls from Lutron. I’m not sure what you’d monitor on your HVAC system.. do you really need to know what speed your furnace fan is spinning at? Most home HVAC systems aren’t large central boilers/chillers that send chilled/hot water to terminal units that can call for more heat/cold, a furnace can be controlled with its factory controls and an external thermostat.
Nope incorrect. Crestron and rti offer end to end solutions for whole home automation including the commercial space. Clearly you don’t care and/or get home automation, no skin off my back. It’s not for everyone
The negativity is because it's a free project that competes with the thousands of home automation startups.
Is there a beginner non-coder friendly HA “getting started” guide that someone here could recommend?
I’m interested in investing in an ecosystem of smart switches, blinds, thermostat and music that is future proof and I can take with me as I rent
Have some experience with ecobee and smart switches and trying to get onto Airplay 2 currently
HomeAssistants official plug'n play solution is HomeAssistant Green: https://www.home-assistant.io/green
It's basically a mini computer (sbc) with homeassistant preinstalled and ready to go.
Do expect that HA will expect some attention every few months. It's not a "set and forget" thing.
One of the things I'm really surprised by about HA/Nabu Casa is the complete lack of an LTS branch/releases.
Things related to homes are measured in years or decades. HA has gotten better about it but there are still occasional "cross your fingers and pray" scenarios when doing upgrades because every single release combines new functionality, fixes, breaking changes, and introduces new issues (of course).
People come to rely on things like their lights working and upgrade management is a tough spot - "Oh this integration broke because something else changed an API so I need to upgrade but let's find out how much time I need to update my config and hunt down any other issues".
This is one of the reasons things like Lutron are so expensive. You can have it installed and come back to the house 10 years later and everything will generally work as it did a decade ago.
For things like Nabu Casa cloud and their own hardware I'm sure plenty of people would pay a fairly significant premium for a subscriber-only LTS release that balances HA power, local, and flexible with Lutron user experience.
That said open source monetization is tough, and consumer monetization is as well. Combine the two and it sounds like a complete nightmare to me.
I think the answer to this is generally to pin to a working version and expect to upgrade once a year unless there's a security patch.
I think the answer the HA folks would give is to point out that they are still under very heavy development and "longterm stability" just isn't something that the project has reached in a way that supports LTS. I don't think this answer is wrong - HA today is amazingly different than HA from two years ago or three years ago.
It is painful and it is why I do caution people that adopting HA means some regular investment in tooling around with it on occasion. There's a big gap still before it's ready for set-and-forget non-technical audiences.
In a way HA is fundamentally an operating system for your home. It does target more technical users than Joe consumer but not by much in the grand scheme of things, especially as they intend to make it more and more 100% web driven, sell "plug in and go hardware", etc.
The plug in and go hardware is interesting because when you think about it a user who is intimidated to flash an SD card and stick it in a Raspberry Pi is going to have quite the shock when an upgrade eventually becomes necessary and they encounter the challenge that is trying to upgrade even a many months old HA install (forget about years).
As they target more and more users of less technical ability and sophistication this is going to only get worse and worse. If you look through this thread even the HN crowd (which leans heavily technical) is saying things that essentially come down to "the last thing I need in my life is more time spent on Github issues and random forums". Many of them end up going back around to "full home luddite" mode because they just can't stand to have to debug a light switch.
I appreciate this all too well. Many people who know me (their nerdy friend) are surprised I use iPhone, Mac, etc. I simply tell them something like "when I spend all day doing the hard tech stuff I have to do I need to be able to turn that part of my brain off and use something dumb". When I'm checked out and burnt out yes please give me the Fisher-Price experience that is the iPhone.
The issue with your upgrade approach is the same thing as all rolling releases - the more time that goes by, the more likely an upgrade is likely to break things even worse.
If you peruse the HA community forums, reddit, Discord, etc you will often see advice like "if you're not going to upgrade every month when you do upgrade do it progressively through each release", which is still and arduous and very time consuming process.
I opted for the Home Assistant Yellow, PoE version. It has built-in zigbee support and one less cable to deal with, no DC power cord and brick.
Seconding this. I was able to just run it with docker compose on a cheap mini PC and it chugs away happily, interfacing with all manner of devices (Phillips/Lifx/IKEA/Airpurifier/Bunnings brands). Only gets tricky to set up devices when you're dealing with some hostile cloud based gadget that doesn't want to play nice.
Unbelievable it can all be controlled offline using Siri on an iPhone, or other voice assistants.
It can even display your electricity consumption by counting the LED pulses on your smart electricity meter that fires every 1000th of a kw/h, only takes a cheap ESP32 and a photodiode: https://github.com/klaasnicolaas/home-assistant-glow
Such a wonderful project.
>Unbelievable it can all be controlled offline using Siri on an iPhone, or other voice assistants.
Does your iPhone need an i ternet connection for this to work?
No, just WiFi. Your HA server acts as a HomeKit bridge and exposes its entities to the iOS Home app.
Yep, I'm relatively new to Home Assistant but love it. Combined with ESPHome, I've got most of the lights in my house controlled (via switch changes, not smart bulbs), and my all my air conditioners via the MHI-AC-Ctrl project[1,2] (which is fantastic - ordered the boards from JLC-PCB, parts from Ali-Express (AUD$2.50 ESP8266 boards), told ESPHome to program everything and plugged them into the ports and...it all just worked!).
Just got a Mitsubishi Electric (which is different to MHI) and a Daikin at my parents house to get online - but code for both exists and I suspect the MHI boards can be reprogrammed to fulfill the role without any hardware changes.
It's incredible that the future we wanted in like, 2010 can be had and had without selling your soul to the cloud: I can leave the house, and turn off all my lights and AC's while walking out the door, or get notified if I've left my garage open - without a single cloud provider dependency, all open-source.
EDIT: And yeah...I'm starting to eye anything which has a required cloud connection as "maybe I should just crack that open and see if we swap an ESP in..." - haven't done it yet.
I've tried getting into Home Assistant a few years ago, but it was right at the switch from declarative yaml files for (almost) everything to most of the stuff being set up via the UI. I would love to give Home Assistant another shot - is that still the case, or is there some way to set up the Home Assistant config via code?
All the config can be done via YAML still. The UIs are just another option that makes it easier, as far as I can tell the UIs just build the YAML.
This is false. While you can set a lot of things through yaml, some like setting the MQTT broker have to be done via the UI.
Ah interesting, I didn't realise that! I often drop into the YAML to configure Automations, etc. I'm not using MQTT at the moment.
Yes, automations and UI can still be done using yaml (and I don't think they plan on dropping that - it's very useful to be able to put that on version control). It's mostly for configuring integrations that they've dropped the yaml (annoying if you're trying to set it up with NixOS or something, but the home assistant maintainers are unusually aggressive against distro packages anyway, especially for nix...)
I used to be annoyed by the push from yaml to ui. I wanted my config to be version controlled, and I wanted the power that I though text based config gave me.
However, it turns out it's really annoying to use text based config for most things. Primarily because integrations can't edit your config, so you have to do a lot more manual migration of config. Yaml also doesn't have any proper ide support, so it's an annoying loop of restarting the app and staring at logs looking for typos.
And finally the version control was useless because so much of what I wanted to keep was state, which can't be in config.
I've recently realised that I only actually needed the complex rules and UI to be in code. And they still are: now through the ui with instant validation.
I'm very much in the same boat as you here I think. I loved the idea of version controlled config and accepted the edit/reboot loop as that was the only way of doing it back then. It does seem though most of what was in config does live more naturally in UI, a great example is editing a scene with realtime feedback on the actual devices.
I do still periodically go into the config folder and do a bulk 'bump' commit, though given the config is likely useless without the state of the database I don't know if this is ever going to be useful. Perhaps having some history is good in case a complex automation is lost but still quite limited.
Isn't Yaml a serialization format? Seems like it shouldn't be a big deal to read it into a live object, remap things and then write the updated config back out.
>Yaml also doesn't have any proper ide support, so it's an annoying loop of restarting the app and staring at logs looking for typos.
Since YAML is a superset of JSON, I highly recommend converting[1] it to JSON, and then just treating it as a JSON config file.
1: For this, I use yaml2json (npm yaml-to-json)
You can do most of the setup right from the UI nowadays. I rarely resort to yaml-files, and if I do it is because the integration is old (and probably not that many that uses it - I can think of two integrations on top of my head that I needed to configure with yaml, traccar for tracking my bike and my local public transport organization) or it's something really special special (I have a thing that calculates the block of the cheapest two hours every day to schedule my dish washer, that was tricky to do OOB in the UI).
Otherwise it's pretty straight forward nowadays!
Most of the YAML-configuration has been deprecated and is now in the process of being removed. With the exception of manually-configured MQTT entities and some database configuration, everything is mostly done through the UI now.
I was a complete beginner and had a hard time setting it up years ago since I didn't know much about it. Here's how I did it:
https://www.amalytix.com/en/blog/home-assistant-with-conbee-...
Note: This guide is based on an older version of Home Assistant, but it might still be useful for someone just starting out to understand some general concepts.
When I tried HA that was exactly what made me hate it. It was all configurable via files, and it was documented that way back then. But my instance wasn't. It took a while and a few useless tries until I realised the UI config is the upgrade and not the other way around.
I end up having to do a mix of YAML and UI (on top of their templating language which i still can't grok). I think all-YAML is viable but all-UI is not if you use enough advanced feautures
Well that sucks, I missed that.
I've been 'intending' to set it up nicely for years (more than 'a few', clearly) but that's a dealbreaker. Every time I've thought about/planned it, the main annoyance has been NodeRed being like this, I didn't realise HA was now too.
It makes sense maybe for mass market appeal I suppose, but is there something else catering more to developers/tinkerers, those who want it all in text (or better: terraform!) for version control (and just as a more familiar way to edit it than a love-it-or-hate-it UI)?
I ran HA for a few years, but have since switched to Homey, which is more like an appliance, but also not quite as powerful as HA can be, provided you have the right hardware.
It works well for me.
I've never really been into home automation, but when I stumbled upon Philips Hue bulbs on sale for $5 at Home Depot a few years ago, I went ahead a bought a few. It turns out that they are great to wake up the kids on a schedule in the morning. I used the Philips app because it worked well enough that I couldn't be bothered to look for alternatives. Then recently I got a notification saying that the app wouldn't work without a Philips account. Yeah, no thanks.
The bulbs don't directly work with Home Assistant for protocol reasons (I think). I went ahead a bought a ConBee II dongle, which is a kind of USB stick that interfaces with the Philips bulbs (and devices from other companies). Plug that into a Raspberry Pi that has Home Assistant installed and you got yourself a single app that can manage smart devices from almost all imaginable companies. It works very well for my use case. If you have devices from several different manufacturers, you should definitely look into HA to have a single app manage everything, and to future-proof your setup against shady moves by some these companies.
> The bulbs don't directly work with Home Assistant for protocol reasons
They are based on the Zigbee networking standard, that's why you had to buy the stick. It is effectively a networking adapter like a wifi usb adapter. That said, you can buy most other Zigbee devices now as well. Ikea has far cheaper Zigbee switches than Hue or almost anyone and you can configure them to also cross control other HA features.
Yup. I got mad at Hue for forcing an account, so I got a $20 USB zigbee hub and spent 2 hours swapping all my Hue stuff over to it with zigbee2mqtt with Home Assistant. I've never felt better about my ability as a consumer to give a vendor the middle finger. I gleefully tweeted them some pics of my Hue hub in the trash.
I recently did the same and have been thrilled with it though I'm sad that the bulbs don't transition to new colors. They immediately change which looks a little jarring.
I had the same thought at first since that's the default, but it's configurable!
In the zigbee2mqtt control panel, click the device, choose "Settings (specific)", and change transition to 1. The look/feel ends up being indistinguishable from the Hue defaults.
Hey nice! Is there an equivalent in ZHA?
Thank you for the info! Why is that not the default... :/
For reference:
"Settings > Devices & Services > Zigbee Home Automation > Configure > Global Options > Default light transition time" = 1
PS. Not sure what this does exactly:
"Enable enhanced light color/temperature transition from an off-state"
Bingo. I just used the standard Zigbee plugin to do the same but purely so I could manage everything in one place. A good trick others should know is that if you have any Hue Switches, you can use them to rapidly reset a bump by holding the on and off switches down for like 10 seconds next to a bulb.
> Ikea has far cheaper Zigbee switches than Hue
Not beating the $5 sale price that the parent mentioned.
I love the IKEA smart home devices (practically all of the commercial smart devices I have still in use are IKEA). But the size and shape of their US outlets is absurd.
> cheaper Zigbee switches
OP got bulbs for $5.
Wait, do all Philips Hue bulbs come with Zigbee, even the Bluetooth ones? I had to reverse engineer their Bluetooth, and it works, but obviously I'd prefer Zigbee. BTW, the Philips app is garbage in exactly the ways one would expect (requires some account, doesn't work on some phones, requires your phone to be close to the bulb, etc)
All "Hue"-branded bulbs are Zigbee, some additionally add BT connectivity. All "Wiz", "Connected by Wiz", and "Phillips smart bulbs" without Hue branding are Wifi based. Incidentally, both are compatible with HA.
They do "directly work with Home Assistant;" your computer just didn't have the hardware to communicate with them. You bought the dongle which is just a Zigbee modem that allowed Home Assistant to talk to the bulbs using ZHA (which is built-in to Home Assistant). Zigbee is the hardware wireless protocol that Hue uses.
I love HA but hate how manufacturers are going all-in on preventing people from integrating their devices into the platform without an alternative.
Chamberlain MyQ did this by turning on CloudFlare Super Bot Fight and 429'ing anything that doesn't look like it came from their app. That's fine and reasonable, but I can't even pay to create an OAuth client, even though I am paying for their Tesla integration, and they provide no pathways for integrating with Apple HomeKit or Alexa.
I don't want to use a billion apps to control my house. HomeKit was supposed to solve this, but companies just won't let up.
MyQ was my reason for trying HA. When I saw that the plug-in keeps hitting their API over and over, my excitement faded. I know Chamberlain are the ones causing this issue to begin with (missing HomeKit integration) but DDOSing somebody’s API is not a solution.
My experience with HA came to an end when my gate unexpectedly opened on its own - and based on the log in the phone app, it came from HA.
MyQ had a HomeKit bridge... which they cancelled [1]. My experience with it was that, aside from eliminating the Internet/cloud dependency, it didn't make the MyQ experience any more reliable overall and I'm much happier with ATHOM's ESPHome-based kit.
[1] https://www.theverge.com/2022/8/23/23318157/chamberlain-myq-...
I have a Meross garage door opener and it has been rock solid for 2 years. Not a single hiccup or miss.
The issue I’d like to solve is my driveway gate. It’s too far from WiFi and I don’t want to run any cables. It’s Homelink and MyQ compatible but that’s about it.
I suppose I could take one wireless remote and replace the switch with a HomeKit compatible relay. lol
If it's conceivable that a WiFi signal isn't completely obstructed, Ubiquiti UAP-AC-M + UMA-D antenna.
If not, DIY with a couple LoRa ESP boards.
Re: MyQ, check out ratgdo [1]. It's a lovely little hardware project that wires into Chamberlain/Liftmaster controllers and provides a local WiFi-only interface. It integrates perfectly with HA and requires no soldering or disassembly to install. It's a shame Chamberlain discontinued their homekit bridge, because it shouldn't be necessary to use a cloud integration to trigger a garage door.
Update: I landed up getting a Meross. Very easy to set up and works fantastically within HA. I'm going to keep myq since the Tesla integration does add value and $45/year is a very reasonable cost, but if that changes, then myq is gone.
I have; he's super backlogged (great problem to have!)
Apparently you can still buy the HomeKit bridge (it's even on Amazon) and it will still work.
I'm at the point where I vote with my wallet on something like this. I'm in the process of buying a heat pump / HVAC system, and I've been very clear with the salespeople that _local_ Home Assistant support is a must-have requirement. No clouds, no apps, just Home Assistant.
If we ask for it, especially at the point of sale, companies will catch on at some point.
I would be surprised if any of them had the first idea what you were talking about, and they probably don't even work for the manufacturer. Even if they do, their feedback is extremely unlikely to make it back to product, and even less likely to be taken into account.
Ah shit, I had plans to reverse engineer the opener too. Thanks for saving me the time, anyway. Next option is to try to reverse the opener button, but I've already determined that it's not a simple "short these two connectors" style like in the days of yore. I hope it's not some kind of rotating key like what remotes (justifiably) use, but given how much they charge for their "smart" buttons, no guarantees.
Have you considered ESP32 or something like a Konnected device to pretend to be a wall button? I'm in the market for a jackshaft and myq stuff is a huge red flag for me
Are they still gallivanting their way around the internet being assholes?
https://news.ycombinator.com/item?id=27505277
I still use HA but haven't upgraded in a good while. Partially because of the switch away from YAML, and partially because that link left a pretty sour taste in my mouth.
Who cares and there was no such switch away from yaml
https://www.home-assistant.io/blog/2020/04/14/the-future-of-...
Just one relevant quote:
> Any new integration that communicates with devices and/or services, must use configuration via the UI. Configuration via YAML is only allowed in very rare cases, which will be determined on a case by case basis.
It’s misleading at best. You can configure literally everything via yaml including your dashboard. Mine runs custom js and css for crying out loud. Even if they changed some options that can’t be configured via yaml which I haven’t encountered, what’s the actual damage to you?
The result is things can no longer be configured via YAML, which is the direction they have been moving in for years.
(2021)
Wild. I recognise that I'm starting to become more dependent on Home Assistant. It offers me a lot of value, but this makes me rather worried.
The company does not come off as an asshole at all, unlike the nixos person who came to their forums.
I will never understand the petty gripes people have about HA. This category of software requires a community keeping the integration ecosystem up to date. Software with easy to understand abstractions and no frills UI/UX makes it easy to hack on without having to grok complexity.
A base project for home automation centralization free of big name companies is inherently valuable software and a public good.
I don't think you'll find much software that touches the day-to-day life of the average user as much as Home Assistant does.
Living through breaking backwards compatibility and deprecations I think is the paint point- just continued paper cuts for the grumpy here.
it's easy to lose sight of how great a piece of software it is
My Samsung, Google, Wyze, and car charger integrations slowly stopped working. I'm replacing everything with dumb stuff again, because the breakage (not usually HA's fault) is just too annoying.
This stuff needs to be an appliance, or managed by someone else, to make sense.
I just took the ZigBee approach. A vendor can't (usually) remove or break the features available and it'll just work for years and years.
Though such an approach doesn't work with many other integrations.
Absolutely. Those are the only things still alive, but it seems to be a niche market. I fear that Thread/Matter will be the end of ZigBee, and vendors will take the easy route of using/requiring the border routers.
> I don't think you'll find much software that touches the day-to-day life of the average user as much as Home Assistant does.
This is very true. Whenever I mess around with my homelab cluster (the current iteration is going to be the stable one, I promise!), Home Assistant is the service that needs to work—even though I've built our home automation system to not preclude manual control.
On one hand, I'm deriving a ton of value from HA. The other OSS platforms have nowhere near the same integration coverage. On the other hand, the jank I put up with...
To start - just for the basic display functionality:
* you can't really scroll around or zoom in the dates in the default visualization (graph) cards
* HVAC visualization doesn't show heating heating mode, unless you also enable temperature viz. It can't display heating stages at all, as far as I know.
* From what I understand, one is supposed to do viz through grafana and influx instead. However, if using the Home Assistant OS, one is tied to the add-on store, which has an obsolete version of grafana with some distinct changes from mainline grafana. Forums typically assume that you're not using HA OS, but it's never explicit.
* card layout is clunky (can't easily do full width two column)
* custom sensors show up as numbers instead of graphs unless they have an associated unit (still haven't figured out how to fix that), sensors with the same unit show up in the same graph (why do I want to see percent chance of rain and percent battery on the same graph? why do I want to see sun angle degrees in the same graph as wind angle?
* etc etc
Have you tried alternative cards through the HACS?
The only negative thing I can say about HASS is that getting it running in Kubernetes with a USB Zigbee/Zwave adapter is a real pain. I've got a local cluster and had it working once, but had to rebuild everything for some unrelated reason, and haven't been able to get it consistently working since. There are too many in-built assumptions about how you're running it and the USB access. Documentation assumes that _maybe_ you're using an old version with some Helm chart.
I'm normally pretty good at getting anything running in k8s quickly, but this is difficult!
I'm going to say "screw it" and just run it bare on a Pi soon instead.
What benefit would running it in k8s have? I’ve been running it on a bare pi for years without issue and have never once thought I needed abstractions upon abstractions… is this more a “because I can” sort of thing?
High availability, I assume.
I'm running HA in docker-compose (no USB device needs in my use case) , but being able to have docker-compose be the default tool that handles all of the external settings means I get something pretty close to Infrastructure-as-code, and that is nice for piece of mind and simplifying how the backup-and-restore process will work.
Plus I can be very deliberate about the pace at which I upgrade HA versions.
Helm is an absolute mess in my experience.
I'm using zigbee2mqtt in K8s and just pinning the deployment to a node and mapping the device as a volume: https://github.com/LukeChannings/kube-config/blob/3b61c7607c...
Should work the same for Home Assistant, but I don't use HA for Zigbee directly, instead using z2m -> MQTT -> HA, which I've found to be very robust.
I'm waiting for a new K8s cluster (based on CM4) and when I re-implement all of this I'll get a network-based PoE Zigbee device (https://smlight.tech/manual/slzb-06/), that way I can un-pin the deployment and look at high availability Zigbee via MQTT (something Home Assistant doesn't support)
I love Home Assistant. I only started using less than a month ago (moved into a new house).
However, the two times i needed to upgrade Core (I use Home Assistant OS, their recommended installation procedure), it broke.
The first time they had changed the spec of the 'correct' way of the YAML config file. Which means I didn't have an integration until i fixed the file manually (they deprecated something not gracefully).
The second time I don't know: I couldn't see anymore my Viessman Heater and check everything related to my hot water / heating so I gave up and rolled back.
I am a Clojure developer where there's almost never breaking changes, so this is a good reminder to not take that for granted. I think this is an aspect they have to improve a lot, if they want to cater to people who don't want a new hobby.
I've been using Home Assistant for several years and I can count on hand the number of times I've had breaking upgrades. These were always pretty clearly explained in the release notes. I think the nature of the broad scope of Home Assistant is such that different users may have very different experiences depending on what integrations they use. But I don't think it's generally as bad as your comment suggests.
> I think the nature of the broad scope of Home Assistant is such that different users may have very different experiences depending on what integrations they use.
I think this is a common problem with "hub" projects that intend to bridge together multiple incompatible technologies. I work in VoIP and have been using Asterisk in one way or another for over 20 years. That project is even named after the wildcard character because originally it was intended to be able to connect any kind of telecom technology from analog to TDM to all sorts of VoIP.
As the world moved on and most everyone has standardized around SIP as the future those of us who run all-SIP systems and/or common analog/TDM interfaces have generally been able to upgrade willy-nilly with little to no trouble, but there's always "that one guy" who has rigged up something where a call comes in over a SIP-GSM gateway, gets sent over an H.323 trunk to another box elsewhere in the world, then rings to a SCCP phone and of course they're always having issues because no one else is doing anything close to that.
HA has that problem to an exponentially larger degree because at least the telecom world theoretically has widely accepted standards that most equipment uses where home automation gear has a few competing standards alongside hundreds of vendor-specific APIs that may or may not be documented or even officially open for use.
Someone who is just using HA to unify their lighting control across a few vendors using well-tested Zigbee and Z-Wave implementations is going to have a much easier time than the people who have rigged up a Rube Goldberg machine of integrations of varying quality.
Not sure why there is some much negativity in this thread towards HA.
I'm a very happy user, and there simply is nothing out there that comes close in terms of ease of use and breadth of devices supported.
Sure, if you're going to (and can afford to) pay 200K USD for a vendor locked-in, turnkey home automation system, you'll get something that likely will be a little smoother and more polished that HA.
For a while.
The day something breaks or goes out of date, you'll have to pull out the checkbook again. And good luck integrating anything in there that does not come from the vendor in the first place.
The whole HASS thing is - true - a little bit unusual, but OTOH, does work fairly flawlessly as long as you don't start making outlandish customizations to it.
Yep, I was able to replace a whole set of really really shitty IoT vendor apps with a nice dashboard in HomeAssistant. It's now accessible for everyone in the household from any device or OS without jumping through hoops by creating multiple IoT accounts in multiple clouds.
It's an incredible project (and easily extensible too for a few items of hardware that didn't have official integrations yet).
I’m looking for reasons to use Home Assistant. I know a few folks using it actively in their lives for very many things. Someday I’ll have a good use case but maybe for now I can have it turn the lights off.
One really cool thing it can do is adjust the color temperature based on the position of the sun in the sky.
The lights throughout my house are cool during the day, and warm at night. It's quite nice!
I love HA and will persist with it. Main complaint is that it (and more so its docker containers) want access to the things that are not documented or configurable.
E.g. it tries to contact DNS other than the configured one and i cannot figure out what exactly it needs access to to allow updates to work.
This is especially important for home automation tools as i want them as far from the internet as possible
If you want to try, I build and maintain a rootless home-assistant container (which they refuse to support) that shouldn't have the issue.
Container: https://github.com/onedr0p/containers/pkgs/container/home-as... Source: https://github.com/onedr0p/containers
Oh neat
Today I learned that if you have residency in Denmark can just log into eloverblik.dk and see yearly, monthly, daily and up to hourly statistics about your energy consumption.
Going back to 2021 for me. And it has an API, for which there is an HA plugin.
No special hardware or account required. Fantastic.
It goes even further back. Mine goes back to 2013, though "recent" changes with heat pump and EVs makes the data points kinda moot.
As for the HA plugin, sadly the data is delayed by ~48 hours, so you can't use it for the energy monitor plugin.
Is anyone here using repurposed Mycroft devices with HA? Is this possible and worthwhile?
I wonder how a home assistant built with an Entity Component System architecture would look like.
I like the UI for scripts
HA is so great. It can be used for much more than "home automation/IoT", and I find myself using it as a piece of infrastructure for other self hosted stuff.
For example, rather than sending SMTP email logs for backup jobs, I just push that data to a HA webhook.
I also use it for scraping alerts: once the scraper fires a trigger, it pushes a webhook to Home Assistant, which sends me a push notification on my iPhone.
Great all around tool -- for the house, but for a bunch of other random stuff too!
Fragile but great work!
Shameless plug of my Go library for writing Home Assistant automations - for any HA users out there that want to be able to just write code instead of fussing with UI (built-in automations, Node Red, etc)
These updates keep breaking my seemingly very brittle series of automations and glue holding my house together.
As much as I love ha it still it pretty high maintenance
I switched from Samsung's Smarthub to HASS - been really happy with the move. Took me a while to wrap my head around some of the manual configuration. Regardless, due to strong community support, HASS plays nice with devices that I could never get to work with Samsung's HA.
Home assistant is really awesome. You can do a lot of crazy stuff with it and it's reliable. The best thing is you can build custom views in the PWA (I think per user as well) and you can make WAF and KAF go through the roof!
I used it initially because when my kids were toddlers they would get up and turn on the lights in the middle of the night and play or leave them on. I set up some rules so it would block turning on the light between 8 and 6 but let the bathroom come on for 5 minutes at a dim level.
WAF = Wife acceptance factor KAF = Kid acceptance factor
The new Todo-List integrations look good.
I'm half tempted to do a mostly useless project to replace the pinboard/whiteboard in our kitchen with a wall-mounted tablet.
This thread is very interesting as it shows how difficult it is to provide a solution for everyday use, but that also requires some head scratching.
With this in mind, I am surprised by the fact that people complain about HA. Software that uses words such as YAML, Integration etc. is obviously not a TV that requires a remote with 5 buttons. I would not complain about my TV not making coffee.
I use HA for many years now and I had it breaking exactly once, at a key change. I had automated updates at that time and it just taught me to upgrade manually and read the release notes. This is the "price" you pay for a dynamic, complex system.
I found it getting simpler (and more obscure) with time and overall I think it is a good thing. I used to have everything in YAML files and getting frustrated by the UI. Now I changed my mind and do not care anymore about renaming a device directly in the UI, even though I do not know where the change is (actually I know but this is not the place you want to dig in). It just works and I like home automation but it is not my full time job either.
The learning curve is not smooth. It starts pretty much flat and then there are cliffs you climb through "eureka!" moments when you understand what is what and how it is connected. It takes some time.
The automations went a great way (very great) from the time they were completely crazy all in YAML to today where you can do most of the things in th eUI. I used the YAML version for a short time, wrote my own, discovered AppDaemon, discovered pyscript and finally (the trip above lasted a few years) I am back to the built-in solution. Nothing beats a toggle switch to disable an automation at 4am in the morning from your bed.
The documentation is a bit weird. It is very complete, but quite difficult to master. There are still things I do not understand, I see them in the documentation but still do not understand after reading it.
Fortunately there is the community which is awesome. I think all the questions I ever had were answered. There is a big "but" though: it is very helpful when you are a beginner or an intermediate user, but you are mostly on your own for more advanced things. It is not that someone does not want to help, it is rather that there are so many possibilities with HA that you are likely to hit unchartered territory at some point if you want to become an advanced user. Otherise you will be fine.
In conclusion: THANK YOU VERY MUCH HOME ASSISTANT (but my wife hates you because everything works only 90% of the time, but when it works it is awesome :))
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.