[willis936]

Zigbee is indeed good enough. The issue is that it solves the problem well enough and doesn't allow for maximizing how much customers are milked for. So customers will always choose Zigbee over any other option that also solves the problem plus some useless features, less control, and increased security surface area.

There is a very clear signal that is easy to pick up: either you support zigbee in your IoT device or you are trying to undermine the customer. No customer wants to be undermined. This should make Zigbee support a very easy choice for companies operating in a competitive space. Simply succeeding in the market should be enough and if it isn't that is the company's existential challenge.

[amluto]

IMO Thread has one major benefit over Zigbee: the Thread mesh can extend over Ethernet (via TREL). Zigbee ought to be able to do this too, but I’m not aware of anyone actually doing it.

There are a couple of in-progress implementations of Zigbee on a regular computer using Thread radios and the Thread RCP protocol. Maybe one of them will add the ability to use multiple radios.

[willis936]

I think it's a feature to enforce network segregation and have gateways be intentionally chosen. IoT devices are known to be high-risk security. We should shape the solutions such that the minimal energy path is a good one.

[amluto]

Huh?

If I have one building with one automation system but the building is too physically large or has walls that attenuate RF too much or where I don’t want a router node in the middle or where the latency across a mesh is too high, I want to be able to extend the network at low latency by plugging in another network-attached radio base station but without needing to manually pair each device to the closest base station.

Thread does this out of the box. Zigbee does not.