Zwave JS to MQTT addon and the Zwave JS Integration, trying to get a Yale YRD256 deadbolt working.
For some reason, it seems the status is incorrectly being reported, for at least the “jammed” flag (I’ve not worked out where to find some others like tamer yet).
I’m not sure what to do to get this working, for the moment I’ve only moved one (interior garage) lock over to the new Zwave network since I kinda need to know about lock failures for the exterior doors so I’m stuck until I figure this out.
These used to be reported by alarm_level and alarm_type and were 100% reliable.
I also tried looking at the events listening for “zwave_js_value_notification” like I gather scenes are sent over now and I see nothing when the lock operates (or jams), so I’m not sure how to obtain this information. I also really need to figure out if its unlocked with a valid PIN from outside (vs manual inside) so some of my automatons can work again depending on if an authorized PIN was entered and that data seems to be missing in the new ZWaveJS stuff
Ugh…so basically there’s no longer any way to know if it is or isn’t jammed anymore?
That link looks like its Zwave-JS not Zwave-JS-to-MQTT? Or are they the same? Or is that the integration vs addon?
This all seems very confusing with so many same-name-but-different things.
This is maddening that there’s so many things seem missing and I am having such a hard time finding information. Been at this for 3 hours today and so far the only thing that works is basic lock/unlock status and no context, no abnormal alarm conditions, no any of the smart extra things to know if it was manual or PIN-pad.
node-zwave-js is the driver, which is called Z-Wave JS. Yes, the integration is also called Z-Wave JS. Integrations are normally named after the “thing” they implement.
So I enabled the MQTT portion (even though I’d prefer not to use that) and I can see it sending almost all the things I want…but I don’t understand why this seems to not be visible by other means as either events or entities?
And every time the respective item triggers I see it send an updated time of that “thing”.
I could write MQTT sensors to try and bring in the missing information so I can drive my automations on that…but it seems like there ought to be a better way?
Is there a list of all the possible “event” things to listen for? Because I have been randomly trying things posted in the forums and I can’t find most of the same data, only “lock” and “unlock” for keypad/mechanical. I’ve not found the RF lock/unlock nor any of the error types.
And its not for lack of trying, I’ve been going at this for almost 9 hours today…the documentation is very poor and the overwhelming majority of what I find is other people asking the same questions I am.
There’s only one event for Notifications, zwave_js_notification. What varies is the event data. It will follow what zwavejs2mqtt is showing. They will all look like the sample in the linked docs.
This document lists all of the possible notifications. The events/notifications are listed as Events, while the entities/values are State. These are all based on the Z-Wave specification. Still, the easiest way is to just listen to the events in HA and see what happens. The document lists the entire set of notifications, not necessarily what a device supports.
Ok, I’ve been chasing threads saying zwave_js_event, zwave_js_value_notification, zwave_js_notification, zwave_js_value_updated, and a number of others that I can’t remember anymore and no longer have tabs open for.
Maybe there’s something wrong because I’m definitely not getting any of those abnormal-condition alerts showing under the zwave_js_notification - only the “successful normal” lock and unlock events.
In this screenshot I unlocked the door with the knob, then hit the keypad to lock with it adjar so it jammed, and then entered invalid codes until it went into keypad-lockout. The only event that fired in the developer listener was the original unlocking with the knob, none of the alarm conditions which are really far more important to me than “successful” lock/unlock.
Been at this since about 8AM and the “jam” was the first thing I tested since the most frequent issue is someone leaving doesn’t pull the door shut fully latched before it tries to lock.
Then I would say that does go back to the original GitHub issue I linked to. If the device never sends “Keypad state” or “Lock state” notifications with values “idle” (0), the sensor stays on. The value you show in the MQTT screen shot is 16, or “Keypad temporary disabled”, which matches the binary_sensor naming scheme. If you don’t ever see a value of 0, then HA is showing the same as MQTT.
Unfortunately, these sensors currently don’t work well because of this device behavior and limitations in the driver. HA has way to tell the driver to clear the state.
If you’d rather treat these two variables as events, you can use the zwave_js_value_updated event instead. Use the event data in automations or make your own trigger-based template entities. I think there are Device Triggers that help create these.
I’ve not seen anything yet how to “command” it to reset those values (seems like it would be easy enough if I knew how - in the real physical world any valid unlock/relock resets the lock to working order).
Just tried monitoring for “zwave_jsvalue_updated” but it doesn’t pick up on anything listening for that either.
The disabled entities will also include a sensor entity for the raw notification variables. You can also use that if you want. Z-Wave JS sensor entities have “force update” enabled, which means even if the same state is reported, it will trigger the state machine. The value updated event is probably better for this case though.
Sadly nothing on zwave_js_value_updated either. And I did enable manually the old alarm_type and alarm_level but those never seem to be updated, and it sounds like from things I read on github like that’s “as intended”.
Not sure why this has to be so hard, a lock can’t be unlocking, locking, and jammed at the same time. If it locks or unlocks its not jammed by definition.
I’m also not sure why they moved to “events” vs a state, because “state” represents the real world better. The lock doesn’t just “become” unlocked or whatever, it continues to be that condition until a new state happens. But that’s for another unrelated debate.
Based on all this it sounds like there is no solution outside my making MQTT sensors to capture each thing and build a reliable “status” sensor based on most recent updated. So that’s disappointing, but thanks for the help.
