Open for the lock? That would mean unlatched probably, because there’s no open state for the lock in the Bridge API.
No I meant for door state. Unlocked for lock and open for door state are the only “unlatched-like” things that I see.
probably another stupid question here…
I can’t find anymore the unlatch option and i am just able to unlock but not unlach. I am sure I am missing something… but where?
f
When using the standard lock entity in Lovelace UI you only can select Lock & Unlock. Unlatch is not available in the UI.
I also was confused by this in the beginning.
@alexdelprete answered my question as follows
But you can use the action lock.open to unlatch the door (instead of lock.unlock). I simply made button cards on my lovelace UI that call the lock.open service.
First of all THANK YOU @alexdelprete for NUKI CARD and @kvj for custom components. I was using Nuki Card (some old version), now I wanted to update to newer version and I’m missing what I should remove because I did not find “old version install info”. After I updated to version 11 then I discovered there is Custom Component with HACS. So I have to uninstall Nuki Card again and tried to follow instructions from here GitHub - kvj/hass_nuki_ng: Better support for Nuki devices in the Home Assistant. Unfortunately install info is obsolete too.
My suggestion is: If Custom component is recommended now maybe first post of this thread should mention this BEFORE potential users will install it? What do you think @alexdelprete ?
And also installing hass_nuki_ng readme should be updated? For example: go to HACS, add new Custom Components using link to github repository, then click Download etc. What do you think @kvj ?
I understand that for you guys this is perfectly clear as experienced users/programmers. But for me it was lot of unnecessary pain (I’m just a little bit experienced user). And for beginners it impossible to do…
And again - THANK YOU GUYS !!!
1 Like
Hi everyone and thanks for the great work and support.
I have a problem from some months ago that made me switch from the official integration to the card and later to the custom component. Currently I have a SL v1, a bridge v1 and an opener (don’t know if they have different hw revisions)
From 3 maybe 4 months home assistant HomeKit integration started to push notifications everytime that the bridge is not responding. As bridge is the hw v1 I tried to remove the nuki web and reduce the queries to the minimum. I tried also to change the router and add an access point near to the bridge to remove the connection issues, but anyway it looses connection at least 2-3 times per day. I don’t really know if it is a 503 (because of v1) or something wifi related but everytime it’s happening it recovers in less than 1 minute. What annoys me is the push notification from HomeKit with the “door locked” 3 or 4 times per day.
Is there any possibility to prevent the notifications from the state change transition unavailable → locked?
or should I just upgrade to the bridge v2? Maybe the new white one is a v3??
Replace the bridge with a v3. The bridge v1 doesn’t even support correctly Bridge API v1.12.
That would be great, just happened to me because i was going to this topic to quickly. Others may follow when they looking for support of Nuki 3.0 (wich works perfect with GitHub - kvj/hass_nuki_ng: Better support for Nuki devices in the Home Assistant).
When I activate “permanent mode” on my opener, the lock state of the opener is “locked”. but “unlocked” would be correct (like it is for the “normal” ring to open). Any hint how to change that on the component?
Also is there any chance for a dropdown or something, where I can switch the mode (ring to open, permanent, nothing) for the opener?
When I tap on “unlock” at my opener, the door does not open, it seems to activate RTO, correct? How to change that?
Also there seems no possibility to open the door of the nuki lock (only unlock but not “open” / unlatch).
Thank you! 
Thank you @alexdelprete for your tireless support, dedication and insight in this forum.
Thank you @kvj for developing the next generation Nuki integration, the way it really should have been. It really makes a big difference for so many users! I’ll abandon the official Nuki integration now for your work!
One thing I noticed though is that the new integration is slower to catch door open sensor state changes than the old integration, which is slower than the Nuki Card Callback setup. I’ve done a little video to illustrate this.
One speculation I have is the order of callback URLs registered by the bridge. Maybe the bridge calls one after the other with a little pause? The new integration currently is in slot 3.
Thanks for your kind words. Actually lately I’ve not been very present…life took over a little bit. 
Keep always in mind that the Nuki Bridge is a really low-powered hardware, not up to the task. It will call all the urls configured in the callback list, but since it is sluggish, it will do it slowly, and maybe in the fw there’s also some fixed delay. So if I were you, I would move the nuki_ng callback to #1.
Maybe @kvj could also implement this in the component: reordering the list in case there are other callbacks defined: read the others, delete them, register nuki_ng’s callback and then add the other 2.
That is possible, but do we have the evidence that changing the order helps?
I know for sure that the bridge calls the 3 sequentially…and since that piece of crappy hardware is slow, I can assume calling 2 urls before ours introduces at least 2 secs of delay.
@kongo09 can empirically demonstrate my theory, I hope I’m wrong obviously.
I can also ask a specific question to Nuki dev team, if needed…
I’ll change order manually and will observe. I’ll share any findings here.
1 Like
One question: with Nuki Card, and the same 3 callbacks on the bridge, it was faster? Because that would mean it’s not the number of callbacks before…
Somehow I messed it up now. I removed all callbacks manually, then recreated the nuki_ng one in slot 0. With that one being the only callback, there is still a lag of up to 10s for the state change to show in HA.
I then restarted HA and the Nuki Card recreated its own callback link. However, it doesn’t seem to work. I don’t get any state change in HA anymore. The binary_sensor.nuki_bridge_callback and binary_sensor.nuki_opener_bridge_bt_state both say connected and the sensor.nuki_bridge_callback_list shows the correct data. Not sure what’s going on. I also removed the webhook and created a new one, let the Nuki Card update the callback but it still doesn’t work. I’m sure I miss something obvioius.
Update: sorry, I cannot test it. I have now completely removed the Nuki Card setup with all associated entities, the webhook and the bridge registration from the system and then started from scratch. The webhook update is just not coming through. I don’t know why but then again with the new integration working, I feel I’m spending too much time on the old setup.
I noticed in the manifest of hass_nuki_ng the iot_status local_polling. Does it really poll? That would explain the delay I notice. But with the webhook it should be local_push ?
I think you are running Nuki Card, the official integration and Nuki NG all together. Poor little bridge…
You should’ve removed Nuki official integration and also Nuki Card totally before installing Nuki NG component. You should remove ANY other component that accesses the Nuki Bridge. Only one has to access the bridge. I even uninstalled Nuki app.
The callbacks are working fine, it’s a specific problem you are facing, clean up everything, also the component, delete all callbacks from the bridge, and start from scratch, from a clean situation. It will work…
The component does also polling. But that would mean losing every benefit respect to the official integration.
Hi,
Is there any option to determine if the door is opened by a (specific) Keyfob?
Thanks,
Rien
Hi,
no, unfortunately there’s no function in the APIs to determine how it has been unlocked/opened.