I'm migrating my devices to Matter versions and, one thing I noticed about Hubitat, is that it is still unstable for Matter.
It's very common see the Matter status locked on On, even with device Off, needing I the Re Subscribe button on Matter Advanced Bridge driver to get the newest status.
Another problem, usually happens when I reboot Hubitat or the Aqara hub, for example. When devices is on, I need to re-discovery, otherwise sensors won't send the status to Hubitat too.
Another recently problem I had was offline status from Thread sensors after some IPv6 changes. I needed to reboot Hubitat to make it works.
I don't think it's a device problem, since it happening only on Hubitat, and working well on HomeKit or HomeAssistant. It also happens with different devices, such relays, sensors and more.
Are these all Matter over thread devices? - What is your TBR?, and what EcoSystem did you do the initial provisioning with? (I've had best luck over Apple/HomeKit)
I'm not seeing any of this over 3 different types and manufactures of Matter over WiFi (Linkind RGB Bulb, Tapo Outlet/Plug Switch, Leviton InWall Switch) - All seem fine over various reboots and upgrades, and none have ever needed reprovising. About 10 Matter devices total, and to be honest, this stuff is more reliable than some of my Zwave devices
Are you just using Matter over a Aqara hub Bridge? As I didn't think HE had formally released support for bridged endpoints (I do know that there is a user driver for that).
My personal sense is that there may still be bugs around bridged devices, as I thought that was still under development on the HE end of things - This may be better pointed in the "Matter Advance Bridge" channel, versus "Feedback" - And I'm guess @ kkossev is going to need version details of your hubs, and the specifics around the devices in question.
I’m using HomePods as TBR, and I paired initially on HomeKit, than I exported to Hubitat.
It works well, but I feel when my IPv6 changes, Hubitat can’t detect the new IPv6 from device, even rebooting the device. Than I need to reboot Hubitat itself.
About the bridge, well, I’m using kkossev driver. It’s perfect. But sometimes, when Hubitat or bridge reboot (I don’t know what makes HE lose connection), I need to re subscribe to continue receiving sensors status, for example.
It happened even with a Matter relay directly connected to HE. I could turn lights on or off, but Hubitat status is crashed!!!
What do you mean “my ipv6”? I don’t think matter devices use the lan ipv6, in fact they work without having ipv6 on the lan at all. A separate network is created for matter, I think using link local addresses. A link local address should never change.
There are more variables and possible points of failure for the Zigbee devices used via Matter Bridges. If you can replicate some of the issues (as an example a bridged Zigbee device does not update its status in HE until the events from the bridge are re-subscribed), let me know and I will try to reproduce it myself. When a Matter Bridge is rebooted, it usually takes a minute or two until the connection is re-established. However, this re-connection process is not something that can be controlled on a driver level, so probably there is no much room from improvements here.
@kkossev looks like some of your devices are showing the Local IPV6 (fe80) and some are showing a public address. Is the difference between those thread vs Wifi devices or any distinction between those?
The actual info in the internet about this topic is very sparse, so devices may in fact use your ISP assigned prefix in some cases when you do have IPv6 setup on your LAN already. They should still all be able to use a LL address locally though, so not sure why HE would not just use that for 100% of devices.
Apparently IPv6 is a requirement. I previously had IPv6 disabled on my IOT VLAN (Ubiquiti network) and I recently started dabbling in Matter and Matter Bridge on Home Assistant. Nothing worked at all until I allowed IPv6 traffic, even though all devices already had an IPv6 link local address.
Its not required, others have confirmed it working fine even when their LAN was setup only for IPv4 and IPv6 not enabled. Possibly by using a VLAN and having it disable there, it was causing the router to actively block all IPv6 traffic.
Yes, I think this is what was happening. I think the router and switch was actively preventing any IPv6 traffic on the VLAN. But there was several mentions about making sure IPv6 traffic was enabled on your router on all the Matter Bridge for Home Assistant documentation and it definitely didn't work at all until I enabled IPv6 support on that VLAN.
Maybe they had too many issues like you had so instead of going into to detail they just tell people to turn on IPv6. I have randomly just been reading up on Matter and IPv6 and lots of talk about IPv6 routing being way more complicated for an advanced network than IPv4 especially for automation enthusiasts to configure or understand.
I will just stick to my single /24 LAN and single consumer grade ASUS router.
May add one mesh node down the road for better outdoor coverage.
Despite having a degree in computer networking.
I am admittedly not super savvy on IPv6. I know the basics. Currently I let IPv6 auto configure on my network using prefix delegation to get addresses from my ISP. I don't really know enough about it yet to effectively configure my firewall the same way I have my IPv4 firewall set up. So, more or less for security reasons, I purposefully had IPv6 disabled on my IOT VLAN until a couple weeks ago when I decided to try sharing all my HA devices with Hubitat via Matter Bridge instead of HADB. Many devices on my IOT VLAN had link local IPv6 addresses, but IPv6 communication to other VLANs or the internet always failed.
Anyway, I enabled it for my IOT network now, so I better figure out the important parts now so I can properly firewall these devices and use DHCP6 with proper private addressing instead of prefix delegation.
I've always had it enabled with addresses assigned via prefix delegation on my other VLANs, but since I controlled all of the devices on those networks I wasn't concerned about it. I have no idea how many times a day my stupid Kasa plugs are sending data to TPLink or updating firmware without asking anymore...
I am still using HADB at the moment, but playing around with the experimental Matterbridge Add-on for Home Assistant to share devices with Hubitat and Google Home. Since Matter seems to be the new thing, I wanted to see if I could use this to move all my Zigbee devices from Hubitat to Zigbee2MQTT in Home Assistant and then share them all back to Hubitat via the native matter integration in HE.
This Matterbridge Add-on for HA basically allows you to share any device or entity from HA as a matter device to any other matter capable platform.
BIG Thank you for the info. At a moment I am using HADB without any problems. But Matter seems to be more natural integration. I guess, I will try it at some point when it becomes more stable.
I have just a few devices for testing, three Nanoleaf essentials bulbs. After a few initial months of firmware issues, these matter devices have been rock solid. They were provisioned via HomeKit on an AppleTV 4k. I haven’t had to go in and tinker with them at all in several months. Are you sure it’s not your devices that are wonky? Admittedly I only have a few devices and have no intention of replacing any of my Zwave devices with matter, however I will consider matter where it makes sense. The only swaps I will make is switching my ZigBee Hue indoor and outdoor and Aqara P1 motion sensors to Z wave LR (zooz ZSE18 and 70 motion sensors).
I made a video about the Matter problem I have with multiple kind of devices.
Even with device turning on or off, the status is crashed as "On". That's terrible because crash completely automations. Same problem happens with sensors from Aqara M2 over Matter.
To fix that, I'm using Krassimir driver, where I can use "_ Discovery All" button to refresh connection, but that's something boring to do constantly.
Vitor, as you have the Matter Bridge in the middle, this adds another possible point of failure. So it isn't clear where the problem originates.
Do you have a 'native' Matter device (either Thread or WiFi) to test, using the HE stock matter drivers?
Unfortunately, at the current stage of Matter implementation in Hubitat, there is no information available on the device driver level related to the Matter connection state or the error codes returned by the Matter devices.
Looks like Matterbridge isn't currently a workable solution in the way I intended (to share HA devices to HE), as Hubitat is unable to commission matter devices natively. Bummer.
