How is that possible when thread use an ipv6 stack over 802.15.4 while zigbee use a simpler stack also over 802.15.4 ? The only thing I see is that manufacturers prefer an ip stack because it's "easier" to develop for.
I should have been more precise, I don't doubt the claim about latency nor speed, but I really doubt that running an ipv6 stack requires less power than running the simpler zigbee stack.
Also one Thread advantage from that discussion made me laugh:
safe as the internet, using proven IP technologies
I haven't measured it, but: in a lot of embedded situations, the radio transmission time is the single biggest consumer of power. Thread+matter being more efficient on number of packets transmitted per command (the reason latency is lower) could actually translate to battery savings.
(Joking aside, I get that their point is they leverage the decades of work into IPv6 rather than recreate their own ad hoc, informally-specified, bug-ridden, slow implementation of half of the IP stack, but man did that phrasing get me)
> The only thing I see is that manufacturers prefer an ip stack because it's "easier" to develop for.
It is easier to develop on an ip stack.
You have great tooling and great libraries out of the box because pretty much everything uses ip nowadays.
Plus, at least part of the controllers people use for their smart home will use ip anyway. A non ip network will need a bridge.
> How is that possible when thread use an ipv6 stack over 802.15.4 while zigbee use a simpler stack also over 802.15.4?
Easy, zigbee doesn't use a simpler stack. Using the same physical layer protocol doesn't tell you anything about the rest of the stack.
It's actually pretty simple. 6LoWPAN which is what Thread uses is more efficient than the Zigbee network protocol. Packets are smaller and the routing is better. It's not particularly surprising to be honest because Thread was designed by people who knew Zigbee really well and were aiming for an improvement.
