Please do some in-depth tests when you can and let us know if it works or not…
too generic. I don’t have superpowers unfortunately, so can’t help if you only say: “it doesn’t work”. 
- Provide screenshots of the lovelace card you configured so I can see the status of all the sensors.
- Check HA log and report any error related to Nuki Card
Did you carefully read first post right? the lock/unlock actions have to be configured on the lovelace card, probably you have UNLOCK set for both lock and unlock actions. Pretty simple and common mistake.
Oh now that works haha. I didn’t understand the function of the dropdown menus and I was wondering why you didn’t have normal buttons for LocknGo & Unlatch.
Now I played around with it a bit and now not even the callback function isn’t connected anymore (but unlocking and locking still works).
When I’m looking at the notification, it doesn’t use the webhook token that I created and assigned:
The only error and warning I’m seeing in the logs at all are:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:268
Integration: Sensor (documentation, issues)
First occurred: 12:51:20 (3 occurrences)
Last logged: 12:51:20
Platform rest not ready yet: The request to ':///' is missing either an 'http://' or 'https://' protocol.; Retrying in background in 30 seconds
If I use the webhook token from the notification then the callback function shows “connected” but the states still won’t update.
Because making the buttons configurable covers all the use cases.
Callback has to be connected. Let’s see why it isn’t.
The token looks the same as the one you put in secrets, but you have 2 callbacks (id: 1 and id: 2, with a double slash that won’t work. You need to delete them.
In order to delete those wrong callbacks, you need to execute these two command from a terminal:
curl -X GET 'http://nuki-bridge:8080/callback/remove?id=1&token=xxyyzz'
curl -X GET 'http://nuki-bridge:8080/callback/remove?id=2&token=xxyyzz'
The Platform rest not ready yet error is ok, when HA starts the rest sensors are not ready yet because their config depends on other variables that are not initialized yet, you can safely ignore this error.
You have 3 callbacks on the bridge, while only 1 is needed, and two of them are not configured correctly because you put a trailing slash in the end of the url. Delete the 2 additional callbacks as instructed, the token looks ok.
Let me know…
It wasn’t the same but my bad for not showing the whole token. Anyway I deleted all 3 callbacks now and now it’s connected. But still no updates. And also there’s no notification anymore, but maybe that’s intended.
I checked the logs and there are still no errors.
I opened the door and inside the app it recognized the door opening but not in the card.
If the callback shows connected, it means the bridge is correctly instructed to send updates to HA. So it must receive the updates of the sensors.
The notification of the callback appears only when the Nuki Card modifies the callback configuration of the bridge, if the callback sensor shows connected, it won’t need to do any modification because it’s ok.
This is good.
The bridge has a hw/sw limitation of processing only 1 connection, if you use the Nuki Card you should avoid using other apps that communicate with the bridge, Nuki Mobile app included, otherwise the bridge will reboot or give errors 503.
So when you test the Nuki Card, make sure you disabled/uninstalled the HA official integration, and close the Nuki Mobile app on the phone.
When you open the door, the bridge executes the callback configured in its list, in your case it will send the update to HA with that webhook. So make sure the webhook token in HA is the same you configured in the secrets for the bridge. If it is the same, you MUST see instantaneous update of the door sensor on the card. If you don’t see it, the token or the url or something else is wrong in the configuration. Nuki Card is used by many users, and these basic things are know to work reliably.
Let me know…
To me it looks like the opener_state_id only jumps to 3 (twice) and not to 7 when opening with RTO:
Now my girlfriend came home and it jumped to 7, but the automation still did not fire:
Automation states “No traces found” so I can’t even have a look why it did not fire. Hmm something’s wrong again. What about using only state 3 to trigger the automation?
It jumps from 3 to 7 and then to 1 at 19:25 (more or less) two times, then it jumps to 3 and then 7 only at 20:05. Correct?
Sincerely, I don’t understand that graph. I expect that when you turn on RTO it stays at 3, it shouldn’t go to 1.
The other strange thing is that if you configured the automation correctly, when it goes to 7 it should trigger. Can’t understand why it triggers for 3 and not for 7. 
1 Like
I think I just found the bug. A little embarrasing. 
I did not check the yaml code but only the visual editor of the failing automation and so I overlooked that I still had the 3s from an earlier version:
trigger:
- platform: template
value_template: '{{ is_state_attr(''sensor.nuki_opener_state'', ''opener_state_id'', 7) }}'
for:
seconds: 3
I still don’t know why it did not go to 7 that one time but the last two times it worked as intended:
that’s why it didn’t trigger: it doesn’t stay at 7 for 3 seconds, but only for a brief moment, enough to trigger though.
Mike, the default mode is single, so there’s no need to specify it. Regarding the 30s delay, it’s not necessary because the trigger is not on ring_action_state but on the opener_state, and that shouldn’t trigger 2 times in a row.
Normally it should not, but you know the opener, sometimes this piece of hard and software is really strange 
Thats from one of my ring tests, sometimes it goes to 7 twice. I know you want to keep your automation clean, maybe a hint for people having problems with double unlatch would be nice.
I’m using it with it, and since 2 days (another real life report
) the external gate and the house door opens in the same moment after ringing. I’m really amazed and happy with it.
it goes to 7 two times in the same second or so, right? A delay of 2-3 secs should be enough.
Hello everybody,
Nuki contacted me (thanks to @asemev) to organize a videoconf with their product management in order to receive the feedbacks of this community regarding possible ideas on how to improve the product.
I have a few feedbacks and possible ideas, but obviously I’d like to transfer also your feedbacks/ideas, because I can’t possibly test or even imagine all use cases like an entire community could.
So please help me build a list of improvements/fixes/new features you would like to see implemented, and I’ll try my best to be as convincing as possible, then it’s up to them to decide obviously.
I think this is a great opportunity to be able to influence the developement of a product we use on a daily basis.
Please answer with a short list and, if needed, a short description of the use case or description.
Thanks a lot to all of you,
Alessandro
(cc: @madface @stefancvetkovic @beardedconti @floo @joerg @saeris @jero537 @Harry2 @Lucan)
6 Likes
Thanks for all your work, was able to test your card today - works like a charm. What would be greate, would be “direct actions” instead of having to choose what unlock / lock does.
So for the lock:
- Lock
- Unlock
- (unlock and) Unlatch (and if you choose unlatch it would be perfect if a popup asks you if you realy want to do so)
For the Opener:
- Activate Ring 2 Open
- Activate Permanent Mode
- “Open”
Will have a look if i’m able to do it on my own.
Regarding your question: Currently the main Problem is the weak bridge if you ask me. A more performant bridge would be great.
Thanks for your kind words.
I don’t think that’s a requirement for most people, at least not for me, I rarely change the configuration of lock/unlock, and the way it’s implemented, it covers all use cases because you can execute any possible action, although not by pressing a single button if you want a different action than the configured one.
If you want to do it, all you need is in this post (the ending part, specifically): Nuki Card with Callbacks (supports Lock & Opener, replaces official integration) - #972 by alexdelprete
I think 3 seconds should be enough also, we will see how good it works in pratice.
For the question to the nuki devs:
HTTPS on the bridge would be fine so we doesn’t have to use nginx proxy. But i would guess the bridge is too limited for that also (Althoug a better bridge would be nice also, i would buy it if its more reliable).
Second is that activating rto with a rest call is very unreliable, sometimes it takes me 2 or 3 restcalls until it is activated (even in the app sometimes it took more than one try). For now my automation tries it up to 5 times if it does not activate after 30 seconds, i think it could go better.
Last is the ringstate submitted when ringing and rto is activated, it comes after the state goes opening->open->online , it should also go to on when the first callback with opening comes.
As i see that there are more people who want to open the house door and external gate in the moment you ring outside, maybe they want to integrate that as a feature.
Mike
1 Like
Let me know how it works with 2-3s delay.
Noted.
That’s not my experience here, but that is exactly the problem: the bridge is so limited that it causes these kind of problems to some users (not everybody).
This is certainly a bug, unfortunataly I can’t reproduce it here because my opener is not connected, but I noted this and I’ll report it back to them.
Yes, I already noted this: implement a new lock action that basically allows to open both the Opener and the Smart Lock.
What I’ll try to propose them is:
- A more powerful bridge (v3, new hardware and firmware) since the cost is not cheap
- A discount or trade-in option for old bridge users for the upgrade to Bridge v3
- A well designed software bridge, not based on android like the one that they discontinued, but on Linux, that can be run on several platforms (Rpi, Docker, etc.)
- The bridge and the smartlock should support zigbee, BLE would be only needed for the mobile app. All available states/switches should be available through zigbee, so we could lock/unlock using switches
- The bridge firmware should support POST for commands/queries, not only GET
- The callback should contain ALL information about the system, not only a few things, and should trigger when an event happens or a command is received, but also periodically (every 120s) in case of no-events/no-commands, so we could totally avoid polling with /list and /info commands
- The bridge should support sending the callbacks via UDP broadcast, as an alternative to webhooks
The list is still growing…
Thanks a lot Mike.
2 Likes
Love all of your ideas, but i think many of them will stay dreams in the near future. But with the existing hardware and not a very big change for nuki would be:
- All informations in every callback and all 120s when nothing has happened
- POST instead of GET
- UDP
A new bridge would even be nice (if it is an advantage i would even buy it if there is no trade-in option), and the idea of a softwarebridge running on rpi or even docker on ha (like deconz for example) is really heaven.
I’m looking forward what they say!
Thanks a lot for your effort Alessandro!
If they ask you for ideas, you better dream big. If you don’t ask, you’ll never get anything.
They need to develop a new bridge, this one sucks. It’s their major shortcoming, all the rest is software, it can be fixed/improved easily.
Thanks Mike.
Another wish is to have a physical network port to connect to the network.