the REST error “///” is normal, at every restart. The other errors/warnings should not happen often, only when the bridge doesn’t process the request. Anyway, I never see HA systems with zero warnings/errors in the log. The important thing is that generally everything’s working.
Nuki Card v11.0 released: finally added support for the Opener, highly requested feature. Improved refresh times for some sensors. Fixed some bugs.
Thanks in particular to @madface for testing the Opener integration.
Hope to receive feedbacks from the opener users. 
1 Like
Thanks a lot for your work Alex ! It’s working great for both my opener and my lock. Have there been any changes from beta 4 to public v11.0?
1 Like
Thanks for your kind words.
A couple of lines in the code. Just copy&paste from gist to the file, and you’re done. Not necessary to restart HA now, wait until next mandatory restart, if that is your concern.
1 Like
Thank you for your good work
2 Likes
Maybe someone here can help me with a little automation using Nuki Card V11.
I want to achieve that if someone is at home and ring to open is activated, as soon as someone rings the doorbell, both the front door (opener) and the apartment door (lock) should be opened.
I have tried the following:
trigger:
- platform: state
entity_id: binary_sensor.nuki_opener_ring_action_state
to: 'on'
from: 'off'
condition:
- condition: state
entity_id: sensor.nuki_opener_state
state: rto active
- condition: and
conditions:
- condition: state
entity_id: group.awesome_people
state: home
action:
- service: rest_command.nuki_lock_action
data:
nuki_id: ***********
dev_type: 0
action: 3
Unfortunately this does not work, because rto is deactivated as soon as someone rings. So the condition is of course not fulfilled.
Do you have any idea how I can get this implemented?
Any help is appreciated. 
Thanks for your kind words.
Why are you triggering from on to off? The ringactionState goes off after 30 seconds, so sensor.nuki_opener_state will always be “online” instead of “rto active”.
I would trigger from: “off” to: “on”, so as soon as you ring. Try it and tell me if it works.
Also introduce a delay of 5 secs before the rest command, because the bridge is busy after you ring, it’s sending/receiving from HA, so give it some time to be available to answer, otherwise it will throw http error 503.
1 Like
Best thing is to reverse the logic: trigger on the attribute opener_state_id of sensor.nuki_opener_state. It’s better to check for the state id (numeric) because the string value can change in the future, the numeric state won’t.
(check the attributes of sensor.nuki_opener_state and binary_sensor.nuki_door_state for a lot of useful info about the state of the devices you can use in automations)
This automation triggers on the transition to “online” for 3s, then checks if binary_sensor.nuki_opener_ring_action_state is “on” (someone rang the opener) and it checks if there are awesome people home. If so, it unlocks the smartlock.
Let me know if you prefer this approach.
- id: "nuki_rto_unlock_smartlock"
alias: "Nuki RTO Unlock SmartLock "
trigger:
- platform: template
value_template: "{{ is_state_attr('sensor.nuki_opener_state', 'opener_state_id', 1) }}"
for:
seconds: 3
condition:
- condition: and
conditions:
- condition: state
entity_id: binary_sensor.nuki_opener_ring_action_state
state: "on"
- condition: state
entity_id: group.awesome_people
state: home
action:
- service: rest_command.nuki_lock_action
data:
nuki_id: "123456AB89"
dev_type: 0
action: 3
1 Like
Wow thanks a lot for your fast and helpful answer! I’ll try your approach as soon as I get home from work today and will let you know about it.
Nice Approach to check the state going back to online, i was thinking a lot of time how to check if the state WAS rto_active. But this strange piece of hard/software (the opener) has it’s own life i think. Here are 2 screenshots of the states when ringing the bell while rto was active:
One time it goes from 3 (rto_active) to 7 (unlatching) to 1 (online), another ring it’s 3->7->5 (unlatched)->1
We can use 2 triggers or just
to: 1
- platform: state
entity_id: sensor.nuki_opener_state
attribute: opener_state_id
from: 7
to: 1
- platform: state
entity_id: sensor.nuki_opener_state
attribute: opener_state_id
from: 5
to: 1
But with the first it triggers if rto changes back to online and nobody rings the bell.
Second problem seems to be that the ringaction state is callbacked after the ones above. So you coudn’t use it in the condition as there the ringaction state is still off. I will try to check this in the action: section, when i have a working one i will post it here.
EDIT: For me this one is working (i have a small and big home zone, fyi):
- alias: NUKINEW - Haustür öffnen
initial_state: true
trigger:
- platform: state
entity_id: sensor.nuki_opener_state
attribute: opener_state_id
from: 7
to: 1
- platform: state
entity_id: sensor.nuki_opener_state
attribute: opener_state_id
from: 5
to: 1
condition:
- condition: or
conditions:
- condition: state
entity_id: person.mad
state: 'home'
- condition: state
entity_id: person.mad
state: 'BigHome'
action:
- delay: '00:00:01'
- service_template: >
{% if is_state('binary_sensor.nuki_opener_ring_action_state', 'on') %}
lock.unlock
{% endif %}
data_template:
entity_id: lock.nuki_lock_action
Then i have another 2 questions:
The input_numbers for the state or mode id, shouldn’t be this integer values (the show me as 1.0 for example in the developer settings), maybe just for that it looks nice?
And the other, if the house door is unlocked, how can i unlatch it from the card? On the card there is now only lock, i have to go in Nuki Lock Action and select here unlock, maybe to lines for lock und unlock(latch) would be nice…
For the Opener you can check input_text.nuki_opener_states: 1 is online, 3 is rto active, 5 is open, 7 is opening.
name: "Nuki Card (opener states)"
initial: '{"0": "untrained", "1": "online", "2": "n/a", "3": "rto active", "4": "n/a", "5": "open", "6": "n/a", "7": "opening", "253": "boot run", "254": "n/a", "255": "undefined"}'
max: 255
The Opener is doing its job, because it’s also opening the gate, so it’s showing you intermediate states 7 and 5. But in the end it will go to state 1. So we can check for the transition to holding state 1 for 3 seconds.
- id: "nuki_rto_unlock_smartlock"
alias: "Nuki RTO Unlock SmartLock "
trigger:
- platform: state
entity_id: sensor.nuki_opener_state
attribute: opener_state_id
to: 1
for:
seconds: 3
I updated the previous post with the modified trigger. Let me know if it works.
input_numbers show also the decimal unfortunately, but it’s not a problem when comparing.
For the unlatch, like I explained many times before, the rest_commands I prepared are parametric, so in the action you can use the number for the unlatch action, like he already did in his code, 3 is unlatch for the smartlock and electric strike actuation for the opener:
This is the correct code to unlatch:
action:
- service: rest_command.nuki_lock_action
data:
nuki_id: "123456AB89"
dev_type: 0
action: 3
If you want to do it with lock.unlock service, like you did, you need to configure unlatch on the Nuki Card unlock action:
this one is too much in your automation, in the moment of the condition the ringaction is less than 5 seconds old 
. Without this the action triggers and the ringstate in this moment is on.
I had understand that with the unlock action set to unlatch (you told me above and its working fine). But what i meant was a simple button to open the door when i come at home and something in the automation is not working. On the card there is only lock in that moment (because my wife is at home and the door is unlocked), i searched for a simple button that opens (unlatches) the door in that moment without pressing “Nuki Lock Action” on your card and choose unlock in this, i hope you understand what i mean… It’s not about the technic but simple using it 
Correct, if we check for holding state of nuki_opener_state, we don’t do it for the ringaction. I updated the automation in the previous post.
You didn’t check the code of the automation prepared by @Ey3scr34m, look at the action: you call the rest_command of the automation and you use action: 3 to unlatch. So you just need to put a button on lovelace and associate it with the action.
action:
- service: rest_command.nuki_lock_action
data:
nuki_id: "123456AB89"
dev_type: 0
action: 3
@madface let me notice a few things I couldn’t test, because my opener is not connected so I can’t really know how it behaves when you ring. So I modified the automation based on his feedback, seems to be working fine now with these changes. Let me know.
For those who are in hurry,
trigger:
- platform: state
entity_id: sensor.nuki_opener_state
attribute: opener_state_id
to: 1
for:
seconds: 1
seems to work also. The update of the ringaction is really fast after state going back to online, saves another 2 seconds 
Unfortunately the automation isn’t working for me this way. I don’t know where to start debugging because to me it makes perfectly sense this way. And it seems like it’s working for @madface aswell…
@alexdelprete Came back from holiday today and finally could test the new version with opener integration. I already added the beta version a week ago but couldn’t really test it because I was away.
Everything is working fine for me so far I. Finally I can receive notifications for doorbell rings and integrate actions for opening the door downstairs via opener! Great work! Really appreciate your efforts.
ringactionstate should be reset off after 30 secs, isn’t that the case?