Home Assistant 2023.11
home-assistant.io
home-assistant.io
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.
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.
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.
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"
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.
OP got bulbs for $5.
A base project for home automation centralization free of big name companies is inherently valuable software and a public good.
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
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.
This stuff needs to be an appliance, or managed by someone else, to make sense.
Though such an approach doesn't work with many other integrations.
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
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.
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.
[1] https://www.theverge.com/2022/8/23/23318157/chamberlain-myq-...
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 not, DIY with a couple LoRa ESP boards.
If we ask for it, especially at the point of sale, companies will catch on at some point.
Apparently you can still buy the HomeKit bridge (it's even on Amazon) and it will still work.
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.
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.
Does your iPhone need an i ternet connection for this to work?
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.
It's annoying to have to do a workaround like that but it makes it bearable at least.
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.
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’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
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.
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 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.
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'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.
It's an incredible project (and easily extensible too for a few items of hardware that didn't have official integrations yet).
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.
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.
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!
It works well for 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 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.
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)
Otherwise it's pretty straight forward nowadays!
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.
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)?
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 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.
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 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.
> 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.
> 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.
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.
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)
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.
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 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.
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.
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.
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
Container: https://github.com/onedr0p/containers/pkgs/container/home-as... Source: https://github.com/onedr0p/containers
As much as I love ha it still it pretty high maintenance
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.
As for the HA plugin, sadly the data is delayed by ~48 hours, so you can't use it for the energy monitor plugin.
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.
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.
> 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'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.
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.
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/
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.
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 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.
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.
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.
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-...
The first thing you should do is learn to organize your thoughts into coherent questions.
> 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'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'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.
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.
Ideally K8s w/Flux is pretty great for this, as I can just make a change in SCM and then let it rip. Hardware dies? Drop in a new one and keep going. Backups handled by the larger system, instead of individual computers.
Additionally, my VPN/DNS and other networking setups with CloudFlare zero trust and MetalLB make it really easy to securely access it from anywhere for whatever service I need, with minimal fuss.
But... getting the USB parts working with K8s is so annoying, as their assumptions around using Docker or Containderd are pretty fixed. Obviously I need to set an affinity/requirement of the node having the USB device, but even after that it just doesn't seem happy. I can see the device in HA, but it never connects.
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)
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 :))
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 lights throughout my house are cool during the day, and warm at night. It's quite nice!
I'm half tempted to do a mostly useless project to replace the pinboard/whiteboard in our kitchen with a wall-mounted tablet.
But it's still a huge piece of work and deserves a lot of praise.
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.
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?
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.
(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.
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.
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.
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.
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.
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.
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.