For everything so far I have some mechanism to notice I f they are offline. Wifi I ping with a network monitoring system. Z-wave has a “last seen” and if it’s getting old it pops up and warns me.
Well, almost everything - I need to do something about BLE. But I think I can do something similar to z-wave.
I’m struggling with my new Matter devices (all of three, but growing).
I tried setting up automation based on state changes in things like battery, but those don’t fire apparently when it’s the same value. Hours of googling have yielded all sorts of things that do not seem to work, a mythical last_reported attribute I can’t seem to find for example. Some AI answers say to download diagnostics and search them, but my thread “download diagnostics” just says “no file”.
I believe devices should have some semi-independent monitoring to know if they just stop working. My first 3 matter devices are smoke detectors, so this is even more important.
Am I missing something obvious? I’m happy to script testing in my NMS, or set up automations to track a last-seen, I just don’t see any hook to hang those onto.
Regular matter over wifi is relatively easy (ping), but thread? Especially sleepy devices?
Instead of tracking state changes, then try to track events.
Same state will not trigger a state change, but there should be an event for each time it reports a state, even if it is the same.
Besides that it can be hard, because battery powered devices will go into sleep at times and then they decide themself when to wake up and report again.
If it is mains powered devices then you might be able to ping them, since both Matter over Thread and Matter over WiFi are IPv6 based.
That’s a good idea. I think I can look up what events it reports.
I actually don’t understand how these things actually work. They somehow go to sleep, but they respond nearly immediately. I can press the self-test (HA) button and the tone from the smoke comes out quickly. So it’s asleep, but the thread communication appears able to quickly wake it.
It’s really rather cool that it can do that. And makes me wonder if there is not a “ping” somewhere.
What would be REALLY nice is if HA’s matter implementation monitored everything it could and put up a last_seen like zwave does (well, I assume it’s the zwave hub not the individual components, but it’s there and it is handy).
So if the event list in the automation menu is complete, there’s nothing there which will help. Things like battery level are “Battery level changes”. Assuming that’s literally true I’ll get that on the state trigger.
What I don’t know is if there are other events not shown, but I presume i’s complete.
I’m feeling dense. I know about the event tab there, but I don’t know how to see available events for a given device.
If I create a new automation in the gui for a device, it provides me a list of events (though I don’t know where it obtains it). Is that list not complete?
…
I’m surprised to find out that these “sleepy end devices” actually respond, albeit a bit slowly, to a ipv6 ping. I can find the ip address under the matter integration device display under “matter” attributes. But those addresses can change, and if I want to monitor this via an occasional ping from a network management system, I need to know where they come from.
I looked in the mdns discovered data, and I see each in there, with their ipv6 IP address, but nothing that maps them back to something I can find from HA. At least that I’ve seen. Browsing the HA API (which I already use for some tracking) I haven’t seen a path to the IP address either.
I find it hard to believe this is not a thing someone has solved already. Or conversely am I chasing something unnecessary? Maybe they go unavailable reliably?
I know the BLE ones do not, I’ve seen their battery run dead and not indicate unavailable (Shelly devices go from 100% to dead with nothing in between, at least some do).
If you set the event tab to listen for * then you will see all the events on the event bus.
When you see the device you want, then you can refine the filter and replace the *
I guess the event list you see in the automation GUI is not complete.
Each device might have a set of specific events and the developers can’t possibly know all these in advance.
I assumed the automation GUI was pulling from some device provided list from the integration, which I assumed got queried from the device somehow. Magic, you know.
I tried doing what you described, it’s like drinking from a firehose (as the saying goes), I have too much going on continually. If I filter (e.g. by the word “smoke”) I see just events from the entity names smoke. All so far are state changed (I forced a bunch by a self test). I have no idea if eventually there’ll be something else, but so far not.
I also pulled the battery from one. Maybe HA is smart enough to drive them unavailable after some timeout (maybe the 7201 seconds in the ot-ctl output above). I’ll know in about 6900 seconds – or when I wake up next, whichever comes last.
Yeah, with a * you get EVERY state reported to HA. It is the true picture of what HA sees.
Maybe someone can help with a better filter than *.
HA can only “know” when a device is unavailable if it has a time which the device need to return within.
There is no way for a device to report it is unavailable (because if it can that then it is available).
I tried filtering by “smoke” and left it running over night, in the morning it wasn’t running. Not sure if because that tab lost focus or otherwise, but got nothing useful.
The “no way” comment though is interesting; something in HA notices, and I am surprised by the Thread devices. The smoke went unavailable about 10 minutes after I pulled the battery. I just did it again, and same thing… something has a running timeout and notices very quickly (for a sleeping device) it is gone. In fact the thread child table shows it’s checking in every 5-10 seconds or so.
Which is surprising for a battery, sleep end device.
I think I’ll put this whole question on hold until I get some more battery matter devices. Maybe Thread/Matter has this covered, implicitly, somehow.
