Is there any way a hub event can created based on Hubitat and a Matter device re-subscibing? I see a MatterNodeCheckJob under scheduled jobs, but no hub events affiliated with it.
Iām pretty sure that Matter buttons are not formally supported yet in Hubitat which is related to these issues. If they are and I missed it, what is being used to stop these attribute dumps being treated like events?
@bcopeland, I hate to bother you, but can I get some input on how Hubitat resubscribes its Matter subscriptions with devices? I'm currently hacking it by including a time based suppression of events every time Initialized is run to block ghost button presses showing up as real event. If this is the way I need to do it for now, I'm fine with that but I was hoping for a little bit cleaner method.
@kkossev, did you ever find a good solution to button presses based on Matter events?
For anyone that comes across this thread, the only way to really get Matter Buttons to work right now is via an event block during initialization. Right now, when a button re-subscribes, it sends previous button presses (see the forum posts at the top) from the device's history. I'm using a three minute block from when initialization is called before the Hubitat can accept a device's button push. It's not ideal but works. My guess is that until Buttons are officially supported, this is what has to be done.
Note, the Inovelli's work perfectly fine in normal dimmer mode. This thread is strictly about Smart Bulb Mode which converts the device to buttons rather than a switch.
@Hubitat_Staff , if you all need someone to be a guinea pig for Matter Buttons, just let me know as I'm happy to help.
Thanks! That is the behavior I see with the ThirdReality Night Lights, but I'm seeing something slightly different with community driver. I'll keep digging to see if there is something odd, but when I add further debugging code, I caught random initialization being called which was triggering false button presses.
Also, the offer still stands if you want someone to test Matter Buttons as the Inovelli provides three of them in Smart Bulb Mode.
Matter.attributePath as I'm using @jvm33's very in-depth driver. Of course, it is an Inovelli switch, so I'm dealing with 6 different endpoints and a custom Mode Select. For good or bad, I'm currently installing their Beta software that gets rid of the Mode select and adds 9 more EP to manage.
It's really just the generic switch events that are causing problems. The driver handles the first one on initialization, but there seems to be several more that come through. It might be a firmware issue as well, which is why I'm uploading the Beta right now too.
@bcopeland and @kkossev...I've got some updates for both of you. Over the last week, I've been creating a Hubitat Device Driver from scratch for the Inovelli White and tracked down the issue with Generic Switch/Buttons from a multi-tap perspective. matter.attributePath () method works fine for any single press button (00 ā 01 edge = pressed, 01 ā 00 = released).
To get multi-taps, hold, and release working, I had to use the matter.eventPath () method. This was not a fun adventure for a two big reasons: (1) for whatever reason the Inovelli switch does not use persistent subscriptions with Matter. It is constantly re-subscribing on its own (verified with Inovelli). This causes the second issue: (2) an Event subscription causes the device to send a backlog/history dump. I've worked around it by suppressing all Events for 5 seconds after a subscribe call is made. This workaround does what is needed to allow multi-taps to work. It's not ideal, but does allow the Inovelli White to be fully used in a Hubitat environment.
With the above said, Bryan or whichever @Hubitat_Staff member that is in charge of the Matter implementation, is it possible to get Subscribe Response Action Information (per spec 8.5.x) to be passed to device drivers? This is the missing piece that our drivers need in order to not use workarounds. Basically, it would tell the driver that the device is done with its backlog/history and that everything from that point forward is live. Basically, my ask is can Hubitat add "Subscribe Response Action Information" as a report that gets passed to the parse(description) routine or perhaps to its own method.
