Kalman filters are great! For people interested of one used in practice, it's used by Sendspin to keep speakers in sync, even works in browsers on phones on 5G etc.
Home Assistant [1] has been written using web components and it has been great. In 13 years that we've been around, we never had to do a full rewrite of the frontend but always have been able to gradually update components as needed. Not being tied to the JavaScript industry upgrade cycle (which is short!), has allowed us to pick our own priorities.
We currently use Lit for the framework on top (you do need one, that's fine). For state management we just pass props around, works great and allows community to easily develop custom cards that can plug into our frontend.
The downside is lack of available components. Although we're not tied to a single framework, and can pick any web component framework, the choices are somewhat limited. We're currently on material components and migrating some to Shoelace.
I talked more about our approach to frontend last year at the Syntax podcast[2].
I've written quite a few web components that were more or less standalone. I've looked at lit quite a bit but never fully understood the "why". Could someone share their own personal experience with why they needed lit? What does it offer that can't be done with standard spec web components?
For me, a big draw of web components is that there's no `npm install` needed. I prefer to ship my components as plain JS files that can either be hot linked from a CDN or downloaded and served locally. Call me paranoid but I just don't fully trust node modules to be clean of bloat and spyware and I just don't want to have to regularly deal with updating them. I'd prefer to download a web component's static JS file a single time, read through it, and forget it. Maybe down the line I might revisit the source for the component as part of standard maintenance.
For example, I made a simple like button component[1]. Later, my friend made a cool component for showing a burst of emoji confetti[2]. I decided to optionally pull it in if an attribute was set on the like component. I downloaded his source and hosted from my own domain. However, there was actually a bug in his code that caused the confetti to "rain" if you spammed the like button a few times quickly. He fixed that, but I actually kind of liked it so I just didn't update the source for the confetti component.
> I've looked at lit quite a bit but never fully understood the "why".
Because people don't want to write hundreds of lines of useless boilerplate by hand.
Web Components API is verbose enough that you want to handle it with at least some abstraction. And at one point it was explicitly marketed as aimed at library/framework developers.
The cycle isn't short like people continue to say each year. I use react since 2014 and it hasn't changed much in 6-7 years.
I just built a script tag based reusable library for our company with react as the only dependency and thanks to stuff like shadow Dom and dialogs I get a much higher quality dev experience than plain js.
Best practises have changed dramatically in React since 2014 though. It’s easy to say “oh you don’t have to use hooks, you can keep using class components” but that’s not really true when the entire ecosystem is pivoting.
My bigger problem with React is that it ends up being used as a form of vendor lock in. Once your entire page is in the React VDOM it’s very, very difficult to pivot to a different framework piece by piece. That’s a core strength of web components.
Class components still work, and you can still use function components with hooks inside class components and vice versa.
In the parent comment's case of not having other dependencies, whatever the React ecosystem does isn't relevant if you aren't using any React libraries, which aren't really necessary anyways, especially nowadays when the LLM can reimplement what you need for you.
Nothing has changed about react-dom that prevents you from using React piece by piece—its docs still recommend attaching to a #root node even for single page apps.
Including web components in a React app is very seamless, and embedding non-React-controlled elements inside React is not uncommon (e.g. canvas, Monaco, maps), though for common use cases there's usually convenience libraries for React that wrap around these.
I think React originally started with the opposite intent: a library where you can mount a component onto selected elements of the web page. The lock in only happened when React was used to develop SPAs, which effectively meant that React takes over the document root. With that came state management, and frameworks that managed the complexity of state were not far behind.
Indeed. I've gradually adapted a server rendered jquery and HTML site to react by making react render a component here and there in react and gradually convert the site. Works great.
React DOM/views have not significantly changed in 12 years.
Our 10 year React projects that used mobx have not changed very much.
Savage take: I found React when it came out and I thought “wow you made this gorgeous DOM library and then you bolted on this messy ugly wart for state.” Then hooks came out and I’m like… this is a good electrician pretending they can also do plumbing.
Agreed I might have gone too far with "excellent". :) I think they do a good job though at operating at the level of abstraction React lives at, which generally requires less detail to live in the DOM (e.g. ids/classes used only for JS bindings compared to classic jQuery soup).
I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.
To be clear, it's not 100% react. It's the entire ecosystem around it. Want to take wigdet-x v3 for bug fixes. It requires newer react, which may or may not be compatible with widget-z I'm using. Newer react requires newer tools which aren't compatible with the configuration that was created by create-react-app from 2 versions ago. etc...
> I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.
That's what AI is for. It makes previously unfeasible projects feasible again
Exactly what are you using in React land that has lasted for 6-7 years. No components to hooks transition? No styling library changes? No state management changes? No meta framework changes? The React ecosystem is the least stable thing I have ever worked with.
I don't really agree that "best practices around useEffect have changed a lot". It's more that that particular hook was used a lot when it didn't need to be so the team finally wrote some guidelines.
Hey, cool to see you here on HN. I was recently looking through your codebase to see how you handle automations. It looks like you are relying on asyncio? I was wondering how you came to this decision and if you ever considered alternatives like a APScheduler or any other job library?
For state management, you might be interested in looking at Lit State. It's a very lightweight state management lib written specially for Lit, with the same mindset. With it you won't have to pass props everywhere all the time.
> Not being tied to the JavaScript industry upgrade cycle (which is short!),
> We currently use Lit for the framework on top
These two are contradictory statements.
1. lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer
2. Despite being acrively promoted as "not a framework just a lib" it's rapidly sucking in all the features from "fast moving js": from custom proprietary syntax incompatible with anything to contexts, a compiler, "rules of hooks" (aka custom per-dieective rules) etc.
> We're currently on material components and migrating some to Shoelace.
Again, this is exactly the "fast js churn" you're talking about.
Is it that Lit gives you a different way of authoring web components than the raw APIs? Yes, that's entirely the point. It's a library that gives you better ergonomics.
Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.
> Is it that Lit gives you a different way of authoring web components than the raw APIs?
than the raw APIs, than Polymer, than Stencil, than...
> Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.
No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"
Again, at this point I literally couldn't care less for your obstinate willful avoidance of authoring, and of your pretending that only the output matters. (And other lies like "lit is native/just html" etc.)
> than the raw APIs, than Polymer, than Stencil, than...
Yes, and? Those are all different opinions and options on how to author web components.
> No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"
It's extremely hard to tell what your point is. Lit's newer than React? Yes. Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components. We have customers do this all the time.
I don't avoid authoring, authoring is the main point of these libraries. And what you build is just web components. That's like... the whole idea.
Can you even communicate what this complaint actually is?
> Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components.
Keyword: make.
Again: you keep pretending that authoring web components is an insignoficant part of what people do.
At this point I am fully disinterested in your pretence.
> I don't avoid authoring, authoring is the main point of these libraries.
Yes yes. When authoring web components Polymer is fully compatible with lit.
(Funny when even lit's own channgelogs talk about backward incompatible breaking changes between versions, but sure, sure, Polymer you can just drop into the authoring flow, and everything will work lol).
But as I said, I am completely disinterested in web component salesmen at this point.
This has never been the case. Custom elements are DOM Elements and so are just JavaScript objects. Just like you can do aEl.disabled = true, you can set any prop to any type of value.
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.
reply