I can install it too (it takes me a bit longer since I have split config and each sensor/script is in separate file - but that’s just few minutes more of work for me compared to hours you invested).
We use Opener more then Lock so will test it heavily 
1 Like
So you don’t like the packaged version? You preferred the old split version?
Thanks for the help, yesterday I watched a video on your channel and subscribed.
1 Like
I’m happy to test
No it’s great, but my whole configuration is each thing in separate file. And wanted to keep it same 
And Thanks for subscribing!!! Really much appreciated 
@madface @stefancvetkovic @beardedconti @floo @joerg @saeris @jero537 @Harry2 @Lucan:
v11.0 Beta 2 is ready for your tests: Nuki Card v11.0-beta2 · GitHub
Note: A lot has changed, sensors, input helpers, etc. so it’s MANDATORY before installing this version to delete ALL previous sensors. Proceed like this:
- delete the nuki_card_callback.yaml from the packages directory
- delete the cards from lovelace
- restart HA
- go to HA->Config->Entities and filter the entities with the keyword “nuki” so to only show nuki card entities
- the list now should present all entities with a red symbol in the last column (orphan entities), select all of them and remove them
- once you’re sure everything is clean, install the new beta1 version creating the new file in /config/packages
- here’s the code for the two full lovelace cards (Nuki Lock/Bridge and Nuki Opener) with all available sensors/entities. After the tests, when in production, you can customize whatever you want, removing what you don’t need.
Nuki Card lovelace code
cards:
- type: vertical-stack
cards:
- type: entities
entities:
- entity: sensor.nuki_lock_friendly_name
- entity: lock.nuki_lock_action
secondary_info: last-updated
- entity: binary_sensor.nuki_door_state
secondary_info: last-updated
- entity: binary_sensor.nuki_bridge_callback
secondary_info: last-updated
- entity: sensor.nuki_lock_last_update
- entity: input_select.nuki_choose_lock_action
- entity: input_select.nuki_choose_unlock_action
- entity: sensor.nuki_bridge_fw_version
- entity: sensor.nuki_bridge_wifi_fw_version
- entity: binary_sensor.nuki_bridge_wifi_connected
- entity: binary_sensor.nuki_bridge_cloud_connected
- entity: sensor.nuki_lock_id
- entity: sensor.nuki_lock_device_name
- entity: binary_sensor.nuki_lock_bridge_bt_state
- entity: sensor.nuki_lock_bridge_bt_rssi
- entity: sensor.nuki_lock_battery_level
- entity: sensor.nuki_lock_fw_version
- entity: binary_sensor.nuki_lock_battery_critical_state
- entity: binary_sensor.nuki_keypad_battery_critical_state
state_color: true
title: Nuki Card v11 (Lock/Bridge)
- type: vertical-stack
cards:
- type: vertical-stack
cards:
- type: entities
entities:
- entity: sensor.nuki_opener_friendly_name
- entity: lock.nuki_opener_action
- entity: sensor.nuki_opener_state
- entity: sensor.nuki_opener_last_update
- entity: input_select.nuki_choose_opener_lock_action
- entity: input_select.nuki_choose_opener_unlock_action
- entity: sensor.nuki_opener_mode
- entity: binary_sensor.nuki_opener_ring_action_state
- entity: sensor.nuki_opener_id
- entity: sensor.nuki_opener_device_name
- entity: binary_sensor.nuki_opener_bridge_bt_state
- entity: sensor.nuki_opener_bridge_bt_rssi
- entity: sensor.nuki_opener_fw_version
- entity: binary_sensor.nuki_opener_battery_critical_state
state_color: true
title: Nuki Card v11 (Opener)
Before posting possible issues, make sure the output of the bridge /list and /info commands is similar to the following (click the arrow to expand the content). The list of fields for both the lock, opener, and bridge must be present, otherwise you have specific issues with your setup:
Bridge /list command output
curl -X GET 'http://nuki-bridge.axel.dom:8080/info?token=xyzkzy'
{
"bridgeType": 1,
"ids": {
"hardwareId": 458388402,
"serverId": 1312687564
},
"versions": {
"firmwareVersion": "2.10.1",
"wifiFirmwareVersion": "2.2.0"
},
"uptime": 5392,
"currentTime": "2021-09-01T14:25:08+00:00",
"wlanConnected": true,
"serverConnected": true,
"scanResults": [
{
"deviceType": 2,
"nukiId": 480607010,
"name": "Nuki_Opener_1CK81B22",
"rssi": -51,
"paired": true
},
{
"deviceType": 0,
"nukiId": 469204325,
"name": "Nuki_1BL19B65",
"rssi": -57,
"paired": true
}
]
}
curl -X GET 'http://nuki-bridge.axel.dom:8080/list?token=xyzkzy'
[
{
"deviceType": 0,
"nukiId": 469204325,
"name": "Porta Casa",
"firmwareVersion": "2.11.8",
"lastKnownState": {
"mode": 2,
"state": 3,
"stateName": "unlocked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 42,
"keypadBatteryCritical": false,
"doorsensorState": 2,
"doorsensorStateName": "door closed",
"timestamp": "2021-09-01T14:02:19+00:00"
}
},
{
"deviceType": 2,
"nukiId": 480607010,
"name": "Citofono Casa",
"firmwareVersion": "1.6.4",
"lastKnownState": {
"mode": 2,
"state": 3,
"stateName": "rto active",
"batteryCritical": false,
"timestamp": "2021-09-01T14:04:08+00:00"
}
}
]
Thanks a lot for your help guys. I appreciate it. Hope there are not too many issues.
Alessandro
@alexdelprete I tested only smart lock for now.
It works, only first time when I click “Lock”
after that first time, lock is locked, and I can see changed status button to UNLOCK, but when I click nothing happens…
My api responses:
I have slightly earlier firmware for nuki bridge (from some reason, I didnt get an automatic update yet…), but I think that can’t be the problem? or it can be?
in my HA logs:
So let me understand: when you installed it, Nuki Card showed the yellow icon, you pressed the button LOCK, and Nuki Card showed the gray icon (locked), and then you pressed UNLOCK but nothing happens? But do you hear the lock doing something, I mean, it’s just a GUI refresh or it doesn’t send the action?
From your /list command I see that the lock is unlocked, so the command has been sent.
Do like this:
- put the lock in unlock mode
- restart HA and make sure nuki card shows the LOCK command and the icon should be yellow
- check the API /list command output, the variable to check is stateName and the Last Update timestamp on the card
- now press the lock button and wait for the action to be completed (the last update timestamp is a good indication when it refreshes)
- check the API /list command output again and see if stateName has updated
- if it works, press UNLOCK
- check API /list again to make sure it’s updated
Let me know…everything’s working fine here.
This is normal, the REST resource is initialized and configured at runtime, so when HA starts, it’s empty and issues a warning, it’s no problem. If you have ONLY that error it’s a great result.
I understand your problem now, it was easy:
You configured UNLOCK for both Lock/Unlock actions. 
1 Like
Welcome back after Vacation 
.
Mainly it works, but sometimes (no matter if i lock or unlock the opener or the lock) it’s a little bit unreliable. I press the button and nothing happens, most of the time i have this in the logs:
Logger: homeassistant.components.rest_command
Source: components/rest_command/__init__.py:136
Integration: RESTful Command (documentation, issues)
First occurred: 18:28:35 (1 occurrences)
Last logged: 18:28:35
Error. Url: http://10.10.11.138:8080/lockAction?deviceType=0&action=2&nowait=1&nukiId=123456557&token=123456hex289. Status code 503. Payload: None
But i don’t think it’s your card, i tried on myself the last 2 weeks and i think the bridge sometimes cannot handle one request at all. The url manualy works (eg from the browser, but only most of the time, lol) and the next time i hit the button it locks or unlocks as it should. So it’s not your card.
For me one of the main reasons was the sensor for the ring action state, this one works as expected. When ringing the doorbell the binary_sensor.nuki_opener_ring_action_state goes to on as well as the input_text.nuki_bridge_opener_ringaction_state goes to true. The binary_sensor changes on the next callback to off, the input_text text stays. Is this normal behavior? Even i must say i don’t even know what the input_text is for
I will test for the next days an give further feedbacks!
Mike
Hi Mike. This is your problem: the bridge was processing another command while it received the command from Nuki Card. Make sure you’re not running the official integration in parallel, or the mobile app, or any other thing that might be sending it commands.
Nope, it was not normal. In the binary_sensor I didn’t use the input_text, that’s why you had to wait the next callback. Now you should see the update instantaneously because I use the input_text, that is updated by the callback. Thanks for reporting it. I updated the code to beta 2, please let me know how this works.
The input_texts are used as a sort of global variable in the code: every sensor that can be updated both from polling and callbacks (not all are in the callback) is configured through input_texts/numbers, so you can see updates quickly and in a consistent way.
I thought of something like this, i now stopped my app on the phone manually. Works a little bit better, but still sometimes there is the error. I think while the bridge is syncing with the nuki cloud it does also not accept the api requests, right?
Do you know if there ist a way to use the bridge only with api requests and callback and fully without the nuki cloud?
I never open the app on the phone, so I never needed to stop it, it does not do any action in background as far as I can tell. The bridge talks to nuki cloud only when initializing the API, or upgrading the firmware, that’s all. The rest of its activities is BT/BLE communication with the Lock and other devices, plus the local communication for the callback or if queried from LAN.
Ok, thanks for explaining. Updated to Beta2, i’ll report tomorrow if input_text returns to false.
Use the binary sensor instead of the input_text, I might change the name of the input text, it’s an “internal” variable.
thanks @alexdelprete. now it’s working!
can you please add an example of calling a restful service for lock & unlock
I want to be able to put it on a lovelace as a separate button on a dashboard. thanks
Stefan, here’s the documentation for the Bridge API from Nuki: https://developer.nuki.io/uploads/short-url/5tLp76dEJ1RYfkSUKxFTUSeyJNg.pdf
For Nuki Card I chose to use the /lockAction endpoint, which allows me to do lock/unlock for both the smartlock and the opener, passing only a few parameters:
rest_command:
nuki_lock_action:
url: "{{ states('input_text.nuki_bridge_url') }}/lockAction?deviceType={{ dev_type }}&action={{ action }}&nowait=1&nukiId={{ nuki_id }}&token={{ states('input_text.nuki_bridge_token') | urlencode }}"
Here’s the description of /lockAction from the document I linked you above.
If you want to use the Nuki Card, the rest_command can be used as a service in scripts or automations:
action:
- service: rest_command.nuki_lock_action
data:
nuki_id: (the id of the nuki device, smartlock or opener)
dev_type: (0 for the smartlock, 2 for the opener)
action: (1,2,3,4 or 5 - check the table below)
dev_type for smartlock: {{ state_attr('sensor.nuki_bridge_endpoint_list_lock','deviceType') }}
dev_type for opener: {{ state_attr('sensor.nuki_bridge_endpoint_list_opener','deviceType') }}
nuki_id for smartlock: {{ state_attr('sensor.nuki_bridge_endpoint_list_lock','nukiId') }}
nuki_id for opener: {{ state_attr('sensor.nuki_bridge_endpoint_list_opener','nukiId') }}
Or you can simply put the entity in your lovelace card:
- entity: lock.nuki_lock_action
- entity: lock.nuki_opener_action
1 Like
Hi Alex,
First of all big THANK YOU for this awesome integration.
I set it up and it worked well the first time and shows all the data correctly. I also managed to lock my door via HA.
But then right after that i noticed that the Lock FW version suddenly changed to unknown and i cannot lock/unlock the door anymore. connection is broken.
I restarted HA and again all worked until i unlocked the door again and right after that the same thing happens.
There are several errors in the logs:
Any idea what could be causing this?
Many thanks.
Hi Emre,
first of all, are you using the official version or the beta I just published?
second question: are you using the official HA Nuki integration?
From the logs you posted, the /info endpoint of the rest calls is not working correctly, probably because of the usual bridge problem that it only allows one command at a time.
So the usual suggestions: make sure you’re not using ANY other app/component/integration/script that interfaces the bridge in parallel, otherwise the rest calls could fail. So first make sure that no other software is communicating with the bridge, for example the mobile app, etc.
And last thing: you have a very old fw version for the bridge, you need to update it. As I wrote in the note of the first post:
- the code is based on Nuki Bridge API v1.12, make sure the bridge fw is updated to last available version before starting the configuration of this integration. min. version supported: v2.5.3
Let me know…
Ok, now both the binary_sensor and input_text stays on/true. In my understanding the binary_sensor.nuki_opener_ring_action_state should be the mirror of the doorbell, it turns on when it’s ringing and off when ringing is over. That would be usefull in my opinion, now you can see someone has rang the bell but it never returns to state off (so if the next one is ringing you would not recognize it).
The question now is, should i do it with an automation on my own (if binary_sensor.nuki_opener_ring_action_state = on for 5 seconds turn off) or should your automation do it, what do you think?
Second one, i pressed the unlock button on the opener card today 5 or 6 times before the state changed to ring to open, where do i have to look to check if my ha does a restcall when i press the unlock button, is it possible?
Mike