The article addresses the point of standards needing time to mature. Could you elaborate on this further and compare the challenges and progress of Matter with ZigBee, Z-Wave, Thread and/or HomeKit?
What can we learn from the history of these other standards and which challenges have these standards overcome which Matter is still facing?
Home Assistant has seen advances in supporting the integration of Matter devices into our self-hosted smart home, but that is only half of the story of Matter. Matter should also eliminate the need for multiple bridges and enable older devices using Zigbee or Z-wave to be integrated through a matter bridge.
Now my question: is there a plan for Nabu Casa to enable a “bridge mode” for Home Assistant? It is in direct conflict with the monetization of the project since it would be much easier to integrate all of our Home Assistant devices into Google, Alexa, etc. In this post, one of the comments explains that a node-red implementation already exists and that a similar project like Homee already implements a Matter bridge.
I appreciate that you’re doing this livestream, I will be watching!
I build my home network mostly on Z-wave, and am wondering in what direction I should expand further. I feel like Z-wave is the better technology (no interference with wifi & bluetooth frequencies, better penetration trough all the concrete & rebar in my house, the new Z-wave LR range looks amazing), however it looks like in practice it’s losing some steam with not many new z-wave products being released.
So I would like it if you could cover possible transition scenario’s for us z-wave adepts who are considering to venture into Matter in future.
Also what does the future look like: direct matter support on devices, or will many of them need proprietary hubs that ensure the Matter integration? Just today I looked at the Aqara Curtain Driver E1 for example, which supports Matter but only if you buy the Aqara HUB…
I was also looking at a review of the Nuki 4 Pro door lock, which supports Matter, but for most of the configurations you need to use the Nuki app. In practice this means that if Nuki goes bankrupt the lock becomes mostly useless as well. With Z-wave this problem does not exist, as all configuration settings are done trough Z-wave. The only problem you could face if the manufacturer of a z-wave goes bankrupt is that there will not be any firmware updates anymore to fix possible bugs. Will Matter be able to catch up with Z-wave on being bankruptcy proof? In the Nuki review they mention connection problems when using Matter over Thread, any insights on reliability of Thread connections could be interesting as well.
True, but Matter should not reinvent the wheel either.
The Z-techs have matured a lot of things right and they have lived with the invention and addition of new products, that were not even thought of at their birth.
The idea of Matter to make a common strict standard is good to some extend, but it seems that it is now so strict that it is killing progress and invent. A good example is the smart plugs that can not provide power measuring too.
So the question is will Matter open up for some room in their standard to allow for cases that have not been thought of or make it more flexible?
As you pointed out, I definitely think it would be beneficial to discuss the differences between Matter at the application layer and Thread,WiFi and Ethernet at the transport layer. Also, how Bluetooth ties into the mix as well.
I’m looking forward to this! I’d be interested to see a discussion on best practices for zigbee/thread coexistence - I’ve found some general recommendations around that in some GitHub issues but it’s not clear to me how to best act on those. In my case, I have a Yellow running Zigbee on the onboard radio and then a SkyConnect running thread-only firmware with OpenThread. I have some pairing and stability issues with my Matter-over-Thread devices (I do use an Android) but I’m hoping to avoid needing Google/Nest devices for the Thread implementation. Any guidance there and also any kind of roadmap for when using SkyConnect as a Thread border router might be supported more formally would be great.
@WallyR That is strange as there are product avail that are smart plugs that do monitoring.
I think its just interpretation as guess of course you can but both a seperate matter nodes than butcher a smart switch with the inclusion of monitoring.
Currently you are using Google to add MATTER Thread devices! Are you planning on changing this, as THREAD & there for Matter is broken in my home & others using Google Home but does works with Alexa. Google have given up trying to assist. So I’m unable to add any MATTER Thread devices to Home Assistant even though I have the Skyconnect dongle.
The Meross smart plug, as well as others, with Matter support provide the power measuring over its own app. It can’t do it over Matter, because Matter have not provided a sensor standard for it.
Same goes for Eve smart plugs.
Matter devices are using IP, weather the medium is WiFI, ethernet, or thread.
How, exactly, are users supposed to guarantee that a (thread) Matter device isn’t piggybacking off a border router’s access to the LAN to reach the open internet? With a wifi/ethernet device, it’s pretty easy to just put it on a distinct vlan to limit access.
Somehow, I don’t think Apple/Amazon/Google/etc are going to provide configuration options to tag packets from matter devices with a VLAN id. Having to manually add blocks per ipv6 address of a thread device does not seem appealing.
Yeah but the HA Team addressed this last month (or the month before).
Matter under the hood is using stuff a lot like the Zigbee clusters technology, and that’s how this is working - Eve are publishing the power information to a manufacturer specific cluster, and Home Assistant is temporarily subscribing to that cluster for Eve devices until Matter supports it natively.
EDIT:
As for the people complaining that Matter does not support this and that - like power monitoring. I suspect that was why Belkin pulled out for a bit. It was expect to arrive with the first Matter update last Spring, but that largely ended up being a bugfix to fix reliability and connection problems. The next release was more concentrating on adding more device types. Because manufacturers are desperate to get on board, they need the matter standard to focus on adding more device types, because they want to release products onto the market, which they can’t do until matter supports that device type.
It’s matter I have no home kit integration, I got the eve plug and then aqara all pulling into Hass with matter. Andrew does explains why it’s working though the HA team did a solid.
It been asked above but to me the biggest questions are around HA acting as a matter bridge. This seems a fundamental requirement for any centralised home automation system.
While most of us who are on Home Assistant might dive deep into Matter, it’s not trivial to replace dozens or hundreds of devices with Matter so I think there’s plenty of time for Matter to mature and for HA to make use of it before it becomes a bottleneck. That being said, I try to buy from manufacturers that either currently support Matter in it’s infancy now or have built in the ability to do so in the future. Inovelli is a great example of this approach, where all their Zigbee is “Matter Ready” for when that comes to maturity.
I have yet to even try Matter at all, because it’s just not as robust yet and I don’t particularly want to be an alpha tester of the system. Once the major players really start to throw their weight behind it I believe things will change rapidly and I see 2024 as a good possible year for that because with all signs pointing to what could be a red letter year in terms of a tanked economy, this is when they will want to try to innovate to boost sales.
I am so confused about setting up matter devices, I am not sure if I should go through the matter integration or the integration that corresponds to that devices manufacturer. Does this lead to duplicate devices?
Nanoleaf app, has a feature which shows you the thread border routers. It would be good for the home assistance app to do the same without having to set up the app. It would be good to see more info on Thread Network Authentication, as this seems to be a topic not covered at all. Info on ensuring you only have one thread network and not multiples in home. Thanks for all the effort.
I love DIY projects and I like the flexibility of esphome. I have 46 esp devices at home (relays, sensors, switches, rfid,…).
I am not an expert in matter nor thread, but I believe matter support WiFi. Would I be able to use my esp devices flashed with esphome to get the advantages of having a connection-mesh with my existing devices? If not, will be other esp prepared for that? Esphome will give support to this new standard?
PS: I’m glad you guys are inside CSA, we need nice people in there to think first in the users
a stable thread network with multiple border routers (especially a mixture of Apple devices and OTBR devices)
merging existing thread networks (especially Apple and Open Thread networks)
moving configured devices from one thread network to a different network without having to delete, reset and reconfigure them in HA (including all automations, blueprints,…)
iOS apps being able to manage Matter devices in a OTBR (e.g. SkyConnect) thread network, as currently iOS ignores all non-Apple thread networks
Thank you, it looks promising. However, I don’t want to buy modularized hardware, I really like the freedom of esphome.
And the key points: connectivity with Home Assistant (like calling services of HA or exposing new services), automations and low programming inside the esp itself, custom components,…
Esphome is based on Espressif libraries for esp hardware, so I understand matter possibilities in esphome will come.
Will matter reduce the need for things like ZHA quirks to correct manufacter mistakes? Or do you expect even with matter and/or thread that we still need to use quirks to compensate for mistakes?
Are companies required to provide public url’s to their matter device’s firmware’s? Will HA add these public URL’s to make it easier to update a device? Always hate to sniff my network to catch a zigbee inage. I’m looking at you Aqara!
As I said at the beginning, I don’t know exactly what Matter is, perhaps I am confusing Matter with Thread. What I want is the cool IP connection protocol with low latency and mesh capabilities that I can easily use in my esp flashed with Esphome.
Thank you for your clarifications, but I still have that doubt. Maybe my question should be: Esphome is going to implement Thread? And what Esp devices will be compatible?
Do you think that there will be a situation where there will be a lot of custom endpoints in Matter, like it is with ZigBee and z-wave? How can CSA prevent it?
In discussions of getting Nanoleaf devices connected to Home Assistant Matter system, I got lost when the discussion turned to IPv6 setup needing to be set correctly. Can you p provide some advice if what that means?
I realise Remote HA is not part of core, is there a better option for setting up a Thread Border Router using Sky Connect when all your Matter devices are far from your Home Assistant box?
How are firmware updates managed with matter? Will we be able to do them via home assistant or will we need the eve app, nanoleaf app, and so on to update devices?
Got some open Matter + Thread related questions for ESPHome and HA that be nice if could answer:
1a. News about native Matter support in ESPHome firmware over WiFi on ESP32?
1b. News on Matter support in ESPHome firmware over Thread on ESP32-C6/H2?
* That is, to make our own Matter compatible devices using ESPHome on ESP32, so wondering if begun working on it as Tasmota has? → Adventures with Matter protocol on Tasmota · arendst/Tasmota · Discussion #17872 · GitHub
2. Any news on TREL (Thread Radio Encapsulation Link) support for SkyConnect?
3. Any news on native TREL support for multiple OTBR with HA’s Matter controller?
4. Any news on native support for multi-admin support in HA’s Matter integration?
5. Will Matter controllers eventually be able to join HA’s Matter Fabric?
6. Any tips or help with OTBR firmware builds for (TI) CC2652P based adapters?
7. Will the Matter integration depend on “Matter device handlers” like ZHA-quirks?
PS: Looking forward to the day when Home Assistant’s Matter controller has native for having multiple Open Thread Border Routers on its own in the same Thread network to avoid SPOF (like Zigbee has).
My high level understanding is that Matter devices need to be certified for other devices to accept to talk to them. How do we get around that with DIY devices like a custom Home Assistant instance (which is obviously not certified)?
You previously said that hardware manufacturers use Home Assistant for testing their devices. Is the main purpose of HA’s Matter support to provide a standards compliance benchmark or an end user product? Because, these are sometimes contradictory goals. Like when the Matter integration recently broke some devices by removing a workaround for the devices’ faulty software. This makes it a good benchmark but was a big headache for users, who had to disable updates and roll back to a previous version.
Tasmota devs are also working on a Tasmota to Matter bridge that allow a user to pass along sensors from non-Matter Tasmota devices via a proxy to get the data into third-party Matter Fabric.
Will Home Assistant support Matter Casting?
This is a standard similar to Google Cast or Apple AirPlay. Amazon is currently implementing and pushing this standard.
I dunno even if Matter casting is Matter casting or that Amazon because Chromecast & Airplay has far more market has created a open-source casting and called it Matter casting. I would prob say because of the approach Amazon has made with no colaboration and announcement its very likely they will not and Matter casting will only work in the Amazon ecosphere.
While probably not directly related to the home automation side of Matter that is still a very interesting question, especially if that means it could also be used an open multi-room audio streaming protocol that can be used for syncronizing music streams to Home Assistant satellite speakers.
For me the strangest thing about the opensource Matter Cast is I can not find the source? Does anyone know where Matter Cast source code exists as then if it syncs or not could be explained or likely the best audio sync virtual cable on Linux is GitHub - badaix/snapcast: Synchronous multiroom audio player
Please cover planned Matter button improvements for triggering automations. Specifically, easily setting triggers for various multi-tap, short press and long press actions.
Provide a sneak peak into any Matter device management UI enhancements, such as viewing IPv6 addresses, pinging a device, etc.
I’ve recently “lost” all of my Eve Matter devices. They bugged out, then ate up their batteries trying to reconnect. Replaced the batteries with no auto reconnect so I deleted them all from everywhere and reset them.
Now I cannot onboard them directly (using QR/PIN) to HA nor can I onboard them FROM an Android device. I have no idea whether this is because there’s a bug on the Thread/Matter implementation in HA or on Google’s end. Either way, they’re $300 worth of paperweights until I can onboard them into HA.
At this point I’m not buying any more Matter devices until some huge breakthrough, but I still have an ask…
Is it possible to offer some sort of Matter or Thread dashboard so you can see whether there are any service affecting bugs impacting HA Matter or Thread functions or bugs affecting onboarding from Android or iOS?
I understand there are reasons why the initial Matter implementation relies on Google and Apple code on a mobile device; I know the roadmap mentioned ending this dependency, and I hope this is achieved soon.
What I do not understand is why Matter support for us Core users aren’t even mentioned on the roadmap presented in the livestream. What is stopping the add-on Matter process from being installed independently, like a Node-RED or Wyoming process?
After seeing the livestream I have some basic questions.
If I understand correctly, Matter is a protocol that works over IP; and Thread and WiFi are just IP networks. So, if I have a Thread network I would expect that I could “ping” my thread devices from my laptop which could be connected over WiFi or via ethernet.
My question then is, could a matter device be connected via ethernet?
Moreover, I understood that Bluetooth was only necessary to join the IP network (not Matter per se). Would an ethernet Matter device not require Bluetooth as it could join the IP network without credentials, just by plugging the cable?
Finally, once the device has joined the network, does the Matter protocol not require further authentication? Is it automatically detected and adopted by Matter hosts already in the IP network?
I’m learning Matter like most of us, so I can’t claim to be an expert, but I believe I can answer your questions.
The Thread network does not share the same IP space as the WiFi/Ethernet networks and the Matter/Thread router is not set to bridge anything between networks other than the Matter protocol, so things like ICMP traffic from Ethernet to Thread is not possible at this time.
Since Matter is IP based, in theory a wired ethernet conneciton would work the same as a WiFi connection. Other than some Matter bridges, I’m not aware of anything with a physical connection that’s Matter certified today.
Bluetooth is used in the “commissioning” process to set up the WiFi or Thread connection, passing credentials, etc. Once it is attached to a network, it also passes the security keys to the device for authenticating to the Matter bridge/router. For that reason, there still has to be some connectivity even if on a hard-wired network.
Matter is encrypted by design. As part of the “commissioning” process over Bluetooth, the device and the bridge/router exchange “keys” for authenticating that secure connection. This is unlike ZWave or Zigbee, where the gateway can detect new devices and auto provision them. For that reason, new devices will not just be detected by bridge/router.
Thank you! Your answers make total sense. I was awfully unaware that Thread only allow Matter communication to the rest of the network, that is interesting to know.
i’ve seen “Matter over zigbee” devices. I suppose it actually is a zigbee device that has to be connected to a zigbee bridge (that supports matter, like Hue bridge?).
The low-power radio version of Matter is Thread, which is uses similar radios to Zigbee but are different.
Zigbee and Thread both use IEEE 802.15.4 (hence Skyconnect dual-stacking). Thread uses IPv6 addressing and supports multiple routers, both unlike Zigbee so they are incompatible.
Personally, I’d avoid, and look for the controlled certification logos which suggest the manufacturer knows what they are talking about!
Here is a thread device from the _matter._tcp. mdns records
(I know it’s a thread device because other stuff on the actual network including the Google hubs and the Switchbot mini hub have public ipv6 addresses)
And here is my windows laptop, pinging that IP address:
You can see there is an initial high latency as the thread border router does it’s thing, and then the latency drops off a bit, but is still much higher than pinging a device on the LAN.
It was mentioned. I think the answer was basically that they currently are focusing on integrating Matter devices. Making Home Assistant act as a bridge is currently not in scope for the Matter work.
A bit of a ‘Rube Goldberg’ path, however I think you could use Tasmota’s esp32 based ‘bridge’ functions to expose something from Home Assistant that Tasmota could get at via a API call or MQTT, see link below. At least for a interim, path. Easy to setup basic bridge function and explore the Matter ‘connections’ and control between the various hub systems.
I’ve not done this yet, however I have exposed some Open Beken x-Tuya devices and ESPxx devices to Google Home and Apple HomeKit via this ‘Matter Birdge’ function of Tasmota32, I am very impressed by the function and stability of this code (at least on the Tasmota side, the changes going on with Matter stuff by the ‘big three’ not so much).
Probably because my ISP doesn’t do IPv6 yet (and thus I don’t have any IPv6 on my internal network yet), so I have no visibility to the Matter over thread devices (since they are native IPv6) from my IPv4 networks.
The new update for Matter did not fix the ability to set transition times. They are still turning on instantly. Was this expected to work in this update or a later one?
Because the Matter server requires a whole bunch os OS-level patches. Even running it yourself in a docker container can cause issues. There is only like 2% of users running HA without docker or HAOS so I think you can do the math why this has no focus. We have been tweaking the Home Assistant OS to give the best performance and meet all requirements. I suggest you fire up a VM and run Home Assistant in there if you want to use Matter or any other component that relies on external components.
Yeah, it was too big for a quick bugfix as its actually a new feature. So it will (hopefully) be in the next HA version (so the february release). The issues with setting colors did make it to the bugfix release though
There was a ton of great information and lot of slides in this 2.5 hr video, would be nice to be able to access them directly instead of scrubbing the video…
Thread can run local ip6 over your network without any requirement for ip6 support from your ISP.
Known as link.local
Any thread border tourer will handle this for you and actually the simpler/flatter network you have the easier and better it works.
If my Thread Border Router (in this case HA) is doing that, that’s fine (I know Matter is IPv6 native). I don’t have my Internet router giving out IPv6 addresses since the ISP is not currently giving it IPv6, and I would have to run a wireshark trace to see if there’s IPv6 traffic on my IoT VLAN. Point being other than the HA itself, I don’t have any other non Matter devices with an IPv6 address to test communication between thread and WiFi devices.
I would like to know what these are. Where can I find documentation or code regarding these patches? It can’t be that hard for me or any other sysadmin to spin a separate server running on the same machine as Home Assistant Core, can it be?
As for using HAOS, out of the question for me. I have close to 35 VMs and none of them can just run random arbitrary OS — it has to run as a process within a Fedora template with customizations because I’m using Qubes OS, within which I simply cannot install HAOS and run it as it’s meant to run.
I hope at some point there is an independent release of the Matter server code just as there is an independent release of Zigbee2MQTT and many other components that run parallel to HA (I’m thinking like Node-RED since that’s one of the things I use).