Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding support for Locking and UnLocking states for LockService #74

Open
GuillaumeB-GitHub opened this issue Aug 22, 2023 · 3 comments
Open

Comments

@GuillaumeB-GitHub
Copy link
Contributor

As per HA documentation (https://developers.home-assistant.io/docs/core/entity/lock/), the Lock entity supports transition states Locking and UnLocking.
It would be great to add the support for these states as unlocking or locking a Wyze lock can take several seconds.

Note: ha-wyzeapi has a bug in the way the lock state is managed, and it will need to be fixed after the support for Locking and UnLocking states will be added in wyzeapi. I'll create an issue there too.
Note2: Great work !

GuillaumeB-GitHub added a commit to GuillaumeB-GitHub/wyzeapy that referenced this issue Aug 22, 2023
@JoeSchubert
Copy link
Collaborator

JoeSchubert commented Oct 25, 2023

My information may be outdated as I've been away from the project for a bit... but I don't think this would really make all that much sense to incorporate as the lock is only polled every 15 seconds or so. So unless you get some really unfortunate polls, you're always going to be in a locked or unlocked state. Wyze stopped permitting third-party polling with enough speed that would really make this level of accuracy difficult to make worthwhile.

Basically, the Wyze App can show these states (and maybe their partner third-party devices) but they absolutely hammer their API to get updates. They said that this project was causing too much load polling anywhere near the rates they do and had threatened to block access to their API back when binary sensors were enabled. After that, polling got SEVERLY cut back.

@GuillaumeB-GitHub
Copy link
Contributor Author

I disagree : this is precisely because we can't pull Wyze more often that we need to have these transition states. At the moment, if you click in HA to unlock the lock by example, the state changes instantanely to Unlocked, then the state pull from Waze happens, and almost all the time, because these locks are slow, the unlocking has not been done, so the state is switched back to Locked until the lock finally unlocks and the pull provide an Unlocked state. This is very confusing and it makes you wonder if the command has been sent or not.
Knowing that the lock is Unlocking or Locking has nothing to do with the ability to pull more often the state of the lock: these states are just there to be between the moment you click on Lock/Unlock and the state pull from Waze that indicates that the desired state has been reached. Basically, they tell you that the command has been sent and the lock is transitioning.

@JoeSchubert
Copy link
Collaborator

I guess you're not asking to get the state from Wyze. You could accomplish what you want by modifying the lock/unlock functions here to set the is_locking and is_unlocking properties instead of the locked/unlock states here:
https://github.com/SecKatie/ha-wyzeapi/blob/5ccebafe3266ceb26bceadfd73f0ce4e2124477e/custom_components/wyzeapi/lock.py#L85

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants