Perhaps I never put enough effort into it, but I've slowly coalesced on only having IKEA smart home products after years of acquiring piecemeal stuff and trying to wire it together with Home Assistant. I've shut down HA, and with every non-IKEA "smart" thing I have nowadays I just use the manufacturer's app (though I've become pretty sour on most smart devices overall and avoid them when possible).

I didn't really care for the way it became a sysadmin job where the stakes of a bad update or me not reading some release notes were that my light switches didn't work until I sat there and futzed around with it. I'm a programmer, enjoy Linux admin, run a whole bunch of servers....but having to dive into logs and YAML configs because the lights in my kitchen won't turn off is just not ideal. Similar issues with HomeKit, except when things mysteriously stop working there's even less ability to diagnose, given Apple's design principles that everything "just works", so apparently providing detailed error messages or diagnostics is gauche.

> if you're on Home Assistant, like basically anyone who's serious about their smart home

I would think that as smart homes become more popular the number of people not using the defaults will rapidly decrease and manufacturers will be less and less beholden to them.

I use HA and all my IKEA lamps are zigbee. Raspberry pi obviously doesn't have native zigbee radio support, so I have a USB zigbee antenna. Now this means if I buy any more IKEA lamps, I would need a second antenna, and the new lamps would not integrate into the zigbee mesh network. It really sucks.

Yes, but then you have a hard-dependency on HA for inter-network communication, which I try to avoid as much as possible (but I fail to, for a couple of subsystems). My failure model is:

1) no electricity, everything down but fiber, wifi, HA and the doorbell (they run off an UPS)

2) internet down: no problem, you just cannot reach the home automation from outside

3) Home assistant down: zigbee devices are paired together (like buttons + bulbs) or I have physical zigbee relays controlling dumb bulbs.

But, as said, I have some subsystem not fully working when (3) happens, like a zigbee button controlling a tasmota-based fan control.

Yes and no.

Pairing a Matter device takes much longer than pairing a Zigbee device through Z2M in my experience, and the Matter add-on still sometimes needs restarting as it refuses to allow any more devices to pair after a while.

But - rather than need a Zigbee dongle (or manufacturer hub) if you've got Apple or Google devices such as HomePods you've got a ready made Thread network as they act as border routers.

You can configure Zigbee devices to interact directly to each other, without using the hub as a middle-man for all their communication (the hub only does the configuration itself).

This doesn't work when mixing Zigbee+NonZigbee devices.

See: https://www.zigbee2mqtt.io/guide/usage/binding.html

It is still somewhat annoying for those of us with solid walls.

I can't just add a new Thread device at the other side of my house as the walls attenuate the signal between it and the border router. Equally I can't start replacing Zigbee devices willy-nilly in case I create Zigbee dead zones.

Not the biggest problem in the world but it does mean I'll likely need to get some pointless Thread smart plugs as temporary network extenders when I add my first Thread device.

Depends on your 2.4GHz band's saturation. Where I live I have only a few "good" channels. I have about 350 zigbee devices over two separate networks - and thus two channels - and the remaining good 2.4GHz channels are used by the physically separate IoT WiFi network. I dont want to deal with yet another network that may or may not like the channel I have to put it on.

HA doesn't care but your radio environment probably does. One of the great strengths of Zigbee is the mesh network - it doesn't matter where in my house I dump something, because all my bulbs are Zigbee repeaters it's going to get a signal and be able to route back to my HA box.

If I now get a _single_ Thread/Matter/Zwave device to replace one that's broken, ignoring the cost of a new radio for HA, I have to give very serious thought to where it's going to live vs signal availability as I build out yet another network.

tldr: HA is fantastic for coordinating disparate devices, but RF still bites.

most people don't want to manage a self-hosted server just for interacting with some smart devices in their home

zigbee has one great advantage over everything else: it's immune to DHCP and DNS failures and misconfigurations. if you're running a pihole or something, it can break iot devices in random ways if your DHCP server boots after your access points. (don't ask me how I know and the fix was to hard reboot my lights by cycling power in the distribution box. not great, not terrible.)

Agree. It’s a hassle to set up once but then you quickly forget about it.

> Just like Apple HomeKit you can add devices that aren't certified. It shows a warning, but apart from that it functions like a normal device (for as far as I can tell).

Correct.

Matter doesn't need internet access, it's an entirely local protocol even when you integrate to other vendor ecosystems.

Now, something like Google Home might decide to go online to talk to a Google Home Hub device, which is where Google wants to initiate all Matter communication from, but that's a Google thing, not a Matter thing.

>Why were thread and matter hailed as the open revolution when they're exactly the opposite?

Subterfuge PR or the subversion of original intention by greed.

Also, wasn’t there recent news that thread was being abandoned by manufacturers, even declaring it EOL? Or am I conflating that with something else?

> Why were thread and matter hailed as the open revolution when they're exactly the opposite?

Because consumers are lazy and dumb, and do not do any kind of research. They believe what is written on the tin. Why is OpenAI called "open"?

>the ability to commission a finished product into a Matter network in the field mandates certification and membership fees,[15][16] entailing both one-time, recurring, and per-product costs.[17] This is enforced using a public key infrastructure (PKI) and so-called device attestation certificates.[15]

Thank you for the clarification?

Matter is "open" in that it is published. It is not "open" in that you can make a matter device in your basement.

Here is the Silabs explainer on the certification process: https://docs.silabs.com/matter/latest/matter-certification/

Can I make a Matter device for myself?

I don't know why you're downvoted, it's the same reaction I had tbh.

You’re partially correct, but you’ve got enough details wrong details that you’re misrepresenting reality.

Matter has a public blockchain with certificates added to enforce which products are considered certified. This is called the distributed compliance ledger (DCL). The hardware devices are expected to ship with certificates on them that match the public ones, and it’s generally not possible to change the on-device certs.

This is distinct from “normal” internet PKI certificate authority where you can just swap out a few files or grab a new cert from Let’s Encrypt. Because this uses a dedicated blockchain with a history of signatures. Depending on how you want to control the device, you’d need to rebuild the whole chain of trust, including eg signatures from Google or Apple.

Also, from a practical perspective, I’m not sure of any actual controllers that let you point to different certificate sources. You can create devices with a “test vendor ID” (0xFFFF) and the controllers are supposed to ignore certs. This has downsides, like OTA updates require signing, you can’t encode proper identifiers in the device so info pages in apps are wrong, etc.

Also, the “border router” isn’t really the point of trust here, it’d be the actual controller device. A border router is just that, an IP router, like a WiFi router or a Ethernet router.

https://webui.dcl.csa-iot.org/

I disagree that there’s zero chance for a homebrew scheme; it’s pretty easy to enable development mode and commission self-made devices using Google Home or Apple Home on both iOS and Android.

And manufacturers tend to lock down their Matter devices, too, so you can't flash Tasmota or ESPHome on them. See: Shelly, Sonoff.

What? You can buy a very cheap ESP32 with Thread and easily build your own device with Matter/Thread and it will work. Doesn't seem that closed. There is OpenThread that is an open source implementation of Thread. Home Assistant is compatible with Matter over Thread devices... What's closed about this?

> It’s unlikely that small players can participate, and zero chance of any homebrew scene.

I personally think the worst part of this is that China manufacturers are less likely to produce Matter/Thread equipment.

Cheap China equipment has been great for Zigbee adoption. They're much less reliable, but fantastic for getting a smart home going for cheap.

This. The network fragmentation is the point, just like how some businesses would run IPX internally and use a proxy for web/IP traffic to protect corporate infrastructure from malicious devices or software.

Not everything has to be on TCP/IP. For smart home connectivity, I’d say that’s a feature, provided said networking standard is just as open as TCP/IP.

Yes, not to mention WiFi is so much more power hungry.

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

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.

> letting you use your phone

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 believe this is what thread v1.4 is attempting to solve. Apple has already updated their Thread border routers to v1.4, and Google, Amazon, and Samsung have all promised to update their border routers too.

Yes this is indeed a problem. You can get around this by piping the Z-Wave or Zigbee information into a MQTT server and basically run them as separate networks, with Home Assistant and MQTT tying it all together. But you will need some type of Zigbee to Ethernet adapter (Sonoff makes one, Raspberry Pi, etc.) or Z-wave to ethernet adapter (again Raspberry Pi). It's definitely clunky. But doable.

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.

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

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?

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.

Yeah.

I've got it up and running with some Nanoleaf lights and Amazon Echo running as border routers, and it's rock solid nowadays. But my wife hates voice-controlled devices, so I can't put them in elsewhere until I can slap in some buttons to control them. And that's basically not supported, which leaves me thinking that either the spec is a disaster or Google/Amazon are deliberately kneecapping it.

I think that applies to many other electronics they sell too. I find them pretty well engineered overall.

My guess is that it’s because they sell any particular piece of hardware in millions and it’s in their best interest to design it properly so they don’t have to deal with the returns.

“[Matter in its current version] doesn’t really help resolve the key issue of the smart home, namely that most companies view smart homes as a way to sell more individual devices and generate recurring revenue.”

https://staceyoniot.com/matter-only-solves-about-one-of-the-...

That's the strength of a DIY approach backed by a community of users like homeassistant, it doesn't get obsolete.

I will just have make sure that I have a spare zigbee radio in case they eventually disappear from the market.

I mean... I have an Aqara Matter over Thread smart lock that connects via AppleTV (which is a Thread border router) to Home Assistant. And I can control the lock both with HA and Apple HomeKit. And this whole thing works flawlessly. Aqara, Apple, open source HA. Never thought this would be so smooth.

I think the whole point of Matter is that the devices are manufacturer independent and you can use any device with any hub.

These types of switches will always retain manual control. It is common to separate the user facing switch from the actual electronics and everything still works manually. This means you can take any new or existing switch furniture and make it smart:

https://sonoff.tech/products/sonoff-mini-extreme-wi-fi-smart...

This is good because manufacturers of well built physical switches are usually rubbish at technology, and high tech electronics manufacturers are rubbish at making aesthetically pleasing, durable switches. Separating them gives you the best of both of worlds.

The obsolescence is in the radio integration whereby one day you can control it remotely, the next day you cannot.

IF they design it to work that way it can. Do you trust the manufacture to do that though? This is not only do they need to design it that way, but also that they need to ensure it works in all the edge cases. I've been in software long enough to know there are a lot of weird edge cases nobody thinks of that are then missed for years.

Just look at how long this page is:

https://www.home-assistant.io/integrations/matter/

Adding a device now requires a whole song & dance with bluetooth, a mobile phone and god knows what else.

Meanwhile zigbee is:

1. Buy a zigbee stick, there are dozens, they all work great

2. Press the permit join button in home assistant

3. Press a button on the device for 10 seconds or 3 times or whatever

4. You're done and it works!

Oh, and for some reason https://www.home-assistant.io/integrations/matter/#experimen... involves google cloud in the process of me testing a device I created locally on my own network

The final nail in the coffin is:

> It is recommended to run the Matter add-on on Home Assistant OS. This is currently the only supported option. Other installation types are without support and at your own risk.

So I can't even officially use this stuff without uprooting my entire operating system.

That’s been my experience. My older Zigbee/Z-Wave stuff seemed to work… up until it didn’t, and then cue wailing and gnashing of teeth. My Matter gear was initially a little flaky but is now vastly more reliable than Zigbee ever was.

Z-wave also uses 900mhz in the US, which penetrates walls better and has less competition with 2.4 (Zigbee). So while its closed, it usually more performant than Zigbee (in my experience...)

Yes - but it does feel over-engineered in some places (for good reason, having device profiles that everyone adheres to makes supporting a new device of a given class a doddle for smart home platforms) and it is definitely more finicky at present to pair devices than with Zigbee.

If I had to wipe and re-setup my smart home with 100 Zigbee devices and 18 Matter over Thread devices (Tado smart thermostat and TRV's) the Zigbee devices would take me about half an hour in total to have back up and running in HomeAssistant, the Matter over Thread devices would take me around 2-3 hours as you have to pair them one-at-a-time.

Is there some reason you felt compelled to comment on this, using that tone? Because it was completely uncalled for

That is my sticking point - every border router I can find has a bunch of other things I don't want. I don't want my lights available from the internet, I just want to turn on the shed outside light from inside the house when I have guests. (since they are likely to park by the shed and walk to the house)

That is I don't want google/amazon/samsung/apple to control my house. Most border routers are also connect to our smart home system. (there are exceptions but it isn't clear if they are better)

SMLight also do their PoE sticks that can be flashed to either talk Zigbee or Thread (but you'll need a border router, such as the OpenThread border router).

Their latest one has two radios so you can do both Zigbee and Thread from a single device.

I've found however, that Thread prefers several border routers around my house to operate well.

Ok, let me ask another way.

Can it operate without an internet connection and with an open standard that lets the me, the user, to be in control using a hub (if necessary) and software I choose, including an open source option should I so choose?

Or do I have to use proprietary hubs and software to control the devices?

In short, are there any end user hostile features or can I use the devices like how Zigbee works?

My understanding is that it can never be accidental since all access is mesh-local by default. You'd have to install a border router capable of supporting NAT64 features — SmartFriends™, I think this generally not possible with consumer border routers, correct? — and then explicitly enable it for a device.

> It's "closed" in the same way that all open wireless standards (Wi-Fi, Bluetooth, etc.) are closed. You can read the spec, use the open source SDK, and build devices without paying a cent.

My understanding - correct me if I'm wrong - is that it's not quite the same; I'm pretty sure you can make a wifi card on your own (maybe modulo FCC approval, but that's true of any radio) and you might not be allowed to put an official wifi logo on it without a license but it'll work without needing to see an officially signed cert or the user having to touch developer settings.