Alessandro, yes it’s very easy, I just understand at te begining there is a packaged version, and so I tried like your first post, with curl etc.
Also I first use the token from web nuki and not from the bridge app
I’m not a python developer, and not a HA expert, otherwise I would’ve already done it.
I made only one HACS component, for ABB inverters, but I basically modified an existing component, rewriting 80% of the code. 
Anyway, it’s in the bucket list, but since there’s a package version now, and the configuration only requires 3-4 secrets, it’s not high-priority. Furthermore, the official integration should be out sooner or later, and I hope they will include at least the callbacks for door/lock. I don’t think they will include all system’s sensors unfortunately.
curl is necessary to configure the bridge for the callback. but I could automate that too, I’m thinking about it, so users don’t have to do it manually.
Ok, I’ll see if I can clarify better the difference between the Nuki token and HA long-term token. Thanks.
UPDATE: I updated the first steps and added a note explaining the difference among the two tokens.
1 Like
Hi @alexdelprete
Thanks for the great integration and well explained how to…
I followed your steps and got it working in minutes!
only issue I’m having now is a 1-2 minutes delay for every state change 
I’m guessing it might be related to the fact I’m using “DuckDns” and it means my HA uses https protocol for that reason.
on the other hand all entities do work and I get all the correct info, so the Nuki Bridge does send it somehow right?
If you have any idea of what could cause this kind of delay, and of course any suggestions to resolve it…
Thanks again,
Adi.
Ciao Adi, nice to meet you. 
If you are seeing 1-2mins, it means you are not receiving the callback from the bridge. Please take a look at the last posts I exchanged with @andrej33, start from this and follow the discussion: Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration) - #365 by alexdelprete
First of all you need to make sure you have configured the callback on the bridge with the long-term token generated in HA. Then you need to be sure you are not looking at the official integration sensor, like it happened to some users. Did you follow the installation steps and verify each one of them before moving to the next? Start from there.
I’m pretty sure the problem you are facing is a simple one, you just need to focus on each step at a time, in the end you’ll have the expected result.
Is there any alternative to get the callback if your HA is only accesible via https? How can i enable HA to also be accessible localy by http and from outside the network via https?
if it is ONLY accessible through https, since the bridge only supports http, you can’t use the callback.
You need to use NGINX Home Assistant SSL proxy: “typically used to forward SSL internet traffic while allowing unencrypted local traffic to/from a Home Assistant instance.”
This is off-topic for this thread, but you will find a lot of threads in the forum regarding this configuration. Check this post, as an example.
1 Like
As said by alexdelpetre, you have to use NGINX Home Assistant SSL proxy addon. I use it with my own domain with this configuration :
domain: hass.mydomain.fr
certfile: fullchain.pem
keyfile: privkey.pem
hsts: max-age=31536000; includeSubDomains
cloudflare: false
customize:
active: false
default: nginx_proxy_default*.conf
servers: nginx_proxy/*.conf
1 Like
May be it would be a good thing to add a warning about that into your initial post.
It’s there since the beginning: " Please remember that the callback can be done by the Nuki Bridge only via HTTP. Unfortunately HTTPS is not supported."
Are there any news about integration of Nuki Opener via callback?
Would love to see that
Indeed, sorry ! So may be you could complete the sentence with something like :
Unfortunately HTTPS is not supported. You can workaround this Nuki bridge limitation using NGINX Home Assistant SSL proxy addon.
If I do that, we’ll have to also support NGINX configuration in this thread. It’s up to the users understanding what’s required to support http only. I don’t want the thread to become too chaotic.
It’s up to the users understanding what’s required to support http only.
Many users with https access will stop to read this integration without to know there is a workaround. It’s a pity.
Others as mefistofelis will ask about that and someone will answer them, you cannot control that. Anyway, almost all users without https access will read only the first post, not the full thread. So I fail to understand why that could add chaos to this thread 
If I do that, we’ll have to also support NGINX configuration in this thread.
I don’t see why. Furthermore if it’s not you it could be someone else.
Well, since Italy team has beaten our best enemy (I’m french), do as you see fit 
I think a user who decides to implement NGINX for https access has the skills to understand that it’s possible to implement https only from the internet while leaving http access from LAN/WLAN.
I don’t want to control, but I also don’t want to encourage too many discussions on things that are not relevant to the integration.
the point is not who does it, but the potential confusion in the thread, that would discourage people from reading info regarding the integration.
I would do what I think is appropriate even if France won the tournament.
In any case, I added your note to the first post. Let’s see what happens…
No, you can have https access without NGINX. In my case I installed NGINX only to get callback working. I was not aware of such a solution until I discovered it by myself. And it is not only a matter of skills (I followed a guide to install https access), you still need to be aware that a solution exist.
About confusion in the thread, I think that is a false problem : at the opposite of a “classic” thread, almost everybody will read only your initial post and, in case of problem (or to thank you), will skip all posts to add theirs.
I would do what I think is appropriate even if France won the tournament.
It was a joke, of course 
In any case, I added your note to the first post.
A big thank for the people who will not lose the opportunity to use your nice work because ignoring the workaround. 
PS. By the way, are there really a lot of people using Nuki lock through HA without https access ? I mean, do they limit themselves to control the lock only when they are connected to their local network or, worst, outside but through http access ? It seems to me that this question is a big point to use this integration since many people want to be able to control the lock outside home.
Hello Allessandro,
I have started to create a package that will automatically register the callback url. For now I’m able to check if the callback url is resgisterd. In the package code the only thing you have to set is the internal ip address and port of your HA installation. In the upcoming days I will see if I can register the callback url at the NUKI.
#######################################################################################################################
### ###
### Input Texts ###
### ###
#######################################################################################################################
input_text:
ha_local_ip:
name: Home Assistant Local IP address
initial: <SET YOUR INTERNAL IP FROM HA HERE>
ha_port:
name: Home Assistant Local port
initial: <SET YOUR INTERNAL PORT FROM HA HERE>
nuki_bridge_webhook:
max: 1000
initial: !secret nuki_bridge_webhook
nuki_check_callback_url:
max: 1000
nuki_url2check:
max: 1000
#######################################################################################################################
### ###
### Input Boolean ###
### ###
#######################################################################################################################
input_boolean:
nuki_callback_url_registered:
#######################################################################################################################
### ###
### shell_commands ###
### ###
#######################################################################################################################
#shell_command:
# nuki_register_callback: curl -X GET 'http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/callback/add?token={{ states('input_text.nuki_bridge_token') }}&url=http://{{ states('input_text.ha_local_ip') }}:{{ states('input_text.ha_port') }}/api/webhook/{{ states('input_text.nuki_bridge_host') }}'
# nuki_check_callback: curl -X GET 'http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/callback/list?token={{ states('input_text.nuki_bridge_token') }}'
#######################################################################################################################
### ###
### Automations ###
### ###
#######################################################################################################################
automation:
- id: 'Nuki_check_callback'
alias: Nuki Check Callback
description: 'Nuki Automation to check the registered callbacks'
trigger:
- platform: homeassistant
event: start
condition: []
action:
- service: input_boolean.turn_off
target:
entity_id: input_boolean.nuki_callback_url_registered
- service: input_text.set_value
target:
entity_id: input_text.nuki_url2check
data:
value: >-
http://{{ states('input_text.ha_local_ip') }}:{{ states('input_text.ha_port') }}/api/webhook/{{ states('input_text.nuki_bridge_webhook') }}
- repeat:
count: >-
{{ state_attr('sensor.nuki_check_callback', 'callbacks')[-1]['id'] + 1 }}
sequence:
- service: input_text.set_value
target:
entity_id: input_text.nuki_check_callback_url
data:
value: >-
{{ state_attr('sensor.nuki_check_callback', 'callbacks')[(repeat.index - 1 | int ) ]['url'] }}
- choose:
- conditions:
- condition: template
value_template: >-
{% set url2check = states('input_text.nuki_url2check') %}
{% set callback_url = states('input_text.nuki_check_callback_url') %}
{{ url2check in callback_url and states('input_boolean.nuki_callback_url_registered') == 'off' }}
sequence:
- service: input_boolean.turn_on
target:
entity_id: input_boolean.nuki_callback_url_registered
default: []
- service: notify.persistent_notification
data:
title: Nuki callback url check
message: >-
Callback url is {% if states('input_boolean.nuki_callback_url_registered') == 'off' %}NOT {% endif %}registered.
mode: single
#######################################################################################################################
### ###
### sensors ###
### ###
#######################################################################################################################
sensor:
- platform: rest
scan_interval: 86400
force_update: true
resource_template: http://{{ states('input_text.nuki_bridge_host') }}:{{ states('input_text.nuki_bridge_port') }}/callback/list?token={{ states('input_text.nuki_bridge_token') }}
name: "Nuki Check Callback"
value_template: "OK"
json_attributes:
- callbacks
1 Like
Ciao.
you won’t believe it, but I spent the whole night (last night) to implement the autoconfiguration of the bridge. I’m testing some things before releasing it. I thought it would have taken 3-4 hours, instead it was harder than I thought, mainly because of some missing functionalities in REST commands (the response), so I had to find several workarounds unfortunately, but it’s working pretty good.
There’s one thing that’s bothering me: I needed to know the HA url, to pass it to the bridge, and I was convinced that the internal_url value in config.yaml was available through some system sensor/variable, instead it seems it’s not easy to access HA config items via templates/automations/yaml. They are available through HA API, externally.
I will share it as soon as I’m confident enough on the quality, thanks for your post, I appreciate it.
Alessandro
1 Like
Hi again,
So the problem was the DuckDns after all, My HA was accesible only through HTTPS…, I added the NGINX add-on as you advised @mefistofelis to do.
Good news is the Nuki Card works perfect now!
The bad news is that the “emulated hue” integration probably went wrong because nothing works with Alexa anymore 
I know its off this topic but I’ll apecciate any thought…
Try disabling port 80, under network, in the NGINX addon config.