Unexpected behaviour when controlling Nuki locks using Siri

[Cardo1]

I've already created an issue on the Nuki plugin page, but the developer doesn't seem to be having any problems using an earlier version of Homebridge. I'm on the very latest version of Homebridge, and I'm having this unusual issue:

When using either a HomeKit app or the Control Centre, locking or unlocking my Nuki works as expected.

However, if I try to lock or unlock using Siri on any device, Siri says the command has been made, the state when viewed on a HomeKit app shows the locking or unlocking (what you'd expect), however when viewing the Homebridge log, the command that is actually sent is always to change the lock to its current state.
ie. Door locked. Send an unlock command, HomeKit says I'm unlocking the door, but Homebridge actually sends a lock command. If I send a lock command whilst the door is locked, it also sends a lock command.
And vice versa, if the door is unlocked, sending a lock command shows up in HomeKit as attempting to lock the door, but Homebridge sends the unlock command to Nuki.

As stated, if I use the Home app, or Control Centre, or the Home app on my Watch, it works correctly.

I started noticing this issue some time in the past couple of weeks. Is it possible an update to Homebridge has changed something that would cause this behaviour?

Original issue on the Nuke plugin page:
benzman81/homebridge-nukiio#17

[Cardo1]

Looks like my issue may be the same as that seen in issue 1456, where reverting to an earlier version of Homebridge fixed the problem. Whilst this may be a temporary fix, surely identifying and fixing the issue is a more appropriate option than simply reverting to an older version?

[Cardo1]

Reverting to Homebridge 0.4.22 appears to fix the issue.

[Cardo1]

Whilst using Homebridge 0.4.22, I've updated HAP-NodeJS to the latest version, 0.4.32 and with this latest version everything works fine.
Updating to version 0.4.26 of Homebridge causes the problem to manifest itself. Unfortunately, I can't run versions 23 through to 25 as they appear to conflict with at least one of my plugins.

[NorthernMan54]

I took a quick look at the differences between 0.4.22 and the latest, and there where no code changes in homebridge itself. Each release was a bump in version numbers to stay instep with the hap-nodejs changes. You should go back to the plugin developer with a DEBUG log showing the issue so they can make the changes. PS the only code changes where updates to the sample code

…

Sent from my iPad

On Aug 26, 2017, at 5:17 AM, Cardo1 ***@***.***> wrote: Whilst using Homebridge 0.4.22, I've updated HAP-NodeJS to the latest version, 0.4.32 and with this latest version everything works fine. Updating to version 0.4.26 of Homebridge causes the problem to manifest itself. Unfortunately, I can't run versions 23 through to 25 as they appear to conflict with at least one of my plugins. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Cardo1]

Looking at the DEBUG log we've worked it out. There appears to have been a change where locking actions are different with Siri. When using Siri, the target lock state is true or false, whilst through the app, and how it was before, the target lock state is 1 or 0. The Mrs is going to fix this on the Nuki plugin and do a pull request.

[pdlove]

The plugin developer needs to refer to the HomeKitTypes file in HAP-NodeJS. From that file, the correct values for locks have always been:

// The value property of LockCurrentState must be one of the following:
Characteristic.LockCurrentState.UNSECURED = 0;
Characteristic.LockCurrentState.SECURED = 1;
Characteristic.LockCurrentState.JAMMED = 2;
Characteristic.LockCurrentState.UNKNOWN = 3;

TargetState currently only has the first two as options. The difference is that HAP-NodeJs is now enforcing data sent to HomeKit to be correct in order to prevent the issue where you have to delete persist.