Yale deadbolt wrong status on ZwaveJS?

Sorry, zwave_js_value_updated event is hard-coded for specific devices. I believe the automation Device trigger is available for all devices and values.

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.

Well, the point of that open GitHub issue is to make this work better.

I’m not sure what you’re trying to say here. None of the things that are giving you trouble are events, they are already states. What is a state and what is an event is dictated by the Z-Wave specification. Whether the lock was unlocked for RF or manually, is not a state. The lock being unlocked, locked, or jammed/not jammed are represented by state, which is why they are entities in HA. Your problem is not events vs. state, but the fact that some states are not updated properly.

At the core, it is the fault of the device (and possibly Z-Wave specification) for not properly updating its state. If the lock knows it’s no longer jammed, it should clear the state. The driver software can only assume this is true based on other heuristics.

The events and states are dictated by the Z-Wave specification (see previously linked doc). It wasn’t a whimsical choice to decide which are and aren’t.

You can do all of the same in HA, but it might be easier to just use MQTT. MQTT templates are arguably easier then using HA Device Triggers.

OH. I wasn’t aware there’s something else (not an event, not a state, some other intermediate something) that I could write triggers against.

After a couple hours of reading and research I think maybe I figured out what the “message” might be (but haven’t figured out how I would craft an automation). I’m guessing(?)…I could then set a custom status to an input_select or similar that I could use as my “old” status field to trigger other stuff on or display based on the values I observe to have my own state of the lock the way I’m used to (its jammed until I interact, and then becomes unlocked)

After turning on all the logging and some creative “grep” and “tail” I think I found how I can capture those alarm fields reliably.


##################################
# Keypad PIN Lockout Tripped
##################################
WSMessage(type=<WSMsgType.TEXT: 1>, data='
{
	"type":"event",
	"event":
	{
		"source":"node",
		"event":"value updated",
		"nodeId":30,"args":
		{
			"commandClassName":"Notification",
			"commandClass":113,
			"endpoint":0,
			"property":"Access Control",
			"propertyKey":"Keypad state",
			"newValue":16,
			"prevValue":16,
			"propertyName":"Access Control",
			"propertyKeyName":"Keypad state"
		}
	}
}
', extra='')


###################
# Jammed
###################
WSMessage(type=<WSMsgType.TEXT: 1>, data='
{
	"type":"event",
	"event":
	{
		"source":"node",
		"event":"value updated",
		"nodeId":30,
		"args":
		{
			"commandClassName":"Notification",
			"commandClass":113,
			"endpoint":0,
			"property":"Access Control",
			"propertyKey":"Lock state",
			"newValue":11,"prevValue":11,
			"propertyName":"Access Control",
			"propertyKeyName":"Lock state"
		}
	}
}
', extra='')

I set configuration.yaml like so to collect that data (and put it back after - it generates a TON of output!)

logger:
  default: notset

I’m assuming that’s what you are referring to, and I’ll go try and write an automation to “capture” that…unless there’s another recommendation better than automation to store a custom value when it matches.

An easier way to do this:

logger:
  default: info
  logs:
    zwave_js_server: debug

That is one way of doing it. The Device Trigger will react to those value update messages. You can use a template sensor, or an input_number I suppose. Here’s a template sensor, which I just wrote off the top of my head. The idea is to just react to the last event and save that to a numerical sensor. You could take the logic and do anything you like.

template:
  trigger:
    - platform: device
      device_id: bb6974789f309973dfc455aa6ca28b20
      domain: zwave_js
      type: zwave_js.value_updated.value
      command_class: 113
      property: Access Control
      id: value_updated
    - platform: event
      event_type: zwave_js_notification
      id: notification
      event_data:
        device_id: bb6974789f309973dfc455aa6ca28b20
        command_class: 113
        type: 6
  sensor:
    - name: Front Door Access Control
      state: |
        {% if trigger.id == "value_updated" %}
        {{ trigger.current_value_raw }}
        {% else %}
        {{ trigger.event.data.event }}
        {% end %}
1 Like

Ah, thanks for some sample code…yeah I’ve not fully decided the “best” way to translate it but figuring out where to get the data and how to trigger “a thing” from it was clearly step 1.

I have doubts I’ll get anything working before the end of tonight, but I know I’ll be resuming it when I have more time (probably no more big blocks of time until next weekend but who knows). Hitting the limit on my clear thinking at this point in the day. I’m very glad I did a new zwave network “in parallel” so most of my more critical doors could keep working on the old network while I figure this out.

Certainly appreciate your help with this and ideas.

Thinking over it a little more, at least for the lock jammed state, you don’t need to use the value update triggers. All you need are two triggers, the Notification “Lock jammed” event, and state trigger for the lock entity. When the Lock Jammed notification is seen, the state is “on” (jammed), and when the lock entity state is triggered, the state is “off”. I think that works, if you assume that a lock state change means it’s not jammed anymore.

In all the testing so far I couldn’t locate a jammed event (only normal lock/unlock events) so that’s where we headed down the “value update” path.

But yeah, that was the general idea is a status that will follow the locked/unlocked but when it jams (or any of the other “failure” conditions) the locked/unlocked won’t be able to actually change (because it jammed) so the error-condition overwrites it until the next lock/unlock happens.

Whoops, that’s right, I was confusing myself. So you are stuck with the value update trigger regardless, but could use the lock state as input, instead of the general purpose sensor I had written up. :+1:t2:

Yep. Do appreciate it, though I think this one will have to resume when I’m feeling fresher. Don’t need to break it coding while drowsy.

I’ll try and remember to post back with what I ultimately figure out…whenever I get time to (maybe off and on evenings, maybe next weekend), If I find something that seems to work reliably I’ll share for others with this headache.

I’m going to regret this when its time for work but I just couldn’t sleep. When I pasted your code snip in it had errors, but I think I figured something out (not my ultimate goal, but maybe some key steps along the way).

The error was:

Logger: homeassistant.config
Source: config.py:454
First occurred: 12:39:06 AM (1 occurrences)
Last logged: 12:39:06 AM

Invalid config for [template]: Value 30-113-0-Access Control can't be found on node Node(node_id=30). Got OrderedDict([('trigger', [OrderedDict([('platform', 'device'), ('device_id', 'c5b2bbe667f11062ecea27ead06b8705'), ('domain', 'zwave_js'), ('type', 'zwave_js.value_updated.value'), ('command_class', 113), ('property', 'Access Control'), ('id', 'value_updated')]), OrderedDict([('platform', 'event'), ('event_type', 'zwave_js_notification'), ('id', 'notification'), ('event_data', OrderedDict([('device_id', 'c5b2bbe667f11062ecea27ead06b8705'), ('command_class', 113), ('type', 6)]))])]), ('sensor',.... (See ?, line ?).

I’m confused by the error at this point, but pay special attention to what it said about this:
30-113-0-Access Control can't be found, knowing the leading “30” is the zwave device ID number.
Remember 113-0-Access Control for later in this post.

In spite of the error, this kinda did what I wanted, catching the lock/unlock events, but not any error event.

Thinking process:

So laying in bed staring at the clock, I had a brainstorm that the zwave js to mqtt debug log was printing updates for my other sensors with humidity and stuff “value update” that I understood well, and I compared the “lock jammed” line:

2022-03-28 00:38:40.850 INFO ZWAVE: Node 21: value updated: 49-0-Humidity 43.33 => 42.77
2022-03-28 00:34:09.199 INFO ZWAVE: Node 30: value updated: 113-0-Access Control-Lock state 11 => 11

Specifically, look at the sub-portion:
49-0-Humidity 43.33 => 42.77
49-0 is…idk, Humidity is the name of the property, and 43=>42 is the old/new data

113-0-Access Control-Lock state 11 => 11
113-0 is…part of the ID, 11=>11 is the old/new data.
Wait, what’s in-between, is that WHOLE THING the property name?

Woah, now, hold on - recall with my logs and MQTT it was just “Access Control” and a sub-key was “Lock state”…but wait a minute, this makes it look like the property being updated is “Access Control-Lock state”.

Remember I said earlier in this post, remember the error?
113-0-Access Control
vs
113-0-Access Control-Lock state

So armed with that, and with some other debug code dumped in…I was off to run downstairs and try it as the dogs think I’m insane running around in the middle of the night making locks beep and boop.

template:
  trigger:
    - platform: device
      device_id: c5b2bbe667f11062ecea27ead06b8705
      domain: zwave_js
      type: zwave_js.value_updated.value
      command_class: 113
      property: Access Control-Lock state
      id: value_updated
    - platform: event
      event_type: zwave_js_notification
      id: notification
      event_data:
        device_id: c5b2bbe667f11062ecea27ead06b8705
        command_class: 113
        type: 6
  sensor:
    - name: test_lock_template
      state: |
        {% if trigger.id == "value_updated" %}
        {{ trigger.current_value_raw }}_if1
        {% else %}
        {{ trigger.event.data.event }}_if2
        {% endif %}

And suddenly it passes validation! And also caught the one (lock jammed) error in the _if1 line of the if/else, and then also reported normal lock/unlock on the _if2 line!

So I think this gives me something I can now start duplicating/tweaking the triggers until it captures all the specific events and value changes that I’m concerned about, and then massage some nested if/else lines so it captures exactly what I’m interested in.

Lesson seems to be that depending where you look at logs you may not get the answer in exactly the right format, and I still don’t know how I would have known the right format beyond random luck and remembering I saw some other thingy update and going to look for that again. I don’t know what all the valid values might be still for that, so I think it may require trial and error.

But not tonight. I’m hoping I can relax now with the knowledge an end may be in sight and MAYBE get some actual sleep. I hate having “software engineer brain” when it just won’t shut off sometimes.

Thanks though for some of the critically key building blocks that makes this look like a solvable problem!

I don’t see how that trigger actually works. Access Control is the property, Lock state is the property key. If Access Control-Lock state as the property works, great, but it would be an unintended bug.

My intent was to catch all value updates for Access Control. For your use case it’d be better to specify the property key anyways, but the code for that would be:

      property: Access Control
      property_key: Lock state

The property key is supposed to be optional. My assumption was that any value update for Access Control should match if the key is omitted, just as is the case with event triggers, but maybe it’s not working that way.

I actually tried taking it out first and it then yelled that it was missing. I also poked about the GUI for creating automation and it claims that field is mandatory.

And yeah, I agree it seems strange its mashing them together…maybe it is a bug…

Ok, I see why Access Control-Lock state works. It’s definitely unintended. The sample code I posted should work as well.

Either my understanding about what “optional” means for the property key is incorrect, or there’s a bug there as well. Probably just needs better documentation.

The code to lookup the value just joins the values together with - as separator. It wants to find 113-0-Access Control-Lock state as you’ve seen from z2m. Your way basically says: join 113, 0, and Access Control-Lock state. The intended way is to say: join 113, 0, Access Control, and Lock state. The end result is the same. if the integration code was stricter it’d validate each component individually, complaining that Access Control-Lock state is an invalid Property.

I actually tried taking it out first and it then yelled that it was missing. I also poked about the GUI for creating automation and it claims that field is mandatory.

I think it’s optional only when the value does not have a property key, e.g. the value ID for one of my temperature sensors is 3-49-0-Air temperature.

1 Like

There is a bug with august/yale in that they dont reset the jammed status.

I’m not sure where the fix should go in HA or in zwavejs

I also suggest everybody suggest help tickets to august (which they will probably ignore)

That is the same issue I linked to in my original reply. We are trying to workaround that issue in-lieu of an upstream driver fix.

The problem though is not specific to August or Yale or any other particular device. There may be a set of devices that don’t implement the Z-Wave specification correctly (like that August). You should absolutely bug the manufacturer to try and get the devices fixed. Then are older devices that aren’t required by the spec to reset the Lock jammed state. These devices will probably never be fixed, so a solution is still required.

A fix should go in the driver, because these are device specific and it’s preferable to address these at a lower level instead of making every Z-Wave-JS-based application to implement it itself.

@mmiller7 What is the version number of the Notification command class implemented by your lock? If it’s V8, then you should at least try to contact the manufacturer and report an issue. The V8 specification requires the device to reset the state. If it’s V4, then resetting the state is optional, so the device is operating within the spec even if it doesn’t reset the state.

My august is reporting v8.

Is there a way to go through the z-wave Alliance to “decertify” a device that doesn’t correctly implement the spec? I wonder if that would light a fire under anybody

I was just looking through the HA ZwaveJS code

homeassistant/components/zwave_js/... and I didn’t see any obvious area where a fix could go… without making the code annoyingly specific…

I just fired off an email to: [email protected]

Maybe that could help?

Z-Wave Certification Support

Z-Wave Certification Team for questions regarding the overall certification process or questions regarding certification interoperability testing done by the independent test partners: [email protected]

These “version” things are still kind of a mystery to me, but I’ll post a screenshot I hope answers it. My Yale YRD256 locks are from Fall 2020 and only support up thru S0 encryption. The way Yale does the locks its actually a separate plug-in board for the wireless radio (optional, and among others can be bluetooth, wifi, zigbee, zwave). Alledgedly Yale has a new one mentioned in press-releases that will support S2 security but its as of yet unobtanium from what I understand (and I guess everything from all brands are stuck with chip shortages).

Here’s the one I have set up for testing (I have a total of 3 of these, but I want to make one work right first and mine are all identical)

I was going to paste the debug-info here since it has some relevant looking bits…but I noticed it also had the user-PINs which I obviously shouldn’t post and I don’t have time to scrub the massive file (it supports like 200+ codes, and I have to review it all before posting).

If there’s some other specific field(s) that are helpful please tell me what to look for and I’ll grab them.

It’s version 4, you can see it in the screen shot. The implementation is not required to idle any notification, it’s optional.