Does the new app make it easier for users to expose the Ollama daemon on the network (and mdns discovery )? It’s still trickier than needed for Home Assistant users to get started with Ollama (which tends to run on a different machine).
In the app settings now, there is a toggle for "Expose Ollama to the network" - it allows for other devices or services on the network to access Ollama.
Founder Home Assistant here. Want to chime in that I always love to see write ups like these to see the great things what people achieve with Home Assistant.
Not everyone might know, but last year we started the Open Home Foundation as a non-profit in Switzerland and I donated Home Assistant to it[1]. It's fully funded by users. There are no investors involved.
We are fully committed to building out a smart home that focuses on local control and privacy. Yes there are rough edges, but we're actively working on it in the open, with progress being released every month.
> I donated Home Assistant to it[1]. It's fully funded by users. There are no investors involved.
I cannot thank you enough for this. It was a bit risky adopting Home Assistant for everything ~two years ago, but that you guys did this move really makes me feel less scared about eventually having to replace it with something else.
I'm subscribed to Home Assistant Cloud (via Nabu Casa) even though I don't use it just because it seems to be one of the few ways to financially support you, is there any way of doing one time donations to the foundation itself?
We don't want to come to rely on donations and have to show Wikipedia-style beg banners in our app (I would personally hate to see that myself).
So with the limited resources that we have, we currently only consider bigger donations valued $10k or more. We've had monetary donations from DuckDuckGo and Espressif so far.
I didn't get the begging feeling from using Blender, though it has been some years ago. IIRC they focused on donations for specific features and showpieces like their movies.
As a very happy Home Assistant user, hopefully you can manage something similar so you have enough money to stay afloat and keep up the good work.
smart homes dont work because wifi doesnt work. almost every user is running low quality hardware or does not deploy a meshing AP to reach the devices. the devices are not resilient to lost packets and high latency
just change a wifi ssid with smart devices in a home and watch it all crumble. users want nothing more than to get rid of “smart” once they realize its not smart enough to figure out how to change wifi networks.
endless “updates”, rent seeking, breaking changes, account setup - its not worth it.
You should check out Home Assistant and the vast range of ecosystems it integrates with! There a dazzling range of radio standards and manufacturers that have considered the problems you’re describing.
You could (and I understand many people do) run an entire smart home without any WiFi at all, if you’d like.
Home Assistant is free and open-source, and I understand from his comment above that their founder generously donated the project to a non-profit foundation to sustain it that way for the future.
Which is awfully reassuring with respect to the rent-seeking incentives you’re worried about.
Only my "smart" water heater communicates over wifi. The rest use Z-wave or Zigbee. I know at least Z-wave has from the start had the ability for devices to be programmed to operate without the controller.
So if the controller falls out or you don't have one you can still have your buttons toggle lights etc. Controller or no controller, in either case it works just fine without wifi.
Like my parents wifi SSID was set when I was in high school and 20 years later it's the same.
But if it did change, all the devices just setup a temporary AP and wait to be told the new one and the password (the temporary AP is also password protected).
There is Zigbee, Z-Wave and Matter. These are all smart home standards that are fully local and devices will be able to be set up and used even when the company goes out of business. You are however limited to the things that are standardized.
If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable.
(disclosure: I am the president of the Open Home Foundation and ESPHome is one of our projects and I am also a board member of the Z-Wave alliance)
I am not a practitioner, but instead someone that looks at the ecosystem from time to time and has been waiting for a while, because I dont see the stack + DX/UX that I want yet.
Zigbee never reached critical mass and requires a hub. Z-wave seems to be the same. Thread over wifi (IIRC different protocols/transports are just fine) is what I think will be the future.
IMO Thread wins out, support gets put into routers, and I can just have a thread enabled router which MAY have other
I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi, and I want to control them with a standard networking stack with high adoption and familiar tooling. Thread seems to fit this use case the best.
Please feel free to rip apart the above opinions, they’re loosely held. I’d love to learn how wrong I am today!
> If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable.
Thanks for the recommendation! Appreciate the disclosure and apologize for the blast of relatively uninformed opinions.
One more side question — why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable?
Buildable with an ESP32 clearly but I just want to buy this.
Maybe not exactly what you are looking for, but check out the Shelly BLU Button1. It's a BLE button with a long battery life.
It sends out BLE packets when pressed, which can be picked up by Home Assistant via a Bluetooth adapter or using a Bluetooth Proxy. You can make the latter with any ESP32 and https://esphome.io/projects/?type=bluetooth
Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that.
So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it)
> Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that.
Maybe not, but I don't really want to actually run Home Assistant, I want the basics to hack on, really. Trying to pick the most open thing that will be easy to program without relying on using something like Home Assistant (not that its bad or anything).
> So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it)
Yeah that's my goal -- basically I want to be able to control the devices from anything web connected (and ideally, the same program running in multiple places).
My thinking is that I can build this without being cloud enabled if I "just" (famous last words) had Thread/Wifi.
With all the excellent feedback in this thread (thanks HN!), it's looking like a small SBC + a Thread/Zigbee/BLE dongle[0] is the way forward, and hooking that up to my router via USB so it's always powered and follows the router around (maybe velcro it on).
SBC (or something smaller maybe, but probably the SBC) so I can program it myself.
Home assistant absolutely can own the Zigbee coordinator, it works very well, too (this is what I’ve been using for a couple years with the SkyConnect dongle.)
> Yeah that's my goal -- basically I want to be able to control the devices from anything web connected (and ideally, the same program running in multiple places).
HomeAssistant provides a REST API for all devices connected to it. I don't even use its automation features, I just use it for the API to control my ZWave devices from other stuff.
ZWave is the most stable radio-based standard right now. It's not great, and it's not very extensible, but it's OK-ish. There's one hackable device: https://z-uno.z-wave.me/technical/ but its SDK is not that great.
Pure ZigBee is... spotty because there are no certification requirements. Matter is stuck in development hell, but is slowly getting better.
And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread.
So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff.
> And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread.
This is a problem I'd really like to solve the old fashioned way/I think it prevents too much building. Energy density, rechargability, etc are like CPU speed to me -- it will eventually be solved, and I can deal with replacing a device every month or swapping a rechargable battery (especially if the device can tell me it's low).
I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over).
If either ZWave or ZigBee had managed to get into the home router space, they would have won already IMO. There are probably annoying reasons they couldn't until now.
> So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff.
Thanks for sharing this and your other experience!
> I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over).
That actually had been the case for a while. A lot of WiFi routers had a built-in Thread (ZigBee) radio, but then nobody actually used them and the manufacturers stopped bothering with them. So now pretty much only Eero access points still have it.
> Also TIL KNX.
My dream is to have _actuated_ switches, that have full tactile feedback. So that the paddle will physically flip when switched remotely.
I commissioned an engineering company to look into that, but apparently this is not feasible at all with the NEC and UL requirements in the US. The only way is to use low voltage wiring to the switches and then use them to control line-voltage relays. This kind of system is popular in Europe, so you might as well just go with something like KNX.
The UL requires a switch to be able to physically break the connection in a way that can't be actuated remotely. So the switch will need an additional physical cutoff switch. Which is funny, but workable.
The deal killer is the power dissipation requirement. A solenoid, both compact and powerful enough to actuate the paddle, will dissipate too much power if it gets stuck in the "on" state. And a small geared motor is not acceptable because the switch has to be bi-stable and can't be allowed to get stuck in the middle.
So if you do an integrated device, the paddle will just end up being an input device, rather than an actual current-interrupting component. And there just isn't a lot of space inside a switch for everything without going into Apple-like engineering.
But that would be fine. The biggest problem is not whether a relay in the switch would fail or not, it's that you want the wall switch position to be tactile and to reflect the state of the switch.
Yes, it might be possible, but also expensive. But there just isn't a lot of space available to support both a good tactile feedback, and to be able to interrupt the line voltage. There are requirements for high-low voltage separation that are difficult to meet, while staying within the allowed size for a switch.
Since I'm doing it for myself, I will selfishly just do a low-voltage system :) But I'm seriously considering funding a startup to do engineering for an integrated version.
The closest thing that I found to a _good_ smart dimmer was https://www.alibaba.com/product-detail/Zwave-Zks31-Knob-Dimm... (ZKS-31). It has a physical knob as a control, and it only misses the visual indication of the current state and simulated detents.
I'm really at a loss why nobody else is trying to do something like this, while doing crap like touch-sensitive switches with LED displays.
> That actually had been the case for a while. A lot of WiFi routers had a built-in Thread (ZigBee) radio, but then nobody actually used them and the manufacturers stopped bothering with them. So now pretty much only Eero access points still have it.
Thanks for this context -- when I searched I only found "thread border routers" -- I couldn't find a router made by a well known brand that included thread functionality -- it always seemed to be "buy a router AND buy a thread border router".
Really surprised that I missed the wave on this and wonder if it was a "we want people to buy two things" rather than no one actually using it. Maybe I just have to wait for it to come back around?
Maybe the answer here is a USB powered device with an extra 2.4Ghz radio (running like.. OpenThread or whatever I need to do thread over an available antenna?) attached to the router?
What I don't understand is why I just use the existing router's 2.4Ghz antenna for this? The amount of confusion in the space and inability of devices to do multiple things is really annoying, to be frank. I can only surmise the reason this stuff is not easy/obvious is profit-incentive (outside of the difficulty of designing good standards of course!).
[EDIT] OK, so the antennas aren't the same, despite being the same frequency -- clearly this is to ensure speedy operation at the hardware level.
So the add-on antenna would probably work if I bought some parts from mouser:
[EDIT2] Nope, more confused. Multi-protocol antennas exist. Why is this not a set-and-forget option for all the routers??? Someone clue me in to the politics/power struggle or whatever the real reason is here.
And then connected + taped something to my router.
> Really surprised that I missed the wave on this and wonder if it was a "we want people to buy two things" rather than no one actually using it. Maybe I just have to wait for it to come back around?
It's worse. There are _no_ new stand-alone Thread Border Routers on the market. You might find old stock of GL.iNet routers, and I believe there were a couple of other experimental devices.
If you want a robust Matter network, your best bet is to use Apple or Google devices as border routers. Or you can use a USB ZigBee stick with HomeAssistant.
> [EDIT2] Nope, more confused. Multi-protocol antennas exist. Why is this not a set-and-forget option for all the routers???
No market demand, so router manufacturers just don't bother. The initial versions of Matter were a burning trash fire.
thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden.
Think HomeKit but a tiny bit more open, the open bit is, that a vendor can allow it to communicate with devices of other vendors. But they don’t have to.
Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM.
Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors.
> thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden.
I'd counter with the fact that walled gardens are incredibly popular, and in particular to consumers. Consumers don't care if the gate is locked or not, they care if the flowers are pretty and the tea at the garden party is nice.
> Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM.
IMO prices of SOCs are going to zero. ESP32s are a great example of this. Once RISCV is more widely used and capable things will accelerate even faster.
> Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors.
I think we agree here...? I think that HomeKit device that is just a bit more open is going to win. But I think that HomeKit device gets adopted faster if it's just a router -- I can understand updating a router to get a smart home. What I don't want is confusion around whether I need a hub or not, or whether devices work together or not.
Buying a single router that acts as a hub + Wifi "repeaters" (IIRC that's what they're called) that can "extend" the signal (and along the way give other devices a point to connect to) makes perfect sense to me as a consumer. I already know what WiFi is, and I want better coverage, not worse. The smart home stuff just falls out of tech I am already familiar with, efficiency by damned.
Thread is a WiFi replacement, the devices talk IP over thread.
And it has an encrypted pairing process to your vendor controlled hub. Said vendor can allow or disallow it which other vendors may speak with said hub.
Here is the landscape we have:
HomeKit: fully closed, requires certification from Apple. Very expensive and limited functionality.
Zigbee: fully open, anyone can make Zigbee devices and sell them without any restriction. Operates on the same frequency all over the world. Devices are super cheap. You can expand the protocol however you like as a vendor.
Z-wave: fully closed, several incompatible frequencies, requires certification to sell devices.
Thread and matter: semi closed, same ieee standard as Zigbee for data transfer. Vendors can allow it to talk to devices of other vendors. Requires certification. Same price tag as HomeKit, aka 3-4 more expensive than Zigbee.
All of them require hubs. And only with Zigbee you are guaranteed to have interop between all vendors and all devices sold across the globe. Thanks to Home Assistant.
With thread the vendor can simply disallow you to use your devices with HomeAssistant, which is unacceptable by me.
Thanks for all this context/explanation -- also the follow up. Automatic range extension (i.e. actually being a mesh and forwarding along messages) is an excellent feature.
> All of them require hubs. And only with Zigbee you are guaranteed to have interop between all vendors and all devices sold across the globe. Thanks to Home Assistant. With thread the vendor can simply disallow you to use your devices with HomeAssistant, which is unacceptable by me.
This is the one I want to push back on -- Thread over Wifi doesn't require a special Hub right? Taken with other info from this thread clearly in the real world it's not so simple to find the right hardware... but it's possible to just buy a thread device and use it over regular old wifi.
Sounds like Zigbee is closer to ideal than Thread or Thread/Wifi.
Maybe this is the startup someone needs to do -- some reasonably powered device to attack to a router/connect close to a router which supports Thread and Zigbee, has completely local management and call it a day. Is this just over-complicating a smart hub? Don't know.
Thread is using the same protocol as Zigbee, which requires specialized hardware to talk to it. You can’t get around a centralized hub when wanting to use them on your WiFi network.
Thread just adds an IP layer above Zigbee. Zigbee is on the same protocol layer as Ethernet or WiFi.
Technically works but not well enough to move past “experimental”
> This experimental firmware has been available since December 2022. Through extensive testing, we have found that although it works in some circumstances, it has technical limitations that lead to a worse user experience. We now do not recommend using this firmware, and it will be experimental for the foreseeable future. Instead, we will focus on making sure the dedicated Zigbee and Thread firmwares for Home Assistant Connect ZBT-1 deliver the best experience to users.
> Thread is using the same protocol as Zigbee, which requires specialized hardware to talk to it. You can’t get around a centralized hub when wanting to use them on your WiFi network.
>
> Thread just adds an IP layer above Zigbee. Zigbee is on the same protocol layer as Ethernet or WiFi.
AH, I've just realized that I've been using the wrong terminology.
I've been meaning to say Matter over Thread vs Matter over Wifi!
Matter seems like a decent way forward, and it can work only over wifi which is what drew me in to focusing on Matter. IIRC Matter/Zigbee isn't a thing (though it technically should be possible, Zigbee is just a transport as far as Matter is concerned right?).
[EDIT] works -> can work, Thread/Zigbee -> Matter/Zigbee
But here comes the tricky bit, when you buy either Zigbee or matter devices each vendor will add its own extensions.
In the Zigbee ecosystem vendors out right refuse to communicate with devices from other vendors even though Zigbee is an interoperable standard.
That lead to the birth of zigbee2mqtt, literally hundreds of years of development time went into it to have full feature support for every Zigbee device that exists.
For thread and matter devices each vendor would have to do the same. And that won’t happen, leading to a fragmented ecosystem.
Thanks again for laying this out -- I've been seeing zigbee2mqtt everywhere and this explains why someone would add mqtt to the mix. Sounds like this is another thing that needs to be run/managed on the software side to be robust.
This is an insane goal (and who knows when I'll actually get to work on this project), but what I want to build is an all in one something that "just works". So roughly:
1. Pick a good enough physical comms stack to hit most things
2. Write software to fill in the rest
It's going to be difficult but it feels like the setup for all these tools is just hard, when it doesn't have to be if you could pin down the hardware/install instructions, then write a really decent software layer to pull it all together without making people go homelab.
That said, that's probably what home assistant devs thought before they reached the current level of complexity, I'm probably preparing to attack a windmill here.
I think my secret sauce here will be WebAssembly -- if I can nail down the hardware below, build/convert a ton of adapters via WebAssembly, and then build a compelling/easy to add/install/manage/configure UI on top of that, I might have myself something worth posting to HN someday.
IMHO, thread and matter will probably be as mature as homeassistant and zigbe2mqtt in the 2030ies. At the moment, Zigbee devices can work without any hub as long as you stick to one vendor.
Aka buy lightbulbs and switches from ikea and you can right out start using them, I believe you only need a hub to create groups of devices which then can get controled with one switch. You then could unplug the hub and still use them, only needing a hub for ethernet bridging and automations.
> Aka buy lightbulbs and switches from ikea and you can right out start using them, I believe you only need a hub to create groups of devices which then can get controled with one switch. You then could unplug the hub and still use them, only needing a hub for ethernet bridging and automations.
Yeah thanks for pointing this out -- just need a single Zigbee coordinator (if my light research has been correct so far) and I'm ready to go.
Different expectations. I don't want my things to know that wifi exists. It stops vendor lock-in, it ensures local communication, it means things work even if network goes down. It also makes sure they will never autoupdate or join Mirai botnet.
I've got a mix of zwave (fibaro), ZigBee (Ikea) and ble at home and I'm ok with that.
Same boat here, I like knowing that none of of my devices can get network access, all they can do is communicate with HomeAssistant.
And with Zigbee bindings most of my inputs are set up in a way that they still work even if HomeAssistant goes down.
Not that HomeAssistant has ever down, but I can imagine its SSD or something failing and not bothering moving it to a different computer for a few days while I get a replacement in.
Yeah I think so -- I like to think I can control my router at least, so I don't have to worry about it. That said, probably not protected from the botnet case.
Also, unfortunately up until now I've been saying the wrong thing -- I mean Matter over Thread versus Matter over Wifi. Matter over Wifi seemed like a winner to me because I could just use it.
It looks like going forward I'll be plugging a small SBC into my Router's USB (+ ethernet) and connecting a Zigbee + Thread dongle. That should cover me for most communication options, then from there it's "just" a software problem :)
> I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi,
Having a lot of career experience in this area, I greatly prefer to keep my IoT devices off of my WiFi.
You don’t need a separate hub device for Zigbee or Z-Wave, just a simple USB adapter that you plug directly into your device controlling everything.
Keeping the low bandwidth IoT devices off of the main WiFi had a lot of advantages. It’s also much easier to rotate your WiFi password when you can do it all without reconnecting every light switch in your house, for example.
Thanks for sharing your experience here -- agreed that it's better to avoid the chatter and also rotating your WiFi passwords is indeed an issue to consider, that would be quite a pain.
The "Hub" device can be as simple as a USB stick that's attached to the machine running Home Assistant. That's what I have been running for years, a Z-Wave USB stick that passes through to a ZwaveJS docker container (which also communicates with HA).
So it's not like you need a big stand alone device that has to have it's own Wifi or ethernet or anything like that, it's just a USB stick.
Thanks! This is what I eventually got to. That said, I'm leaning towards putting the USB stick in a Pi or something like that, which is attached to and powered by the router!
Just want to have the one device and I think that's maybe the simplest way to get it without trying to run stuff on the router.
Basically, it is a hub, but it's more of an attachment to the router than anything else.
> why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable?
Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues.
> Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues.
So what do you consider to be "bad" battery life? I've got quite the tolerance, but the problem is that they don't even exist. Everyone seems to stop out on this at "it would never be worth it".
> Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge.
This is intense for me, I'm happy with replacing batteries every 6 months if I could simplify deployment by 10x.
> The hub is an usb dongle attached to the home assistant server, no issues.
Maybe deployment isn't as hard as I'm making it out to be! That said, nothing easier than sending some packets to an IP address. I assume Zigbee APKs are easy... But for example if I search on crates.io (https://crates.io/search?q=zigbee) I don't see any obvious choices.
To restate what I want (and hopefully is sounds a bit more reasonable) I want to be able to buy one smart light bulb, configure it over BLE to connect to Wifi and for the rest of it's live configure it/change it via Wifi. I want that for basically every device, and I'm fine with swapping batteries every 1 to 6months if I could have that!
> Maybe deployment isn't as hard as I'm making it out to be! That said, nothing easier than sending some packets to an IP address.
I think this might be the case. Get a USB zigbee dongle and spend ~1 hour setting up Home Assistant and you're more or less done. Adding a new device consists of clicking a button in HA to enable permission for devices to join and then powering on the device. It will discover the network and report the features it exposes.
You can control devices via HA over wifi. Plus HA gives you an API that you don't have to maintain and update as you add new classes of devices to the network.
You'll spend far more time repeatedly replacing batteries with wifi devices than you will with configuring HA once.
Edited to add: one nice thing I forgot to mention is that using HA for your own homebrew devices lets you keep a single consistent API for those and commercial devices. You can build a little ESP32 device with custom sensors, displays, etc. and control those exactly as you would with off-the-shelf products.
I really need to figure out how deep I want to go -- HomeAssistant is clearly the best off the shelf option. Maybe I'll set up HA first and then see if it really is worth trying to build something better.
BLE should also work but you also want a dongle, so hardware wise it’s the same; ideally you also want a couple gateways (Shelly devices can do that out of the box btw, and new Shellies will be supporting Zigbee.)
Yup, you're right -- looks like zigbee2mqtt is a huge unlock, hard to build without it since it supports so many things!
Not excited about having to essentially now also bring along a MQTT broker but... It's probably pretty painless to run most brokers and it's likely a single-machine-is-fine affair.
While true, it's really hard to shop for devices that have access to WiFi without internet. It's too easy for the manufacturer to slip in the internet requirement and not put it on the box. Using other protocols makes the expectation disappear.
Founder Home Assistant here. Want to chime in that I always love to see write ups like these to see the great things what people achieve with Home Assistant.
Not everyone might know, but last year we started the Open Home Foundation[1] as a non-profit in Switzerland and I donated Home Assistant to it[2]. It's fully funded by users. There are no investors involved.
We are fully committed to building out a smart home that focuses on local control and privacy. Yes there are rough edges, but we're actively working on it in the open, with progress being released every month.
I agree with what you wrote. The whole situation reminds me of the old "Standards" XKCD, to an extent. In the short term something like LiteLLM, which I just discovered doing more research on the whole topic, can at least hide some of the underlying complexity.
That being said, considering what you've done with Open Home and Home Assistant (which has run my home for years, thank you!), perhaps there is some hope of an open standard in the near future.
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.
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?
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.
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.
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?
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.
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.
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.
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.
Inside Home Assistant the processing is delegated to integrations providing Speech-to-Text, command processing, Text-to-Speech. You can make custom integrations for all of them
> Analytics in Home Assistant are opt-in and do not reflect the entire Home Assistant userbase. We estimate that a third of all Home Assistant users opt in.
I'm a big fan of home assistant, and use it to control a LOT of my home, have done for years, have tonnes of hardware dedicated to and for it, and I've also ordered some of these Voice devices.
