|
|
|
|
|
by Asmod4n
393 days 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. |
|
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.