I already replied here: Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration) - #981 by alexdelprete
Ok done. deleted the old file, deleted the lovelace card, deleted all the entities, restarted HA, created thr new file from the new beta. remade the lovelace card and it showed everything correctly and when i pressed the “Unlock” nothing happens and right after that fir FW version again becomes unknown… this time the lock didnt react at all. In the last version it always worked after a fresh HA restart… strange.
can you show me the lovelace card? want to see which sensors are unknown. I think it’s the /info command that is not processed correctly by the bridge, like in your previous logs. Check the HA logs also now. Let me know.
Confirmed: the /info command is not working. But you told me that when you restart, the first time, you see everything correctly, so the /info command is processed normally.
All the errors you see in the log are due to the fact that variables are empty because the /info command hasn’t been processed. Can you double click this error and show me the details? I want to check the Status Code error.
btw, would you be so kind and delete my email address from the forum? dont want all the bots to scan it and spam me later thanks a lot…also deleted it from my post.
The usual suspect: error 503. It’s the bridge that is not available, it receives the command but it’s busy from a previous command and it throws error 503.
ok thanks. so the bridge is really the problem. will talk to NUKI folks…
it’s the same problem we faced at the beginning of the developement of the Nuki Card. We solved 95% of the 503 errors implementing a queue mechanism with some delays. It has been working pretty good since then for everybody I know. What I think, in your case, is that v1 HW is less powerful than v2, so probably it needs more time to process commands, and it probably requires some fine-tuning.
Can you issue these commands from terminal?
curl -X GET ‘http://bridge-ip:8080/list?token=xxxxx’
curl -X GET ‘http://bridge-ip:8080/info?token=xxxxx’
curl -X GET ‘http://bridge-ip:8080/log?token=xxxxx’
Wait 5 secs between each command, and then paste the logs of all 3 here. Thanks.
Hi,
Just stopping here to thank you for this integration.
Received Nuki, 1h later, it was all working, the longest was to actually install it physically !
Great work !
1 Like
That’s not entirely true: the bridge has limitations, but you can adapt the software to make it work. Reality is that we’re stretching HA automation features, a custom component should be developed, so that you can fine tune all communication with the bridge, something I can’t do now with the REST commands/sensors I’m using. I can’t even check the status code of the REST call.
So I wouldn’t tell him: the bridge is not working. I’d tell him that the bridge could be designed to be very much easier to integrate.
Understood. Will relay accordingly and will request a call with you…
1 Like
Thank you for the feedback, much appreciated, glad it’s working fine for you. v11 is coming out in a few days, once I receive feedbacks from beta-testers. If you want to test it: Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration) - #961 by alexdelprete
Mike, everything’s working fine in the code, the issue is that the bridge is taking 12-14 secs since it receives the lock/unlock command for the opener, to when it issues the callback. I asked Nuki devs to see if there’s some bug and if something can be done to improve this weird delay. The strange thing is that if you use the button on the opener to lock/unlock, the update on the Nuki Card is instantaneous.
Here are the logs: HTTP-LockActionStart is when it receives the command from Nuki Card, and HTTP-Post is when the bridge sends the callback to Nuki Card, notice the timestamps.
/lock
{"timestamp": "2021-09-02T23:51:16+00:00", "type": "HTTP-Post", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:51:16+00:00", "nukiId": "1CA57B22", "type": "SSE-KeyturnerEventReq"},
{"timestamp": "2021-09-02T23:51:16+00:00", "nukiId": "1CA57B22", "type": "BLE-ReadStates", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:16+00:00", "nukiId": "1CA57B22", "type": "BLE-Retry", "pairIndex": 1, "count": 2},
{"timestamp": "2021-09-02T23:51:16+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:16+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:51:15+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:51:15+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:15+00:00", "type": "BLE-EarlyDisconnect", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:51:15+00:00", "nukiId": "1CA57B22", "type": "BLE-Retry", "pairIndex": 1, "count": 1},
{"timestamp": "2021-09-02T23:51:15+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:15+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:51:14+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:51:14+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:14+00:00", "type": "BLE-EarlyDisconnect", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:51:14+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:14+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:51:13+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:51:13+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:13+00:00", "nukiId": "1CA57B22", "type": "BLE-StateChanged", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:12+00:00", "nukiId": "1CA57B22", "type": "BLE-Disconnected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:51:12+00:00", "nukiId": "1CA57B22", "type": "BLE-Disconnect", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:51:12+00:00", "nukiId": "1CA57B22", "type": "BLE-ConnectionTimeout"},
{"timestamp": "2021-09-02T23:51:05+00:00", "nukiId": "1CA57B22", "type": "HTTP-LockActionSuccess"},
{"timestamp": "2021-09-02T23:51:05+00:00", "nukiId": "1CA57B22", "type": "BLE-SendLockAction", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:05+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:05+00:00", "nukiId": "1CA57B22", "type": "BLE-GetChallenge", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:05+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:05+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:51:04+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:51:04+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:51:04+00:00", "nukiId": "1CA57B22", "type": "HTTP-LockActionStart", "action": "lock"},
/unlock
{"timestamp": "2021-09-02T23:42:13+00:00", "type": "HTTP-Post", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:42:13+00:00", "nukiId": "1CA57B22", "type": "SSE-KeyturnerEventReq"},
{"timestamp": "2021-09-02T23:42:13+00:00", "nukiId": "1CA57B22", "type": "BLE-ReadStates", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:13+00:00", "type": "SSE-PushNukisResponse"},
{"timestamp": "2021-09-02T23:42:13+00:00", "type": "SSE-PushNukisRequest", "count": 2},
{"timestamp": "2021-09-02T23:42:13+00:00", "nukiId": "1CA57B22", "type": "BLE-Retry", "pairIndex": 1, "count": 1},
{"timestamp": "2021-09-02T23:42:13+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:13+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:12+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:42:12+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:12+00:00", "type": "BLE-EarlyDisconnect", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:42:12+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:12+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:11+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:42:11+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:11+00:00", "nukiId": "1CA57B22", "type": "BLE-StateChanged", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:10+00:00", "nukiId": "1CA57B22", "type": "BLE-Disconnected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:10+00:00", "nukiId": "1CA57B22", "type": "BLE-Disconnect", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:10+00:00", "nukiId": "1CA57B22", "type": "BLE-ConnectionTimeout"},
{"timestamp": "2021-09-02T23:42:05+00:00", "nukiId": "1CA57B22", "type": "BLE-SendLockAction", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:05+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:05+00:00", "nukiId": "1CA57B22", "type": "BLE-GetChallenge", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:05+00:00", "nukiId": "1CA57B22", "type": "BLE-Retry", "pairIndex": 1, "count": 3},
{"timestamp": "2021-09-02T23:42:05+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:05+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:04+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:42:04+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:04+00:00", "type": "BLE-EarlyDisconnect", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:42:04+00:00", "nukiId": "1CA57B22", "type": "BLE-Retry", "pairIndex": 1, "count": 2},
{"timestamp": "2021-09-02T23:42:04+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:04+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:03+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:42:03+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:03+00:00", "type": "BLE-EarlyDisconnect", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:42:03+00:00", "nukiId": "1CA57B22", "type": "BLE-Retry", "pairIndex": 1, "count": 1},
{"timestamp": "2021-09-02T23:42:03+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:03+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:02+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:42:02+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:02+00:00", "type": "BLE-EarlyDisconnect", "nukiId": "1CA57B22"},
{"timestamp": "2021-09-02T23:42:02+00:00", "nukiId": "1CA57B22", "type": "BLE-TurnOnNotific", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:02+00:00", "nukiId": "1CA57B22", "type": "BLE-Connected", "pairIndex": 1, "bleHandle": "0001"},
{"timestamp": "2021-09-02T23:42:00+00:00", "type": "BLE-Connect", "macAddr": "54D272A57B22"},
{"timestamp": "2021-09-02T23:42:00+00:00", "nukiId": "1CA57B22", "type": "BLE-Connect", "pairIndex": 1},
{"timestamp": "2021-09-02T23:42:00+00:00", "nukiId": "1CA57B22", "type": "HTTP-LockActionStart", "action": "unlock"},
So when you activate RTO, and you see the updated state of the opener, ring and wait for the callback (you should see the bridge led blinking when it sends the callback), then after 5 seconds send the /list command and show the output, we need to monitor the ringactionState variable.
I’ll give a log today evening or tomorrow, maybe i’m late tonight.
But i would bet the ringactionState goes to false after a few seconds (could be 30), but as far as i saw the opener do not make another callback in this moment. So if there is no further change (rto on/off or something like that) the ringactionState stays on in HA even if it’s false already in the nuki. Could i be right?
Here are the logs:
First, rto activated, ringed the bell, the external gate opened and five seconds later:
[
{
"deviceType": 0,
"nukiId": 474412345,
"name": "Zuhause",
"firmwareVersion": "2.11.8",
"lastKnownState": {
"mode": 2,
"state": 3,
"stateName": "unlocked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 70,
"doorsensorState": 3,
"doorsensorStateName": "door opened",
"timestamp": "2021-09-03T18:40:22+00:00"
}
},
{
"deviceType": 2,
"nukiId": 484312345,
"name": "Opener",
"firmwareVersion": "1.6.4",
"lastKnownState": {
"mode": 2,
"state": 5,
"stateName": "open",
"batteryCritical": false,
"ringactionTimestamp": "2021-09-03T17:47:26+00:00",
"ringactionState": false,
"timestamp": "2021-09-03T18:40:38+00:00"
}
}
]
I have checked, the binary_sensor goes to on when ringing while rto is activated, but it seems it resets short after opening the external gate.
Here is 5 sec after ringing without rto:
[
{
"deviceType": 0,
"nukiId": 474412345,
"name": "Zuhause",
"firmwareVersion": "2.11.8",
"lastKnownState": {
"mode": 2,
"state": 3,
"stateName": "unlocked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 70,
"doorsensorState": 3,
"doorsensorStateName": "door opened",
"timestamp": "2021-09-03T18:40:22+00:00"
}
},
{
"deviceType": 2,
"nukiId": 484312345,
"name": "Opener",
"firmwareVersion": "1.6.4",
"lastKnownState": {
"mode": 2,
"state": 1,
"stateName": "online",
"batteryCritical": false,
"ringactionTimestamp": "2021-09-03T18:41:45+00:00",
"ringactionState": true,
"timestamp": "2021-09-03T18:41:39+00:00"
}
}
]
And short time after that:
[
{
"deviceType": 0,
"nukiId": 474412345,
"name": "Zuhause",
"firmwareVersion": "2.11.8",
"lastKnownState": {
"mode": 2,
"state": 3,
"stateName": "unlocked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 70,
"doorsensorState": 3,
"doorsensorStateName": "door opened",
"timestamp": "2021-09-03T18:40:22+00:00"
}
},
{
"deviceType": 2,
"nukiId": 484312345,
"name": "Opener",
"firmwareVersion": "1.6.4",
"lastKnownState": {
"mode": 2,
"state": 1,
"stateName": "online",
"batteryCritical": false,
"ringactionTimestamp": "2021-09-03T18:41:45+00:00",
"ringactionState": false,
"timestamp": "2021-09-03T18:41:39+00:00"
}
}
]
So in the nuki the ringActionState resets, but there is no callback when it turns off. If there is no other event from the opener it stays on in HA.
Mike
You could be right, and that’s a bug on their design. I’ll ask the devs.
It resets after 30s, as per Bridge API docs.
I don’t think this is a bigger problem, and i even think resetting the state should be done by an automation instead of another callback from the bridge. The bridge has so limited resources, it should only do the important things but that more reliable 
.
For now i solve this with a little automation like this:
- alias: Nuki - Ringstate zurücksetzen # setzt den Ringstate nach 5 Sekunden wieder auf off
description: ''
trigger:
- entity_id: binary_sensor.nuki_opener_ring_action_state
from: 'off'
platform: state
to: 'on'
for: '00:00:05'
action:
- service: python_script.set_state
data_template:
entity_id: binary_sensor.nuki_opener_ring_action_state
state: 'off'
The python script can be found here in the forum. Is it important for your automation also to set the input_text.nuki_bridge_opener_ringaction_state to false or can i ignore it?
Mike
Wrong approach, from a sw design perspective: the state of a device has to be determined and updated by the device, not by an automation that presumes the state of something. I can do it in the Nuki Card, but it would not be correct.
The problem is this: we have info from the last callback, few seconds after the ringactionState changes and probably the callback is not sent, so I need to think of a way to update nuki state info despite the callback, in that case. I would like to avoid periodic updates, but I’ll think about it…