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!