Schlage Locks Clear User Code still not working

ptdalen commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

dy1io commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

edif30 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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).

root-hal9000 commented 4 years ago

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,

root-hal9000 commented 4 years ago

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

Dragonpark commented 4 years ago

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.

dy1io commented 4 years ago

@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.

root-hal9000 commented 4 years ago

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

Fishwaldo commented 4 years ago

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

stale[bot] commented 4 years ago

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 commented 4 years ago

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).

root-hal9000 commented 4 years ago

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

root-hal9000 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

mguaylam commented 4 years ago

I have the same problem unfortunately. 😥

root-hal9000 commented 4 years ago

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

root-hal9000 commented 4 years ago

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

root-hal9000 commented 4 years ago

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

Icexist commented 4 years ago

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 commented 3 years ago

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

root-hal9000 commented 3 years ago

It's been a few versions since - I haven't been able to update and work on my setup, but curious if any of the many updates have fixed this for anyone?

root-hal9000 commented 3 years ago

Just dropping by for my biannual check-in on this issue :) anyone seen any changes here? @ptdalen perhaps?

ptdalen commented 3 years ago

Honestly this was always a Zwave issues, but at the time this was submitted HA had branched the Zwave code, so the hope was they'd fix the branch. As of the last update to HA Zwave is deprecicated. It will never be fixed in that version. It has however been working in Open Zwave and looks to be working in the new zwaveJS. I'm just gonna close this issue. If anyone is using the old zwave and wants to fix it them selves, the fix details are in the first post. I had done that back a long while ago and it worked for me.

PrplHaz4 commented 3 years ago

Honestly this was always a Zwave issues, but at the time this was submitted HA had branched the Zwave code, so the hope was they'd fix the branch. As of the last update to HA Zwave is deprecicated. It will never be fixed in that version. It has however been working in Open Zwave and looks to be working in the new zwaveJS. I'm just gonna close this issue. If anyone is using the old zwave and wants to fix it them selves, the fix details are in the first post. I had done that back a long while ago and it worked for me.

I've opened this PR to add this known issue to the docs: https://github.com/home-assistant/home-assistant.io/pull/16413

home-assistant / core

Schlage Locks Clear User Code still not working #22464