Can’t wait 
Will also use it as soon as the opener support is there - thank you for your work 
@madface @stefancvetkovic @beardedconti @floo @joerg @saeris @jero537 @Harry2 @Lucan:
I need to beta-test v11, will you be able and willing to test it to solve the inevitable bugs?
Thanks for any help.
If you don’t get anyone by Monday, sure thing Currently on a trip without access to the Nuki heh
Let’s hope nobody else accesses the Nuki while you’re away. 
I’ll post the beta later…I don’t use the opener (but I got one borrowed from a friend), so I need feedbacks from people who use it extensively.
Thanks for your help.
Yup, I can test it. Just a note for you: I didnt connected some wires for opener, so I can open the door, but openning the door on a interphone button, it’s not working yet beacuse of gardware installations itself…
Just give me which version should I get…thanks!
I implemented all lock/unlock actions available for the opener, it will be up to testers to tell me what works and what doesn’t, since I don’t use it.
I will publish the v11-beta in the thread later, with a link to gist…
Thanks.
1 Like
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.