Edit: One thing Matter adds that was not in Zigbee is Bluetooth provisioning, letting you use your phone to add a device to your network without QR codes or numbers to type in.
Also fun fact; Homeassistant is part of the CSA and apparently, Google, Apple and others use HA for testing!
What follows are my two pennies as a developer working in home automation for 7 years. In this venue, readers may even have more knowledge regarding security, but I hope to speak to a common case.
I develop this exact feature though not for Ikea. Having made the sausage, some of these UX-first flows are worrisome.
Consider a lightbulb that factory resets given a rapid succession of power cycles. Most consumers won't have redundant power during a brownout, so there is an edge case where dirty power can mistakenly send the bulb to a reset state. (More plausibly, a child tugging at a light switch?) Now, any device in radio range has an opportunity to take over the bulb.
Provisioning is rare. Unless the owner enjoys tinkering, a residential IoT device is provisioned a handful of times in its life. I personally think it's a waste of time to optimize this flow if the improvements are also vulnerabilities.
Suppose I have a great new smart bulb. I'm ready for a larger market so I prepare a demonstration for Lowe's, hopeful for space in their lighting and rough electric aisles. Lowe's has seen this before. My bulb works fine but my users aren't technical. Lowe's replies, "we can't carry this. Users must deploy and control from a single app in 5 minutes." If I want my smart device to compete, my hand may even be forced to implement UX-first provisioning.
Companies like Lowe's and IKEA don't want to be in the tech support business. My bulb is a liability because their customers will call with complaints or questions.
I find QR codes to be a slick implementation. They don't even need electricity! Users can manage the system even when components go offline. Folks are trained on social security numbers and PINs for bank cards. It's easy to comprehend the QR code as a password.
It would be nice if technical users (installers) could reset the certificates or keys too. Besides losing the QR code, secondhand owners also want some assurances.
The security concerns probably have typically zero impact on the operation of the device. I'm not saying that the security concerns are unjustified. Really I'm actually leaning more that this is completely impractical and not a good replacement for a dumb physical switch. The security issues are unacceptable and the downtime caused by even the useless security measures available is even worse. (Also, the security measures seem more concerned with whether or not I have a license to watch my video on that particular device than preventing people from turning on my toaster.)
Can you explain more about how you reached this conclusion? Why are devices offline for years now?
And the whole point of this is to provide a seamless experience that's easier than using a physical switch. But in practice this just generates chores that are actually more time-consuming than simply using a physical switch. (Even in the single-user setup, I can imagine that I actually just revert to using whatever hardware controls are available on the device for quite some time because reprovisioning it is too much of a chore, and whatever wireless options it provides are not worth doing that chore.)
Requiring you to use your phone.
I understand the value in streamlining the flow for the Average Joe, but as a power user I wish there were an escape hatch. Ultimately, it's a minor quibble. It is a much more streamlined setup.
I haven’t tried Thread yet, but I’m delighted by the concept of having a couple of easy-to-maintain base stations (routers or whatever they’re called) connected to the local network and having devices automatically roam between them.
I am not delighted by the fact that an Apple Home Thread network, a Google Home thread network, and a Home Assistant native thread network appear to be different things that are not entirely compatible with each other.
I am running multiple Zigbee networks near each other (in a house and in a detached garage) with Home Assistant, MQTT server and a Sonoff Zigbee bridge, with Tasmota.
Hmm, in what way? The Matter standard does demand that devices support at least 5 of such "fabrics" at once. Where is the issue in practice?
Also one Thread advantage from that discussion made me laugh:
safe as the internet, using proven IP technologies
> as redundant and safe as the internet
Ahaha! Haaahahaha! i'm choking
(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)
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.
Current systems require a hub, talk protocol to hub, hub talks Zigbee to device. Home Assistant is great, but you still need device running it. Thread requires border router, but that is simpler device and only does networking.
Matter is the other part of Zigbee, the home automation profile. I get the impression it is bloated with multiple companies involved, but it is standard. Matter means that your phone can talk to Wifi device with your choice of apps.
The only thing that seems to advantage thread is manufacturers support, but I don't see what's stopped them to regroup around zigbee.
Any one has clues on why Thread was needed when zigbee already existed?