Cardo1
commented
8 years ago 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
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.