VTM31-SN Matter Generic Switch events: should cluster 0x003B subscriptions be reported without delay per Device Library R1.4 §6.6.4.1?
I’m looking for Inovelli’s/firmware team’s interpretation of Matter Device Library R1.4 §6.6.4.1 for the VTM31-SN White Series Dimmer.
I am running VTM31-SN firmware 1.1.5. The switch/button endpoints expose the Matter Switch cluster (0x003B) and it seems those endpoints (3, 4, and 5) are using device type 0x000F / Generic Switch.
The issue I am investigating is not the device’s multi-press detection delay. I understand that the device may need a short amount of time to decide a tap sequence is complete before it can generate a MultiPressComplete event. My question is about what happens after the Matter event has been generated.
Using chip-tool on a test fabric, I can reproduce the following behavior:
-
Subscribing to Switch cluster
0x003Bevents withoutEventPathIB.IsUrgentcan result in events being held until an opportunistic (attribute change) report or until the subscription max interval. -
Subscribing to the same
0x003Bevent paths withEventPathIB.IsUrgent = truecauses the VTM31-SN to report the generated events immediately. -
This confirms that firmware 1.1.5 does support and honor urgent event subscription behavior for these Switch cluster events.
The part I am hoping Inovelli can consider is the Generic Switch device-type requirement. Matter Device Library R1.4 §6.6.4.1 appears to acknowledge that generic event subscriptions may otherwise be delayed due to batching / min-interval behavior, then says that a Generic Switch device SHALL send updates of attributes and events defined in the Switch cluster “without delay” to subscribed parties.
Given that:
-
the relevant VTM31-SN endpoints are Generic Switch (
0x000F), -
the relevant events are Switch cluster (
0x003B) events, -
firmware 1.1.5 demonstrably sends them immediately when
IsUrgentis set, and -
non-urgent subscriptions can delay generated events until max interval,
should the VTM31-SN firmware treat Switch-cluster event subscriptions on Generic Switch endpoints as urgent-equivalent by default, or otherwise guarantee immediate reporting for generated 0x003B events even when the subscriber does not explicitly set EventPathIB.IsUrgent?
I am also pursuing a controller-side feature request with Hubitat to expose EventPathIB.IsUrgent for Matter event subscriptions, because that is the clean controller-side mechanism. But from the device side, I’m wondering whether §6.6.4.1 means the White should already provide this low-latency behavior for Generic Switch events regardless of whether the controller explicitly requests urgency.
Happy to provide the exact chip-tool commands / subscription matrix if useful.