Not working with https

[asetGem]

Hi,

I configured the integration on my HA instance, and it was working very well. Now, I would like to be able to access HA from the outside, so I started to secure it. I added ssl certificates, and I am now connecting via https://192.168xxxxx Since that, the Nuki Lock integration is not working anymore. Do I have to change something to specify that I am using this new protocol? Thanks

[alexdelprete]

Nuki Bridge doesn't support SSL. You have to configure HA to accept also http on the LAN side, otherwise it won't work. It's a hw limitation.

[asetGem]

But even when I skip nuki bridge (I'm just giving the web api token) it does not work. However, nuki web is supposed to accept https.

[alexdelprete]

Nuki web works fine, only the bridge doesn't support https.

If Nuki web doesn't work with https, you have configuration issues, either with the ssl or with something else. Did you configure the web token and the rest correctly? Here it works fine. Did you check the logs for errors? Please provide the logs and try to reconfigure it, but do a screenshot before submitting the configuration so we can double-check the parameters you are using. Also, check your internal_url and external_url parameters in HA, report them here.

If you have the bridge, it doesn't make sense to not use it just because you want to force SSL. Configure the SSL addon you're using to accept http on local network, if you want to keep using the bridge.

[alexdelprete]

Check also this thread: https://github.com/kvj/hass_nuki_ng/issues/42

Sometimes there are issues with the configuration of internal_url / external_url in HA. Since you managed those settings to configure the SSL, could be that you have some strange config in place.

[asetGem]

Here is my configuration:

When I press ok, I get the "success" message. However, after, I have this, and no device nor entity is created:

When I go to the logs, it is empty! Before I used https, everything was working perfectly, with this same configuration (regarding the web API).

I don't want to force SSL, I am just novice and followed the duckdns + let's encrypt instructions to be able to access HA from outside my network.

[alexdelprete]

In the screenshot, you filled the bridge IP field, and you put the https external_url of HA.

This doesn't work, as I told you, because the bridge can't call HTTPS URLs.

In order to have HA available via http internally and https (duckdns) externally is to use the NGINX Home Assistant SSL proxy, read here: https://community.home-assistant.io/t/nuki-card-with-callback-support-supports-both-lock-opener-it-replaces-the-official-integration/311932/390?u=alexdelprete

[asetGem]

Ok thanks! I will install this add-on, so that I can have access to the bridge API also :)

I am only missing one thing, but I may open another issue for that: is it possible to get the state of the nuki smartlock button ? Like firing an event "button pressed" or "button pressed twice" when somebody hits the button, in order to start an automation on pressed, and not after the action due to button pressed is done.

Thanks again for your help

[kvj]

is it possible to get the state of the nuki smartlock button ?

Most likely no, but let me test it

[kvj]

In the screenshot, you filled the bridge IP field, and you put the https external_url of HA.

Theoretically it doesn't matter. The "Bridge token" field is empty - nuki_ng should ignore bridge stuff.

[alexdelprete]

In the screenshot, you filled the bridge IP field, and you put the https external_url of HA.

Theoretically it doesn't matter. The "Bridge token" field is empty - nuki_ng should ignore bridge stuff.

He says he got a Success message after he submitted. Anyway, I think it would be better to do some kind of validation of config_flow and provide a status message instead of a simple success/failure, mainly for debugging all these configuration issues that are mostly due to users not knowing certain things (I will check to improve the doc in the repo).

For example, we shouldn't accept https in HA url when using the bridge. When a user puts the IP of the bridge, he MUST provide the token. If we autodetect IP of HA etc., can we autofill the config_flow fields? Things like this...I think we would have half of the open issues we have. :)

[kvj]

If we autodetect IP of HA etc., can we autofill the config_flow fields?

We do that now. HA url and bridge IP are both auto-filled.

I think it would be better to do some kind of validation of config_flow

Not many options are available though. The field is either mandatory or optional.

we shouldn't accept https in HA url when using the bridge

We don't accept it now, but only when bridge token is filled. Otherwise the integration ignores the input of two other fields.

I agree that the current config flow is quite confusing because we put all the possible field into a single list and try to figure out what user actually wants

[alexdelprete]

We do that now. HA url and bridge IP are both auto-filled.

so we can validate if it's an https url and warn the user that it doesn't work, right?

The field is either mandatory or optional.

got you, but can we validate a field based also on other fields' contents?

We don't accept it now, but only when bridge token is filled. Otherwise the integration ignores the input of two other fields.

I understand, but there's no feedback to the user, so they get confused and issues are opened.

I know you're busy, appreciate all your effort on this integration.

BTW: I'm in a small beta group of Nuki for MQTT implementation. We managed to convince the devs finally to implement support for MQTT, that will solve A LOT of issues we're facing now. Hope you'll like it. The first beta has not been released yet, I'll keep you posted.

[kvj]

BTW: I'm in a small beta group of Nuki for MQTT implementation

That's a very funny coincidence. I've been working on a similar stuff in my spare time and (mostly) re-implemented bridge and web API functions using ESP32 platform and Nuki bluetooth API and MQTT. I was about to ask whether someone is interested in this direction or not.

It's quite functional and stable, it also uses HA MQTT discovery protocol, so no custom integration is needed. In my test setup I have no Bridge, no nuki_ng just a tiny m5atom device and everything mostly works.

[alexdelprete]

re-implemented bridge and web API functions using ESP32 platform and Nuki bluetooth API and MQTT. I was about to ask whether someone is interested in this direction or not.

Basically, you're creating what we asked Nuki devs: implement MQTT in the Nuki Bridge, so it will basically act as a Bluetooth-MQTT gateway. :)

This is the latest spec available: https://developer.nuki.io/uploads/short-url/tEQwbNLIuawOgr8ItMT5jLr2hYB.pdf

They came out with the first beta firmware implementing that spec, but only for SL3P devices for now, so I can't test it. Will have to wait for the beta fw for the bridge. :)

it also uses HA MQTT discovery protocol, so no custom integration is needed. In my test setup I have no Bridge, no nuki_ng just a tiny m5atom device and everything mostly works.

This could actually be very interesting because I don't know if Nuki devs will implement HA MQTT discovery (we asked them), so if they don't, having an alternative bridge could be a good option.

Does the project require soldering or it's just a device ready to be programmed and it works? In that case if you give me some details I'd be interested to try it. :)

[kvj]

This is the latest spec available

Ok, pretty basic stuff. Status + lock action. I wouldn't expect Nuki devs. will expose anything extra than bridge can do now. Actually it can do much more via the Bluetooth API, basically anything you can do via the App and/or Web API should be available to bridge.

Does the project require soldering or it's just a device ready to be programmed and it works?

No, no soldering. Just any cheap ESP32 board from Amazon, USB cable and PlatformIO installed should do the job. Let me publish something and I let you know. For now only the Lock 2.0 / 3.0 is supported, the Opener can be supported also, the API is 95% the same but I have no Opener, so no motivation to work on it :)

Here is what's already exposed, and some data is also writable:

[alexdelprete]

Ok, pretty basic stuff. Status + lock action. I wouldn't expect Nuki devs. will expose anything extra than bridge can do now.

That is what has been asked them: Bridge API through MQTT. If you have suggestions on what could be interesting to be added, let me know so I can try to ask to modify the MQTT API. :)

Just any cheap ESP32 board from Amazon, USB cable and PlatformIO installed should do the job. Let me publish something and I let you know.

I understand, ESP32 has Wifi and BT embedded, so any board with ESP32 is fine. Let me know, I'm very interested in this project. It's a better version of the bridge. Hope the BT signal is strong enough to be located not very near the lock.

the Opener can be supported also, the API is 95% the same but I have no Opener, so no motivation to work on it

I tried to find my opener, it's in one of my old IT gear boxes, my wife helped me fix the confusione but now I can't find where the opener ended. When I find it, I can send it to you so you can develop and test it. :)

[Mincka]

That's a very funny coincidence. I've been working on a similar stuff in my spare time and (mostly) re-implemented bridge and web API functions using ESP32 platform and Nuki bluetooth API and MQTT. I was about to ask whether someone is interested in this direction or not.

There are hidden gems in this GitHub issue. 😍

I would be very interested to have access to this implementation, having myself a spare M5 ATOM Lite. Is it related or based on this project? https://github.com/technyon/nuki_hub I just discovered it, and it seems similar to your project. It looks very promising, and it can impersonate an app in the latest version so you can also keep the poor hardware hub.

There's also this one but unrelated to MQTT https://github.com/I-Connect/NukiBleEsp32 I also had a look at https://github.com/dauden1184/RaspiNukiBridge (based on https://github.com/jandebeule/nukiPyBridge)

[alexdelprete]

There are hidden gems in this GitHub issue.

Your post is actually a gem. It has been a while I didn't look at alternative projects for Nuki.

Nuki Hub seems perfect, it also supports HA MQTT Discovery. I'll wait until Nuki releases its official MQTT support, and if I don't like it, I'll probably switch to Nuki Hub. :)

Is there a sort of M5 ATOM Lite with the physical format as the Nuki Bridge (with the embedded AC plug)?

UPDATE: I ordered this, will be shipped in 2 weeks...let's see how it works out.

@kvj: Nuki Hub seems to be exactly what you are developing. Did you also check NukiBleEsp32? That could practically be used in an alternative Nuki Hub project for all communication with the lock.

[kvj]

@Mincka @alexdelprete

Indeed. https://github.com/technyon/nuki_hub looks very good code quality wise. I haven't gone that far, even though the functions are quite similar. I will definitely compare the performance/stability/etc and happy to start using nuki_hub and/or contribute. After a quick check, MQTT discovery can be improved a bit. Also, exposing auth entries and/or keypad entries as enities could be handy.

Is there a sort of M5 ATOM Lite with the physical format as the Nuki Bridge (with the embedded AC plug)?

No I don't think so, I use small USB AC plug + 10cm usb-c cable + m5atom

[Mincka]

I can confirm nuki_hub is easy to use. I tried with an Espressif ESP32-DevKit. It looks like it supports only one lock for now. Indeed, I would be very happy to see more things discovered in HA, there's an open issue about this already.

You may be both also interested in this project if you use, or would like to use ESPHome. https://github.com/uriyacovy/ESPHome_nuki_lock/

This project is less "complete" but is going to support multiple locks very soon. I am also going to test it since it would be also great to share the ESP32 with other modules of ESPHome.

[alexdelprete]

You may be both also interested in this project if you use, or would like to use ESPHome. https://github.com/uriyacovy/ESPHome_nuki_lock/

Nuki Hub seems more complete in terms of functionality, just missing some things that Konstantin mentioned in his last post. In terms of performance, maybe esphome is faster, but MQTT decoupling allows to debug issues better, at lease in my experience. :)

What I actually was thinking is asking HA devs if Nuki support (through NukiBleESP32?) could be directly integrated in the core. They seem to like Bluetooth a lot in latest versions, there's a lot of hype around it. I will write a post in WTH section of HA forum. :)

The only issue is that that library is not in Python...

[alexdelprete]

I will definitely compare the performance/stability/etc and happy to start using nuki_hub and/or contribute. After a quick check, MQTT discovery can be improved a bit. Also, exposing auth entries and/or keypad entries as enities could be handy.

Let me know what you decide, right now I like Nuki Hub, but your technical judgement is needed to appropriately assess the decision. Would be perfect if you can contribute/PR Nuki Hub, also taking into account that you're very busy usually. :)

After a quick check, MQTT discovery can be improved a bit.

What's missing in discovery?

Also, exposing auth entries and/or keypad entries as enities could be handy.

Agreed, all the web integration, etc. we have in the component. :)

[alexdelprete]

I was also thinking: can we hack the hw of the bridge? I mean, open it, and replace current board with a better ESP32 based one with better software? Because the form factor is cool, square with the plug, the problem is the inside. ;)

[kvj]

Let me know what you decide, right now I like Nuki Hub, but your technical judgement is needed to appropriately assess the decision.

Nuki_hub is good. I was able to compile and setup it using the same M5Atom device. The performance and stability is the same, mainly constrained by the ESP32 hardware. I'm thinking about opening some PRs to the original project to proposes a number of improvements. The orverall approach exposing the data via MQTT isn't well defined there

[alexdelprete]

The performance and stability is the same, mainly constrained by the ESP32 hardware. I'm thinking about opening some PRs to the original project to proposes a number of improvements. The orverall approach exposing the data via MQTT isn't well defined there

This is EXCELLENT news Konstantin. :)

I'm sure you'll improve the project with your knowledge and experience done with Nuki APIs and HA. I noticed the entities don't have unique ids and all the web api sensors are missing.

Meanwhile, I opened the first issue there: don't enable Keypad Control, it messes up everything, I was getting crazy.

Thanks @Mincka for letting us know about this project.

[platini76]

Mincka

someone can explain me how to use technyon/nuki_hub/ with nuki_ng and retrieve api bridge api token ?

[alexdelprete]

Mincka

someone can explain me how to use technyon/nuki_hub/ with nuki_ng and retrieve api bridge api token ?

Nuki Hub replaces Nuki Bridge and Nuki NG.

[platini76]

Mincka

someone can explain me how to use technyon/nuki_hub/ with nuki_ng and retrieve api bridge api token ?

Nuki Hub replaces Nuki Bridge and Nuki NG.

I wrote you on discord... (in italian)

[dtill]

I was also thinking: can we hack the hw of the bridge? I mean, open it, and replace current board with a better ESP32 based one with better software? Because the form factor is cool, square with the plug, the problem is the inside. ;)

fun fact: the nuki bridge seems to host already a ESP-WROOM-02 chip for WIFI + a Cypress CY8C4248LQI-BL483 chip for Bluetooth according to this teardown-article: (https://314159.xyz/post/nuki-smart-lock/).. maybe some day we see a custom firmware for the original Nuki Bridge. :)))