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)
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.
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.
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?
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]
[1]: https://arstechnica.com/cars/2023/10/mazdas-dmca-takedown-ki... [2]: https://www.home-assistant.io/blog/2023/11/06/removal-of-myq...
I suppose in some ways, it’s a good thing. 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.
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.
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.
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.
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).
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.
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.
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:
https://www.home-assistant.io/connectzbt1/
The also sell Home Assistant servers with zigbee radios built in:
https://www.home-assistant.io/yellow/
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.
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.
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 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.
My devices can't reach the internet at all, but I have easy access to them the other way.
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.
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.
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.
Dimmable smart switch plus dimmable standard bulbs accomplish this. No color (though Phillips has a line that tints red when dimmed.)
That seems like the best of all worlds.
Networked smart switch. Switch in absolute authority of light. Switch still able offer advanced light features (e.g. hue set).
https://sonoff.tech/product-review/product-insight/zbmini-ex...
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?
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.
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.
They've just received an injunction banning their sales in the EU and have to take back all their products sold here. https://community.homey.app/t/athom-wins-lawsuit-against-chi...
I had never heard of the Chinese company before.
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).
Returning current through ground is impossible in Europe anyway due to residual current breakers. More than 30mA and the whole system shuts down.
And none of the light switches have ground either by the way.
Try putting a 50 mA fault and see if the GFCI does anything. It won't if you don't have a second line for return current.
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.
Though I’ll admit, it might be worth the hassle if you have guests often or many people living at your place.
https://www.home-assistant.io/integrations/flux/
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.
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.
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!
edit: clarified that I used to run OpenHAB
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'm personally avoiding wifi devices now and holding out for matter/thread variants
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.
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.
Will look into Shelly
Perhaps have a look! Thanks for all your work again, I love HA
Thanks for all your great work!
Now the community should be able to create such things, as our automation engine is very powerful.
I think the challenge in general with room presence detection is that these systems are not very common/reliable yet for us to aim to standardize.
- 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.
Or is there already a way to do this?
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?
You set up a reverse proxy (including websocket proxying) for your HA subdomain on your VPS and you're done.
It would be an issue if you’re stuck behind double NAT, but I think tailscale can help with that.
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
You can use an exit node. In that case it will route all your traffic to your home network.
But tldr is that you don’t need any cloud VM or other service for remote access. Works great.
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?
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.
(this can also be seen on our roadmap update https://www.home-assistant.io/blog/2024/11/15/roadmap-2024h2... )
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.
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.
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.
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.
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.
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.
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?
Yes, there are resources loaded from the Internet. The map tiles are loaded from a third party in the initial setup and every time you view the map. Icons are loaded from https://brands.home-assistant.io/. https://github.com/home-assistant/frontend/issues/18549 is the issue.
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.
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.
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".
It has access to security cameras and having to trust a ton of code downloaded with Docker is a no go.
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.
Accessing it through the web UI or through the mobile app will still load icons from https://brands.home-assistant.io. The details are in this ticket https://github.com/home-assistant/frontend/issues/18549
The frontend has its own dependencies.
[1]: https://github.com/VictoriaMetrics-Community/homeassistant-a... [2]: https://github.com/VictoriaMetrics-Community/homeassistant-a...
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.
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.
[1] the Nabu Casa run icons site - https://brands.home-assistant.io
[2] https://github.com/home-assistant/frontend/issues/18549
[3] Home Assistant Python requirements https://github.com/home-assistant/core/blob/dev/requirements...
Nada.
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?
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.
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.
> 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.
"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.
1. https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
this is my friciton log. i am left with a $60 brick. hope your folks can use this to improve the experience.
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.
1: https://www.home-assistant.io/voice-pe/
2: https://www.home-assistant.io/installation/#advanced-install...
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.