Core: Schlage Locks Clear User Code still not working

[ptdalen]

Home Assistant release with the issue:
90.2 and all previous versions that I am aware of

Last working Home Assistant release (if known):
N/A

Operating environment (Hass.io/Docker/Windows/etc.):
Python VENV on ubuntu 18.10 but I believe this is on all versions

Component/platform:
Schlage locks and clear usercode

Description of problem:
Basically many locks clear user codes by sending 0000 as a code. On the Schalge BE469 and FE599, this actually sets a valid code of 0000. This is well commented and has been ongoing for quite a while. It is an issue with usercode.cpp in the OWZ library. I'm not a developer, but I have been able to fix this by using this code

https://github.com/OpenZWave/open-zwave/pull/1576/

I dont know why this was never added to the official dev branch, but if someone could review the code and either merge, or determine what the issue is and maybe make the correct changes that would be great. As it is now, everyone using schlage locks have to use workarounds, either setting random codes as a "clear" or forking the HA openzwave, and adding the code from 1576. I have used the 1576 PR and it worked well for me, and I did not see any reprecussions, but maybe it had issues with other brands, not sure??

I believe that Schlage is one of the biggest user bases for HA but I see many comments in the forums about people not willing to move their locks over until they properly clear user codes, which is fair.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
N/A

Traceback (if applicable):

Additional information:

[uchagani]

https://github.com/OpenZWave/open-zwave/pull/1576 didn't make it into the dev branch of OZW because it seems it wasn't an appropriate solution for all locks. Looks like @Fishwaldo replaced it with https://github.com/OpenZWave/open-zwave/commit/4d93ee11513ac1dbabe0d19bbc03f4d958f5fe56 which is currently in the dev branch. We would need to cherry pick this commit into the HA fork if it isn't already there. @pvizeli can maybe offer some advice on this.

[ptdalen]

Agreed, I felt like there was a difference of opinion on how best to handle this. I have only tested the 1576 because it seemed to be more appropriate for my lock. the comments on #997, let me to believe that maybe it was not fully working. But you're right https://github.com/OpenZWave/open-zwave/issues/997 was included in the dev branch, and https://github.com/OpenZWave/open-zwave/issues/1576 was not. If we could cherry pick https://github.com/OpenZWave/open-zwave/issues/997I believe that would solve a lot of peoples issues with locks. I was looked back through some of the previous comments and it seems as if yale locks may also be having issues with clearing codes too.

Actually looking at the current dev branch, there was a very minor update in dec. Not related to clearing codes, but fixes issues with building on windows machines.
https://github.com/OpenZWave/open-zwave/commit/12a30b9f87e8b3cabec45db313c0db689453bb49

So I guess is we're lucky enough to get this added to the HA fork, that we'd probably want that commit which includes the fix implmented in https://github.com/OpenZWave/open-zwave/issues/997 as well.

Edited to fix formatting. Also to add a comment that this could be considered a security risk for users who believe they are clearing out user codes on thier doors not knowing that either the old code is still valid or they now have a code of '0000' in their door. This happened to me and I was aware of the issue. It happened when I started using the HA fork, and forgot to update my fork with this update.

[srpape]

I have a Kwikset zwave lock and Clear User Codes wasn't working for me either.

I forked home-assistant/python-openzwave and applied OpenZWave/open-zwave#1576, which fixed it for me. Here's how to install my fork (on hassbian, change into your venv however it's appropriate to you):

source /srv/homeassistant/bin/activate
pip3 install --upgrade git+https://github.com/srpape/python-openzwave.git

[ptdalen]

I've done the same and it works for me as well, just wanted to get this in the official HA fork of OZW to save the trouble.

[thegame3202]

Commenting so I know when this gets added to the HA fork:-) Annoying that you can't clear a code.

[ThePicklenat0r]

Been struggling with this as well. I hope we see this released in the official build soon. In the meantime, is there a way to apply this fix in Hass.io? I tried @srpape 's instructions, but hass.io must store the files in another location (I'm not super familiar with docker/python).

[JoshFouchey]

Been struggling with this as well. I hope we see this released in the official build soon. In the meantime, is there a way to apply this fix in Hass.io?

Just switched to hass.io and wondering the same. Haven't tried it yet but will let you know if I find something.

[bachya]

Same issue here. I'm not clear on what's preventing us from cherry-picking the relevant commit(s). @pvizeli?

[edif30]

@bachya the way I understood it from a while ago was that certain patches were accepted based on appetite in the user base. Many wanted the barrier feature and thus was added. Then when one offs and requests came in and the response was "we would end up supporting too many so we'll wait until the next upgrade of OZW" and I can understand that as well. I guess this is a case of features/patches being a popularity contest.

[ptdalen]

@edif30 - I generally agree about not being able to support every request out there, etc. But in this case an HA user who did not know any better could believe they were clearing user codes from their locks and not clearing them at all. I feel like this is more of a security concern. The only options are to set a random number or a specific number to overwrite an existing code.

I think this alone would be enough for many people to not add these to HA, or at least not to manage user codes with HA. I know when I first started using HA, I did not realize the codes were not clearing, and was surprised to find a code that I had set for a temp worker was still usable weeks later.

Anyway, i'm working around the issue, and others are as well. Not complaining. I'm not a developer but for a while I was updating my OWZ to add the clear codes and it worked, but it just became a bit too much work to keep it updated every release, so I just reverted back to setting random numbers.

[bachya]

I just reverted back to setting random numbers.

@ptdalen That’s a clever idea. I could even envision a daily automation that iterates through all empty slots and sets new random numbers (for extra security).

[ffcruz85]

This would be great, just adding my voice to the "appetite of the user base" here. This has been quite a pain, and completely overwhelming for regular users who just see the ASCII and don;t even get any feedback from running clear code, thinking it was cleared,

[ffcruz85]

@srpape or @ptdalen , echoing @JoshFouchey here --- any chance you might know how to implement in hass.io? much appreciated

[Dragonpark]

Thinking about it a bit more anybody tried changing the passcode length, changing it back and then setting your permanent entry codes again? This could maybe be ran as a nightly automation and use the random code workaround to ‘disable’ codes that are meant for temp use. There is a bit of a risk here as there is a bit of time where there are no entry codes, but eliminates having a number of random codes that could be used.

[ThePicklenat0r]

@Dragonpark I can confirm this works, I'm doing it in my setup, but it is not ideal. I add/remove lock codes based on presence, and re-writing all the codes after clearing them all can take a long time. I've stood in front of my door waiting for the automation to finish on several occasions.

[ffcruz85]

any idea how we can get the developers' attention on this? I mean, seems like a pretty serious issue to me...

[Fishwaldo]

This should be fixed in OZW 1.6 so it’s dependent upon the new integration that’s WIP

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[bachya]

This is still an issue. Commenting so stalebot doesn't close it (and we can properly test once the future Z-Wave work is integrated and tested).

[ffcruz85]

Yea, I am running 0.105.3 and still have this problem. Being able to just type acii instead of hex on the zwave config page would be nice too

[ffcruz85]

So just checking in on this one. Any news of the OZW update coming into the HA code? It would also need some work on the UI for the Z-wave integration I guess

[gcorgnet]

Definitely keen to see this fix make it's way into HA. I am running hass.io so I have limited options to manually fix this.

[pvizeli]

The hole zwave stack going to replace soon anyway, the current zwave is ugly

[mguaylambert]

I have the same problem unfortunately. 😥

[ffcruz85]

@pvizeli that's fantastic news, thanks for letting us know! Is there a branch I should watch for? sorry to bother

[ffcruz85]

@pvizeli Maybe I am just confused, but is the new z-wave integration on 0.110 the thing we are talking about here?

[ffcruz85]

Change log on 0.113 seems to have the fix for this - I will be updating tonight and trying

[Icexist]

At least for me, on 0.113.3, calling ozw.clear_usercode sometimes sets the code to 0000... and sometimes clears it fully (as shown in the OZW GUI). Schlage BE469ZP

[FuzzyMistborn]

Also seeing similar behavior where sometimes the code is cleared but most of the time it's not.