This sucks. Matter is a closed ecosystem, enforced using a public key infrastructure (PKI) and device attestation certificates. Thread seems to require paying royalties if you want to ship devices. It’s disappointing that IKEA claims that this move is towards a more open ecosystem.
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.
> 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.
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.
Home Assistant "just works". Yes it has a ton of knobs, but in the 3 years I've been running it, it's had no issues. Certain manufacturer devices being flaky, yes, but as a platform, it's been rock solid. I've not touched its config in over a year and everything works as it should.
I guess the fact that some manufacturer integrations are flaky is hard to reconcile for me as far as the promise of "having multiple kinds of smart devices isn't really a problem". Regardless of whose fault it is, those flaky devices contribute to a less stable system.
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 have been using Home Assistant for more than 5 years. The stability of the system has improved a lot in the last year. I don't recall the last time I had to reinstall or restore a backup.
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.
For my flaky devices, it it not a manufacturer integration, but over Zigbee. It's definitely the device as my other Zigbee devices are solid. Others have reported issues with the device in question (Aqara Temperature and Humidity Sensor)
I ran the docker version on a QNAP for a long time, now on a Home Assistant Green.
I second that. Home Assistant "just works". I have had it running on this cheap used HP EliteDesk 705 G3 Mini Desktop for more than 4 years now without a hiccup and barely any maintenance or hygeing work on it. Just sitting in my tv stand and doing it's work.
Not who you asked, but I do it “manually once a year or so” on a HA instance in a container running on unraid. It sometimes causes problems. Recently HACS (not a built-in part of HA but useful to get some extensions) broke on a HA update and I had to spend more time that I would have liked figuring out how to fix it. It involved running shell commands inside the container. Definitely not for anyone who isn't a techie.
> Certain manufacturer devices being flaky, yes, but as a platform
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?
I think one solid way of handling the instability is to use high quality light automation (Lutron Caseta, for example) for the things you'll really notice, but for stuff you care less about (for me that's cameras, temperature sensors) you can use cheaper ZWave stuff w/ home assistant. The lights turn on and off when I expect, but temperature might update a little less frequently if HA is flaky.
Honestly, for any sensor that's basically just read only, the best thing I've seen is to just avoid all of the bluetooth/wifi/zigbee/zwave entirely, and just use basic tried and true accurite (or similar) sensors that never need updates and just pull the data with rtl_433. Way, way less fuss, they always just work, batteries last longer, by and large zero bullshit.
It's the devices that is flaky. Some of the shitty bulbs I got don't always turn on in one command but that was true via their own app too. Basically shitty devices aren't magically better via home assistant.
If I had to guess, they're probably referring to the way that certain devices broadcast their APIs to external services. A lot of them have no intention of allowing open access to APIs (e.g., my mini-split controller requires a slight hack to get it connected to HA).
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 have several Aqara temp/humidity sensors that intermittently lose connection. They don't affect the operation/stability of the rest of the HA platform and is not a problem with HA, as my other zigbee devices that report the same data work fine.
I should probably just remove them, but I don't have any automations that depend on them.
Yes it just works, but it's soooo difficult, here's my annoyances:
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.
Surprised at your issues with HA. Similarly to others that responded, my setup with HA / zigbee2mqtt and >30 zigbee devices (including some ikea buttons) has been pretty rock solid over many years, including easy migrations from an rpi3 -> rpi4 -> rpi5 (with ssd).
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.
The problem I’ve run into is that once you’re running a lot of devices, you inevitably end up with a bunch of automations and logic that can’t really be simplified. With Apple Home/HomeKit, everything Just Works, but having dozens of automation rules and scenes configured in Apple’s low—information-density UI is worse than managing yaml config.
There is a tradeoff here. If your expectations are high you will always be disappointed with a smart device advertised as an appliance. it’s difficult to customize to make it _actually_ smart if it’s designed as an appliance, because every manufactures app is limited. Even apple home and google home are junk for automating things. It’s OK as a basic dashboard though.
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.
I just lived half a year without Philips Hue remote control because it stopped working during an update and I couldn't bother to check why. It was some name change somewhere, might have been an issue with how I set it up, can't even remember. Simple fix but I did have to dive back to the config files.
ZWaveJS used to break frequently for me, but I run an HA container on a Linux box, rather than the HAOS or whatever. I control the updates, and can rollback if things break, so it's not really a problem.
I installed Home Assistant recently and the docs suggest HAOS is the strongly preferred option these days.
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).
I'm sure the support burden is much easier on HAOS. I don't use any Home Assistant extensions, I don't even know what they are. I use a number of custom integrations, but I manage them all through github and github actions. I'm doing great with just running the containers with podman - just need to keep ZWaveJS and Home Assistant in sync and I don't run into problems.
What you’re describing hasn’t happened to me yet with Home Assistant luckily, even after 5+ years of running it. I can’t remember an update ever breaking any of my stuff. I’m running a docker container though so YMMV. Might be different with the other install types.
Me neither, but I'm running the HA Yellow dedicated low power hardware instead so I can keep it running off my battery backup longer just so it lasts as long as it can along with my internet during outages.
I have about 20 Phillips Hue bulbs at home. My younger brother laughed at me for spending a small fortune on them.
Approx 1 bulb per year dies and requires a replacement. Other than that everything just works after the initial setup - daylight like automation.
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.
I use SmartThings and ive never missed with any configs at all. Only ever one single app - smartthings. Ive been extremely happy after dozens of devices.
I also switched from Philips Hue to IKEA. I like how you can pair things by holding them close and pressing a button. Doesn’t need to get smarter than that for me.
I just use Ikea's remote because I won't bother to link the light and the rmote through HA and set up scenes. It just works as a remote: on/off/dimmer. I can either pair the thing with the HA ecosystem or the remote, but the remote always works, regardlesif HA is on or not. I have just one set of lights.
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.
I'm in the same boat; HA is making a considerable effort, but connectivity is challenging. I was a bit frustrated when I found out that the antennas don't support both Zigbee and Matter simultaneously, despite the claim. You can only support one at a time, so apparently we will need the second antenna.
Some USB zigbee dongles can be flashed to be "multi-PAN", but my experience is it's currently buggy and I would let them bake that for a bit longer.
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.
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.
I consider it a requirement of any smart home that alternative methods need to be available during failures. Simply having other devices around that aren’t smart, like an old fashioned light bulb and physical switch to get you through until you can fix whatever is down. 100% uptime is very difficult for large, well-funded IT companies, so I don’t think it’s reasonable to expect it from these consumer-grade devices.
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.
Lutron Caseta switches don’t use an open protocol and don’t seem to get much love in the fancy consumer-level smarthome space, but have been bomb-proof for reliability for me and work to turn lights on/off as long as they have power.
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.
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.
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.
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.
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.
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.)
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).
> 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).
Yeah and matter needs internet access in many cases. It was supposed to be the saviour of open home automation. But in practice it leaves too many strings attached that the manufacturer can take advantage of.
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?
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.
Technically Matter itself doesn't require Internet access, but you'll come across many devices that won't operate (or even join) without a functioning border router. What's in the spec and the lived experience are sort of different here.
I remember an interview [1] with the Nanoleaf CEO (they switched to Thread over Matter years ahead of everyone else) about why Thread/Matter was so difficult, why everyone else didn't adopt it, and that they're going to wait for Thread to get better before they launch new products with it.
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.
But it's not just consumers. I know the tech press hailed it as the end of manufacturer-specific closed systems, and so did some of the developers like the ones from Home Assistant.
>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]
To be clear, this is the same organization that developed Zigbee, which requires paid certification - without, you're not allowed to say the product supports Zigbee or to use the Zigbee logo.
You can connect devices without this, it just shows a warning during commissioning that the device is not certified. No impact whatsoever.
So by analogy, Zigbee is like USB in that it encourages certification through trademarks, while Matter is like HDCP or Blu-ray in that it enforces certification through technical means (cryptographic signatures)?
> It is not "open" in that you can make a matter device in your basement.
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).
This isn't entirely true, isn't it? I mean, the whole internet runs on a PKI and we need such a mechanism to ensure secure communication across devices in the network.
I understand home devices that contain all sort of sensors and actuators should be handled in a similar fashion, isn't 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)
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.
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.
Do you extend that criticism to USB, Bluetooth, WiFi, etc.? The alternative and current status quo is every vendor developing their own proprietary, incompatible and insecure protocols. Unless there's a better alternative I am unaware of, Matter is a step towards greater interoperability and openness.
I do, but it's especially grating here because Zigbee didn't have this restriction, and none of your examples actually enforce it technically. I have some Chinese USB devices that are very useful but use an incorrect VendorID. But I don't care, they work great.
And besides, so far I've been able to use 100% of my Zigbee devices with Zigbee2MQTT and it's been wonderful.
Matter has nothing to do with Google except they are supporting the standard. If you care so much about an open ecosystem Google Home shouldn't even matter, you would be worried about Home Assistant support.
> 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.
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.
My first reaction here was horror: Home Assistant and Zigbee integrate perfectly with IKEA’s devices, and the devices are beautifully designed! Please don’t take these away! Only the other day did I marvel at how a low battery indicator flashes on one of my remotes when I use it. A design flourish that I really appreciated.
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!
> Can anyone here confirm that Matter/Thread will be a bright, open, and happy new future?
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.
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.
Dev mode seems like such a nonstarter. I don't know what dev mode entails, but I don't want to be running my kitchen light in dev mode, I'll just use an analog switch.
> Dev mode seems like such a nonstarter. I don't know what dev mode entails,
... 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 can't conceptualize exactly what the use case is here, but I get the impression there's a set of steps that have to be done in sequence after installing my light bulb, and that's another step to an already fairly involved process. All to screw in a light bulb. And the light bulb is the easy case. If it's actually two devices and I want them to talk to each other, and one of them is automatically trusted, and the other one is untrusted, I'm skeptical that just pushing the button is going to help. (Actually in general I'm skeptical that it will typically work without extensive research, and this is just one in a long list of potential gotchas.)
Matter specifies that all firmware images must be signed so the device can verify authenticity before installation, ensuring they haven’t been tampered with. Matter further requires mechanisms to prevent unauthorized firmware execution and ensure that firmware can't be downgraded.
Matter states that firmware images “may be encrypted.” This is not a requirement, though encryption is allowed and may add security
This sounds like it only affects OTA updates going through the Matter stack, not an explicit requirement to block serial flashing.
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? 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?
I know almost nothing about Matter but is this true? I though that if you control your own fabric, you can talk to any device on it because they trust your controller.
This is correct; the hand-wringing in this thread is fair in that Matter does have a central governing authority who determine which devices are trusted, but completely unjustified insofar as that making a DIY Matter fabric/network is extremely easy.
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.
So it's kinda like UEFI Secure Boot? PKI with a default list of officially trusted companies, and it's supposed to let the end user add their own keys, but the details make people nervous because it would be really easy for the vendor to break that any time they feel like it?
* 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.
Buy a device from the manufacturer “Eve” try to add it to homeassistant after upgrading its firmware to use matter/thread: no can do, they don’t give you their key to talk to their devices.
I did exactly this. Got an Eve smart plug meter and it works flawlessly in HomeAssistant. I'm also pretty sure I had upgraded to the latest firmware via Apple Home app before doing so.
Great, their new devices actually work in thread mode with HA, but their older ones only when you got an Apple hub device. I’ve got 6-7 of their devices before matter was a thing and 0 work with HA. Even those that got firmware updates.
> It did always feel a bit awkward having Zigbee networking and IP networking competing over the same site
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.
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.
The thread border gateway (Apple TV, HomePod, Google Nest Speaker, etc) sends an IPv6 router advertisement to the network for the Thread IP space. Multiple border gateways can advertise the same IP space for redundancy.
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.
I don't understand the problem that thread solves that zigbee doesn't! The article says that thread doesn't require a hub but it require a border gateway that is almost indistinguishable from a hub. And as far as my home assistant setup is concerned, it doesn't require a hub, only a zigbee radio.
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?
Matter was created by the Connectivity Standards Alliance (CSA), formerly known as the Zigbee Alliance! Basically, Matter is the next generation Zigbee. Thread as a protocol predates Matter, and it is just one of the supported transports, together with Wifi and Ethernet (for now).
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!
> 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.
on the other hand - I had contractors install our Nanoleaf recessed light cans (thread over matter) in our new house. In all the hubbub, I forgot to make sure to save the light cans boxes that had the QR codes inside. I found around half the QR code stickers, but I lost the other half. The light cans also have the QR codes printed on the top, but we have nailed-down attic flooring that covers them completely. So I'm basically just praying that Nanoleaf's CS can give me the pairing codes based on my order number, haha.
Oof, yes that's certainly a way QR codes can go wrong. Ideally manufacturers print the QR code on the device such that it lasts the device's lifetime.
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.
I feel like the problem is a lack of realism about what is required to meet the usability standards of traditional analog switches. Like, I hear you talking about a tradeoff between security and usability for a "rare" provisioning event but I think in practice if you imagine a device has a 10 year lifespan, I would guess that making the provisioning hardware probably translates into at a minimum a full month of downtime over the lifespan of the device, with many devices being down for months or years at a time because no one can be bothered to figure out why.
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.)
> if you imagine a device has a 10 year lifespan, I would guess that making the provisioning hardware probably translates into at a minimum a full month of downtime over the lifespan of the device, with many devices being down for months or years at a time because no one can be bothered to figure out why.
Can you explain more about how you reached this conclusion? Why are devices offline for years now?
The Bluetooth connection gets screwed up for some reason and it needs to be reprovisioned. The device is in a room which isn't really the domain of the person who can reprovision it. Whoever is actually affected by the outage can't fix it, has to realize that it's a solvable problem and ask the person who can solve it to fix it. This social problem of recognizing that a chore needs to be done will likely take at least a week, typically a month or even years to resolve.
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.)
while your example is correct, I have many many examples in my experience why scanning a qr code is simply infeasible in some situations and as a owner of a heavily automated home I welcome the development with open arms.
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.
As I understand it, Thread can transparently extend its mesh over regular IPv6 (Ethernet, Wi-Fi, etc), whereas extending a Zigbee (or Z-Wave) mesh beyond useful mesh range is a mess. I have a Z-Wave network that uses two controllers, and it sucks. It’s utterly obnoxious to maintain, the whole concept of multiple controllers is barely supported by zwave-js-ui, it is far to dumb to recover quickly on its own if it transiently loses connectivity to a node, and roaming between controllers is a complete non-starter.
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 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?
Maybe there isn’t one. Can I “pair” a Thread device with, say, an Apple TV and have it talk to the Apple TV via radio to an IKEA Dirigera hub and then IPv6 over Ethernet from the Dirigera to the Apple TV?
Thread can talk to your phone using a gateway. Thread is IPv6 based. The gateway, called border router, is no different than access point in function.
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.
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.
I am hoping that this is the thing that triggers Matter/Thread to go mainstream.
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'm not sure what I am missing, but isn't it completely possible to connect any kind of smart button to control a light bulb? Isn't this exactly what home assistant is being used for? I only tried it, but was able to add a generic smart button to HA and let it control a USB switch with some led lights. How is your use case different?
UPDATE: Ok, is this about the state of Matter implementation? I think I misunderstood that.
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 only recently discovered and invested in the IKEA ZigBee hardware, about the only product their MBAs havent destroyed. The hardware is very well built, and sensibly priced. What I liked most of all was that the hub was optional, and thus no cloud account required.
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.
Huh... anyone know what this will mean for people with legacy Ikea lightbulbs and hub?
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.)
The newer DIRIGERA hub has both radios, and recently added full thread support in a firmware update, so you should be good if you have it. Otherwise, add that or an upcoming hub or migrate the old bulbs.
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!
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.
Isn’t this the history of home automation? The money is in getting people locked into a “system,” but the systems are things that tend to rapidly become dated. So people will invest in a system and either get disillusioned due to the downside of lock in or the system goes obsolete and the newer stuff is not compatible because it’s a whole new system. Rinse, repeat.
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.”
“[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.”
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.
I have an Aqara Thread over Matter smart lock too. The only thing I can do with it via Home Assistant is remote unlock/lock and get the battery %. I can't do user management or the million other features that require me to use the Aqara app.
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:
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.
If you toggle or otherwise manually manipulate a light switch, surely it is physically disconnecting the circuits? I don't see how that mechanism could ever not work, absent mechanical issues.
A smart switch cannot be a toggle. It needs a relay of some sort so that it can be controlled by software. There is a switch you control, then something, then the relay. That something needs to work.
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.
In my experience, Matter already works better than Zigbee and Z-Wave ever did, and it gets better every year. I'm interested in what your unusable mess of a system consists of, if you don't mind elaborating.
> 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.
To be fair, step 4 isn't a real step, step 1 is just buying the "hub" or "border router" or whatever, and step 2 & 3 are the same for Zigbee and Matter, the button is just somewhere else.
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.
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.
This is horrible news. Zigbee has been trouble-free and Thread has been nothing but Trouble to the point I had to throw out everything based on Thread…
This could easily have as much to do with support costs as anything with the technical side of the protocols.
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.
My IKEA was missing a lot of Trådfri assortment when I visited this week. I started to have doubts if they had abandoned the home automation niche. Now when I am searching their site, much is gone. But I guess they are clearing the inventory for a Threads relaunch
That's such a shame. I bought quite a few IKEA devices as they were the cheapest in the market and were Zigbee-driven, which meant I could use it with my custom-made SmartHome software (which does what Home Assistant does but without a heavy runtime) and they connected with other manufacturer's devices (they form a mesh, so as long as you have a Zigbee device every few 10s of meters, the devices can communicate with the central hub even from very far away). I wonder if I will be able to connect to Thread devices at all now.
I’d not read much into that. My local IKEAs have stock issues since 2020. There is always a couple of products that are completely gone.
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.
The lamp+speaker is interesting. Wish it had usb-c for power, and or wireless charging.
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.
Unfortunately, the writing's on the wall for mainstream adoption of Zigbee. For me, Leviton not making any more Zigbee smart switches was the last straw and I've prioritized Z-wave devices where possible. I also get much better performance out of Z-wave. Sad to see though, as the Zigbee devices I do have are working just fine. I don't really get the point of Matter or Thread when Z-wave works so well.
It's pretty straightforward: Z-Wave is a closed (one company owns and controls the tech and brand) hub-bound mesh, and really should've been displaced by an open solution long ago. Matter is an industry-standard IPv6-based application layer that works over Thread (the successor to ZigBee) and Wi-Fi.
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.
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...)
I don't know if there's an MQTT bridge yet. Generally, you run some kind of border router and connect through that. While the work doesn't seem complete yet, there's a guide to turn a Home Assistant install into a Thread border router if you have the necessary hardware: https://www.home-assistant.io/integrations/thread/#turning-h...
You can probably plumb Home Assistant into your MQTT server from there.
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)
While not a proper product, you can buy a small ESP32C6 devboard for up-to-5 USD/EUR and flash an example from esp-idf. This is paired with some software that runs on posix systems (think your HA host) that together form the necessary commissioning and border routing functionality. Its ends up being a relatively simple device that just takes IP packets off the radio and puts then somewhere else, so I've no doubt somebody will shortly make one (I've been working on one such for myself as an experiment.)
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.
Just checked again, those ideas have started to mature to something that is possible now (vs 6 months ago when I last looked). I have kids and many other things in my life, so I'm don't have much time to work on projects like this. That might be what I end up doing, for now I just have a light that hasn't worked for months because I don't want to figure this out (the manual switch is broken. Since the switch is both rarely used and one I'd want remotely controlled anyway I've been hesitating)
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.
This really sucks. I have a smart home with home assistant and most of my things are Zigbee and Ikea stuff are great. They are affordable and they are high quality. So now I have to find another provider of especially light bulbs.
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%.
Some Amazon devices (see a list here: https://www.amazon.com/b?ie=UTF8&node=37490568011 ) already support Matter devices, so you might already have everything that you need. The Tapo 110M (M for Matter) plug for example can easily be paired with them and work flawlessly (an also much faster than the non-Matter counterparts). And yes, they don't need internet access to work.
You still need the TP-Link app for some more advanced functions like power metering though.
Matter has been very disappointing so far, with very unreliable connectivity and behavior (using Apple TV as a border gateway). I basically gave up on it and prefer to use non-Matter HomeKit hardware (usually WiFi) where I can. Don't know if Zigbee was better, but it can hardly be worse.
The question doesn't really make sense this way. Thread is more or less like Wi-Fi. It's a transport technology and protocol. It's HOW your devices can talk to each other. It's how they can say "I'm here and I can see 'AirPurifier324' over there."
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?
I've done everything using old Particle Xenon boards (nrf52840 microcontroller) and didn't encounter anything 'user hostile'. Originally I had all the 'hub' stuff on one of the boards too, but the newer recommended way is to have the board be the 'radio' and to use a normal computer for the routing.
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'.
Yes but since it routes IPv6 and hubs are usually connected to the Internet when set up by the average consumer, it is very easy for Thread devices to "accidentally" gain Internet access.
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.
I use some sort of cobbled together solution with Philips Vue lights, a couple of LIFX lights, halfway set up HomeKit, the Vue app, some Alexa integration, some sort of gateway that I believe connects Zigbee to my LAN...
.. but all I can remember from growing up is the X-10 POWERHOUSE
"A software development kit (SDK) is provided royalty-free,[13][14] though 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]"
So it's a closed ecosystem that makes money for a cabal of corporations
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.
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.
> 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.
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.
This sucks. Matter is a closed ecosystem, enforced using a public key infrastructure (PKI) and device attestation certificates. Thread seems to require paying royalties if you want to ship devices. It’s disappointing that IKEA claims that this move is towards a more open ecosystem.
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.
> 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.
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.
Home Assistant "just works". Yes it has a ton of knobs, but in the 3 years I've been running it, it's had no issues. Certain manufacturer devices being flaky, yes, but as a platform, it's been rock solid. I've not touched its config in over a year and everything works as it should.
I guess the fact that some manufacturer integrations are flaky is hard to reconcile for me as far as the promise of "having multiple kinds of smart devices isn't really a problem". Regardless of whose fault it is, those flaky devices contribute to a less stable system.
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 have been using Home Assistant for more than 5 years. The stability of the system has improved a lot in the last year. I don't recall the last time I had to reinstall or restore a backup.
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.
For my flaky devices, it it not a manufacturer integration, but over Zigbee. It's definitely the device as my other Zigbee devices are solid. Others have reported issues with the device in question (Aqara Temperature and Humidity Sensor)
I ran the docker version on a QNAP for a long time, now on a Home Assistant Green.
I second that. Home Assistant "just works". I have had it running on this cheap used HP EliteDesk 705 G3 Mini Desktop for more than 4 years now without a hiccup and barely any maintenance or hygeing work on it. Just sitting in my tv stand and doing it's work.
https://homeautomation.substack.com/p/setting-up-home-assist...
Curious, do you do HA updates automatically, manually regularly, or “manually once a year or so”?
Not who you asked, but I do it “manually once a year or so” on a HA instance in a container running on unraid. It sometimes causes problems. Recently HACS (not a built-in part of HA but useful to get some extensions) broke on a HA update and I had to spend more time that I would have liked figuring out how to fix it. It involved running shell commands inside the container. Definitely not for anyone who isn't a techie.
Manual, would do it once a month or so. Hasn't broken ever since I have been running HA. I run the full Haas OS btw.
> Certain manufacturer devices being flaky, yes, but as a platform
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?
I think one solid way of handling the instability is to use high quality light automation (Lutron Caseta, for example) for the things you'll really notice, but for stuff you care less about (for me that's cameras, temperature sensors) you can use cheaper ZWave stuff w/ home assistant. The lights turn on and off when I expect, but temperature might update a little less frequently if HA is flaky.
Long tail can be flaky, but in practice as long as you buy devices that are local first IE don't need to access the cloud you'll be fine.
(For temp and humidity sensors the Bluetooth Xiaomi sensors are great and they're about $5 each)
Honestly, for any sensor that's basically just read only, the best thing I've seen is to just avoid all of the bluetooth/wifi/zigbee/zwave entirely, and just use basic tried and true accurite (or similar) sensors that never need updates and just pull the data with rtl_433. Way, way less fuss, they always just work, batteries last longer, by and large zero bullshit.
It's the devices that is flaky. Some of the shitty bulbs I got don't always turn on in one command but that was true via their own app too. Basically shitty devices aren't magically better via home assistant.
If I had to guess, they're probably referring to the way that certain devices broadcast their APIs to external services. A lot of them have no intention of allowing open access to APIs (e.g., my mini-split controller requires a slight hack to get it connected to HA).
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 have several Aqara temp/humidity sensors that intermittently lose connection. They don't affect the operation/stability of the rest of the HA platform and is not a problem with HA, as my other zigbee devices that report the same data work fine.
I should probably just remove them, but I don't have any automations that depend on them.
Yes it just works, but it's soooo difficult, here's my annoyances:
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.
Surprised at your issues with HA. Similarly to others that responded, my setup with HA / zigbee2mqtt and >30 zigbee devices (including some ikea buttons) has been pretty rock solid over many years, including easy migrations from an rpi3 -> rpi4 -> rpi5 (with ssd).
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.
That's exactly the reason I'm hesitant to dive into Home Assistant myself. I want my smart-home devices to Just Work. I want them to be appliances.
The problem I’ve run into is that once you’re running a lot of devices, you inevitably end up with a bunch of automations and logic that can’t really be simplified. With Apple Home/HomeKit, everything Just Works, but having dozens of automation rules and scenes configured in Apple’s low—information-density UI is worse than managing yaml config.
I don't mind the idea of writing configuration. I mind the idea of things breaking mysteriously, or on upgrade.
View above is bit outdated. Yes, there was a lot of yaml in the past. Right now you can just install Home Assistant OS and configure it from GUI.
There is a tradeoff here. If your expectations are high you will always be disappointed with a smart device advertised as an appliance. it’s difficult to customize to make it _actually_ smart if it’s designed as an appliance, because every manufactures app is limited. Even apple home and google home are junk for automating things. It’s OK as a basic dashboard though.
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.
For what it's worth, mine do. Nothing in my HA has ever broken after an update or randomly for some other reason.
I just lived half a year without Philips Hue remote control because it stopped working during an update and I couldn't bother to check why. It was some name change somewhere, might have been an issue with how I set it up, can't even remember. Simple fix but I did have to dive back to the config files.
ZWaveJS used to break frequently for me, but I run an HA container on a Linux box, rather than the HAOS or whatever. I control the updates, and can rollback if things break, so it's not really a problem.
I installed Home Assistant recently and the docs suggest HAOS is the strongly preferred option these days.
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).
I'm sure the support burden is much easier on HAOS. I don't use any Home Assistant extensions, I don't even know what they are. I use a number of custom integrations, but I manage them all through github and github actions. I'm doing great with just running the containers with podman - just need to keep ZWaveJS and Home Assistant in sync and I don't run into problems.
What you’re describing hasn’t happened to me yet with Home Assistant luckily, even after 5+ years of running it. I can’t remember an update ever breaking any of my stuff. I’m running a docker container though so YMMV. Might be different with the other install types.
Me neither, but I'm running the HA Yellow dedicated low power hardware instead so I can keep it running off my battery backup longer just so it lasts as long as it can along with my internet during outages.
I have about 20 Phillips Hue bulbs at home. My younger brother laughed at me for spending a small fortune on them. Approx 1 bulb per year dies and requires a replacement. Other than that everything just works after the initial setup - daylight like automation.
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.
It’s not acceptable for any LED bulb, let alone one as expensive as Philips HUEs are, to die so soon.
I use SmartThings and ive never missed with any configs at all. Only ever one single app - smartthings. Ive been extremely happy after dozens of devices.
Same. Their Hub (now sold by Aeotec) does Z-Wave, Zigbee, and Thread. There is also a pretty active plugin community.
I also switched from Philips Hue to IKEA. I like how you can pair things by holding them close and pressing a button. Doesn’t need to get smarter than that for me.
I just use Ikea's remote because I won't bother to link the light and the rmote through HA and set up scenes. It just works as a remote: on/off/dimmer. I can either pair the thing with the HA ecosystem or the remote, but the remote always works, regardlesif HA is on or not. I have just one set of lights.
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.
I'm in the same boat; HA is making a considerable effort, but connectivity is challenging. I was a bit frustrated when I found out that the antennas don't support both Zigbee and Matter simultaneously, despite the claim. You can only support one at a time, so apparently we will need the second antenna.
Some USB zigbee dongles can be flashed to be "multi-PAN", but my experience is it's currently buggy and I would let them bake that for a bit longer.
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.
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.
I consider it a requirement of any smart home that alternative methods need to be available during failures. Simply having other devices around that aren’t smart, like an old fashioned light bulb and physical switch to get you through until you can fix whatever is down. 100% uptime is very difficult for large, well-funded IT companies, so I don’t think it’s reasonable to expect it from these consumer-grade devices.
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.
Lutron Caseta switches don’t use an open protocol and don’t seem to get much love in the fancy consumer-level smarthome space, but have been bomb-proof for reliability for me and work to turn lights on/off as long as they have power.
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
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.
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.
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.
I wish Matter accounted for mixed-mode networks. If a Thread device is nearby, use that. If not, try Wi-Fi.
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.)
Thread doesn’t depend on DHCP or DNS either.
Agree. It’s a hassle to set up once but then you quickly forget about it.
I don't think that is entirely correct.
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.
> 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.
Yeah and matter needs internet access in many cases. It was supposed to be the saviour of open home automation. But in practice it leaves too many strings attached that the manufacturer can take advantage of.
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?
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.
Technically Matter itself doesn't require Internet access, but you'll come across many devices that won't operate (or even join) without a functioning border router. What's in the spec and the lived experience are sort of different here.
But wouldn't the same issue apply to Zigbee in that case?
>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?
I remember an interview [1] with the Nanoleaf CEO (they switched to Thread over Matter years ahead of everyone else) about why Thread/Matter was so difficult, why everyone else didn't adopt it, and that they're going to wait for Thread to get better before they launch new products with it.
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-...
Yeah, doesn’t sound like EOL to me. Must have been some other IOT/PAN technology.
> 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"?
But it's not just consumers. I know the tech press hailed it as the end of manufacturer-specific closed systems, and so did some of the developers like the ones from Home Assistant.
> Matter is a closed ecosystem
If "closed" means open to anyone that has their product certified to adhere to the rules, then I'm ok with that.
That's incorrect. Matter is an open standard.
https://en.wikipedia.org/wiki/Matter_(standard)
>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?
To be clear, this is the same organization that developed Zigbee, which requires paid certification - without, you're not allowed to say the product supports Zigbee or to use the Zigbee logo.
You can connect devices without this, it just shows a warning during commissioning that the device is not certified. No impact whatsoever.
So by analogy, Zigbee is like USB in that it encourages certification through trademarks, while Matter is like HDCP or Blu-ray in that it enforces certification through technical means (cryptographic signatures)?
> …while Matter is like HDCP or Blu-ray in that it enforces certification through technical means (cryptographic signatures)?
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.
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/
> It is not "open" in that you can make a matter device in your basement.
You can! You just can't ship it/sell it without certification.
https://www.reddit.com/r/homeassistant/comments/1adh8ah/esp3...
> It is not "open" in that you can make a matter device in your basement.
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).
I didn't believe any of the information in this post is correct.
This isn't entirely true, isn't it? I mean, the whole internet runs on a PKI and we need such a mechanism to ensure secure communication across devices in the network. I understand home devices that contain all sort of sensors and actuators should be handled in a similar fashion, isn't 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)
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/
What a shit load of disinformation you are spreading. Read up on Matter and Thread, please.
Can I make a Matter device for myself?
Yes. https://developers.home.google.com/codelabs/matter-device
Can I sell it without paying a gazillion fees?
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.
Do you extend that criticism to USB, Bluetooth, WiFi, etc.? The alternative and current status quo is every vendor developing their own proprietary, incompatible and insecure protocols. Unless there's a better alternative I am unaware of, Matter is a step towards greater interoperability and openness.
I do, but it's especially grating here because Zigbee didn't have this restriction, and none of your examples actually enforce it technically. I have some Chinese USB devices that are very useful but use an incorrect VendorID. But I don't care, they work great.
And besides, so far I've been able to use 100% of my Zigbee devices with Zigbee2MQTT and it's been wonderful.
Matter has nothing to do with Google except they are supporting the standard. If you care so much about an open ecosystem Google Home shouldn't even matter, you would be worried about Home Assistant support.
Well, there appears to be some link. I'm not clear on what it is, but here are the Home Assistant docs for using a Matter dev board: https://www.home-assistant.io/integrations/matter/#experimen...
> 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 seriously using some footnote about Android as proof that Google somehow has any control over Matter?
branding is not closing.
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.
Isn't that true for ZigBee too? Can you sell ZigBee devices (and market them as such) without paying fees?
There are no technical limitations preventing this.
No technically limitations, just legal ones. Which are famously irrelevant to international commerce?
You cannot legally certify something as Zigbee with paying a fee. This is the same for Matter.
I don't know why you're downvoted, it's the same reaction I had tbh.
Because it's insubstantial and doesn't further the conversation in a healthy direction.
My first reaction here was horror: Home Assistant and Zigbee integrate perfectly with IKEA’s devices, and the devices are beautifully designed! Please don’t take these away! Only the other day did I marvel at how a low battery indicator flashes on one of my remotes when I use it. A design flourish that I really appreciated.
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!
> Can anyone here confirm that Matter/Thread will be a bright, open, and happy new future?
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.
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.
Dev mode seems like such a nonstarter. I don't know what dev mode entails, but I don't want to be running my kitchen light in dev mode, I'll just use an analog switch.
> Dev mode seems like such a nonstarter. I don't know what dev mode entails,
... 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 can't conceptualize exactly what the use case is here, but I get the impression there's a set of steps that have to be done in sequence after installing my light bulb, and that's another step to an already fairly involved process. All to screw in a light bulb. And the light bulb is the easy case. If it's actually two devices and I want them to talk to each other, and one of them is automatically trusted, and the other one is untrusted, I'm skeptical that just pushing the button is going to help. (Actually in general I'm skeptical that it will typically work without extensive research, and this is just one in a long list of potential gotchas.)
And manufacturers tend to lock down their Matter devices, too, so you can't flash Tasmota or ESPHome on them. See: Shelly, Sonoff.
Not just tend to, have to. Matter certification requires flash encryption and FW signing.
Are these requirements public?
I was working on a Matter device but it never got certified due to high cost/lack of customer demand.
Matter specifies that all firmware images must be signed so the device can verify authenticity before installation, ensuring they haven’t been tampered with. Matter further requires mechanisms to prevent unauthorized firmware execution and ensure that firmware can't be downgraded.
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-...)
This sounds like it only affects OTA updates going through the Matter stack, not an explicit requirement to block serial flashing.
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.
You say that as if that’s a bad thing. I would love to have more iot security
where "security" here means "anything not explicitly sanctioned by the vendor is prohibited"?
No it means signed firmware and verified boot…
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?
You can’t talk to other devices unless you got the private key of them.
I know almost nothing about Matter but is this true? I though that if you control your own fabric, you can talk to any device on it because they trust your controller.
This is correct; the hand-wringing in this thread is fair in that Matter does have a central governing authority who determine which devices are trusted, but completely unjustified insofar as that making a DIY Matter fabric/network is extremely easy.
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.
https://developers.home.google.com/matter/primer/fabric
So it's kinda like UEFI Secure Boot? PKI with a default list of officially trusted companies, and it's supposed to let the end user add their own keys, but the details make people nervous because it would be really easy for the vendor to break that any time they feel like it?
The design is both better and worse:
* 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.
> You can’t talk to other devices unless you got the private key of them
can you explain what you mean by this?
Buy a device from the manufacturer “Eve” try to add it to homeassistant after upgrading its firmware to use matter/thread: no can do, they don’t give you their key to talk to their devices.
I did exactly this. Got an Eve smart plug meter and it works flawlessly in HomeAssistant. I'm also pretty sure I had upgraded to the latest firmware via Apple Home app before doing so.
They work without issues Ine HomeKit mode. With thread/matter only Apple got the keys or whoever paid them to get them.
Also: the Apple home app can’t change their mode to matter, you have to do that in home assistant.
Great, their new devices actually work in thread mode with HA, but their older ones only when you got an Apple hub device. I’ve got 6-7 of their devices before matter was a thing and 0 work with HA. Even those that got firmware updates.
> 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.
I wouldn't worry too much. Espresiff is going to flood the market with countless units of this chip available for cheap. It can do Zigbee/Thread/BLE.
https://www.espressif.com/en/products/socs/esp32-h2
> It did always feel a bit awkward having Zigbee networking and IP networking competing over the same site
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.
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.
> just like how some businesses would run IPX internally
when? In the 1990s?
Yes, not to mention WiFi is so much more power hungry.
The thread border gateway (Apple TV, HomePod, Google Nest Speaker, etc) sends an IPv6 router advertisement to the network for the Thread IP space. Multiple border gateways can advertise the same IP space for redundancy.
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.
[dead]
I don't understand the problem that thread solves that zigbee doesn't! The article says that thread doesn't require a hub but it require a border gateway that is almost indistinguishable from a hub. And as far as my home assistant setup is concerned, it doesn't require a hub, only a zigbee radio.
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?
Matter was created by the Connectivity Standards Alliance (CSA), formerly known as the Zigbee Alliance! Basically, Matter is the next generation Zigbee. Thread as a protocol predates Matter, and it is just one of the supported transports, together with Wifi and Ethernet (for now).
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!
> 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.
on the other hand - I had contractors install our Nanoleaf recessed light cans (thread over matter) in our new house. In all the hubbub, I forgot to make sure to save the light cans boxes that had the QR codes inside. I found around half the QR code stickers, but I lost the other half. The light cans also have the QR codes printed on the top, but we have nailed-down attic flooring that covers them completely. So I'm basically just praying that Nanoleaf's CS can give me the pairing codes based on my order number, haha.
Oof, yes that's certainly a way QR codes can go wrong. Ideally manufacturers print the QR code on the device such that it lasts the device's lifetime.
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.
exactly, this scenario is why I'm excited about bluetooth provisioning.
I feel like the problem is a lack of realism about what is required to meet the usability standards of traditional analog switches. Like, I hear you talking about a tradeoff between security and usability for a "rare" provisioning event but I think in practice if you imagine a device has a 10 year lifespan, I would guess that making the provisioning hardware probably translates into at a minimum a full month of downtime over the lifespan of the device, with many devices being down for months or years at a time because no one can be bothered to figure out why.
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.)
> if you imagine a device has a 10 year lifespan, I would guess that making the provisioning hardware probably translates into at a minimum a full month of downtime over the lifespan of the device, with many devices being down for months or years at a time because no one can be bothered to figure out why.
Can you explain more about how you reached this conclusion? Why are devices offline for years now?
The Bluetooth connection gets screwed up for some reason and it needs to be reprovisioned. The device is in a room which isn't really the domain of the person who can reprovision it. Whoever is actually affected by the outage can't fix it, has to realize that it's a solvable problem and ask the person who can solve it to fix it. This social problem of recognizing that a chore needs to be done will likely take at least a week, typically a month or even years to resolve.
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.)
while your example is correct, I have many many examples in my experience why scanning a qr code is simply infeasible in some situations and as a owner of a heavily automated home I welcome the development with open arms.
> 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.
As I understand it, Thread can transparently extend its mesh over regular IPv6 (Ethernet, Wi-Fi, etc), whereas extending a Zigbee (or Z-Wave) mesh beyond useful mesh range is a mess. I have a Z-Wave network that uses two controllers, and it sucks. It’s utterly obnoxious to maintain, the whole concept of multiple controllers is barely supported by zwave-js-ui, it is far to dumb to recover quickly on its own if it transiently loses connectivity to a node, and roaming between controllers is a complete non-starter.
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 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?
Maybe there isn’t one. Can I “pair” a Thread device with, say, an Apple TV and have it talk to the Apple TV via radio to an IKEA Dirigera hub and then IPv6 over Ethernet from the Dirigera to the Apple TV?
Thread can talk to your phone using a gateway. Thread is IPv6 based. The gateway, called border router, is no different than access point in function.
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.
My understanding is that Thread is lower latency and lower power than Zigbee.
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.
An excellent question - all I can do is point you at the research. See the top graph here: https://www.reddit.com/r/homeautomation/comments/nxmehn/clea...
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:
But thanks you for answering me!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.
But does it translate to real world gains? I've developed a Matter (wifi) device and the stack is ridiculously chatty.
(offtopic) from the link
> 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)
> 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.
I am hoping that this is the thing that triggers Matter/Thread to go mainstream.
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'm not sure what I am missing, but isn't it completely possible to connect any kind of smart button to control a light bulb? Isn't this exactly what home assistant is being used for? I only tried it, but was able to add a generic smart button to HA and let it control a USB switch with some led lights. How is your use case different?
UPDATE: Ok, is this about the state of Matter implementation? I think I misunderstood that.
For how much hype Matter had (I remember everyone saying "Just wait! Any day now!") it sure... hasn't delivered
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 only recently discovered and invested in the IKEA ZigBee hardware, about the only product their MBAs havent destroyed. The hardware is very well built, and sensibly priced. What I liked most of all was that the hub was optional, and thus no cloud account required.
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.
Huh... anyone know what this will mean for people with legacy Ikea lightbulbs and hub?
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.)
The newer DIRIGERA hub has both radios, and recently added full thread support in a firmware update, so you should be good if you have it. Otherwise, add that or an upcoming hub or migrate the old bulbs.
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!
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.
Looks to me like they'll continue to work. There are multiple mentions of backwards compatibility in the article.
Isn’t this the history of home automation? The money is in getting people locked into a “system,” but the systems are things that tend to rapidly become dated. So people will invest in a system and either get disillusioned due to the downside of lock in or the system goes obsolete and the newer stuff is not compatible because it’s a whole new system. Rinse, repeat.
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.
“[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.
I have an Aqara Thread over Matter smart lock too. The only thing I can do with it via Home Assistant is remote unlock/lock and get the battery %. I can't do user management or the million other features that require me to use the Aqara app.
Haha. Imagine a light switch that becomes obsolete like your wireless router.
Why can’t it keep working via manual control?
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.
If you toggle or otherwise manually manipulate a light switch, surely it is physically disconnecting the circuits? I don't see how that mechanism could ever not work, absent mechanical issues.
A smart switch cannot be a toggle. It needs a relay of some sort so that it can be controlled by software. There is a switch you control, then something, then the relay. That something needs to work.
Oh, I see. Thanks!
> Do you trust the manufacture to do that though?
... 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.
RIP. The ikea zigbee stuff was close to being best in class. Matter is still an unusable mess.
In my experience, Matter already works better than Zigbee and Z-Wave ever did, and it gets better every year. I'm interested in what your unusable mess of a system consists of, if you don't mind elaborating.
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.
Look, I agree with you and as someone with Home Assistant, I much prefer Zigbee.
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.
To be fair, step 4 isn't a real step, step 1 is just buying the "hub" or "border router" or whatever, and step 2 & 3 are the same for Zigbee and Matter, the button is just somewhere else.
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.
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.
I have stuff that didn’t support Matter on launch, that I updated to Matter, and it seems exactly the same in practice.
Well IKEA, I'm not going to buy and "smart" products from you.
This is horrible news. Zigbee has been trouble-free and Thread has been nothing but Trouble to the point I had to throw out everything based on Thread…
This could easily have as much to do with support costs as anything with the technical side of the protocols.
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.
My IKEA was missing a lot of Trådfri assortment when I visited this week. I started to have doubts if they had abandoned the home automation niche. Now when I am searching their site, much is gone. But I guess they are clearing the inventory for a Threads relaunch
That's such a shame. I bought quite a few IKEA devices as they were the cheapest in the market and were Zigbee-driven, which meant I could use it with my custom-made SmartHome software (which does what Home Assistant does but without a heavy runtime) and they connected with other manufacturer's devices (they form a mesh, so as long as you have a Zigbee device every few 10s of meters, the devices can communicate with the central hub even from very far away). I wonder if I will be able to connect to Thread devices at all now.
I’d not read much into that. My local IKEAs have stock issues since 2020. There is always a couple of products that are completely gone.
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.
The lamp+speaker is interesting. Wish it had usb-c for power, and or wireless charging.
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.
Unfortunately, the writing's on the wall for mainstream adoption of Zigbee. For me, Leviton not making any more Zigbee smart switches was the last straw and I've prioritized Z-wave devices where possible. I also get much better performance out of Z-wave. Sad to see though, as the Zigbee devices I do have are working just fine. I don't really get the point of Matter or Thread when Z-wave works so well.
It's pretty straightforward: Z-Wave is a closed (one company owns and controls the tech and brand) hub-bound mesh, and really should've been displaced by an open solution long ago. Matter is an industry-standard IPv6-based application layer that works over Thread (the successor to ZigBee) and Wi-Fi.
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.
> If I had to wipe and re-setup my smart home with 100 Zigbee devices…
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?
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...)
So you dropped a dying ecosystem for a very dead and buried underground one?
Bold move.
Is there some reason you felt compelled to comment on this, using that tone? Because it was completely uncalled for
What is the equivalent for zigbee2mqtt for Matter/Threads?
I don't know if there's an MQTT bridge yet. Generally, you run some kind of border router and connect through that. While the work doesn't seem complete yet, there's a guide to turn a Home Assistant install into a Thread border router if you have the necessary hardware: https://www.home-assistant.io/integrations/thread/#turning-h...
You can probably plumb Home Assistant into your MQTT server from there.
You just need a Thread border router and Matter devices connect to your HA without problems. I use Apple TV as a border router.
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)
While not a proper product, you can buy a small ESP32C6 devboard for up-to-5 USD/EUR and flash an example from esp-idf. This is paired with some software that runs on posix systems (think your HA host) that together form the necessary commissioning and border routing functionality. Its ends up being a relatively simple device that just takes IP packets off the radio and puts then somewhere else, so I've no doubt somebody will shortly make one (I've been working on one such for myself as an experiment.)
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.
Just checked again, those ideas have started to mature to something that is possible now (vs 6 months ago when I last looked). I have kids and many other things in my life, so I'm don't have much time to work on projects like this. That might be what I end up doing, for now I just have a light that hasn't worked for months because I don't want to figure this out (the manual switch is broken. Since the switch is both rarely used and one I'd want remotely controlled anyway I've been hesitating)
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.
This really sucks. I have a smart home with home assistant and most of my things are Zigbee and Ikea stuff are great. They are affordable and they are high quality. So now I have to find another provider of especially light bulbs.
What stops you from adding a Thread border router and adding new Matter devices to Home Assistant? It works.
We could have had ZigBee Smart Energy Profile 2.0 running all of this, with the glory and righteousness of IP networking everywhere. Oh well...
Paywall bypass: https://archive.is/8S1un
Warning: a bit of a rant incoming...
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%.
Some Amazon devices (see a list here: https://www.amazon.com/b?ie=UTF8&node=37490568011 ) already support Matter devices, so you might already have everything that you need. The Tapo 110M (M for Matter) plug for example can easily be paired with them and work flawlessly (an also much faster than the non-Matter counterparts). And yes, they don't need internet access to work.
You still need the TP-Link app for some more advanced functions like power metering though.
I'm pretty sure this is misreporting, and these devices actually support Matter as well as Zigbee.
First daim chocolate, now zigbee...
Matter has been very disappointing so far, with very unreliable connectivity and behavior (using Apple TV as a border gateway). I basically gave up on it and prefer to use non-Matter HomeKit hardware (usually WiFi) where I can. Don't know if Zigbee was better, but it can hardly be worse.
Does Thread work without cloud?
The question doesn't really make sense this way. Thread is more or less like Wi-Fi. It's a transport technology and protocol. It's HOW your devices can talk to each other. It's how they can say "I'm here and I can see 'AirPurifier324' over there."
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."
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?
I've done everything using old Particle Xenon boards (nrf52840 microcontroller) and didn't encounter anything 'user hostile'. Originally I had all the 'hub' stuff on one of the boards too, but the newer recommended way is to have the board be the 'radio' and to use a normal computer for the routing.
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'.
Two devices can talk to each other if the hub helps them exchange keys https://community.home-assistant.io/t/how-to-implement-devic...
Yes but since it routes IPv6 and hubs are usually connected to the Internet when set up by the average consumer, it is very easy for Thread devices to "accidentally" gain Internet access.
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.
Yes, local control is a key feature as well as multi-controller.
yes, that's the entire point of it
I use some sort of cobbled together solution with Philips Vue lights, a couple of LIFX lights, halfway set up HomeKit, the Vue app, some Alexa integration, some sort of gateway that I believe connects Zigbee to my LAN...
.. but all I can remember from growing up is the X-10 POWERHOUSE
The new verge paywall seems to come out of no where, and seems to cover every article with no free limit?
Paywalled. https://archive.is/uOHVR
Leggi tutto
[dead]
[dead]
"A software development kit (SDK) is provided royalty-free,[13][14] though 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]"
So it's a closed ecosystem that makes money for a cabal of corporations
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.
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.
> 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.
Matter has a small but growing hobbyist community. A recent project I saw via https://www.reddit.com/r/MatterProtocol/:
(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.
Apparently "smart home" means that it's now a knowledge worker job to operate a lightswitch.