I’ve been trying to get Keymaster to work with my Yale YRD220 for a number of weeks but failing. The bottom line is that when adding a code, I can’t get the Pin Status out of the Adding or Deleting status.
I’ll provide a bunch of details. Some configuration background: I’m using the latest Zwave JS (Server Version: 1.14.1); the YRD220 lock has the Zwave module (Zwave Plus not supported); the integration is connected via S0 Legacy security (higher security isn’t supported); Device Status is Alive; Device Ready is Yes. I have re-interviewed the lock more than a dozen times; I have Zwave removed the lock/ factory reset the lock/ Zwave added the lock at least half a dozen times. There are 3 AC powered Zwave devices within 5 feet of the lock, 2 within 2 feet (which should be repeaters). I have moved my HA device within 4 feet of the lock during 2 of the adds. I have also tried healing the network. I have tried many different methods of keeping the lock awake during the addings. I have always been able to get it to go through all 5 states of re-adding reported by the UI (ProtocolInfo, NodeInfo, CommandClasses, OverwriteConfig, Complete). I have had various levels of success with these re-interviewing/ remove/add cycles. Typically, the re-interviews usually reduce the level of usability and the delete/add usually brings more capabilities back. By usability, I gauge this based on having the various entities working (lock/unlock, battery level, alarmlevel, alarmtype, node status) as well as downloading the Zwave data and reviewing it for the inclusion of the 250 code slots and the ability of using the Zwave JS services to add/delete codes. Right now the integration is in its best state being able pass my usability tests. When I installed Keymaster this go around I had added 2 codes via the touchpad of the lock before installing. The Keymaster UI Pin Status automatically brought in these 2 codes and showed a Pin Status of Connected. I tried to add a code to a third slot; it stayed Adding. However the code works in the lock. Turning off the Enabled toggle in the UI changed the status to Deleting but did not delete it from the lock. At this point, it is pretty much stuck. Even using the Reset Code Slot in the Advanced Options doesn’t fix anything. Using the Developer Tools to look at the Zwave events, there are events being sent for locking/unlocking the lock.
So I’ve been trying to figure out the problem by looking at the YAML and Python code but not getting too far; I’m not a Python programmer, just C/C++. Looking at the YAML, the issue is that the pin entered value into input_text.frontdoor_pin_3 does not equal the value retrieved somehow from the lock and stored in sensor.frontdoor_code_slot_3; the sensor.frontdoor_code_slot_3 isn’t ever updated. This sensor isn’t in the YAML so presumably it is created and updated in the Python code but I can’t find it. I’ve searched all the py files in the GitHub repository for _code_slot and only found a reference to deleting the sensor. So I don’t know how the sensor.frontdoor_code_slot_x is supposed to be updated.
Sorry for rambling, but at this point, I’m guessing the lock doesn’t provide the data (event?) necessary for the required feedback for sensor.frontdoor_code_slot_x but I’m hoping someone could point me to what is going on and if there is some sort of work around. Thanks for reading.
I’ve had similar problems, and (with a few exceptions) it was issues with the underlying zwave network.
I have a few locks that really struggle with communication through a relay. They will get the command refuse to send an ACK through the relay, leading to keymaster thinking the code hasn’t changed.
Unfortunately the troubleshooting tools in the built in add-on just aren’t capable of going very deep. My suggestion would be to switch to zwavejs2mqtt to get a better idea of the network graph. You could find that even though your lock is surrounded by repeaters it is ignoring them.
Just throwing this out there. I’m currently AirBnB multi-site but on SmartThings for the platform using RBoy’s Rental App. I’ve been working on an integration which I recently announced for hooking up rental calendars. The end goal is to have it feed door codes directly into Keymaster to manage everything.
Current functionality just gets the calendar(s) imported in in a way that is usable. My next major step is to actually get it managing door codes. Some of the initial configuration is already there for it, that is select what lock and what starting slot you want it to manage.
My next major bit of work is to actually get it pushing information into Keymaster inputs so that Keymaster can do its magic.
Once I have a fully functioning integration I’ll be building out HA instances for each of my locations so i can decommission my SmartThings platforms.
My home HA will then be linked up using Remote Home Assistant so I can monitor what’s going on easier.
I’m working on a lock manager that talks directly to bridged MQTT servers. Allows for lots of locks and locations without all the entities. I’m to keep using keymaster for singleton locations, but once you hit a dozen or more locks it becomes very unwieldy. I’ll post an update here if it ever hits a publicly releasable state.
Edit: I figured it out. in KeyMaster I had the name as Laundry Door (Laundry_Door) I changed it to LaundryDoor. Apparently, Telegram doesn’t like underscrores.
Hello, I have an old Schlage BE469WK. For the most part it’s working good with KeyMaster, I’m trying to set this up with Telegram, it works if I disable Title, but if add Title back in, I get this error:
Error sending message: Can't parse entities: can't find end of the entity starting at byte offset 7. Args: (-503647029, 'laundry_door\nManual lock operation'), kwargs: {'parse_mode': 'Markdown', 'disable_web_page_preview': None, 'disable_notification': False, 'reply_to_message_id': None, 'reply_markup': None, 'timeout': None}
Error sending message: Can't parse entities: can't find end of the entity starting at byte offset 7. Args: (-503647029, 'laundry_door\nKeypad unlock operation (Ali)'), kwargs: {'parse_mode': 'Markdown', 'disable_web_page_preview': None, 'disable_notification': False, 'reply_to_message_id': None, 'reply_markup': None, 'timeout': None}
Anyone know how I can get Title to work correctly?
@jwsample : Thanks for the response. I researched what is needed to migrate to ZwaveJS2MQTT and concluded the safest way is to remove my 38 Zwave devices from my existing ZwaveJS, install the various ZwaveJS2MQTT components, then re-add my 38 Zwave devices back in. That sounds a bit too painful at this time, particularly after reading this posting which leaves the utility of the networking tools of the ZwaveJS2MQTT UI in question:
I had hoped someone would have been able to tell me exactly what the Python code was looking for. I did a bunch more testing (viewing the Zwave events and the Zwave live log) and was actually able to get the status to be Connected twice (so my hardware apparently does support whatever is needed). What I did notice is that there were no Zwave events involved with the adding/deleting pin codes but there were obviously Zwave commands but also Zwave responses when it worked. So when it doesn’t work, these responses aren’t there. Interestingly, the changes to the Alarmlevel and Alarmtype (providing similar information to the lost responses) do appear to make it through, maybe because they aren’t responses? I would have to agree with your assessment that for some reason, some of the Zwave responses are being lost. The way Keymaster is designed with its state machine approach, if one of these response is lost, it kinda gets locked up and I have to fiddle with the desired pin value (changing it to what the software thinks is in the lock) in order to be able to try to change the pin again. I’m next going to look at some of the old deprecated implementations that used Alarmlevel and Alarmtype and see if maybe I can get one of them to work.
I’ve been trying to puzzle out some of the same issues, and here’s some tidbits I’ve figured out along the way if its helpful at all. I’m not even sure if what I’m about to say is accurate, so take it with a grain of salt.
Keymaster seems to get confused if zwavejs takes more than one attempt to set a code or disable.
I’d go so far as to say zwavejs itself gets confused, because when I hit this situation I can see a bunch of complaints in the zwavejs log about “security encapulsted commands” with expired nonces.
If there are problems on the first attempt, many times the node will be marked dead. Once this happens requests to set the code don’t even get attempted, but there’s no feedback about this in the UI. Whether its stopped at the keymaster or hassio level I don’t know. I can almost always get the node back with a call to zwavejs.ping(entity) or the ping button in zwavejs2mqtt
There are an astounding number of non-compliant locks, of which I seem to own all of them. For example, the zwave spec clearly states that when a pin code is disabled, it should be set to 0000.
It also states that use codes should be reported accurately as a property of the device.
Schlage has decided to report user codes as “**********”. Literally just a bunch of asterisks. I believe this also causes a lot of confusion internally.
As far as setting the codes, keymaster seems to just pass the data straight to the hassio zwavejs.setUserCode service:
Perhaps there’s an exception getting swallowed somewhere, or the whole thing is hanging waiting forever.
One thing I can say for absolute certainty is that I only have these issues with locks that HAVE to talk to the network through a relay. This makes me wonder whether its an underlying zwavejs issue.
Nothing is being swallowed. The async nature of code doesn’t have an impact on the integration. If your lock isn’t responding to requests via the service call (we are basically just passing pin entries onto the right HA service) that points to an issue with integration/driver. If it’s zwave_js its the driver and you should post an issue there (zwave-js/node-zwave-js). If it’s not the zwave_js integration, plan to switch to it soon. It’s a lot better than the other zwave integrations
I agree this is an issue with zwavejs or hassio’s interaction with it.
To put it plainly, when a code gets stuck in adding/deleting indefinitely, there is almost always some sort of indication that the command failed or timed out in the “silly” level zwavejs log, but I don’t think zwavejs is gracefully handling handling it.
Given the " Improved handling of device tracker entities" feature in 2022.2, could we get rid all of the support entities this integration creates from normal home assistant devices? It would make this hugely easier to deal with, esp if you have a fair number of code entities per lock, or several locks.
I tried KeyMaster but abandoned it due to the clutter of entities it creates but also because I decided I did not really need it. I have two locks, four user codes per lock which seldom change and are never scheduled i.e always available. If/when I need to change/add/delete a code I just go to ZWaveJS2MQTT and do it there. It would be nice if there was a way to amalgamate the entities into a few or one per lock with multiple attributes…
It’s on our todo list to modularize the integration into smaller bit sized chunks so if you only want to see/edit your codes, then you only get those entities.
Nice! We’re completely aligned. I’ve looked at (and actually purchased a license for) RBoy’s Rental App. The problem I have is that I’d have to buy it for every single unit we own. I just can’t justify that. We don’t do short-term rentals, our minimum stay is 30 days so each place really only has at max 12 code entries per year.
I’d love to be kept up to date. I’m happy to contribute help in anyway that I can as well. I’m pretty new to HA so still feeling my way around the coding so not sure how much help I am there, but I’m pretty resourceful and willing to buy you also willing to buy you many cups of coffee/beers to help keep your tanks full.
@jwsample Interesting. I haven’t moved to MQTT yet, but will be sooner than later for some of the stuff I want to do. I’d love to see it/beta test it if you ever get that far with it.
Yeah, that’s a function of having so many “options” for codes being enabled. You can remove these and rerun the setup. But unless it’s slowing your device down, there’s no need. If you use a good naming scheme, you can avoid the noise in the developer tools.
How many locks are you using? How many units? Do any of the units have multiple locks?
Ideally you would setup an integration for each lock, and if you have multiple locks per unit you would “slave”each lock to the “master” lock. That way you only have to set a code one time. However I recommend you start with a simple approach.
Create 5 or so slots for each lock.
Make slot 1 on every lock the “owner” slot, active 24/7/365. Use the same code for every lock. Protect this number!
Slot 2 should be for cleaners. Make it active on any schedule you wish or 24/7
Slot 3 for maintenance. Activate it on an as needed basis (date range) or 24/7
Slot 4 for Guest Smith. Active on occupancy date range. Give them extra time for checking out so they don’t get locked out
Slot 5 for Guest Jones. Active on their date range.
As Guests stay expires, you can clear their slot or overwrite them with new Guests.
You would do the same for every lock. KeyMaster is essentially a database of locks and codes. This approach would require you to setup the business slots on every lock. But you could slave the locks to a master lock and only have to program them in a slot once. You wouldn’t slave guest slots, those would be programmed individually.