home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
74.08k stars 31.09k forks source link

[0.81.0] Breaks Schlage BE469 locks in a unsafe way #17838

Closed jwelter1971 closed 6 years ago

jwelter1971 commented 6 years ago

Home Assistant release with the issue: 0.81.0

Last working Home Assistant release (if known): 0.80.3

Operating environment (Hass.io/Docker/Windows/etc.): Ubuntu venv

Component/platform: Zwave Locks

Description of problem:

After the upgrade my Schlage BE469 locks will report they are locked; but physically they are not locked. Also sending a lock command will not result in it locking. Physically turning the lock knob will cause HA to update to locked. Then sending an unlock will physically unlock the door; but it reports it is still locked.

My KwikSet locks do behave normally; so it seems something unique to this model of Schlage lock.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

dshokouhi commented 6 years ago

Is this just in the front end or do the service calls for lock.lock and lock.unlock don't work either? Also is the state reflected correctly in the states tab?

jwelter1971 commented 6 years ago

Trying to test to narrow it down. Just factory reset and re-added a lock to test with. It appears the front end doesn't update the state correctly; and that the lock call fails; but unlock works fine.

I can repeatedly get the lock to unlock under HA control; but not to lock.

I've now enabled auto-relock on the lock as a safety until I get HA able to lock them again. This works. Probably a safer way to leave them; except the auto-lock option is too short of a delay.

dshokouhi commented 6 years ago

@jwelter1971 if the service calls are failing then check the HA logs and OZW logs to attach them to the issue. You should probably attach the OZW logs anyways with each action too. You should see that communication flow in as you lock/unlock the door.

cgarwood commented 6 years ago

Try with fresh batteries in the lock. I have the same lock and if the batteries start getting low it will stop reporting it’s state correctly. (“low” meaning around 80% battery_level in my experience)

ronytomen commented 6 years ago

Either replace the batteries or disconnect and reconnect. I have had this happen as well and a "reboot" of the lock seems to fix it. In my case battery levels are good.

jwelter1971 commented 6 years ago

Interesting; with existing batteries it was reporting 70%. But replacing them solved the problem. Lock added cleanly and reports properly.

Thanks for the pointers; will make note to swap batteries at the 70% mark.

jwelter1971 commented 6 years ago

Ok it seems still problems here. With them rejoined and all working nicely I still am failing to get the _alarm_type and _alarm_level sensors to update. They stay at 0. The lock. entities update but not these associated sensors.

My KwikSet's are doing the right thing.

dshokouhi commented 6 years ago

do you see the communication in OZW logs?

jwelter1971 commented 6 years ago

Yes and the lock.lock and lock.unlock services work, it’s just the status failing to update it seems.

dshokouhi commented 6 years ago

@jwelter1971 I had just updated to 0.81.1 and I do not have any of these issues with my zwave lock. I suspect the issue may be isolated to your setup. Do you see any "dropped commands" in the OZW logs for your lock?

jwelter1971 commented 6 years ago

I've updated to 0.82.b1 and they are all working fine again. No changes made except the upgrade.

Under 81.x the _alarm_type and _alarm_level were perpetually 0 and 0 and the lock status was often incorrect.

Now under 0.82.b1 the _alarm_type and _alarm_level are returning the expected status for the lock state and the lock status is also correct.

Closing.