supportedNotificationTypes property and alarmMapping compat flag

[spudwebb]

Checklist

• I have read and followed the above instructions

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there or the fix did not work.

Describe the issue

We rely on the supportedNotificationTypes property to know which notification types a device support. For a device that supports Notification CC version 1 and has an alarmMapping compat flag, the supportedNotificationTypes property returns nothing, however the alarm values are correctly mapped to notifications and are sent to us, but this is causing some issues because we do not expect them.

2024-05-30T18:51:56.552Z CNTRLR   [Node 092] compat mapping found, treating V1 Alarm frame as Notification Repor
                                  t
2024-05-30T18:51:56.553Z CNTRLR   [Node 092] [~] [Notification] alarmType: 21 => 19                 [Endpoint 0]
2024-05-30T18:51:56.553Z CNTRLR   [Node 092] [~] [Notification] alarmLevel: 2 => 1                  [Endpoint 0]
2024-05-30T18:51:56.553Z DRIVER « [Node 092] [REQ] [ApplicationCommand]
                                  └─[SecurityCCCommandEncapsulation]
                                    │ sequenced: false
                                    └─[NotificationCCReport]
                                        V1 alarm type:       19
                                        V1 alarm level:      1
                                        notification type:   Access Control
                                        notification status: undefined
                                        notification event:  Keypad unlock operation
                                        event parameters:
                                          userId: 0x01
2024-05-30T18:51:56.554Z CNTRLR   [Node 092] [~] [Door Lock] currentMode: 255 => 0                  [Endpoint 0]
2024-05-30T18:51:56.554Z CNTRLR   [Node 092] [Notification]
                                    type:   Access Control
                                    event:  Keypad unlock operation
                                    userId: 1

In this case shouldn't the supportedNotificationTypes and supportedNotificationEvents properties be populated with the mapped values from the alarmMapping compat flag during interview?

If not, is there another way to get all the possible notification types/events that we can expect to receive from a device?

Software versions

Driver (node-zwave-js): 12.5.6

Z-Wave JS UI: 9.12.0

Device information

Manufacturer: Yale
Model name: YRD240
Node ID: 92

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

zwavejs_2024-05-30.log

[AlCalzone]

If not, is there another way to get all the possible notification types/events that we can expect to receive from a device?

I'll have to double check when I'm back at work on Monday, but AFAIK Home Assistant uses getDefinedValueIDs to determine which stateful notification variables exist. Not sure they are doing anything similar for events (stateless).

[spudwebb]

We need to know which events (stateless) a device support, or at least the notification types supported.
Don't you think it would make sense to populate the supportedNotificationTypes and supportedNotificationEvents properties accordingly to the alarm mappings?

[AlCalzone]

I'm not opposed to it, but I want to check first if there isn't another existing way already.

[AlCalzone]

Escalated to an issue: #6913