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.
Is it possible to donate to your foundation via some kind of a subscription?
I have a Nabu Casa subscription, but I don't really need it.
dengolius 3 hours ago [-]
My friend uses self-hosted open-source software to monitor all his home IoT devices[1] and copies important information to the cloud. I'm using StarFive VisionFive 2 to host my database for monitoring, but also have a copy of the data of a chip hetzner arm vps, as well as hosting backups on the two different clouds. I know users who are running[2] for years to monitor Solar panels, lawn watering and vegetable garden watering.
My question is: is it really convenient to use only SaaS now if there is always the possibility of losing your data? I am referring to the case described in the article.
in recent podcast episode with the found of your company ( https://www.youtube.com/watch?v=8xkCykuJwKs , От стартапа до международного бизнеса: история VictoriaMetrics и её уроки | Александр Валялкин | #36) he explicitly described the path VictoriaMetrics has come and one of the early steps was trying to sell SaaS, while quite a lot of users/customers want to have on premise/own setup for such tooling.
So, answering your question:
> My question is: is it really convenient to use only SaaS now
no, it's not
protocolture 2 hours ago [-]
Home Assistant is great, I have been able to push it to do things I wasnt expecting it to permit. Just running Python within a container arbitrarily interacting with the network and sensors. I used it to backend my own home web application.
I believe a lot of people who are upset with the product have radically incorrect expectations.
hardwaresofton 10 hours ago [-]
At some point a company is going to start making hackable, local connection devices (cloud optional) with published APIs and sell them at a higher price tag, and they’re going to be fabulously wealthy, commanding higher margins than the others.
At least, that’s what I like to tell myself.
baby_souffle 8 hours ago [-]
The number of companies that does this _is_ growing.
Shelly was early, the cheep chineese stuff was easy to hack but they eventually moved to cheaper and more esoteric chips where custom firmware is non existent or not as mature. This is changing back, though! The number of ESP-32 powered LED light controllers that I've seen on Ali that feature a USB port for reprogramming / have all the GPIO labeled ... even have a HA/ESP-Home/WLED logo on them is infinitely more than I saw in years past (a few is infinitely more than zero, right?)
dns_snek 3 hours ago [-]
Buyer beware - There's a mountain of products on the market that are advertised as "open source" which lures many of us in, but many of those products have poor quality hardware.
My heuristic for anything operating at mains voltages is "If I can find a product that looks just like this on Temu/Aliexpress, I'm not buying it". They're probably white label products sourced from the same factories and suffer from the same quality issues.
Relays found in smart plugs are often sketchy in my experience. About half of the ones I bought or set up for others make unsettling noises that made me worried about poor electrical connections and risk of fire. I only have two Shelly plugs but those don't suffer from these issues.
viraptor 1 hours ago [-]
Tuya and their rebranded versions fall into that area too. Their power switches die early and they actually went from easily reprogrammable to hostile firmware. They have own cloud service you can't leave, only get an access code to - and the firmware prevents downgrades. Terrible company.
dns_snek 1 hours ago [-]
Tuya is just an IoT platform used by many cheap devices but I agree, it's low cost and cloud based which is a terrible combination. I wouldn't touch it.
There is a crucial difference here, though: the Home-Assistant integration for Refoss devices, which interfaces directly with the monitor and needs no cloud connectivity, is written and provided by Refoss itself. Home-Assistant compatibility is the first bullet item on the above-linked product page.
balloob 10 hours ago [-]
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)
hardwaresofton 9 hours ago [-]
> There is Zigbee, Z-Wave and Matter.
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.
raffraffraff 3 hours ago [-]
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)
hardwaresofton 1 hours ago [-]
> 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.
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
hardwaresofton 5 hours ago [-]
BTW, just bought a bunch of Shelly stuff. Looks like that project might happen sooner than I thought! The Shelly 1 also looked like a good option :)
Thanks again for the rec.
hardwaresofton 7 hours ago [-]
Thanks for the recommendation! This definitely makes it easier. IIRC BLE power mode + wake on BLE + wifi would probably work for easy use!
Sounds like a far off weekend project
viraptor 1 hours ago [-]
> I don’t want to buy an IoT hub.
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.
hardwaresofton 52 minutes ago [-]
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 :)
Asmod4n 5 hours ago [-]
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.
hardwaresofton 5 hours ago [-]
> 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.
Asmod4n 4 hours ago [-]
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.
hardwaresofton 4 hours ago [-]
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.
Asmod4n 2 hours ago [-]
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.
hardwaresofton 1 hours ago [-]
> 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
Asmod4n 38 minutes ago [-]
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.
hardwaresofton 22 minutes ago [-]
Welp that's depressing.
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.
Asmod4n 50 minutes ago [-]
Thread and Zigbee implement the same IEEE standard.
Matter would be correctly the application layer protocol of thread and could be spoken over any transport.
Like HTTP
Asmod4n 4 hours ago [-]
Oh and, Zigbee has automatic range extension as part of its standard. Every device with a plug expands your network.
baq 6 hours ago [-]
> 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.
hardwaresofton 6 hours ago [-]
> 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!
baq 5 hours ago [-]
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.)
You should look into zigbee2mqtt IMHO.
yjftsjthsd-h 9 hours ago [-]
With Thread+WiFi, can devices talk to the internet? Because denying them that ability is a lot of why I like Zigbee/Z-Wave.
8 hours ago [-]
balloob 8 hours ago [-]
Wifi yes. Thread depends on the settings on the Thread Border Router. Ours defaults to no internet access.
hardwaresofton 7 hours ago [-]
I’m sure I’m speaking to the choir here but access to Wifi != access to the internet!
Why I’m excited about thread over wifi is that I don’t need any extra specialized gear and possibility one device could run by itself
cyberax 7 hours ago [-]
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.
hardwaresofton 6 hours ago [-]
> 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!
Also TIL KNX.
cyberax 5 hours ago [-]
> 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.
hardwaresofton 5 hours ago [-]
> 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.
cyberax 4 hours ago [-]
> 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.
hardwaresofton 4 hours ago [-]
Thanks for the color here -- sad but I get it.
Sounds like we're almost there and Zigbee/Thread are at least supportable with the same hardware. I can work with that I guess!
> No market demand, so router manufacturers just don't bother. The initial versions of Matter were a burning trash fire.
I remember hearing about this -- they fixed/improved it eventually but I guess the damage was done.
05 5 hours ago [-]
Lots of “smart” products come with BK7231x chips that are flashable to esphome, nobody needs another custom protocol (even if open) since esphome currently supports local encrypted transport that’s going to be better than 99% of what the Chinese (or even western) companies are going to design for local communication.
Oh, and hobbyists mostly aren’t going to pay premium for those either, unless those come preflashed with esphome and sponsor hass project, and even then 90% people are still going to buy the cheapest option on the market:)
Home Assistant is a very popular home automation platform used by many. Most articles and posts fail to mention concerns regarding the user experience, security and long term stability. The most common complaints are related to the ease of use and to the backwards incompatible changes. The ease of use complaints are usually about setting it up, putting together automations and setting up dashboards.
Home Assistant is described as a home automation solution which runs locally on your hardware inside your home. Its current development process has many issues.
https://github.com/home-assistant/frontend/issues/18549 is a serious privacy concern. Nabu Casa and the owners of the CDN can collect the following information about the users of a Home Assistant installation: the integrations they use, the IP address of all devices which use the particular Home Assistant installation, the user agent of the device opening the dashboard, the precise location based on IP address, the user's ISP and possibly very specifically the people through a combination of IP address associated with a specific set of integrations configured for an installation. Nabu Casa employees can claim that the data isn't sold or used. The people who run the CDN can do as they please without Nabu Casa's knowledge. It's not possible to load these icons without an Internet connection.
The recent changes made to the backups in Home Assistant OS aren't user friendly. It's no longer possible to make an unencrypted backup without resorting to manual work by invoking an action. This arbitrary change wasn't necessary. It shows that the development process is chaotic and without a clear focus on making Home Assistant a more polished solution with the user in mind. It's just what they want to do.
Security is yet another weak point for this project. Home Assistant is a Python monolith with 1000 direct Python dependencies and countless other indirect dependencies https://github.com/home-assistant/core/blob/dev/requirements.... All these Python packages and their dependencies are bundled in everyone's Home Assistant installation. This is likely the biggest Python monolith in existence. You can compromise this project by compromising any dependency. Some of these packages are provided by Chinese companies for cloud based integrations.
Some addons can only be run with net: host on Home Assistant OS. This is one more potential vulnerability if one of these addons is compromised.
Bugs and regressions frequently get ignored on their tracker. There's a bot which closes tickets for which the developers have no interest. They choose to implement new features and to refactor without concern for people who can no longer do what was once possible. Features can change from month to month without any regard for the user's experience or for the overall stability. The graphs are one such example. New or changed functionality appears to lack thorough design before implementation. Unstable changes make it into stable releases every month.
Paulus has recently stated that Home Assistant is the best home automation solution out there. It's not really the best because it's very good. It just happens to be the most popular among people with some technical skills. It's the best because the others are very bad, support less hardware, require a cloud connection, have poor security, are privacy invasive, require a subscription, are extremely expensive, are updated once per year or for several of the mentioned reasons.
Home Assistant's advantage over commercial solutions is its large number of integrations, that it's open source and that there's a large community behind it. I wouldn't call it better at all. It's very similar to commercial solutions when privacy, security and usability concerns are ignored. The advantage of some cloud free commercial solutions is that they're likely to be more stable without breaking something once per month or every other month.
Those who still want to run Home Assistant may want to run it as a Docker container without Home Assistant OS, to use a separate network for the smart home devices, to avoid cloud connected cameras, to avoid cloud based integrations and to isolate Home Assistant from the other non-IoT devices found on the network. It can be a high value target for hackers and for companies who want to sell your data. I wouldn't recommend running it if one's not tech savvy. It's not something one sets up for someone else who's not tech savvy either. Things will break. It's just a matter of time.
Rendered at 12:52:15 GMT+0000 (UTC) with Wasmer Edge.
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.
~Paulus Founder Home Assistant & President Open Home Foundation https://github.com/balloob
[1]: https://www.openhomefoundation.org [2]: https://www.openhomefoundation.org/blog/announcing-the-open-...
I have a Nabu Casa subscription, but I don't really need it.
My question is: is it really convenient to use only SaaS now if there is always the possibility of losing your data? I am referring to the case described in the article.
[1]: https://vrutkovs.eu/posts/home-infra/ [2]: https://github.com/VictoriaMetrics-Community/homeassistant-a...
PS: I'm working at VictoriaMetrics company
So, answering your question: > My question is: is it really convenient to use only SaaS now
no, it's not
I believe a lot of people who are upset with the product have radically incorrect expectations.
At least, that’s what I like to tell myself.
Shelly was early, the cheep chineese stuff was easy to hack but they eventually moved to cheaper and more esoteric chips where custom firmware is non existent or not as mature. This is changing back, though! The number of ESP-32 powered LED light controllers that I've seen on Ali that feature a USB port for reprogramming / have all the GPIO labeled ... even have a HA/ESP-Home/WLED logo on them is infinitely more than I saw in years past (a few is infinitely more than zero, right?)
My heuristic for anything operating at mains voltages is "If I can find a product that looks just like this on Temu/Aliexpress, I'm not buying it". They're probably white label products sourced from the same factories and suffer from the same quality issues.
Relays found in smart plugs are often sketchy in my experience. About half of the ones I bought or set up for others make unsettling noises that made me worried about poor electrical connections and risk of fire. I only have two Shelly plugs but those don't suffer from these issues.
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.
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)
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.
[0]: https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbe...
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
Thanks again for the rec.
Sounds like a far off weekend project
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.
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 :)
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.
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.
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.
> 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 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
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.
Matter would be correctly the application layer protocol of thread and could be spoken over any transport. Like HTTP
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!
You should look into zigbee2mqtt IMHO.
Why I’m excited about thread over wifi is that I don’t need any extra specialized gear and possibility one device could run by itself
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.
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!
Also TIL KNX.
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.
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:
https://eu.mouser.com/c/passive-components/antennas/?protoco...
[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.
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.
Sounds like we're almost there and Zigbee/Thread are at least supportable with the same hardware. I can work with that I guess!
> No market demand, so router manufacturers just don't bother. The initial versions of Matter were a burning trash fire.
I remember hearing about this -- they fixed/improved it eventually but I guess the damage was done.
Oh, and hobbyists mostly aren’t going to pay premium for those either, unless those come preflashed with esphome and sponsor hass project, and even then 90% people are still going to buy the cheapest option on the market:)
https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/
1. Sell the gullible public long-term memberships to a gym, with long-term subscriptions.
2. Sell the subscriptions to a 3rd party.
3. Close gym. Subscription contract still valid.
https://www.celebitchy.com/8971/dr_phil_ran_a_health_club_sc...
Home Assistant is described as a home automation solution which runs locally on your hardware inside your home. Its current development process has many issues.
https://github.com/home-assistant/frontend/issues/18549 is a serious privacy concern. Nabu Casa and the owners of the CDN can collect the following information about the users of a Home Assistant installation: the integrations they use, the IP address of all devices which use the particular Home Assistant installation, the user agent of the device opening the dashboard, the precise location based on IP address, the user's ISP and possibly very specifically the people through a combination of IP address associated with a specific set of integrations configured for an installation. Nabu Casa employees can claim that the data isn't sold or used. The people who run the CDN can do as they please without Nabu Casa's knowledge. It's not possible to load these icons without an Internet connection.
The recent changes made to the backups in Home Assistant OS aren't user friendly. It's no longer possible to make an unencrypted backup without resorting to manual work by invoking an action. This arbitrary change wasn't necessary. It shows that the development process is chaotic and without a clear focus on making Home Assistant a more polished solution with the user in mind. It's just what they want to do.
Security is yet another weak point for this project. Home Assistant is a Python monolith with 1000 direct Python dependencies and countless other indirect dependencies https://github.com/home-assistant/core/blob/dev/requirements.... All these Python packages and their dependencies are bundled in everyone's Home Assistant installation. This is likely the biggest Python monolith in existence. You can compromise this project by compromising any dependency. Some of these packages are provided by Chinese companies for cloud based integrations.
Some addons can only be run with net: host on Home Assistant OS. This is one more potential vulnerability if one of these addons is compromised.
Bugs and regressions frequently get ignored on their tracker. There's a bot which closes tickets for which the developers have no interest. They choose to implement new features and to refactor without concern for people who can no longer do what was once possible. Features can change from month to month without any regard for the user's experience or for the overall stability. The graphs are one such example. New or changed functionality appears to lack thorough design before implementation. Unstable changes make it into stable releases every month.
Paulus has recently stated that Home Assistant is the best home automation solution out there. It's not really the best because it's very good. It just happens to be the most popular among people with some technical skills. It's the best because the others are very bad, support less hardware, require a cloud connection, have poor security, are privacy invasive, require a subscription, are extremely expensive, are updated once per year or for several of the mentioned reasons.
Home Assistant's advantage over commercial solutions is its large number of integrations, that it's open source and that there's a large community behind it. I wouldn't call it better at all. It's very similar to commercial solutions when privacy, security and usability concerns are ignored. The advantage of some cloud free commercial solutions is that they're likely to be more stable without breaking something once per month or every other month.
Those who still want to run Home Assistant may want to run it as a Docker container without Home Assistant OS, to use a separate network for the smart home devices, to avoid cloud connected cameras, to avoid cloud based integrations and to isolate Home Assistant from the other non-IoT devices found on the network. It can be a high value target for hackers and for companies who want to sell your data. I wouldn't recommend running it if one's not tech savvy. It's not something one sets up for someone else who's not tech savvy either. Things will break. It's just a matter of time.