IKEA ditches Zigbee for Thread going all in on Matter smart homes
theverge.com
theverge.com
On top of that, the switch breaks compatibility with existing hardware (except for the Touchlink functionality). If you have a bunch of Zigbee devices, but at some point want to add some of the new ones, you need to start thinking about replacing all the perfectly working Zigbee devices or have a fragmented network.
Yes, if you're using the manufacturer's half-assed smartphone app, but if you're on Home Assistant, like basically anyone who's serious about their smart home, having multiple kinds of smart devices isn't really a problem. It's just one more radio to configure. Some people run both Zigbee and Zwave, some people run Zigbee + Wi-Fi or even Zigbee + Zwave + Wi-Fi + cloud integrations, Home Assistant doesn't care.
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.
We survived for over 100 years by getting up and flipping a wall switch, so the risk of a few hours without smart features shouldn’t be a showstopper.
Alternatively, both Sonoff and Home Assistant do a thread dongle for about $30 that you can use simultaneously with a zigbee one. Plus if you have any of the following, they can be used as a Thread border router: Apple TV, HomePod, Echo G4, Eero 6/7, Nest Hub, Nest Wifi, Google TV Streamer. There's also the OpenThread Border Router which can be used on certain ESP32 hardware (ESP32-S3 for $10 or ESP32-H2 for $6?) but that obviously requires more work.
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.
Something about HAOS uses docker to install and manage extensions, whereas if you run the HA docker container it can't as docker-inside-docker isn't supported (?), and thus some functionality is unavailable (at least at the surface level).
Here are a few “smart” things my home assistant can do in my home, which are impossible with an “appliance”:
- when washer or dryer is done (detected via power monitoring), send push notification. But ONLY send it to the people that are home at this moment. If nobody is home, send it to the person that left home last. (i store this state in a custom _last_person_departure_ variable).
- if the washing machine door was closed after it was emptied, send push notification to the people that are home. Remind them to leave the door open. (front load washer where closing the door leads to mildew)
- If a water leak is detected, send a push notification. if not ACKed within 3 minutes, send a “critical alert” to everyone’s phone.
- If nobody is sitting on the couch (pressure sensor under the cushions), and no media is playing on the tv, turn off the tv after 20 minutes.
- turn on the hallway light if motion detected or if the front door is in an open state. but keep it on if the door remains open (chatting with a neighbor, bringing in packages, etc) Importantly, delay the “turn off” action with a timer and reset that time if more motion detected or the door is re-opened.
- when i’m on a work zoom call, automatically turn on a red light next to my home office, so family doesn’t interrupt.
That’s just the tip of the iceberg. I also get a push notification when the printers ink is below 20%, and more.
Unfortunately a truly smart home requires effort to set up. Because a smart home is unique to YOU. Everyone has different workflows, habits, and preferences. It’s not a generic off the shelf component like buying a washing machine, where the user preferences can be simplified to a handful of settings.
This makes me a little weary of your comment. I don't think I'd really care if my lights not working was due to a "manufacturer being flaky" if they worked yesterday, but don't today.
Are you talking about devices being flaky on first setup (which sucks, but is understandable), or are you talking about them being flaky after an update?
(For temp and humidity sensors the Bluetooth Xiaomi sensors are great and they're about $5 each)
That is, the flakiness isn't due to HA updates breaking connections or an unstable server, but rather manufacturers designing closed and/or brittle systems. Try as they might, the HA authors and surrounding community can only do so much for such devices.
Also, I believe the word you're looking for is 'wary' (as in, to be skeptical or suspicious), not 'weary' (as in, to be tired). :)
I feel like half the griping about HA is people realizing all the hardware errata and physical reality bullshit embedded developers have to paper over on a daily basis.
E.g. no, you can't just read contact sensors without debouncing
I should probably just remove them, but I don't have any automations that depend on them.
It's been a bit since I was operating it, but I did at times certainly have issues with updates—perhaps just individual plugins or system updates that created an issue, either way, still a situation where I had to sit at a terminal and debug. I only ever ran the Docker version, not the OS, so perhaps this is less problematic in a more completely controlled stack.
I don't think I'm alone in this view, broadly speaking: https://www.reddit.com/r/homeautomation/comments/18hvl3b/i_g...
I ran the docker version on a QNAP for a long time, now on a Home Assistant Green.
At the beginning (0.7 or maybe even earlier) I remember to have to reconfigure or reset my instance a few times a year. Those times are long gone.
https://homeautomation.substack.com/p/setting-up-home-assist...
00. Installation method - you don't flash ISO into your thumb drive, no you boot ubuntu from usb drive, THEN download ISO and THEN flash your boot drive. This caught so many people. RTFM of course but FM should just say this in huge letters - BOOT UBUNTU FROM USB FIRST.
0. Host method - you either run this in docker and don't get like half features (add-on store) OR install HAOS and don't have access to your device anymore. Wanna use your computer for something else? Tough choice.
1. Integrations vs add-ons vs HACS - why is this so complicated. Add-ons only work when you run HAOS, but HACS works on any installation method. I've spent so much time moving from docker to HAOS just to realize HACS store works with with docker.
2. Root - I've succumbed to running HAOS and now I have no idea how to get root remote root access. Yes I can connect keyboard and a monitor which I had to get for this reason only and there's 0 fun to work on basic terminal on a high res monitor where you can't change font size.
3. UI performance - wanna explore data from one of the devices - either select all sensors from it and let UI crash trying to display 50 charts or pick sensor one by one (with broken scroll on desktop app).
4. Copy paste - how did they managed to break this on their desktop app is beyond me.
5. Disorienting UI - whenever I wanna reboot something I'm pissed off. Whenever I wanna find integration or add-on - I'm pissed off. Why there's media and to-do list? Why do I have to enable professional mode to unlock some menu's?
6. Bizarre way of doing things - wanna add derivative sensor? Install file editor, find some file, then fight fucking YAML syntax and then maybe reboot or reload or restart. Good luck! Why I need to add home assistant user and create password for my light switch?
Bonus. They are not selling their own device (which is great way to get started) and offering some cloud subscription which usually is on path of enshitiffication.
And don't get me wrong, there are things that it does't great and is very powerful and useful, but man it is difficult.
Integrations are running under control of Home Assistant, while addons are separate applications, running under control of the OS. With HAOS they have that control as they are delivering the OS. They are simply lacking the manpower and experience to deliver a smooth control of external applications for every OS.
> 2. Root - I've succumbed to running HAOS and now I have no idea how to get root remote root access.
Yes, that is a pretty big flaw. They are trying to make it a simple as possible, they are probably flooded with complaints and issues from too many people with barely enough knowledge. But this whole setup they maintain with HAOS is really annoying. Though, there is documentation[1] for this.
> 5. Disorienting UI - whenever I wanna reboot something I'm pissed off. Whenever I wanna find integration or add-on - I'm pissed off. Why there's media and to-do list? Why do I have to enable professional mode to unlock some menu's?
They are doing too much, want to serve everything to anyone. Really annoying, but I guess the loud voices kinda demand this one-fits-all-solution. They should really rethink they focus and architecture. Maybe making clear, distinctive apps for specific jobs might be better.
> 6. Bizarre way of doing things - wanna add derivative sensor? Install file editor, find some file, then fight fucking YAML syntax and then maybe reboot or reload or restart.
To be fair, that's really depending on the devices and nowadays often an old solution. They have worked really hard to get rid of YAML for the normal jobs. But at the end of the day, HA is a hacky tool in a vibrant, extremely diversified environment. They are doing their best to deliver a unified solution, but it takes time, and sometimes still some hacking. HA has come a long long way, and is changing really hard, and they probably have still many technical debts left from a decade ago. Their biggest problem at this point is probably history and complexity. People who are using it for years, which are still knowing the old ways, or encountering old documentation.. And it's hard to get a clear picture with all the things that HA is offer and doing.
[1] https://developers.home-assistant.io/docs/operating-system/d...
2. Ssh and vscode addon?
6. Been using it for 2 years and have yet to touch yaml.
Usually when I had some zigbee issue, it was because of a crappy product (eg some wired air sensor that would spam the zigbee network every 1 second with a lot of data), so then I just stop using such devices and before I buy I check compatibility with HA / zigbee2mqtt.
I even once had my wife add a bulb and while it wasn't easy, she did it.
When a year later I asked brother about the some random bulb he had - didn't work anymore.
It's even better, because Norwegian law gives 5y guarantee on electronics - could just have this bulb replaced as faulty in the shop.
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.
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.
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.
This doesn't work when mixing Zigbee+NonZigbee devices.
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.
It always seems like you need $100+ dollars of hardware to run it well, not just a pi and an SD card.
It seems like it's a lot better now, but until recently it didn't seem like it was anywhere near PLC grade reliability.
Is it up to the level where you could install it at a non-technical users house and expect it to run for five years without maintenance?
And despite it not being open enough for open source enthusiasts, it's also got a bad name with manufacturers. I work for one and I asked why we wouldn't implement matter and thread and it was laughed off because apparently marketing will never give up their own app as a data collection and cross selling vehicle. Of course those are exactly the reasons I don't want this.
I didn't even know about the certification that only big players can do and the locked firmware requirements. It's ridiculous. 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?
On the other hand, I believe all the major Thread Border Router manufacturers (Apple, Google, Amazon, Samsung) have updated their Thread routers or committed to updating their Thread routers to Thread v1.4, which is a pretty major upgrade.
[1] https://matter-smarthome.de/en/interview/nanoleaf-ceo-gimmy-...
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"?
As long as people keep claiming this asymmetry doesn't exist we will keep getting things like Thread
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.
A border router is used to bridge e.g. Thread networks onto a regular IP network so that your non-Thread smartphone can talk to it, and so Matter devices on different network types can link up directly if you want a Thread switch to control a WiFi light for example.
Matter devices use link-local IPv6 addresses and cannot route packets onto the internet even if they wanted to.
Spoiler alert: No. There's a whole bunch of bullshit: https://developers.home.google.com/matter/integration/pair#p...
You can sort of run your own device if you're fine with giving google far too much information and they can block you at any time.
Face it, bigtech has a hardon for closed ecosystems. If they could they'd make it so every computer that wants to send an ethernet packet has a private key blessed by some bigtech cabal which they can revoke, but luckily for us this standard predates this gross new fetish.
And besides, so far I've been able to use 100% of my Zigbee devices with Zigbee2MQTT and it's been wonderful.
a closed ecosystem means hermetically sealed: nothing gets in or out. matter is just treating their brand with respect. not different from any other industry standard.
if you're saying "I want all industry standards to become governmental ones", well, I happen to agree.
> NOTE for Android users: You need to follow the instructions at the bottom of the page to add the test device to the Google developer console, otherwise commissioning will fail.
Anyway, you absolutely should care about Google Home support if you want to sell a device. It'd be ridiculous to sell something that only works with Home Assistant even if I'd personally be perfectly happy with that.
Are you saying the home assistant docs are wrong? Please, elaborate.
> This process is a bit more involved but is also pretty straightforward and easy to do in most setups, though it is not officially supported and is intended for developer use.
I'll stick with my zigbee flow of "press 2 buttons"
I do not want another crappy USB C type experience to satisfy the zero dollar hobbyist. We'll just end up with zero dollar garbage from large manufacturers named Xhflk.
Here is the Silabs explainer on the certification process: https://docs.silabs.com/matter/latest/matter-certification/
You can! You just can't ship it/sell it without certification.
https://www.reddit.com/r/homeassistant/comments/1adh8ah/esp3...
I did exactly that last week... Certification is required if you want to use the trademarked logo in your marketing materials (same as with Wi-Fi and Bluetooth afaik).
Thank you for the clarification?
You can connect devices without this, it just shows a warning during commissioning that the device is not certified. No impact whatsoever.
It doesn't even enforce that. You are free to use uncertified devices on your Matter network, as hobbyists making their own Matter devices can attest.
In both cases can ignore certifications and have a working product. I run uncertified, open source Matter things myself.
It's not like HDCP in that HDCP is a technology no end-user wants, but something certain content creators want.
If "closed" means open to anyone that has their product certified to adhere to the rules, then I'm ok with that.
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).
I have been using https://github.com/t0bst4r/home-assistant-matter-hub to expose my home assistant devices to Google Home without having to expose my Home Assistant to the cloud.
Second, certification is what separates Z-Wave from Zigbee which in my (n=1) experience means less issues in terms of compatibility.
Of course, with that GitHub package I shared all of that goes through the window, but who cares? I can clone the code and modify it.
Correct.
Basically, it’s not much different than when an Open Source project is supported by a company that separately offers an “Enterprise” option where they host the application and provide additional Enterprise features and support. It’s not required, but a business might choose to do it.
I mean, that PKI doesn't exclude non-approved manufacturers from producing Matter devices, you can always trust their PAA (their CA) in your border router if it's not a well-known manufacturer. And also, I am pretty sure that if this is the case the Matter border router should warn you of this and ignore the fact that the PAA is not in the local store of root CAs (as we did in the times when we had https without Let's Encrypt and didn't want to pay Comodo to sign our certs)
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.
But I read that Thread supports IPv6 via mesh networking. It did always feel a bit awkward having Zigbee networking and IP networking competing over the same site. It would be very nice to issue commands from any peer to any other peer, using standard networking. Can anyone here confirm that Matter/Thread will be a bright, open, and happy new future?
A lot of people I know would scoff at “smart home” stuff. I used to. Having a programmable house is incredibly useful though. When all your lights and sensors are available for programming you can do stuff that’s cool not because it is particularly innovative but because it is incredibly easy to implement:
- my partner can control a “do not enter, call in progress” red light bulb;
- my outside lights trigger off PIR, door sensors, or Ring motion detection;
- I have a series of indoor lamps come on in succession if motion is detected outside at night;
- we programmed a push button to turn a light green on one tap and red on a double tap for a fun game of twenty questions;
- and my indoor Ring cameras shut down unless both my partner and I are out of the house.
All of these things were trivial to do given that everything is available on one Home Assistant instance!
Sorry, it’s a closed ecosystem. It relies on PKI and device attestation to ensure that only devices from approved partners are usable. It’s unlikely that small players can participate, and zero chance of any homebrew scene.
can you explain what you mean by this?
Also: the Apple home app can’t change their mode to matter, you have to do that in home assistant.
The part about Matter that's "closed" is the device attestation process; the Distributed Compliance Ledger (DCL) contains a closed set of trusted Product Attestation Authorities. The device's Device Attestation Certificate (DAC) needs to chain to these PAAs for a "production" Matter Commissioner to enroll the device in a fabric without additional steps.
Here's he thing: all available Matter Commissioners make it really easy to commission a device with an untrusted DAC; for Google you need to add the IDs for the device to a Developer account associated with device you're trying to use as the Commissioner, and for Apple (at least as of a year or so ago when I last tried this), you just press "Trust this untrustworthy device" on a dialog box.
* The list of officially trusted companies and root certificates is stored on a blockchain, for whatever reason, but at least this way it's a fairly open list and it's supposed to be shared equally across all vendors.
* It's a lot easier to get an official key provisioned / device certified. It's not like UEFI where there's some murky trusted set of root keys belonging to a major manufacturer (Microsoft) who blesses things at a whim.
Importantly:
Even if the "vendor" (in this case, it's Google/Apple) stopped supporting test keys in their Commissioner, one could still run a "fully private" Matter fabric with their own Commissioner. Of course, if this happened, a user couldn't commission their devices onto the walled garden Google Home / Apple Home ecosystems, but, they could still make their own Matter fabric with their own Controller. It's not done this way normally: even with HomeAssistant, which can run its own Matter Controller, the Commissioner role is typically delegated to Apple/Google SDKs through the Home Assistant app. But this is because it's a huge pain to develop a working Commissioner (due to Bluetooth, mostly), not because it's not possible. There's no "lock-out" that causes Matter devices to only provision to approved Controllers/Fabrics - the lock only goes the opposite direction, to prevent end users from buying insecure/spyware devices with the Matter label.
However, unfortunately:
* You don't really enroll your own key or root certificate with most of the "standard" (Apple/Google) Commissioners to use them with development devices - rather, you use a fixed set of vendor or device IDs which signify them as test devices (in the extra easy path, you even use a fixed device certificate for a Test Device). This makes sense from the constraint that users can still build and develop their own devices while protecting the ecosystem from "rogue vendors," but it's not like UEFI Secure Boot in this case where the end user can enroll their own keys and truly control the system end to end.
Now again, there's nothing stopping the end user from building a Commissioner which would trust their own self-signed certificate, besides it being a pain in the butt, but that's not how it works by default - it's truly a development mode, not a bring-your-own-keys.
I was working on a Matter device but it never got certified due to high cost/lack of customer demand.
Matter states that firmware images “may be encrypted.” This is not a requirement, though encryption is allowed and may add security
(https://community.arm.com/arm-community-blogs/b/internet-of-...)
Disclaimer: I haven't tried serial flashing of Shelly/Sonoff Matter-enabled devices myself, just remember some complaints of customers that failed to re-flash such devices.
... what?
All it means is that the "commissioner" (broker which attaches Matter devices to your Fabric) ignores the chaining of the device attestation to an approved CA. In the case of using Google's Commissioner, this requires adding a Vendor and Product ID in your account's Developer console. In the case of Apple's Commissioner, it's just pressing a "Trust this unknown device" button. That's it.
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.
Some manufacturers also make Z-wave devices, like this[3], which has some generic low-voltage inputs and outputs.
So while not as trivial as other things, it's possible to do a lot of DIY stuff.
[1]: https://z-wavealliance.org/development-process-overview-2/
Funny, to me that's a feature. It makes the threat of a hacked device that exfiltrate data from within your network much less likely. I avoid any wifi device because of that.
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.
when? In the 1990s?
I have/had a segmented network, so I made sure my router accepted this route so that devices on different networks could communicate with the Thread devices. It worked, usually. However, I ran into some challenges with the reliability of communicating from my phone to various devices. I never quite got mDNS reflection 100% correct, and I strongly suspect that's my problem. If you look at an mDNS entry for a device, you'll see some advertise all their IPv6 addresses including link local (fe80::). I suspected some clients were dumb, trying the first IP they found, and giving up when it didn't work. I was working on modifying the golang mdns-reflector project to filter these entries. I had some success, but I haven't finished.
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?
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.
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.
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.)
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.
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.
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?
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.
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.
I'm currently blocked because Google and Amazon don't support "Generic Switches". Which means that if I switch over a light-bulb to being a smart one I can't use something like the Arre Smart Button to control them. Which seems like such a standard requirement that I do not understand why it's not supported.
If Ikea will let me set that up then I'll be delighted.
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.
UPDATE: Ok, is this about the state of Matter implementation? I think I misunderstood that.
I ended up pairing mine with a 'ConBee II' and with a bit of Go code was able to receive sensor data with very little latency, and activate switches and lights very quickly.
What a shame they discontinue such a great product line. But I already decided this is the last home automation technology I'll invest in. ZigBee seems perfectly suited for this role, and no idea why we need yet another new standard. Although I also said that switching away from x10, if anyone still remembers that.
I managed to get remote access working via an iobridge IO-204 X10 module and a custom iOS App. Great fun. I still have the X10 stuff lying around because I was then trying for local only using the X10 serial controller that I never managed to hack.
e.g. if I add future Ikea lightbulbs or other equipment, will this mean managing them via a different system?
(By the by, I've been very happy with Ikea bulbs so far; while other people complain of LED bulbs with a short lifespan, [touches wood] I've not had a single failure with Ikea smart bulbs, with ~7 years and counting on one of mine.)
There have been many attempts at industry standards but they fray around the edges. Nobody understands that a protocol and a spec is not a user experience, so the standards just become the basis for closed walled garden “systems.”
It’s why I stay away from it.
I will just have make sure that I have a spare zigbee radio in case they eventually disappear from the market.
https://staceyoniot.com/matter-only-solves-about-one-of-the-...
I think the whole point of Matter is that the devices are manufacturer independent and you can use any device with any hub.
I love my Ikea smart home gear, it works really well. Odd that a cheap furniture store that sells meatballs seems to have a more coherent smart device strategy than major tech companies!
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.
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.
... Yes?
I use Lutron so I'm less concerned about obsolescence... but yeah. Pretty much every smart light switch I've ever used is just a normal light switch with additional networking capabilites.
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.
But if you imagine a typical consumer, not a tech nerd, I think "smartphone and bluetooth" is by far preferable to your 4-step process.
A typical consumer has bought a zigbee hub (like they need to buy a thread border router), then use their phone to press a button in the app and then they press a button on the device. Still dead simple and doesn't require flaky bluetooth from their phone, which in 2025 most androids still suffer from.
Maybe I judge them poorly because they’re the cheapest devices I let myself buy? Idk. They look great though.
They are also pretty good at labeling the products in their website, you can search by “last chance to buy” (or local language equivalent) to see the list.
A member of my family works in customer support for a company making devices using both zigbee and thread, and claims that support calls for debugging zigbee are often among the longest (and thus most expensive) calls they handle.
Unsure what IKEA's tech support looks like, but I assume that most issues not solved by support turn into returns, which are also bad for the bottom line.
You can probably plumb Home Assistant into your MQTT server from there.
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.
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)
For what you're looking to do in principle you don't really need any of this after the initial commissioning. So long as the radio waves can reach the devices they will be able to talk to each other.
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.
FWIW, this is purely an HA issue, not a Matter one. Once HA includes the Matter credential store in backups/restores, the experience will be the same.
Out of curiosity, what is the reason you find yourself completely wiping and re-pairing all of your Z-Wave devices?
It was more a comparison of how quick and easy adding a Zigbee device is compared to adding a Matter device. Hit "Enable join" and the new device just shows up. For Matter it's either scanning a QR Code, waiting, hoping your phone is close enough for the initial bluetooth handshake - or hit "share" from an existing smart home platform (e.g. Apple/Google Home) which in my experience takes around 30s at a minimum.
Bold move.
A pity there's no home standards for audio streaming. Matter Cast is an abomination, unfortunately: from what I can tell it requires native apps for each device, and there's not really an app store system, and indeed seemingly many devices only can stream via the pre-installed software!!
Really emphasizes the incredible power of Netflix's DIAL protocol, which tells a device to go to a URL & opens some command channels. Which is, if you squint, what Chromecast 's protocol was for a long long time (now I think there's also the ability to ship native apps to devices too?).
Really glad to see Ikea on board here. This creates a lot of pressure for other devices makers to modernize & use the much improved Matter stack, with much better network performance & much more standardization for Apple Google & potentially other control fabrics to make viable home systems, something Z-wave and Zigbee weren't positioned to make great progress on.
I've found Matter totally confusing. Given a device that supports Matter (e.g., a smart plug) and a set of devices I want to control that from (e.g., an Amazon Echo and an iPad) it is not clear to me what else I need.
Apparently I need a "controller", which is not necessarily the thing that I as a user would think of the controller--as a user I think of the controller as the device I issue command from. A Matter controller is apparently a hub for connecting the thing I'm using to issue commands to the IOT device I want to control.
And maybe I need a "Thread border router"?
As far as the controller goes, apparently at some point Apple added the ability for iPads to be Matter controllers, so you could use a Matter device with just an iPad (if the Matter device used WiFi...if it used Thread then you would need a separate Matter controller and I'd guess one of those Thread border routers).
I was able to briefly use a Matter smart plug with my iPad without having a separate hub, but it stopped working not too long after. I deleted the plug from the iPad and did a factory reset on the plug and tried setting up again, but now when the iPad searches for the device during setup it doesn't even see it.
Apple still has instructions on their site for setting up devices for direct use from iPad, but several sites on the net report that they actually dropped that support from iPad.
So lets say I go get an actual Matter hub. Do I need a separate hubs for using my Matter devices from my Apple devices and using my Matter devices from my Amazon devices? How about if I need a Thread border router--will I need one for Apple and one for Amazon? What if I add Home Assistant later--am I going to need a third hub?
All I'm really trying to do for now is use this one TP-Link Tapo smart plug that supports Matter from Apple Shortcuts without having to use the Tapo app. The Tapo app does integrate with Shortcuts but you have to be logged in to your TP-Link account on the app for it to work. Every so often you have to re-login, breaking your shortcuts until you do.
What I'm currently considering is installing Home Assistant somewhere, probably in a VM on my Mac for now but latter on a dedicated RPi if the experiments in a VM show that it will work, and setting it up to be my Matter controller for the smart plug. Shortcuts (or Siri) won't be able to directly use Matter to control the plug with that setup, but there is a Home Assistant app for iOS/iPadOS that can do so and that supports Shortcuts.
It will basically be like I'm doing now with the Tapo app but instead with the Home Assistant app and no need to be logged in to TP-Link (or to even have internet access).
PS: I wouldn't need any of this if Apple would just get around to implementing for iPadOS the same 80% charge limit option that they have had on iOS for ages. I'm using the smart plug and Shortcuts as a kludge while waiting for that. I charge through the smart plug and have a Shortcut automation to turn off the smart plug when the iPad's battery level rises above 80%.
You still need the TP-Link app for some more advanced functions like power metering though.
Matter is a bit like HTTP. It's WHAT your devices say to each other. It's a way for them to say "Hi, I'm a lightbulb and you can change my color and brightness."
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?
The matter network is just an IPv6 network, so I run coap server on my matter devices and then control them with command like 'coap-client -m post coap://[<ipv6 addr>]/open_button'.
.. but all I can remember from growing up is the X-10 POWERHOUSE
So it's a closed ecosystem that makes money for a cabal of corporations
If you want to participate as more than a hobbyist, you'll need to join the CSA (a non-profit mutual-benefit corporation). This will cost a bit less than half of what it cost manufacturers to join the equivalent organization for Z-Wave — a closed, single-vendor, non-IP-based solution that was state-of-the-art 25 years ago.
Money paid by commercial vendors funds stuff like test labs, interop events, and compliance support systems.
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.
(1) https://tomasmcguinness.com/2025/06/27/matter-building-a-tin... (2) https://tomasmcguinness.com/2025/06/30/matter-tiny-dishwashe...
You can definitely add uncertified accessories (using CSA test Vendor ID 0xFFF1) to HomeKit via an "Add Anyway" confirmation. Because Apple tends to be extremely conservative about this kind of stuff, I'd expect that all systems that support Matter would allow this.