[hardwaresofton]

> 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]

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]

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]

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.

[hardwaresofton]

> 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.

I think IKEA bulbs will also be in my future.

[Asmod4n]

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