This might be a good use case for the WATO app.
@bangali, what do you think?
1 Like
yup. might actually work out of the box without any new code for WATO.
@mchouse could you please misalign the door so it jams on attempted locking … trigger the lock … then share the state information from the lock device?
I think my Schlage once reported "unknown" when jammed. Need to check.
I was already using a custom driver, so... What I've done in the meantime is add the contact capability to the driver. Whenever it successfully locks or unlocks, it sets the contact to close. Whenever the state goes to unknown, it sets the contact to open, then I just use the open event for the trigger.
ok. you could set up a WATO checking that attribute for unknown … then trigger any command on any device when it matches.
1 Like
Am i correct if i have a Yale YRD210 Zigbee lok i should be able to create / edit lock codes in the device driver? As i dont seem to be able to, I can lock / unlock the lock just not add / edit codes.
I have a Yale zigbee, different model, lock codes are working.
Anything in the logs?
I have a Z-Wave version and use the generic lock driver. Here's what my device driver screen looks like.
Right after setting up the lock or after clicking get codes ( if you unnecessarily did that like I did), then you’ll need to wait a bit before you can do anything with codes. It has 250 codes to go through on my YRD256. Might be the same with yours. You can open the logs and see it parsing through them just after one of those two events.
This was my issue anyway. Hope this helps.
SmartHomePrimer, is your YRD256 very chatty? Mine is sending messages every couple of minutes, continually, even when it's not being used. I have the Zigbee module, but wondering if yours with Zwave is the same.
Also when I click "Get Codes" I just get a "debugmaxCodes is not set, unable to get any of the device lock codes" message in the logs.
Quiet as a church mouse. Is your debug logging turn on? Maybe that's what you're seeing or maybe the Zigbee module just doesn't stop talking.
You'll have to ask @mike.maxwell about that issue. Did you click "Configure"? Not sure if it's needed to send the data to the lock. I don't recall if I did that, and don't know if it's needed, but it couldn't hurt I, or at least I would think it shouldn't. Might help though.
- Make sure debug logging is enabled in the driver.
- Open your logs
- Click on the lock in the logs to isolate it from every other device in the logs
- Click clear
- Click "Get Codes"
- Send the log results to @mike.maxwell
1 Like
yeah, this is a bug in the current driver, patched and fixed in the next release.
Same with the incessant battery reports.
2 Likes
soon...
3 Likes
What a tease! 
Man you walked into that one.
That's great, thanks. Am about to buy 3 more of these locks so was keen to figure out what all the messages were before buying them.
I did ask this already in another post, https://community.hubitat.com/t/unencrypted-zigbee-message-logs/5154 , but how do I get Hubitat to log the decrypted message data?
Not following? One aspect of encrypting it is that it doesn't show in the logs in plain text. What specifically are you looking for. All the codes or the unlock and code change events
I was looking for debug log messages that are plain text. It would be useful to have a debug mode where the messages are printed in plain text. In my particular case the messages being encrypted wasn't very useful for figuring out what messages were being sent, as the only readable message text when I converted the hex was "yalelockv2". So at the moment I'm just guessing/hoping that the messages in my logs are the incessant battery reports you mentioned, and not some other issue.
