Bridge Beta FW 2.6.0 / 1.16.0 with door sensor state

With the latest Beta firmware version 2.6.0 and 1.16.0 you can now:

  • get the door state in /info and /lockState commands
  • get callbacks for door state changes



  “mode”: 2,
  “state”: 1,
  “stateName”: “locked”,
  “batteryCritical”: false,
  “doorsensorState”: 2,
  “doorsensorStateName”: “door closed”,
  “success”: true


  "nukiId": 1,
  "deviceType": 0,
  "name": "Home",
  "lastKnownState": {
    "mode": 2,
    "state": 1,
    "stateName": "locked",
    "batteryCritical": false,
    “doorsensorState”: 2,
    “doorsensorStateName”: “door closed”,
    "timestamp": "2018-10-03T06:49:00+00:00" }


{“nukiId”: 11, “deviceType”: 0, “mode”: 2, “state”: 1, “stateName”: “locked”, “batteryCritical”: false, “doorsensorState”: 2,   “doorsensorStateName”: “Door Closed”


ID Name
0 unavailable
1 deactivated
2 door closed
3 door opened
4 door state unknown
5 calibrating

Note: Very fast sequences of door state changes may not trigger an individual callback each, so you can not build a complete door state history witht this feature.

The update will be done autonatically if your Bridge is part of the Beta program.

Please test it out and give us your feedback!


Great to see this is now supported. I have tested it and it seems to work as intended. Havent found anything strange yet. As mentioned the callback from the sensor is not real time and that is something to be aware of when integrating it into your domotica system.

Does this pave the way for other features in the HTTP bridge API like the user or keycode that caused a lockstate change?

@Stephan great. Added to homebridge-nukiio in version 0.11.0. Quick tests show that it works, although I want to add, that there is the typical delay from the bridge which is about 5s. But that’s by design as I understand. My native Eve Contact sensor reacts immediately.

I’ve updated my Hubitat Elevation driver for the Smart Lock and it is working fine. This feature will spare me a Fibaro contact sensor!!

As usual, the bridge’s delay to report status changes is between 1 and 2 seconds.

And now, behaving as users usual behave: expecting future features …

With the addition of information on how the door was opened/closed (manually, smartphone app proximity, fob, keypad, etc) and, eventually, which user opened/closed the door, it would open a world of possibilities!

Imagine Alexa greeting the user when he/she opens the door with a variety personalised information and actions, like greetings with the user’s name, telling who’s already at home, asking if the user wants to set the lights to his/hers preferences or starting warming up dinner, and so on. It would be 2001 Space Odyssey coming true! Well, not exactly, since nobody wants Alexa killing people as HAL did …

Congratulations to Nuki’s team! :+1:



i’ve updated today Opener to 1.4.6 and Smartlock to 2.7.23, but nuki Bridge List shows only the old firmware Version.
Bridge is with Beta 2.6.0.

Devices are at night mode, but i did operate them so they send a callback.
but after readout the Bridge list still same firmware.
With Bridge at firmware 2.5.2 no problem

Hi @Stephan,

how do I update to 2.6.0? Nuki support confirms that my bridge is registered for beta channel. If I open /fwupdate in the browser the firmware stays on 2.4.8. What do I do wrong?


The Bridge should update automatically 1 hour after restart (and then retries every 24 hours). - or you can use /fwupdate command if the Bridge API is activated (as you seem to have tried) to trigger an immediate update.
If your Bridge firmware is still on a quite old version that means the update keeps failing. You could try to connect the bridge to a hotspot or another Wifi to see if that helps. In any case our support should assist you on trying to update/solve this for you.

Thanks for the quick reply. Won’t work. Neither the Bridge API command nor restarting / unplugging the bridge.
I contacted the Nuki support for and provided the logs.

/lockState is resulting in a HTTP 400 Bad Request

/info is giving me the latest FW {“firmwareVersion”: “2.6.0”, “wifiFirmwareVersion”: “2.1.17”}. But when i call /list i can see the door state.
Any advice on that?

Maybe a general error in /lockState request?

Could you PM the the request you send so I can verify it?

The bridge firmware with these new features will now be rolled out to all users and the Bridge API documentation has been updated: