System: Debian Stable on PC hardware
OH 4.2.1-1
Aeotec Z-Stick Gen5 (ZW090)
All,
I just installed a Yale Assure Lock 2 with the Zwave module.
Almost everything works fine, secure inclusion worked, and I can control the lock from within Openhab.
The only thing it doesn’t do is publish the lock status (LOCKED/UNLOCKED) back to the switch item.
The Yale Smart Door Lock Z-Wave Module Thing (ZWave Thing | openHAB) supports an additional alarm channel, but contrary to the documentation it is a JSON String channel, not a Switch.
I was hoping to use that channel to detect lock changes, but it never changes and the item always holds this information: State="notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"1","type":"ACCESS_CONTROL","event":"1","status":"255"}
It is probably going to take a debug log while doing some tests to answer your questions.
A better source of information is the ZW database. It is supposed to sync, but is off for this device right now. I think this is your device. Looking at the endpoint tab, you are linked to an alarm “raw” channel that returns a JSON object. You might have better luck with alarm_entry channel, but the Debug should show what the device is sending when you change the lock status.
There is a debug log viewer for self help, but if you post the debug file here someone can take a look.
TBH I’m not an expert on locks.
First it is not a necessary to filter logs, in fact not everything related to node 82 is labeled, so it is not recommended.
I agree not much here. It seems to be running through user code configurations. From the viewer (TX or TXD means transmit and RX or RXD means received) all that is received in this time period are user codes.
As to the device, what are the Type:ID on the UI page dropdown for properties for node82? I’m a little puzzled because I thought only alarm_raw returns a JSON object (which in your case says the manual lock is on). Also alarm_access isn’t tied to any events (long story), so that’s not surprising
I agree, from what I can make of the debug log when cycling the lock manually, it doesn’t seem to transmit anything regarding it’s status whatsoever.
Do you mean the Model-ID? That says YRD4XX-ZW2.
As for the channels, I have these:
ID: lock_door
ID: alarm_access
ID: alarm_power
ID: battery-level
ID: time_offset
No alarm_raw.
And alarm_access definitively is a JSON string channel, not a Switch.
And it does contain event-type information in the JSON, it just doesn’t change when the lock is operated. I kind of expected it to contain coded information about the events, like locked manually, unlocked by code entry, that kind of thing. That would easily enable me to trigger a virtual switch from that.
What I was thinking about was to mark up the XML in the binding to see if something would work for you. This would also require you to follow [this process].
(Update ZWave binding with new/updated device xml). After that the ZW DB could be updated.
A couple of things concern me first
Is the device fully configured? When you did the debug, how new was the device at that point? It seems like it was still going through configuration of the user codes. If that is the case it may not have gotten to the alarm configurations yet. Do you have an XML for that node in the userdata/zwave folder and five lines on the UI page?
The JSON object makes me wonder if it is the right device we are looking at. The binding IDs devices by the TYPE:ID pair (and sometimes the version). If I mark up the wrong one, nothing will change. The type:ID on the UI page are usually both in hex and decimal.
Thanks for the reply.
The device was first initialized yesterday, so it had >24h in the network now.
I do see five lines at the end, although a bit different than yours:
I’m confident, though, that it’s been included correctly, I can actuate the lock via zwave and I also see the user codes (that I entered via the Yale App) in the configuration.
Ok. I did mark up the XML here if you want to try. I added the Basic CC to the door lock channel, sometimes that helps with manual triggering at the device. Also added the alarm_raw and alarm_event. If it doesn’t work you can go back. yrd4xxzw2_0_0.xml (8.5 KB)
My concern on “fully” initialized was from the debug yesterday. It looked like it was marching through the user codes and only up to 32. Aren’t there like 255? Anyway without the “Reinitialize device” it is not done. It may work, but since there is still an issue, it could be related. Is there an XML for the node in the folder noted above? Is there a manual “wake button” on the lock?
edit: FWIW your type:ID is 8104:05d1. The type is the last line in your picture
Understood.
So before anything else I probably need to make sure the lock is properly included, so that it shows the “Reinitialize device” option. I have that on all other zwave devices, although the lock is unique in that it is securely included.
Maybe I just need to wait to let the zwave binding sort that out?
But yes, there are 250 possible user codes I can see.
In the folder where the zwave jar resides (is that the folder you meant?) there’s only the jar and the sha1 checksum, nothing else. No yrd-xml anywhere on the system, either.
And no, the lock doesn’t have a “wake” button, inclusion/exclusion is started through the app.
Probably a good idea before messing with the XML. You could do a quick debug and see what is happening now.
Is there a wake interval on the UI page?
The folder depends on how OH is setup; openhab-userdata/zwave or var/lib/openhab/zwave. Not the addons folder with the .jar/.kar. Your other nodes should be in the directory as they have the reinitialize device line.
edit:
/var/lib/openhab/zwave contains a xml file for every node, the lock among them.
It’s called “network_d05cf35b__node_82.xml” and seems to be the configuration file for that node.
There’s only a polling period defined in the Device Configuration, 86400s (24h) like on any other node, too.
I’ll switch the binding into debug tomorrow, operate the lock and see if anything happens. But the “Reinitialize Device” option is still absent as of now.
As you have the node82 xml, the device has made it to fully configured. I’d have to review why a frequently listening device doesn’t show the reinitialize device. That normally means there are command(s) in the queue. This does happen with regular battery devices (that sleep-waiting for awake) but shouldn’t happen with a frequently listening battery device that doesn’t sleep. Could just be a one-time issue after inclusion.
Anyway the unfiltered debug should provide more data.
Yes, it looks like the lock is correctly and fully included and configured.
I even get updates from the lock, such as battery level changes.
Just nothing when operating the lock itself.
Here’s the unfiltered debug log. Hope that helps.
Only about a minute long, but in that time I manually operated the lock twice. I don’t see anything related to that in the log, though.
Progress. It does seem to be responding, it is just not getting to OH. I would try the XML from above. I think the alarm_event might work. I still don’t understand the JSON
Note these in the file
2024-09-02 09:39:14.201 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 82: Alarm converter NOTIFICATION event is 2, type OnOffType
2024-09-02 09:39:14.201 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 82: Alarm converter NOTIFICATION event is 2, channel alarm_access is not implemented.
2024-09-02 09:39:22.398 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 82: Alarm converter NOTIFICATION event is 1, type OnOffType
2024-09-02 09:39:22.398 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 82: Alarm converter NOTIFICATION event is 1, channel alarm_access is not implemented.
Ah, I see it now.
I’ll try to modify my zwave-jar file with the xml and activate it.
If I need to go back to my original jar file, all I need to do is issue “bundle:update 254 file:///path/to/original/jar”, right?
Well, with whatever number my zwave bundle is.
Hmm, I modified the jar file with the xml file (separate directory, of course), confirmed it worked (file size is a bit larger now), installed it with “bundle:update”, restarted OH and even deleted and re-added the lock thing.
But I still only see the previous channels, no alarm_raw or such.
Shouldn’t they come up now?
(On a positive note, I now have the “Reinitialize device” option).
I’m not entirely sure what you mean here.
My expectation is that the “bundle:update” loads the modified jar-file into OH, and the original version remains unmodified in the file system, or am I wrong here? Does it need to be copied somewhere?
So that’s the backed-up original and the modified, note the larger file size.
I then installed the modified one from karaf console using “bundle:update”.
Is there any way to identify the loaded module since they’re both v4.2.1?
When you overwrote the old XML using the procedure, what was this directory? mkdir /home/openhabian/jarmodify/OH-INF/thing/yale (not zooz, that was an example)
I’m not sure how much bigger the file should be as it is an overwrite, not an add.
EDIT: I have a fork on the ZW binding in windows. Here is where it is located.
