Founder of Home Assistant here. Let me know if anyone has any questions about the project or the Open Home Foundation (which now owns Home Assistant, ESPHome etc)
Hi Balloob, great project, thanks for all your work! I've been using it for over 10 years now.
I am wondering if you've ever considered a change to your release rules. Monthly releases are great, but having breaking changes in every release can get to be a bit of a burden. I think it would make end users lives easier if you were able to limit breaking changes to only once (or twice) per year.
I try to read the breaking changes list every time, but sometimes I don't mess with HA for a few months as it's all running smoothly. Then when I do log back in I have a large backlog of breaking changes to review. Usually at this point I just don't upgrade and the problem keeps getting worse. If instead I knew that certain upgrades do no include breaking changes I could more easily keep up to date, and only look more closely at the yearly (or bi-yearly) update that includes the breaking changes.
We've actively managing our backwards incompatible changes, but sometimes it's out of our control (ie an API change). For things we deprecate in Home Assistant, it is a minimum of 6 months period where we print warnings with alternatives. Integrations set up via the UI, will only change for improvement if we can ensure there is a migration path (sometimes requiring adding some extra info).
Some backwards incompatible changes like requiring a new Z-Wave JS version are also able to be managed automatically by Home Assistant. However, because of choice, there are many ways Home Assistant can be installed and we're not always responsible for the installation.
I believe that we can do better in knowing what integrations you use, and mapping that against the integrations that require changes.
First, thank you. Home Assistant is an outstanding example of having control of our electronics rather than giving money to data harvesting companies.
Second, I'm curious, how often do you guys have to deal with negative actions taken towards you by those same data harvesting giants? I'd imagine they aren't huge fans of this technology. Any Cease and Desist or other fun examples you guys have had to defend yourselves from?
We have very good relationships across the industry, especially the bigger companies. I literally just came back from a meeting with Google Home :)
Where we see the most pushback is from industries adjacent to the smart home, as they don't appreciate the openness. Think garage doors, cars, or cloud data providers for info that can be useful in the home.
When someone complains, like Mazda [1], we pull their integration and communicate their stance to our shared users, and people considering buying into their products. We don't fight for access, as a manufacturer with a cloud service will always be able to find a way. If it is a local device though, our community tends to find a way[2]
It’s interesting how some of these actions backfire. I will literally never purchase a chamberlain product ever again because of how overtly money-grabbing they are.
I suppose in some ways, it’s a good thing. It shows me what companies I should support, and which I shouldn’t.
> It shows me what companies I should support, and which I shouldn’t.
I used to think that way too. Now, I think that all it takes is one bad quarterly report leading to a new CEO, and even the most open of companies can instantly switch to being closed, lock off all their APIs, stop working with open source projects like HA.
I don't know any solution to this, and if I'm honest, being bitten a couple of times has stopped me from experimenting with anything like home automation that requires me to buy physical hardware.
I think a big part is buying things that work locally and don’t require a cloud connection at all.
If it requires a cloud to function, you’re at the mercy of a company changing attitudes. If it runs entirely locally, the company can’t get in the way even if they want to.
It’s one of the aspects I really like about matter (or any other device that operates on a purely local protocol). If Inovelli decides to take a turn, it just means I won’t buy any new products from them, but the switches I already put in my wall will continue to function the way they do today.
Don't buy things that need a cloud integration and it's not really a risk.
Even if you don't use Home Assistant, their site is really good for helping with this--every integration lists a "class" like "Local Polling" or "Cloud Push".
Another shortcut is picking up a Zwave/Zigbee dongle (~$30 when I got mine) and buying products that work with that. If the only radio in the device is one that can pair to a local controller, it's a relatively easy way to ensure it's meant to work locally without a cloud integration. (If Kwikset has a bad quarter I'll never know--my door lock only communicates as far as my utility room.)
Besides "the company can't screw me over", if everything is running locally it also immediately limits the privacy and security implications. And ensures your house doesn't break if the internet goes out.
Hi @balloob. No question but I moved yesterday night from a Home Assistant Supervised on Raspi 3 to an HAOS on Raspi 4 + SSD and the migration had been flawless. Thank you very much to you, the team, and all the contributors for making such a great and fair piece of software and building such a great community.
Organizing devices and creating automations is still very tedious.
I'd love to be able to add a device and describe it (where it is, what it does, etc.) and have HA automatically integrate it with existing automations or fuse it with other sensors. Maybe leveraging LLMs for this.
e.g.:
I buy a new leak sensor and add it to HA. I should just tell HA it's a leak sensor and it's in my laundry room and have it create an automation to send alerts, etc. when there's a leak.
Or I add a temperature sensor in my living room and have it automatically be fused with other sensors to update my living room average temperate.
You're right. Home Assistant is the best toolbox out there, but people need to build things themselves. That's something we plan to tackle, but no timeline. Leak sensors, smoke detectors, CO2 sensors, garage door openers, they can all have benefit from some built-in automations to warn when a problem is detected.
Add to HA, and set 'area' or 'label' to the same as all your other leak sensors. Use the area or label in your automation.
I find HA joyously easy to use. I have my garage door, lights all around the house, thermostats, hot water recirculation system, doorbell, lutron blinds, and ceiling fans. The automations are easy to make, and have been getting easier over the last few years with HA improvements. (and same as others in this discussion, I use zigbee smart switches. The GE brand ones are great).
One trick: Add your automations.yml (and ideally, all HASS config/ymls) to a git repository, so you can track changes, organize and observe how automation changes behave.
Like the other commenter said, smart switches are the way to go. I prefer the Shelly modules behind light switches. They are tiny, affordable and their new generation does Zigbee/Wifi/Matter/Bluetooth, so always something that suits your installation.
Agree with your Shelly-behind-the-switch model. My one hesitation going all-in with them has been perhaps reaching an eventual state of "too much 2.4Ghz WiFi traffic on a narrow IoT-specific WiFi network", but I suppose that's easily solvable by buying another AP. Currently I'm happily running a few of them behind the wall plate in my switches (check the space in your switch box first!)...no issues after many many months of continuous operation. Didn't know about the new gen supporting Matter, that's great.
Also, I too wanted to extend to you a really big THANK YOU from a very happy member of the HASS community. I came over from OpenHAB a handful of years ago and I couldn't be happier. Please keep up the good work! Good luck with all the hardware sales and Nabu Casa stuff!
In real terms though, it not that bad. I've got about 25 such devices always online and the traffic really is negligible. Most devices aren't sending anything while nothing is happening except for the periodic heartbeat like once a minute. Its not noticeable, even on my 20MHz wide network.
I have like 54 devices running on 3 unifi APs...it's unnoticeable (either that or my phone/laptop etc. are just using 5ghz and happy about it - either way).
I use smart lights with smart switches in detached mode and they are not resilient to ha going down. I wish I could get smart bulb functionality (dimming, color change) with smart switches being the physical driver of them being on/off.
I’ve got some inovelli white series switches that are on a circuit with Nanoleaf thread based lights.
I’ve managed to bind them using Matter bindings, so even if HA is offline, the switches can still on/off and dim the bulbs.
No UI supports this yet (though I think HA is working towards it), but the underlying protocol support exists, and products are starting to come to market that take advantage of it.
I think it 2-4 years, it’ll probably be ironed out and working well, but if you really want it, you can have that now with matter/thread.
I think Zigbee devices also have bindings, and those should probably be a lot more mature, but I haven’t played with those yet.
Not sure about color change, but dimming works fine - I have Shelly Dimmer2 modules behind switches, paired with "dumb" dimmable bulbs. Remotely controlled by HA / Adaptive Lighting, while also working with physical switch.
One solution to this if you're using Shellies to provide your "turn a dumb light switch into a smart light switch" is the scripting it has on offer.
I have 100% Zigbee lights, and each lighting circuit has a Shelly Plus 1 with the relay in "detached" mode (so the shelly will sense the light switch changing from open to closed and send a command to HA to turn on the lights via Zigbee). Most (all?) smart bulbs have a setting for "what do I do when power is restored" and you can set it so that they come on when power is restored.
You can then create a script that uses the MQTT HomeAssistant up/down topic and if HA is down, when the switch changes position operate the relay.
It's not perfect - if you have a powercut during the night all of your lights will come on when power is restored.
I totally missed Shelly becoming an HA Darling - I have an older home with some of the wiring not having a Neutral wire, so Lutron Casetta has been my only option and those No-neutral dimmers are extremely expensive.
Not the fella you asked but let me offer some wisdom: smart switches are a lot easier to live with than smart lights. If you also want color control, HA can do a decent job of making smart switches work well with smart lights.
The core problem with a smart light is that it very likely has a switch somewhere. If someone turns that switch off, that smart light just lost power and became dumb. Turning it back on now involves a trip to the switch.
A smart switch is smart so long as utility power is running and you never find yourself in a position where the managed device is in an unknown and/or uncontrollable state.
Even better, get smart switches that don't use wifi or IP addresses. I'm personally of opinion my homes core features should not rely on needing IP addresses, working DHCP or DNS etc just to turn a light bulb on and off.
Home assistant works amazingly well with zigbee devices, and these are plentiful and cheap etc, and don't rely on working wifi/IP infrastructure. When I sell up, my zigbee switches will work just fine as plain-ole light switches even with all my Home Assistant infra ripped out, leaving no issues for next buyer.
You can add zigbee support to pretty much any Home Assistant setup with a 20 buck USB adapter, Home Assistant even make an official one:
The light switches are often cheaper than wifi equivalents too. Wifi bulbs should really only be considered by renters IMO - people who can't easily replace wall switches or similar.
Except IP works far better than Zigbee's alleged mesh networking, and all the other home network technologies because somehow home automation is a special snowflake that can't use the same network technology everybody else uses.
There are a few reasons why Wi-Fi is not my first choice:
* I don't trust any company to use my Wi-Fi and not attempt to access the broader internet. A Zigbee or Z-Wave device isn't going to be able to stealthily update itself in anti-user ways, nor is it going to be hijacked into serving as part of a Bitcoin botnet.
* There are way too many devices, which can cause issues if they're all using Wi-Fi at the same time. Smart homes take a router that would normally be dealing with 2-4 phones and 2-4 laptops and add N bulbs, M switches, P contact sensors, Q motion sensors, and assorted random sensors. Not a chance am I hooking that much up to my Wi-Fi.
Z-Wave LR has worked very well for me—no mesh to worry about, just a controller and devices. The only downside is that it's not as broadly supported as zigbee or Wi-Fi.
The main drawback with keeping the switch "dumb" and only using smart bulbs is someone can turn off power to the bulb etc, which is why I and parent commenter focus on automating the switches. If someone turns wall switch off and its dumb, you can't turn the "smart" bulb on with home automation regardless of what tech is used inside it. Focusing on automating the switch generally has best returns on making most dependable system, as you will always be able to get the light back on. Again, I only recommend smart-bulb only if you are a renter or similar and can't mess with your switches.
Zigbee access to the bulb is great for stuff like changing whitebalance etc though. In my own home I have the bulbs and the switch on ZigBee so I can do this, but power on/off is solely preserve of the automated switch.
I've had great results with the Aquara zigbee stuff - almost all of them work fine connecting to HomeAssistant via generic zigbee USB adapters, and can be found online pretty cheaply. I have >50 of their switches and sensors at the moment.
Aqara is a bit of a mixed bag. A lot of their switches are not Zigbee certified and don't conform to the standard. Specifically, they won't bind directly with devices from other manufacturers.
This might not matter if you're pushing everything through a hub like HA, but if you want to connect directly with other devices and remotes then it likely won't work.
My solution was to add Shelly relays behind all of my “dumb” switches. They keep power always on and essentially turn the switch into a smart button to dim or brighten my Lifx lights. This way I get circadian & party lighting while still maintaining the convenience of physical light switches!
And to parent question: Lifx still has the best color/brightness of any smart bulb and they’re IMO the best. Just make sure your WiFi can handle it.
The problem with smart switches is they require 3 wires: live, neutral and the switched wire to the light. Where I live most switches have only two: live and the switched wire to the light. The neutral goes directly to the light and doesn't pass through the switch. Because of this I have no way to power the smart switch module. Unless I want to rewire half the house :(
There are some smart switches that work without neutral. They trickle some power through the load. This only works with some loads. I have one fixture with small LEDs where one of them glows slightly.
I assume they hack what little power they need from the AC wobble? How do they do that without triggering a current leakage cutout though? Perhaps they “charge” when current flows for the first time?
Returning current through ground is a bad idea in general. You should consider rewiring your house for the safety benefits rather than enabling some smart devices.
Putting significant return current through ground means anything in the environment can be part of the path of least resistance. You will see small voltages across your house depending on what loads are on and there will be load-dependent noise conducted and radiated everywhere. This also puts the system one open circuit away from making nearly every conductive part of your house a shock hazard (if the wrong place in the ground network goes open circuit).
What is done in modern times is to have the current return on a neutral wire then monitor the ground wire for current and open the circuit when current is flowing back through ground (a fault).
No, the current goes back through the neutral. This is the normal operating mode with single phase power.
This is different from ground. Neutral is the way the return is meant to go. Ground is a safety feature. Connected to the enclosure in some devices.
So sockets here have 3 wires: Live (Brown), Neutral (Blue) and Ground (Green with Yellow stripe). But the switches only have Live and the Switching wire (Black, the wire that goes to the light). The light then receives the switching wire and has Neutral. Because the power is consumed in the light and returns via neutral.
The switch doesn't need the neutral normally because it doesn't use any power. It just switches it on and off on the way to the light. But the wifi switchboxes do need it because they need to remain connected even when the switch is off.
Athom make ESPhome smart switches with no neutral wire, they work great.
The way it works is you put a bypass capacitor to neutral in the light fixture, and then it lets the switch be powered - no flicker or low energy requirements needed.
Ah I see, does require to modify the light though. But it's interesting to look at, thanks. I don't use Homey though, I use Home Assistant. So I'm not sure if it works with that.
They're not open source so I thought maybe their other stuff isn't either. I didn't even know they made switches in fact.
Several of my friends have the homey, they're very popular here because athom is a Dutch company and they market here a lot. But I prefer the openness of home assistant.
Edit: Aah I see the confusion. The athom that makes the esphome devices is a Chinese copycat company that has nothing to do with the real athom but is trying to get a free ride on their name.
Can you do that yourself or would you need an electrician to sign off? What about your landlord?
I agree in principle that this is much nicer in theory. Just like wired is more reliable than wireless. However, retrofitting all that is also much more difficult.
Depends on where you live. In most jurisdictions in the US it's generally OK for a homeowner to perform "like for like" replacement work on their own residence without a license or inspection. This means you can replace an existing light switch, or an outlet, or a breaker. You generally cannot run new wire or new outlets without a permit.
If you own a property but don't live there (eg, you're a landlord), it's essentially never legal. The best answer is to contact the local AHJ.
Disagreed. To get the best of both worlds I run smart switches that control the smart lights. E.g. install the Philips Hue Wall Switch Module (Zigbee) and make an automation in HomeAssistant to turn off the corresponding light(s).
Now you benefit from both, like being able to make the lights fade off/on.
Also, in case it doesn’t always respond instantly, you should be able to bind the Zigbee devices directly to each other so that it doesn’t need to travel to the Zigbee coordinator (or mesh?) first. Haven’t had the need for this myself though.
Smart switches are a lot more annoying when renting, though. In addition, for us, all but the hallway bulbs make frequent use of color features, so I’d need both anyway.
Though I’ll admit, it might be worth the hassle if you have guests often or many people living at your place.
This works with almost any smart light you can get connected to HA (most smart lights have white balance adjust), it's brand agnostic etc. I have lights from several different vendors working together this way.
This is the way. Especially if other people live in your house.
Look at this stuff as "progressive enhancement". Make the simple things work, then build on top of that. Don't replace the simple things with complicated, elaborate things. You don't want to live without lights for a week because a SD card died in a Raspberry Pi somewhere or something.
The overly complicated setup I'm using to run my smart home automation stuff shit the bed and I was too busy with work to really spend the time fixing it so... I just didn't. For six months. The only major complaint I heard was that the outside lighting was no longer turning itself on and off with the sun.
Even in the worst case scenario, all of the lights still have switches that can be turned on and off as long as there's power. It's all zwave, and I've made use of the scenes / direct associations / etc such that most of the stuff people actually care about happens without being mediated by Home Assistant. Or requiring any sort of network. When I move out of this house, I could leave it all behind and it would keep working as-is without my server, access point, active internet connection, or anything else. If there's power, it works.
All my living room lights (three dimmers) are controlled by a single dimmer.
The three way switches in our bedroom are now dimmers. One controls the lights, the other acts as a remote control for it.
The pantry light turns itself off after 20 minutes because people always forget it on.
Both the kitchen light switches turn on and off with the single, easily accessible switch.
The switch for the porch lights also turns the string lights on the gazebo a hundred feet from the house on and off.
My kid's too small to reach the regular switches, so there's a battery-powered remote switch mounted on the wall at her height in her bedroom and the bathroom. Those still work and are still able to dim the lights in her room.
Etc, etc. All without anything but electricity.
I said only _major_ complaint--my kid definitely had some complaints. We have one switch that has a couple of those RGB projector bulbs hooked up to it. When you turn that on, an automation turns off all the rest of the lights and starts playing some dance music. Her party lights still turned on, but it no longer made the music start.
If you want colour control then get smart bulbs to go downstream of your smart switches. Set them to always go to "on" when power's restored, and build that _on top_ with your automation. You'll always have a working light, your automation can always turn them on even when someone's turned the switch off like a normal person would, but when everything else is working you'll _also_ get colour control.
Are there any plans to add automations based on People and Areas (not zones)? I found the cool project Bermuda[0] and it triggers person entered/left area events based on bluetooth devices. This works great in my testing with a phone being tracked by Shelly switches. But I can't seem to find a way to actually make these events do anything. It would be even better if I didn't have to set up area specific automations at all and just be able to say "turn on the lights in an area to 20% if someone enters it after sunset".
The old automation in YAML is very cluncky as the author also mentioned. The new UI guided creation is not powerful and can become confusing for complex cases on the other side. I do all my automation with the node-red Integration. But the combination of the node-red flows with the Homeassistant dashboards is not very good.
Do you plan to change the automation to something like node-red but better integrated? Or change the yaml to sonething less declarative and more code centric?
Just wanna say thanks for leading such a strong and comprehensive open source project. A lot of open source tools are wonderful in and of themselves (being that they are free) but might not always live up to expectations or offer a whole lot. With Home Assistant, I feel like it is the opposite and the capability/power of the tool (particularly out of the box) is really quite impressive. So keep it up and thank you again!
- Home Assistant Cloud (paid)
- VPN
- Port forwarding
Is there any plan to make something like Home Assistant Cloud available for self hosting? Like a simple docker container to put on a VPS?
I don't want to deal with DynDNS to expose my home network but would prefer a Server component on a VPS with a static IP which connects to my home server and allows remote control.
The problem is that my home server isn’t reachable from the internet, so there’s nothing for the proxy to forward. I would need to set up some kind of VPN for that, right? But this functionality already exists in HA, that’s why I asked.
The biggest problem with Tailscale and/or WireGuard is that I can’t inform IOS to only connect to VPN when home assistant app is running or when notification comes in.
I have to run it on my phone all the time effectively routing all mobile traffic through my home VPN which is not ideal for bandwidth and battery life.
I end having to manually turn it off and on.
Instead I wish home assistant had a way to make mobile notification resources easily accessible without VPN - say behind a short lived access token so that I could quickly view the notification media without having to expose local HA install or having VPN always on
seems completely out of scope for HA? if you want to proxy it from the internet then you can just do that using any of the tools used for this - NGINX, wireguard, rathole, etc etc etc.
But this functionality already exists in HA. There’s a simple login page where I can connect to the HA cloud. The idea would be to start a docker container, set up a domain name where it’s reachable, enter the domain name on the HA cloud screen and connect to it. It would be much simpler than setting up everything yourself.
What would be the correct way to DIY it? You would need a VPN to connect you home network to the Proxy and then expose the web interface on the proxy, right?
Whole bunch of alternatives too - https://github.com/anderspitman/awesome-tunneling. I will advocate for zrok.io as I work on its parent project, OpenZiti. zrok is open source and has a free (more generous and capable) SaaS than ngrok.
> Founder of Home Assistant here. Let me know if anyone has any questions about the project or the Open Home Foundation (which now owns Home Assistant, ESPHome etc)
Every time I visit the big box stores, I see Wi-Fi as the primary means of connecting to the smart home ecosystem. Do you see this trend changing in the future, why from the average consumer prospective? Especially with thread?
Not much a question, but a RANT. As an user I'm grateful for HA slick UI and functionality but while the best on the market is... A damn hell.
YAML instead of pure Python is a hell. Trying to push things to be configured via WebUI is a big discomfort because well... Generic users do like clicking around, but generic users will not use HA simply because it's not and will not be possible in future to create a no-code usable IoT. All low-code/no-code stuff COMPLICATE life instead of simplify. External deps like InfluxDB to just prune past data and keep them as I wish it not much nice, having a built-in option to state how to prune and for how long to keep each specific sensor or default policy would be very nice.
Essentially the RANT could be condensed in: please consider designing for people who know how to code, because they will anyway be the most common users. IoT OEMs will only be hostile for most because they still fails to understand how to makes business in an open world, so professional integrator will not much choose HA anyway since it's way too time consuming to really customize and keep it up. A pure code approach with NO energy wasted in config WebUIs/low code/no code on contrary could makes HA an interesting "base for system integrators" in a much broader sense. NanoKVM PCIe, JetKVM show the start of a feature-rich light-out management for anything, they will be the bridge between home IoT and classic homelabs/IT. HA could play a very nice role there, essentially offering a platform to bridge the not-really-IT-ready world of ModBUS and co appliances to the TCP-enabled and digitally controlled stuff. A future where small devices could be fitted in most appliances to "makes them smart" like being in the middle of a washing machine control panel connected to home p.v. system to start programmatically depending on available p.v., a connected oven pre-loaded with food the user start when he/she knows the time he/she will be at home.
This is a potentially nice niche market who could explode in the relatively near future. It's not possible as low code/no code/pre-packaged black box stuff. Being a component anyone could easily plug in a larger system is needed.
YAML might be ok if we limit HA to some smart bulb, just having a Victron battery inverter with some 40+ sensors demanding a significant load of YAML it's nightmarish. In python native it's HYPER quick.
It's a major pain to write YAML for Home Assistant. Some parts of Home Assistant lack complete examples which are up to date. The documentation doesn't include examples for every single thing. Part of writing some automations was just a lot of trial and error, looking things up on the Internet, validating the configuration, and restarting Home Assistant. It's just not a great experience.
Discovering what has to be selected to use as an action in the automation GUI is another nuisance. The most recent example is with a light I wanted to set to 20% brightness. I had no means to find something with the keyword "brightness" or anything similar. It turned out that this was exposed as turn light on.
Breaking changes are their own source of friction. My only advantage has been that many of my automations are now just GUI automations with some custom YAML where it can't be avoided.
All of these things are far beyond what a non-technical user could be able to do. It can be difficult even for someone who knows how to look things up, read documentation and update everything when breaking changes are made.
Home Assistant isn't the kind of tool one can put in someone else's hands to use it without additional maintenance or supervision. It's also not the tool to use in any commercial setting due to its countless problems.
Well... GUI automation is not automation. It can't be. Automation must be automateable, code is, since you can save in a text file, versioned etc. GUIs can't. Reproducing them means doing countless step every time, hard to document with screenshots etc instead of "here the snippet" and Python code is self-documented, so discovering how to do things is MUCH easier, YAML need to be read from source code, not just importing a module and run help(modname). That's why to me HA should be pure-python NOT "sold" as a pre-deployed blackbox but as a simple pip-able package. Anyone could easily integrate it in anything else, documenting could be just the code for most simple stuff or a wiki with shared personal configs. Those can be automated as well to test it's validity pinging the author when a snippet fails as well.
That's the power of automation, of code, of end-users programming. Harnessing it means reduce all efforts after the first implementation and speed up anything breaking changes as well.
Thanks. I understand where you're coming from now. Your requirement to use Python code for automation could be satisfied by an external component which uses the Home Assistant API or through some internal custom Python based component which runs your code for automation.
The current setup for automations isn't good for anyone - not for end users, not for developers. I've resorted to using the UI because it seemed to be less likely to break across releases.
Any plan to update the GUI for conditional logic inside of automations? It's really clumsy to do IF/THEN or switch style constructions. Too much visual space and clunky overall.
In the past I've had issues with forgetting to add triggers for states that are used somewhere as a condition or switch. This leads to lost updates and frustation.
React state hooks, which I'm deeply familiar with, will result in a linter warning if any of their dependencies are missing. I'd really like something similar for automations.
NodeRed is awesome. I didn't even bother with anything beyond very, very simple automations until I installed that.
For me the flow design feels very natural and is easy to modify and monitor. And it's pluggable with custom nodes so if functionality is missing you can add it in. Like I installed a node that handles OAuth2 so I can have it log into a web service and check a status page.
I regularly test disconnecting my HA server from the network and make sure nothing home critical stops working.
I do have a few internet integrations (weather, upcoming sports events, etc) and those all stop when I do a “no internet” test, but Home Assistant runs just fine without any network access.
A fresh Home Assistant Operating System installation is useless without an Internet connection. It needs to download several gigabytes of Docker images for it to be usable.
It's very likely they'll take the infrastructure down if they sell their business or go out of business. Home Assistant OS will be completely useless in such a scenario.
The more likely scenario is that someone installs Home Assistant OS, sets it up with the current version and uses it as it is to avoid breaking changes. Their storage or the entire device breaks down. They'll want to install the same version to restore a backup. They'll learn the hard way that it's not possible to bring up what they had before.
Using the Docker image is the only choice which mitigates this risk.
The Home Assistant core container relies on resources hosted at https://brands.home-assistant.io. Those are cached in the browser for a while. Your mobile phone and web browsers still load the icons. They can do whatever they like with these bits of information. This includes selling allegedly anonymous Home Assistant usage data. The people who host their infrastructure can still do that without their knowledge since they claim it's a CDN.
The use of this CDN means that an existing Home Assistant core based setup can stop displaying some icons if those icons are removed. This can happen if someone decides to use a specific Home Assistant core version.
I ran the UI and didn't load anything from external source.
The Internet should only needed to download the image. You could download and flash it manually. The setup shouldn't require the Internet. What needed the Internet?
As I've written in the other comment, the Home Assistant Operating System is useless without an Internet connection. It has to pull the Docker images since it doesn't have any version of the images at all.
This thing isn't as private and as local as it is claimed to be. It's very tied to services provided by Nabu Casa, including the very visible cloud integration of theirs. They've expanded it now to backups.
Do you think there is any hope of convincing Tuya to make their devices easily flashable?
They'd be the unquestioned king of the space if us local only people could reliably convert them to ESPhome, and they're the way a lot of brands end up making things "smart".
Tuya's entire business model is about getting their customers' data and getting them to pay for their services through vendor lock-in. They're not going to give up on all that juicy data collection and on the money they currently charge.
It's enough for just a single direct or indirect dependency to be compromised to have a botnet or turn it into something used for surveillance against the users.
Preventing it from exfiltrating data by isolating it from the network with Internet access is the only option if you want to run it. This requires local only devices.
The way the world works, you need to be either a company or a non-profit to be able to partner with the industry. Just being an open source project is not enough.
Since the launch of the foundation, we see a large uptick in companies and universities reaching out to partner with Home Assistant. A lot of manufacturers are very happy to see that an independent platform is being established as alternative to the big tech platforms. Universities want to collaborate on energy and privacy research for the smart home. We've also seen some industry donations (ie DuckDuckGo) to support our work.
I've been using Home Assistant for about three years. I was very glad it exists. I wanted to make the most out of it. It has numerous problems and regressions are very frequent. The disappointment lies in it not being as it's described and in the fact that its development process doesn't appear to improve, nor does its overall quality appear to improve. It still gains new features in spite of all of these issues.
Home Assistant's dashboards and UI have regressions in every single release. Many such regressions aren't fixed quickly or remain that way permanently. Github issues get closed by the bot. New features ship in every release without fixing these bugs. This gave me the impression that the developers employed by Nabu Casa have very little time to focus on bugs and that there's no pre-release QA. The graphs and their history had plenty of bugs in the 2025.1 release. Are there plans to improve the development process to improve quality?
Home Assistant is described on its home page as "Open source home automation that puts local control and privacy first.". A Home Assistant OS download is useless offline and without the Nabu Casa infrastructure. A download of a Home Assistant OS image obtained today would be completely useless in 5 years for now. These are completely useless if Nabu Casa's infrastructure goes away for any reason. Do you have plans to address this?
Another point related to Home Assistant being local and making privacy a priority, Home Assistant downloads all icons from [1]. The GitHub issue [2] has been open for a while without any involvement from the developers. The Home Assistant container image doesn't include all the assets required for it to provide a Home Assistant deployment in a container. Is this something you plan to address or should it be handled in a fork of Home Assistant meant to be run completely locally?
Home Assistant bundles numerous dependencies [3]. The Home Assistant container bundles and has all of these available. Are there any plans to let users disable all cloud only integrations? What's done to assess the security of these numerous packages? This matters because people allow Home Assistant to access their indoor cameras, door locks and other potentially sensitive devices. Some malicious code run from one compromised dependency's __init__.py could have serious consequences.
Home Assistant is a Python monolith. Adding something as simple as a shell command to my configuration requires a restart of Home Assistant. Are there any plans to split this up or to improve the architecture to not have such issues anymore?
The energy dashboard is extremely limited. Are there plans to make this more flexible?
Why are you forcing people to use encryption since 2025.1? I was including these backups in my encrypted backups anyway.
The voice functionality for Home Assistant and voice PE require a cloud service or a local machine with a GPU for good performance. Are there any plans to address this to provide higher performance local voice control? The old Rhasspy (the version released before Nabu Casa hired its developer) seemed to work a lot better with defined sentences and was faster.
I've seen Home Assistant become faster over the last three years. My YAML had to be updated a few times. New features have been introduced to the dashboards. Old issues and limitations are still there. The dashboards gain new features while the number of bugs and regressions also increases. The custom resources for custom cards don't always load in the mobile app. The UI still loads all the icons from the Nabu Casa icons site [1]. Home Assistant frequently stops updating my location (home vs away) and requires deletion of the device from HA to get it to work again. Entities don't update in the dashboard sometimes.
Home Assistant is described as being an open source project which has been donated or moved to the Open Home Foundation. Why does it still require a CLA to be signed, just like corporate open source projects?
Setting up Home Assistant for someone who's non-technical is a terrible idea. This is an even bigger issue if they want it set up and left alone without updates/maintenance. The mobile app would probably stop working properly with this installation or they'd break it at some point by installing updates.
I'll wait for a bit longer while I prepare to migrate away from Home Assistant and Home Assistant OS. I'm considering a setup which uses Home Assistant core to trigger automations and to display a dashboard. All the automations and device integrations would be done with other tools. This would reduce exposure to Home Assistant's regressions and avoid Home Assistant OS's limitations.
I’ve been using HA for 10 years and I share almost all of your concerns.
Particularly annoying is automated issue closure on GitHub. Imagine spending your free time debugging an issue and describing it meticulously only to see it ignored and closed a few months down the line. I can’t but think about all the burned users who’d inevitably stop reporting anything at all. How does that affect project’s quality?
How do you like the Discord based forums? Having knowledge buried in a proprietary closed source platform hosted by a third party is another problem. They can wipe out countless posts and exchanges through a simple terms of service update to delete older data.
The automated issue closure and ignored issues are pretty much the last straw for me. I appreciate the work done. I can't help but see that this how things are going to be forever without any significant change. The only option is to migrate away from Home Assistant.
FWIW frenk clarified that their issues was not licensing, but support.
> For me, this was not about licensing specifically. However, that point unfortunately is missed and got lost. Which is unfortunate. A lot blew up on the route, which just sucks for both parties.
> In the end, I think the way this project distributes Home Assistant (and its integrations, including Ambee) is not providing the intended working and thus may surprise the end user. In the end, those users are likely to knock on the doors of the Home Assistant project and their integration maintainers, not this project. As a matter of fact, most of my packages in this project are outdated and don't match the distributed version of Home Assistant.
That's why I asked about attitude, not anything else. It's perfectly fine to decide to not to support someone, but...
"I release my code under FOSS license, but if anyone distribute it in a way I consider not nice, I will re-license it just to screw them over." [1]
When I was considering using HA and was casually browsing community discussions, there were many posts gave me similar feeling like above case. There were other technical reasons that I decided to not to use HA, but this certainly left a really bad taste in my mouth.
This isn't some regular contributor. They appear to be one of the most important Home Assistant maintainers and a Nabu casa employee. This contributor is also the author of many release note blog posts such as this one
https://www.home-assistant.io/blog/2025/01/03/release-20251/
Home Assistant may be developed with financing from Nabu Casa. Nabu Casa receives money from partners, from people who buy their products and from those who pay for their cloud subscription. They also rely heavily on countless other Python packages developed and maintained by people they don't pay. Other people make significant contributions to Home Assistant and to its web UI.
I'd expect them to run this project as an open source project and handle such situations with a bit more grace, even more so for someone with such a high profile such as frenck.
They'd have the right to get angry if someone distributed a paid product which didn't include FOSS code from third party contributors or FOSS dependencies. This isn't the case. They use a lot of FOSS code from countless people already for the Home Assistant core, for the frontend and for the Home Assistant OS.
All of the time spent dealing with such needless drama could be better spent living one's life and doing something more meaningful for everyone.
Home Assistant and the Home Assistant Operating System have a log of bugs, regressions, shortcomings and usability problems. They have far too many problems for me to even track them or write all of them down. That's not related to your experience. There are other issues which stand out based on what you've written.
The so called issues you've encountered appear to be due to insufficient knowledge and experience. It might be a good idea to learn more to better understand what's going on. What you've done is similar to complaining about being last in a swimming competition without learning how to swim properly first and without proper practice for several years.
im perfectly fine with that, and am not asking for a refund or anything. i am merely pointing out that as a fellow startup person in tech this kind of friction log is typically what you want to improve the experience, so that in 3-5 years you are not blaming your user for their skill issue when really its always possible to improve the experience. this is what i did for a living. this comes from empathy.
seems your issues started from the beginning. you bought a HA voice believing it was a home assistant server.
it says right on their sales page it is a "voice assistant" and that it is "built for home assistant". [1]
then you didnt want to buy the HA green that is a home assistant appliance with HAOS already setup for people who don't want to diy it (like you didnt).
next you downloaded a .vdi and didnt research what it is or how to install it.
then you complain about docker images, although it is
absolutely possible to run in docker as long as you understand the limitations [2]. did you even read this?
> hmm. new macs dont have apt-get anymore.
they never did. why dont you read whats in all of your screenshots? it says right above "if your OS don't have that, look for alternatives".
> Installing Virtualbox and double clicking the .vdi file i downloaded from earlier gives.... nothing
well, what do you expect? it's a disk image, not a executable. again, the installation instructions for macOS can help you here, you should read it [3]
> anyway, it looks like the default vdi ships with some well known bugs but ALSO its now just straight up missing the \EFI\BOOT\BOOTx64.efi file it expects to load. I found one you can download here and learned that you can import them into the vm via shared folders.
you found a post from 2021, it is not relevant today.
then you started replacing files... oh man!
your actual issue is that you didn't configure the vm like the installation guide showed you.
next you got it running in docker. advice to you: don't. you will not be able to use addons and thus no hacs.
> of course it just expects the networking to work when of course it wont fucking work
> i tried ngrok to setup a tunnel but it just resulted in a bunch of bad 400 bad request errors
you must learn how docker networks work to progress here. docker only listen locally by default and you need to instruct it otherwise if that's what you want.
TLDR:
you should have just started by reading the installation instructions, it explains to you:
> Home Assistant offers four different installation methods. We recommend using Home Assistant Operating System.
then you should follow the recommendation and be done long ago.
you seem frustrated and not keen on reading or learning.
not sure who you expect to take action based on that rant.
yeah, for someone who wrote a book called "The Coding Career Handbook"[0], not being able to actually read the instructions, getting mad about it, and then posting a rant called "Home Assistant Voice Preview is an unusable mess"[1] is not a good look.
