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

Using cached values when the Nuki bridge is not available #8

Open
Cardo1 opened this issue Nov 21, 2016 · 4 comments
Open

Using cached values when the Nuki bridge is not available #8

Cardo1 opened this issue Nov 21, 2016 · 4 comments

Comments

@Cardo1
Copy link

Cardo1 commented Nov 21, 2016

Hello,
First of all, thanks for this plugin. Just got the Nuki and it's great to be able to integrate this with HomeKit straight away.

The plugin seems to be working fine, but I have a request in relation to its behaviour. I've noticed when the Nuki bridge is down, the plugin gives the last cached state. Personally, I don't feel this is the best way to go about it, as the reported state could be hours old and unless you check the Nuki app to see if everything's ok, you would assume the reported state is correct. Would it be possible to change this behaviour so the state comes back as unknown if the bridge isn't reachable? This could possibly be an option?
Thanks.

@Cardo1
Copy link
Author

Cardo1 commented Nov 22, 2016

Further to this, I've been experiencing some issues with the Bridge. I don't know whether there's a glitch with the bridge itself, or problems with the Nuki servers causing the Bridge to act in a somewhat odd manner, however I'm having the following issue:
The /list command only returns the following:
[{"nukiId": a_long_number, "name": "Back door"}]
It isn't reporting the lock state in this response. This has previously been working correctly, so I don't know what's occurred to cause this regression in behaviour. I'm using mode 2 in the lock state in the plugin, and this had been working correctly.
What I'm finding is that the plugin is sending the /list request and is receiving the above response. This is the log in Homebridge:
Lock state is isLocked = 'true' (Nuki state '255' ) with battery critical = 'false'
According to the API, lock state 255 is "undefined". Unfortunately, the plugin is taking this to mean the lock is locked.
As an example, I unlocked the lock, the web hook correctly updated Homebridge with the new unlocked status. However, when opening a HomeKit app on my phone Homebridge sent a new /list request, with the undefined response as above, and changed the lock state to locked, even though the lock remained physically unlocked with no changes from the previous unlock procedure.

@benzman81
Copy link
Owner

Could you check /info for the SW version of the bridge?

@Cardo1
Copy link
Author

Cardo1 commented Nov 22, 2016

The FW version is 1.3.6. I'm not certain what the latest is, I couldn't find this information on the Nuki website.

@Cardo1
Copy link
Author

Cardo1 commented Nov 22, 2016

I now have the Bridge working again (carried out what I believe was a factory reset) and the response to /list now gives the Bridge's cached lock state again, so Homebridge correctly reports the updated state.
However, the ability to report an unknown or error state when the Bridge is glitching or not responding would be sensible, I feel.

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