Schlage ZWave Locks (BE468 and BE469) - No status updates if operated from Home Assistant #18812
Comments
gregg098
changed the title
|
Looking through the Z wave logs after a lock/unlock from the front end, it appears that Z wave thinks the lock is unsecure?? Definitely using a security key, was paired securely, and it has always worked OK as long as I can remember. The lock does physically lock/unlock too. It just doesn't report back. Also, if I unlock the door from the front end, since the status does not report back, I cannot lock the door anymore since it still thinks its locked. Other way around as well. |
|
What happens if you downgrade to 0.82.1? are things working again? |
I attempted to downgrade and got a ton of http errors (unrelated to this issue) and Home Assistant wouldn't even start all the way. I didn't feel like troubleshooting the downgrade so I moved back to 0.83. |
|
I also realized that I can manually call lock.lock or lock.unlock and the lock will take the correct action, regardless of the status it sees. This is good for automation purposes, but still prevents me from using the front end to control it. |
|
Its possible that the issue is related to this PR: #17386 honestly if you can control the lock via HA then it is definitely paired securely. |
|
Ya it is definitely paired securely. That PR was my first thought as to why its acting strangely. |
|
Try reverting that PR or running the older |
|
How do I go about doing that? |
|
@gregg098 I am not sure how well versed you are with home assistant or what install method you have. So please proceed at your own risk. Downgrading to 0.82.1 or restoring a backup is the safest method but you could try the following:
|
|
I tried this, but now the locks do not load at all. Here are the log entries: |
|
I was afraid it may not be that easy, just delete that file and try to roll back to 0.82.1 |
|
I know you'll probably roll your eyes but have you tried a fresh pair of batteries? I've seen some very odd behavior with zwave when the batteries are low. It also depends on what other zwave devices you have as repeaters between the locks and the controller...check them for batteries too. |
|
@gregg098 why are you using a lock custom component? |
I did check batteries and they are fine. I even power cycled the locks. Since its two separate locks (even slightly different models) acting exactly the same, I think its a Hass issue. |
I'm not. It was a troubleshooting step suggested by dshokouhi. Please read the OP. |
|
@gregg098 Yes I see that but reverting the file via a custom component is not going to work. You have to revert the file in the actual location. Thats why it failed. |
I have no idea how to do that. |
|
hit me up on discord @edif30 |
|
@edif30 you can indeed run a custom component that contains reverted code. The reason why it did not work here is because some code around config entries was mixed. There were a couple of Zwave lock PR's in 0.83. The revert that I provided was the last commit before that change but it was still missing things due to config entry support for locks. Using code as custom component will override system files only if the code was correct. |
|
@dshokouhi yes if the dir structure is correct :) |
|
I have this exact problem, reverting to 0.82.1 worked. |
It's misleading - that message means "the door was just unlocked" - here, "Unsecure" means "Unlocked," and "Secure" means "Locked." It's how the underlying openzwave libraries talk about things. It's not actually talking about using 'secure pairing'. 😄 @xbtsw @gregg098 I think your issue might be related to PR #18737 - if you want to test it out, I'd be interested to know if it works for you. Specifically with the BE468, because I don't have that model and couldn't test it. Testing the PR involves using |
|
Hass loaded good the first time. Ran a few tests and everything appears to be working normally. I can operate from the front end and the status is updated properly. Also tested a few local operations to make sure that was still OK. Looks like this fixes it. Thanks. |
|
Hi @ahayworth thanks for the swift response. Just for the information, I am having this problem on a BE469 lock. How does it works for you in a 0.83 setting? Will exclude the lock and re-add help? I really hope I could upgrade to 0.83 as there's some homekit problem in 0.82 I am running into. |
BE469 locks in 0.83 do not report the correct state in HA when you unlock/lock via the HA or via automations. The patch I referenced in this comment does seem to fix it, but it has not been reviewed or accepted yet. |
|
Same issue on 0.83 with the same lock, FWIW. |
|
Same issue. |
|
@ahayworth Thanks for the hint. Sorry I assumed the custom component is an alternative for reverting to an older implementation of After applying the custom component it works great. Thanks. |
|
@ahayworth thanks for this. My BE469 stopped reporting correctly with 0.83 as well and the custom component seems to have fixed the issue for now |
|
Same issue for me after updating to 83.2 from 82.x. OZW Log shows secure and unsecure. Running hass.io on RaspPi. |
|
@mtreinish #17386 should be reverted since this caused more issues than the previous - #14632 from May. |
|
@edif30 no a revert is not warranted here. #17386 fixes things for other devices. The problem here is that none of these locks behave consistently and they all have quirks that we need to account for if we're doing explicit workarounds per model in the code (which is something I talked about in that PR). The proper way to to correct the behavior for those specific locks that are having trouble is something like: #18737 and/or #18996 |
|
@mtreinish while I understand that individual locks have their own quirks and inconsistencies, fixing one issue while causing another does not seem like the right approach. That is trading issues. Especially on devices which are in the security category. More testing should have been done widely before merging. Otherwise we put users at risk and it should be discussed more broadly. Even those two PR's have not been fully tested. |
Of course not, but I'd be very surprised if it was intentional. 😉 The problem with rolling back is that we un-break1 Schlage, but re-break other locks. Something is still broken afterwards. It's not like there's a clear answer as to who should be broken! 😄 And in any case, as @mtreinish said - the PR actually does fix other things, and is not entirely incorrect or anything. Given that the overall pace of development on HA is so rapid, I agree with @mtreinish that fixing forward is the best answer. It's overall less complicated, and at this point, would take about the same amount of time to do. I hope we can get the open Z-Wave lock PRs merged in time for the holidays. I think the custom component approach is working well for those who need the fix immediately, and worst case users can roll back to an earlier version of HA. 1 - just in case people forget, if we were to revert the PR in question, Schlage locks would still be broken, just in a very different way! They haven't ever really worked correctly. |
It would be broke in the exact same way it has been for months. Just the same as the original issue that initiated the PR that broke Schlage locks as it has been around for 6+ months. So again, this is trading one issue for another and unfortunately, automations are now affected by the lock state on one vs the other. Simply asking folks to downgrade is in my opinion not a good user experience. |
|
#18737 is merged so we can close this. |
|
Can anyone confirm if 0.84.1 should contain this fix? I didn’t see anything about it in the release notes and I confirm the behavior is definitely there. The only issue for me is that downgrading to 0.82 didn’t help me: I actually had worse issues with my lock (ez: half the sensors and the lock itself don’t even show up). |
|
I'll confirm 0.84.1 does NOT fix the issue. To be clear, service calls for lock/unlock function correctly but the front end does not reflect correct status as described above. I too reverted to 0.82.1 and although the locks now functioned/reported correctly, other problems existed (most notably, my input booleans did not appear on front end or seem to exist at all - weird). Hopeful this issue gets priority since locks are physical security. |
|
You’re right, it didn’t get merged into 0.84 - although it is in dev. I’m not sure what the cadence is exactly for merging things is as bug fixes, but I’ll ask. :( |
|
Yup, I can also confirm with the BE469 (I have a BE468 too but I haven't bothered trying) that the status just doesn't get updated when you change the lock from within HA. But commands definitely get sent, they definitely work, and status definitely gets updated when you change the lock manually. It's sooooooo close. I can't wait for this fix :) |
|
Fix tagged for 84.3 |
|
84.3 worked for me, however 84.6 has been very flaky. The lock status works for a few hours, then the lock status stops working. I think a bug got reintroduced. |
|
Lets open a new issue - I took a look and the code for the lock itself doesn’t seem to have changed between releases. Some other portion of the system may have though. Notably, it’s still working fine for me- and has been on all of the releases in question here. In the new issue, I think it’d be really helpful to have the zwave and HA logs for the problematic state transitions as well. |
|
I can certainly open up a new issue. Are the following files what you need?
What about my yaml files minus my secrets? |
|
Sorry about the delay - holidays and all. :) Yes, those would be the correct files. |
ghost
removed
the
Home Assistant release with the issue:
0.83.0
Last working Home Assistant release (if known):
0.82.1
Operating environment (Hass.io/Docker/Windows/etc.):
Docker on Ubuntu Server 16.04
Component/platform:
https://www.home-assistant.io/components/lock.zwave/
Description of problem:
I have a Schlage BE468 and BE469. Both worked fine under 0.82.1. Since upgrading to 0.83.0, they do not report status when locking/unlocking via the Front End or through any other automation. If I operate them locally (code, key, manual bolt), it updates OK.
Examples -
With door locked:
Click Unlock on front end
Lock physically unlocks
Status stays as Locked
With door locked:
Manually unlock door (via code, key, or bolt operator)
Status updates to Unlocked
In both examples, it is repeatable in the opposite status (locked vs unlocked)
Problem-relevant
configuration.yamlentries and (fill out even if it seems unimportant):Traceback (if applicable):
Additional information:
Steps I have tried to troubleshoot:
I have not unpaired/repaired as this would require a lot of work to move the locks within 3 feet of my server.
The text was updated successfully, but these errors were encountered: