Home not getting new lock state after manual unlock

[sleepyarmistice]

Whenever we manually open the lock, HomeKit doesn’t seem to be aware of it until the Home app is actually open. I have an automation set to automatically lock the door after 10 minutes, which has stopped firing over the last few days if the door was unlocked manually. However, if you unlock the door by hand, wait a few minutes, then open the Home app, the door will relock ten minutes after you open the home app. The lock state is always accurately reflected in the Sesame app, though.

[jankais3r]

There are probably at least 2 ways how we could make Homebridge aware of the change of the state that happened from outside of Homebridge:

1. Periodically check the lock status in the background, or
2. Implement WebHook API

While the second option would provide more accurate results, it would also require a publicly accessible web server, which would be impractical for most users. Sadly I have trouble understanding TypeScript code, so I don't think I'll be able to create the pull request on my own.

[aschzero]

Yeah, updating accessory states in the background is a little tricky. The two options that @jankais3r laid out would solve this but they both have their pros and cons.

1. Periodically checking the lock status would be the most straight forward, but would require polling the API at certain interval. Figuring out the right interval is the big question here – a large time interval would mean of course taking more time for the lock state to update, but a smaller time interval means more network requests and putting more strain on Sesame's servers. It might be best to let users specify their own interval via the plugin config.

2. Using the WebHook API would would be the best way to ensure the lock state is always accurate, but @jankais3r is correct in that it would require an accessible API of some sort that the plugin would respond to. I wouldn't feel comfortable building and hosting a separate API for everyone's lock states to go through for privacy reasons, but a possible alternative option would be to build a companion API server that users could host themselves if they wanted.

Ideally, I would love it if Sesame's API supported websocket connections that the plugin could subscribe to. I might reach out to them about that... but in the meantime I think the best approach would be to implement the polling functionality now and possibly look into the second option in the future.