• 0 Posts
  • 9 Comments
Joined 2 years ago
cake
Cake day: November 26th, 2023

help-circle


  • This sort of makes it sound like the advantage of Thread is merely that it’s new, and therefore nobody will be affected by having a poor pre-existing Thread setup. If ISPs were sending people Zigbee hubs, it sure would be the cheapest shit available, which could very well translate to similarly terrible Zigbee performance.

    I see your point, but there should be much more merit to the specialized IoT protocols than just that nobody has yet flooded the market with terrible Thread/Zigbee devices.

    I’m not sure manufacturers choose WiFi because of hardware costs. There are often other reasons (some good, some terrible) for this choice, but I’m certain Zigbee support has to be cheaper; having disassembled plenty of such devices it’s almost always a dedicated IC and a tiny PCB trace for an antenna. WiFi support requires a fairly complete TCP/IP stack implementation, basic certificate management etc. which will inevitably require a small SoC; and while prebuilt solutions are plentiful, Zigbee alternatives are an order of magnitude cheaper.

    I can imagine software development costs being lower, though, given how every other programmer knows a fair deal about TCP/IP networking, while good comprehension of dedicated IoT protocols is a much rarer skill, there are also much less community resources and open-source solutions available etc.


  • Both Zigbee and Matter do not rely on cloud connectivity as a protocol

    In my ideal world, no devices would not rely on cloud connectivity ever, regardless of their choice wireless transport layer. The fact that the nature of Zigbee or Thread stop device manufacturers from stupid practices (such as relying on direct WAN access) is nice, sure, but does being less capable really make them better suited for the job? I would prefer to appreciate Zigbee or Thread for what they are and have, rather than by the fortunate side effects of what they can’t do.



  • Using it for very-low traffic applications is simply not what it was designed to do

    Was it not? Sure, it wasn’t specifically designed for low traffic, but it was designed with a wide range of traffic levels in mind; after all, virtually every WiFi capable device, home automation or not, uses very little traffic most of the time as it idles. Now, I absolutely appreciate Zigbee or ZWave being optimized for minimal energy consumption, which is useful for some device types; but I feel it isn’t right to call WiFi a poor choice for low traffic just because it also handles very high traffic well.

    You raise an interesting point about congestion, though, and that is very much was I hoped to learn about. I am sometimes under impression that device designers assume everyone lives in a detached house so interference can be ignored. Do you know how specifically is Zigbee better in this regard? Living in a condominium I always had very poor experience with Zigbee reliability, which might or might not have been due to local radio noise at various ares of the spectrum, so I’m curious to learn about details how exactly these purpose-specific transfer layers deal with noisy neighborhoods.


  • But that is not a fault of WiFi as a medium, but rather of the ecosystem of devices as we know them. Some company might launch a “Home Automation WiFi” product, which would be simply a home hub with a builtin WiFi router pre-configured with the recommended security settings. Zero config nor admin work required, just buy the right (hypothetical) hub.

    Though the real problem is that every other device relies on cloud connectivity, which highly limits such hubs effectiveness. Again, that isn’t an inherent fault of how WiFi works, rather I see it as a problem with the ecosystem and how consumers want their devices to work without any hub. Hopefully with more local-only devices that trend can still be reversed.