Make handle idling of "Lock Jammed" variable smarter

I am trying to get my August Lock Pro (https://github.com/zwave-js/node-zwave-js/blob/master/packages/config/config/devices/0x033f/asl-03.json) to properly report if the lock is jammed or not. When the lock jams I get this event:

{
    "type": "event",
    "event": {
        "source": "node",
        "event": "value updated",
        "nodeId": 8,
        "args": {
            "commandClassName": "Notification",
            "commandClass": 113,
            "endpoint": 0,
            "property": "Access Control",
            "propertyKey": "Lock state",
            "newValue": 11,
            "prevValue": 11,
            "propertyName": "Access Control",
            "propertyKeyName": "Lock state",
            "metadata": {
                "type": "number",
                "readable": true,
                "writeable": false,
                "min": 0,
                "max": 255,
                "label": "Lock state",
                "states": {
                    "0": "idle",
                    "11": "Lock jammed"
                },
                "ccSpecific": {
                    "notificationType": 6
                }
            },
            "value": 11,
            "ccVersion": 8
        }
    }
}

When I then un-jam the lock whether manually or automatically then I get:

{
    "type": "event",
    "event": {
        "source": "node",
        "event": "notification",
        "nodeId": 8,
        "notificationLabel": "Manual lock operation"
    }
}

or

{
    "type": "event",
    "event": {
        "source": "node",
        "event": "notification",
        "nodeId": 8,
        "notificationLabel": "RF lock operation"
    }
}

The problem is there is never another "event": "value updated", to clear the state of the lock jammed back to 0 / idle. What I can’t tell is if this is some particularity of the August lock that it doesnt send a new notification that the lock is unjammed, or if this has to do with how this library is differentiating between which events are value update events and which are asynchronous notifications

Digging around the code if found https://github.com/zwave-js/node-zwave-js/blob/master/packages/config/config/notifications.json#L386-L393 defining the lock jammed as a variable and then down in the events seciton https://github.com/zwave-js/node-zwave-js/blob/master/packages/config/config/notifications.json#L571-L576 there is a jumnp of 0x0A to 0xC skipping the 0x0B for lock jammed.

I am curious if/why not lock jammed isn’t listed in that events section and is instead listed in variables section? Should the 0x0b state be an event instead? Or is this something just weird with how August Lock is woring in which case need some specific override for the august device (if that is even possible in the config).

Before I did any PRs was hoping for some insight on what you all think the “correct” behavior here is for z-wave vs what I am seeing with my august lock.

The context for all of this is experimenting with this libraries alpha intigraiton with Home Assistant and trying to get locks to accruatly display locked/unlocked/jammed. Currently what happens is the lock jammed event value change event comes in and flips the created entity for the Lock State to on but then there is never an event to flip it back to off because that notification for value update only ever comes to say lock is jammed, any event that may indicate its no longer jammed comes in as a "event": "notification" rather then "event": "value updated", for the "propertyName": "Access Control",

[jfroy]

I’m in the same situation with a Yale YRD256 lock. But that’s a V4 notification product/module, so if I understand this issue correctly, there’s no requirement for the lock to idle the state/variable.

It seems to me, taking a step back, that zwave-js should have infrastructure for product “quirks”, much like the Linux kernel. It’s fine to have a “we follow the spec to the T” approach, but the real world is messy and products have defects. I’m new to this project and HA in general, so I don’t know if this has been discussed before.

[AlCalzone]

This issue is still open, I’ll get to it at some point.