Nuki Card with Callback support (supports both Lock & Opener, it replaces the official integration)

[kalinadi (Adi Kalina)]

It was disabled as default, do you know if there’s a way to check if the port is blocked?

[alexdelprete (Alessandro Del Prete)]

@kalinadi

The bad news is that the “emulated hue” integration probably went wrong because nothing works with Alexa anymore

I don’t understand why enabling HTTP on HA would crack an integration: you are not disabling something, but opening something. I don’t know that integration: does it work on http or https? please show us the config of the integration so we can take a look. Did you check the logs for errors that might help debugging the problem?

UPDATE: sorry, I understand now, the emulated_hue integration requires port 80 in order to work with Alexa, but the NGINX HA addon explicitly disables use of 80 to be compatible with emulated_hue, from the docs:

[alexdelprete (Alessandro Del Prete)]

@mahikeulbody

No, you can have https access without NGINX. In my case I installed NGINX only to get callback working

No, you can have https-ONLY access, without a proxy like NGINX. NGINX (and other proxies) have become popular because they allow flexibility in the choice of the configuration, because they allow HTTPS and HTTP local access at the same time. Sure, you can follow a guide to make it work, but at the first problem, if you don’t have the necessary knowledge, you will have services not working and begging for help on forums. I always advice my non-tech friends to keep things very very simple, because you cannot always rely on “asking for help”, at least for important automations running in the house. That’s my approach at least: important automations have to be very reliable, not depend on the internet, and fully manageable by myself.

Many people underestimate how much you start depending on home automation after a few years, and you realize this when something stops working.

@mahikeulbody

It was a joke, of course

I know, I was just specifying my point of view.

@mahikeulbody

A big thank for the people who will not lose the opportunity to use your nice work because ignoring the workaround.

I don’t think someone would stop trying to use an integration because they read (HTTP only). They would ask for help, obviously. But no problem, I understand your point of view, but please understand mine, I know what can happen in these threads after some time: they become full of things not related to the topic.

Ciao,

Alessandro

[alexdelprete (Alessandro Del Prete)]

Nuki Card v7.0 released.

From the changelog of the 1st post: “automated bridge callback configuration and enforcement (with persistent notification) (super-super-easy installation), optimized some code, renamed some sensors, unified nuki secrets url variables”

Please read the paragraph in the middle of the post that describes the new automatic callback configuration process. Note also that secrets config variables have been changed and optimized. I could remove the HA internal URL variable if I find a way to retrieve it from some HA internal variable/sensor/etc., but I still didn’t find out if it’s possible, if someone has info about it, let me know, so we could optimize that too.

Please let me know if the automatic config of the callback works for you, you can test it by removing the callback from the bridge, wait for the rest polling sensor to activate (max 120s) and then reconfiguration takes place, alerting you with a persistent HA notification and a specific sensor that I put on the card:

Ciao,

Alessandro

[kalinadi (Adi Kalina)]

Update
Emulated hue was probably updated recently, causing the problem I had.
Solution here: https://community.home-assistant.io/t/how-to-efficiently-flush-emulated-hue-solved/201480
@alexdelprete thanks again for the great integration! already moved to 7.0
BTW for me it worked 100% only after a full shutdown and restart…
Maybe it’s just happened to me, but if not it worth a comment on the installation steps…

Hi,
Thanks for your answer.
Port 80 disabled on Nginx add on means it stays open isn’t it?

[Sym0nd0 (Sy)]

So, embarrassingly I have to admit that I’d misunderstood about the need for NGINX and that without it the integration falls back to polling, hence the large delay in the state changing. I set NGINX up and now it only takes a couple of seconds for the state to change in HA, which is about the same amount of time that the Nuki app itself takes.

[Sym0nd0 (Sy)]

Just updated to v7, tested (including the callback regen) and all working perfectly. Awesome work, thanks!

FYI, the lovelace card, in your OP, has too many indents and errors out.

type: entities
entities:
  - 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_last_activity
  - entity: sensor.nuki_id
  - entity: sensor.nuki_friendly_name
  - entity: sensor.nuki_device_name
  - entity: sensor.nuki_bridge_lock_bt_state
  - entity: sensor.nuki_bridge_lock_bt_rssi
  - entity: sensor.nuki_lock_battery_level
  - entity: sensor.nuki_lock_fw_version
  - entity: sensor.nuki_bridge_fw_version
  - entity: sensor.nuki_bridge_wifi_fw_version
  - entity: sensor.nuki_bridge_wifi_connected
  - entity: sensor.nuki_bridge_cloud_connected
  - entity: sensor.nuki_lock_battery_critical_state
  - entity: sensor.nuki_keypad_battery_critical_state
state_color: true
title: Nuki Card

[alexdelprete (Alessandro Del Prete)]

@kalinadi

@alexdelprete thanks again for the great integration! already moved to 7.0
BTW for me it worked 100% only after a full shutdown and restart…
Maybe it’s just happened to me, but if not it worth a comment on the installation steps…

Thanks for the feedback. A full shutdown/restart is not needed, probably yours is a specific case, that’s why I can’t put it in the installation notes, only universal/general notes there, not specific cases.

@kalinadi

Thanks for your answer.
Port 80 disabled on Nginx add on means it stays open isn’t it?

A port is open when an application/service opens it, otherwise it doesn’t exist. NGINX HA addon has been configured to not use port 80, that means it is available for other apps to use it, but if no other apps use it, it’s not open. Clearer now?

[alexdelprete (Alessandro Del Prete)]

@Sym0nd0

So, embarrassingly I have to admit that I’d misunderstood about the need for NGINX and that without it the integration falls back to polling, hence the large delay in the state changing. I set NGINX up and now it only takes a couple of seconds for the state to change in HA, which is about the same amount of time that the Nuki app itself takes.

Nuki Card doesn’t fallback to polling. It takes updates about Nuki from polling REST sensors (120 secs) AND a template trigger sensor (callback from the bridge). The REST sensors update slowly, because they poll for data, the trigger sensor is immediate because the bridge calls HA for updates.

Unfortunately, like I wrote in OP notes, the bridge only works on HTTP. For people who configured HA in https only mode, NGINX is required to have HTTP available locally. There’s a specific note about this in OP.

[alexdelprete (Alessandro Del Prete)]

@Sym0nd0

Just updated to v7, tested (including the callback regen) and all working perfectly. Awesome work, thanks!

Thanks for the feedback, glad it’s working for you.

@Sym0nd0

FYI, the lovelace card, in your OP, has too many indents and errors out.

There was 1 indent column more because I have it inside a vertical-stack. Easy to fix it by untabbing 1 column. Anyway, I removed it now.

[jezinke (Joachim Zinke)]

Hi, I just tried to install the actual package from post 1 and get the following error when checking congig: expected dictionary for dictionary value @ data[‘packages’]
Any help on this? Thank you

[Sym0nd0 (Sy)]

Have you updated your config to include the packages location?

@alexdelprete

n configuration.yaml, under the homeassistant: section you reference the directory containing all packages:

[jezinke (Joachim Zinke)]

This what I have in my configuration.yaml :
homeassistant:
allowlist_external_dirs:
- ‘/config/tmp’
packages: include_dir_named packages/
It should work because when I put a # ahead the line the error disapears. Thanks for taking care.

[BeardedConti (BeardedTinker)]

@mahikeulbody

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.

You got it wrong - this is used only to communicate with HA. No mater if you access HA internally or externally. And we use ngnix for external access - that way you I don’t need to publish ports outside, traffic is HTTPS, while keeping http internally. A lot of webhooks work only with HTTP traffic, so that’s one way of going around this issue.

[alexdelprete (Alessandro Del Prete)]

You are missing indents in your homeassistant section, and you are also missing the exclamation mark before include_dir_named clause.

I showed a screenshot in the first post, shouldn’t be too hard to replicate it:

Show me a screenshot of your homeassistant section from config.yaml, or paste it correctly here, using the appropriate code on the toolbar (the icon </>).

[alexdelprete (Alessandro Del Prete)]

Thanks for your post, I had missed the PS.

[alexdelprete (Alessandro Del Prete)]

@mahikeulbody

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.

I had missed your PS when I answered: when users configure an integration with HA, they don’t access the integrated device directly, HA acts as the middle-man and is responsible for the communication to the device. So you can have https to HA from the internet, and HA communicating through http internally, to the integrated devices that are on the LAN/WLAN. This is true for every integration, and that’s one of the main features of HA.

For example, if you use Alexa and you have a device that has direct integration with Alexa through a native skill (through the cloud obviously, because that’s how Alexa works), if you use the same device with HA through an integration, best practice is that you disable the native cloud-based integration and you only configure it with HA, then you use HA to decide which devices Alexa can “see” through HA skill. So HA acts as a middle layer for all your devices, no matter where you access them from, locally, or the cloud.

I think this is what you missed about how HA works…so to answer your comment: users will still be able to access their Nuki safely through https to HA, and HA communicates with Nuki through http on the local network.

I hope it’s clear how it works now.

[mahikeulbody]

You got it wrong […]

I think there is a misunderstanding about what I tried to say (may be it is my fault). Some people use only https access for both external and internal access, without NGINX. It is a simple way to have ever a secure access without any complication. To discuss if it is a good way or not to do is OT. Some of them ask how to add http access (without removing https) in order to be able to use the Nuki callback method. It is the reason why I suggested to alexdelpetre to add a mention to NGINX solution and he was kind enough to do it even if he was reluctant (with some reasons I can understand).

So my “by the way” has to be understood from the point of view of users using only https (without NGINX) : if you are not aware of NGINX and you want use the Nuki callback solution you should restrict HA access only to local network (since http access for external access is a very bad idea) and it seems to me that many people want to be able to lock/unlock from outside home (not to mention others automations).

I hope I managed this time to be clearer and that we could back to the main subject : Nuki Card, thank to alexdelpetre.

[alexdelprete (Alessandro Del Prete)]

Clearer now, but the point is that if someone wants to access automations from the internet through HA, they should focus on securing that channel through https, not the local access. That’s why many users rely on Nabu Casa by the way, to not have to configure NGINX, or proxies like it, and benefit from secure cloud access AND freely use http local access.

[mahikeulbody]

Clearer now

I am happy

@alexdelprete

[…] but the point is that if someone wants to access automations from the internet through HA, they should focus on securing that channel through https, not the local access.

It is exactly my opinion (even more than you since I used https also for local access before using NGINX), so I don’t understand in which way this “but the the point is[…]” is related to my post.

But it is not important, have a good night.