Nuki: use callbacks instead of unreliable polling

Feature Requests
1

The current Nuki integration is using a polling mechanism to get the lockState. As the resources from the Nuki Bridge are limited this often results in 503 errors. A better approach would be to use the callback mechanism. You can set an endpoint which the Nuki Bridge calls when a change in lockState has been detected. This is more reliable, gives faster feedback and reduces the network traffic between HA and the bridge.

https://developer.nuki.io/page/nuki-bridge-http-api-1-12/4#heading--callback

The integration would have to setup this endpoint and register the callback in the Bridge, perhaps as an optional setting when configured under configuration.yaml.

2

Would love to see that implemented!

1 Like
3

I agree. Would also like to have this like @Phuturist described.

4

Is there any possibility to inform the relevant DEV for the Nuki integration? So he get’s notice of it?

5

Sure.

@pschmitt and/or @pvizeli , is this something that could be integrated into the Nuki integration. It would greatly reduce the errors in the HA log for Nuki locks caused by 503 responses by the Nuki Bridge.

3 Likes
6

There are news about? My Nuki integration doesn’t work anymore

7

Sadly no news - Mine also does not work anymore

8

Yesterday i tried Nuki Callbacks with Home Assistant webhook. Which works good. When back home I will post the config.

9

It’s quite easy to get the info through the Nuki callback functionality. The issue is that you can not update the state of an entity from automation. There are python scripts to do this but I have not looked into that (yet). Best would be to add this to the Nuki integration as described in this feature request. Below the info for the webhook.

First add a webhook in HA with the following automation. This particular automation publishes the battery alarm of the keypad and the battery percentage of the lock to MQTT.

- alias: 'Nuki callback'
  trigger:
    - platform: webhook
      webhook_id: <<your_nuki_webhook_identifier>>
  action:
    - service: mqtt.publish
      data_template:
        topic: nuki/battery
        retain: true
        payload: "{{trigger.json.batteryChargeState}}"
    - service: mqtt.publish
      data_template:
        topic: nuki/keypad_battery
        retain: true
        payload: "{{trigger.json.keypadBatteryCritical}}"

Then add the actual webhook as callback in the Nuki using a GET request to Nuki (you need to replace the ip, token and webhook URL).

GET http://<<nuki_ip>>:8080/callback/add?token=<<token>>&url=http://<<ha_ip>>:8123/api/webhook/<<your_nuki_webhook_identifier>>
1 Like
10

Thank you, but if I want Nuki state (lock,unlock,unlatched…) i have to use {{trigger.json.stateName}} ?
My nuki callback is for example {“nukiId”: 11, “deviceType”: 0, “mode”: 2, “state”: 1, “stateName”: “locked”, “batteryCritical”: false, “doorsensorState”: 2, “doorsensorStateName”: “door closed”}
Then how i can read this value from home assistant ?
Can I set
sensor:

  • platform: mqtt
    name: “Nuki state”
    state_topic: “nuki/state”
    value_template: “{{value_json.stateName}}”
    force_update: true
    qos: 1
    in config.yaml?
11

Yes.

But if you want to completely bypass the current Nuki integration you will need to add a MQTT Lock instead of a sensor: MQTT Lock - Home Assistant That’s a little more complicated but just read the docs on how to do this.

12

ok thank you.
Last question: I use nabu casa and when i write an automation with webhook and webhook_id, HA create a webhook “nabucasa based” where URL is set with https://webhook.nabucasa.com and this not work because callback on nuki not work with https.
if i try to use your config http://ha_ip:8123/api/webhook/<webhook_id> not work and log tells me that webhook is not registred. How can resolve this?

13

Dont know, I dont use Nabu Casa. But you are correct that Nuki callbacks do not support https URL’s.

14

Hello,

It would really be nice, or even necessary, to use callback instead of polling in the Nuki integration.
If someone unlock the smart lock, the delay is too long before the state is updated for Home Assistant.

1 Like
15

It seems the 503 errors are at least less frequent but that might be due to a Nuki firmware update. Having this functionality is still on my list …