No POWER_MANAGEMENT events from YRD256 yale/assa abloy lock

I’ve got an older YRD220 lock which I believe implements an older version of COMMAND_CLASS_ALARM so I get the raw json events in the style below, and it works fine.


I’ve got a newer YRD256 lock which I believe implements a newer COMMAND_CLASS_ALARM (v4?) so I get raw json events in this style:


These mostly work, but not all.
It seems that all the events with notification type 0x06 (which I guess are the ACCESS_CONTROL ones) work fine, but the low battery alarms use notification type 0x08, as does the “RF module power cycled” event. (reading the doco here

I can see the events that don’t work likely map to these POWER_MANAGEMENT constants in the code - so there is code for this - so presumably they are supported by the binding?

(the event number in the doco matches the code)

When I try and cause the YRD256 to send one of these events (ie I remove and replace the battery which should send POWER_MANAGEMENT__MAINS_APPLIED), nothing appears in the debug logs at all - no exception or warning or anything to suggest a bug in the code, or even that the lock has sent any data at all. In contrast, the YRD220 gives me the expected raw json string when I remove and replace the battery.

So my question is:
a) does anyone else get POWER_MANAGEMENT events from their Yale/Assa Abloy lock with the newer z-wave chip (eg the YRD256 with the ZWM-1 module)? @ae_0017 I saw you mention in another thread that you have this lock - does it work for you? And @5iver have you got this one - any thoughts?
b) @chris the fact that I see absolutely nothing in the debug logs - does that mean for definite that the lock isn’t sending anything? So potentially I have a faulty lock, or my z-stick (aeon gen5) doesn’t fully support this notification type in the newer COMMAND_CLASS_ALARM? Or would the binding not be logging the message as it doesn’t understand it at some low level?

I’m using OH2. Thanks in advance for any advice from anyone!

Yes - or maybe to be slightly more correct - it means that the binding isn’t receiving anything. However this almost certainly is the same thing as the device not sending anything unless there is some communications issue in the network.

The dongles do not support ANY command class. All of the application level processing is done in the binding - the dongle just passes the messages it receives from the network through to the serial port - it’s pretty simple in this respect.