Nuki Smart Lock 2.0 - support all available API actions (i.e. add lock/unlock)

[mahikeulbody]

You try to unlock manually and then open the door ?
I just tried to do it two or three times successfully and then the following manual unlock and opening the door drives to this problem.
When it runs, the card is updated very fast.

[alexdelprete (Alessandro Del Prete)]

@mahikeulbody

You try to unlock manually and then open the door ?
I just tried to do it two or three times successfully and then the following manual unlock and opening the door drives to this problem.

Tell me what you do exactly, how much time you wait between each try.

Unlock-manual, delay, open-door, delay, retry from the beginning? fill the delay with a number.

[mahikeulbody]

@alexdelprete

probably sometimes it doesn’t work and so no callbacks are triggered

When I unplug the bridge, I have not this problem (door sensor jammed) so I don’t believe it is a physical door sensor problem.

[alexdelprete (Alessandro Del Prete)]

without the bridge you don’t have that warning? weird…

I don’t have that warning, with the bridge…

anyway, I don’t think the problem is in the code of the Card…do you want to try to go back to the Template Switch instead of the Template Lock switch?

[mahikeulbody]

Ok, I just tried a new sequence: open, close, open, close, a lot of time… waiting only a couple of seconds to have status door updated on the card, without any unlock/lock. No problem ! So it seems it is not a physical door sensor.

[alexdelprete (Alessandro Del Prete)]

Have a nice dinner Joerg, talk to you soon. Thanks for your time.

[alexdelprete (Alessandro Del Prete)]

@mahikeulbody

No problem ! So it seems it is not a physical door sensor.

With the bridge obviously, because you mentioned that the card works.

So now try to do a couple of open/close of the door plus a lock/unlock, then wait for 1 minute and see if the sensor give you the warning.

[mahikeulbody]

@alexdelprete

With the bridge obviously, because you mentioned that the card works.

yes, of course.

[mahikeulbody]

So now try to do a couple of open/close of the door plus a lock/unlock, then wait for 1 minute and see if the sensor give you the warning.

I made this sequence three times, no problem. Then I made the same sequence two times waiting only 5 or 10", no problem…

PS. I made manual lock/unlocks since it is doing that the problem occured for me and Joerg.

[alexdelprete (Alessandro Del Prete)]

Form

@mahikeulbody

I made manual lock/unlocks since it is doing that the problem occured for me and Joerg

From the bridge’s point of view, there’s no difference between a manual lock and one made via app or API.

@mahikeulbody

I made this sequence three times, no problem. Then I made the same sequence two times waiting only 5 or 10", no problem…

Very strange. But I don’t think it’s related to the card’s code. Let me know if you find something…

[mahikeulbody]

And now I retried locking/unlocking via HA and then open the door : door sensor problem !

NB. Waiting a couple of minutes, door sensor return to normal without re-calibrating.

Probably a non-sense idea but since there is no problem when only opening/closing the door, only when I do lock/unlock operation, could be that a conflict between HA Nuki integration and “our” solution which would drive Nuki bridge to bug sometimes ?

[alexdelprete (Alessandro Del Prete)]

Did you

@mahikeulbody

Probably a non-sense idea but since there is no problem when only opening/closing the door, only when I do lock/unlock operation, could be that a conflict between HA Nuki integration and “our” solution which would drive Nuki bridge to bug sometimes ?

Interesting observation, did you delete the old sensors of previous versions of the card? Maybe the conflict happens when the Nuki Official polls the bridge and the bridge is busy doing the callback…but we’re just speculating now…

It never happened to me, but you’re testing much more than I did. In any case, in real life scenario, I don’t think it will happen.

[mahikeulbody]

did you delete the old sensors of previous versions of the card?

Yes I did.

Maybe the conflict happens when the Nuki Official polls the bridge […].

Is the HA Nuki integration needed with this solution ?

In any case, in real life scenario, I don’t think it will happen.

Well, it happened at the first try which was a normal use case.

[alexdelprete (Alessandro Del Prete)]

@mahikeulbody

Is the HA Nuki integration needed with your solution ?

I was just looking at that: actually, it’s only needed as a target for the lock/unlock, othwerwise I don’t have a target entity for those actions. What could be done is create a service (a REST switch or something like that) which calls the lock/unlock actions on the bridge via HTTP. If we integrate those 2 actions in a normal Template Switch, we can get rid of the official Nuki integration.

Basically, we’ve redone the integration from scratch, with callbacks.

@mahikeulbody

Well, it happened at the first try which was a normal use case.

I did it too, and had no issues.

[Joerg]

Good morning,

@alexdelprete

What could be done is create a service (a REST switch or something like that) which calls the lock/unlock actions on the bridge via HTTP.

you mean something like this?:
shell_commands.yaml

nuki_unlock: "curl -s '192.168.0.63:8081/lockAction?nukiId=device_id&deviceType=0&action=1&token=**'"
nuki_open: "curl -s '192.168.063:8081/lockAction?nukiId=device_id&deviceType=0&action=3&token=**'"
nuki_lock: "curl -s '192.168.0.63:8081/lockAction?nukiId=device_id&deviceType=0&action=2&token=**'"

[alexdelprete (Alessandro Del Prete)]

Good morning,

@Joerg

you mean something like this?:
shell_commands.yaml

Nope, that was too simple.

I wanted to revisit the whole structure of the user variables so the user only configures these variables: bridge IP, bridge Port, Token, Webhook in secrets.yaml.

Once I have those 4 variables, I can build dynamically all the URLs I need to communicate with the Bridge. I also wanted a single lockAction service to call, passing the service the Action parameter I need.

I used one rest_command service in which the URL is created through the user config variables, the problem was that templates don’t support secrets, but if you create a sensor and map it to the secret, you can bypass the limitation.

sensors.yaml

- platform: template
  sensors:
    nuki_bridge_host:
      value_template: !secret nuki_bridge_host

- platform: template
  sensors:
    nuki_bridge_port:
      value_template: !secret nuki_bridge_port

- platform: template
  sensors:
    nuki_bridge_token:
      value_template: !secret nuki_bridge_token

rest_commands.yaml

nuki_lock_action:
  url: "http://{{ states('sensor.nuki_bridge_host') }}:{{ states('sensor.nuki_bridge_port') }}/lockAction?nukiId={{ states('sensor.nuki_id') }}&token={{ states('sensor.nuki_bridge_token') }}&action={{ action }}"

Once you have the variables and the service, you can create the Template Lock.

locks.yaml

- platform: template
  name: "Nuki Lock Action"
  value_template: "{{ is_state_attr('binary_sensor.nuki_door_state', 'lock_state', 'locked') }}"
  availability_template: "{{ state_attr('binary_sensor.nuki_door_state', 'lock_state') != None }}"
  lock:
    service: rest_command.nuki_lock_action
    data:
      action: 2
  unlock:
    service: rest_command.nuki_lock_action
    data:
      action: 1

It was pretty tricky to make it work, but it does, and doesn’t require the official Nuki integration to be installed.

I learned a lot revisiting the whole structure of the card last night, now it’s much better, more elegant and clean. I’m still testing some things, then I’ll release v4.0.

If v4.0 works, I’ll concentrate on the annoying problem: after an HA restart the callbacked sensors are not initialized and require an action on the door/lock to trigger the callback. I want to solve that…

[Joerg]

@alexdelprete

Nope, that was too simple.

I removed the Nuki integration already and will go on with testing later.

[alexdelprete (Alessandro Del Prete)]

@Joerg

I removed the Nuki integration already and will go on with testing later.

I could release it now, but I’m too tired (didn’t sleep tonight) to rewrite the instructions and could make mistakes.

I was also thinking to start a new thread, this one is getting a little bit confusing, what do you think? Shall we continue here or start a new thread?

Let’s vote

• Start a new thread
• Continue in this thread
• I don’t care, just give me the code

[Joerg]

@alexdelprete

but I’m too tired (didn’t sleep tonight)

Than better get some rest. HA and the locks will still be the there later

[alexdelprete (Alessandro Del Prete)]

@mahikeulbody

According to the Nuki Bridge API, /lockAction does not return door_state. The only way is to use /lockState. But on the other part, the doc says Warning:​ /lockState gets the current state directly from the device and so should not be used for constant polling to avoid draining the batteries too fast. ​/list​ can be used to get regular updates on the state, as is it cached on the bridge.

I don’t use it to retrieve the status, only to start the action (lock/unlock). The status of the door and the lock comes through the callback right after the action.