If anyone is interested in an alternative open-source solution to the official MQTT API implementation for SL2/SL3, please check the Nuki Hub project by @technyon. With a $5-10 ESP32 device, you’ll be able to have total control and management of the Smart Lock. This is expecially useful for Nuki SL2 users, who don’t have an MQTT solution and are forced to upgrade to SL3 Pro with Bridge.
You will have total local control of the lock via MQTT and also automatic integration (auto-discovery) with Home Assistant. All LOCAL, no internet dependency. Nuki Hub acts as a bridge, communicating with the lock via BLE API and via wifi (or ethernet) for MQTT.
Features:
For a list of features please refer to the github repository readme, it would be too long to duplicate it here.
Home Assistant integration:
For Home Assistant users: this is the device view in the MQTT integration, without configuring anything. NH leverages auto-discovery to configure the Smart Lock automatically in Home Assistant.
With other 3 people, we are actively helping the developer test and implement new functionalities. Please redirect all support issues to the github repo, this thread is mainly to inform all Nuki users about an alternative solution.
Thanks @Juergen for allowing us to inform users about this solution.
I love NUKI Hub. Decided to went that path for my SL3 and SL3 PRO.
Very happy meanwhile with it. Even today with the productive release of MQTT support in the official NUKI app I think „should I really switch (for the SL3 PRO)?“. I think I‘ll stay for now, even native MQTT might outperform (in terms of reaction times) the Bluetooth based NUKI Hub eventually.
I have no comparison to be honest. Sometimes it takes a moment especially for entity status in HA to update when locally controlled via button (or completely manually). Might also be on HA side.
Only read something from native MQTT users today talking bout „milliseconds“ so that’s why I mentioned it.
The difference comes from the different ways on how to feed the MQTT client.
The ESP module get’s a notification that there is something new, connects to the lock and fetches some infos (push & pull). The Nuki bridge works the same way. This can take some time (~1-2s) depending on the BLE connection state of the module when the event occurs.
The native MQTT API directly pushes events via MQTT when they happen in the firmware. Therefore it is almost instantenous and can send several events in short succession (e.g. transition states like “locking …”).
Whether you need this speed or not depends on the usecase. There is no general rule which thing is better, because there are other factors at play as well (e.g. WiFi draws more energy on the other hand SL3Ps WiFi also works as bridge for the Nuki App. The Nuki Hub has GPIOs …). Both have their right to exist. The Nuki Hub is certainly one of the best and most complete implementations of the Nuki BLE API out there and a fantastic piece of work.
Great to read this acknowledgement. I still believe Nuki Hub is what the Nuki Bridge should’ve been since the beginning. I hope one day we’ll see a Nuki Bridge 2, with an ESP32 and native MQTT and Home Assistant auto-discovery integration, so that also Nuki SL2 customers could use it, not only SL3 ones.
Maybe some hardware tinkerer could think about retrofitting the Nuki Bridge with an ESP32 device.
Awesome!!
Thank you very much for this complement. It is much appreciated.
Great that you guys are open minded and have shared the API with very good documentation. Without this and your help on this forum I would not have been able to create the underlying library ( NukiBleEsp32) Nuki Hub uses.
Kudos to all who have worked on this…
Very nice to see efforts of different people coming together in a nice, practical and usable tool like Nuki Hub.
Dumb question - can I also have my Nuki locks talking to the Bridge (as I currently have setup), so this Nuki Hub becomes an additional comms channel not a replacement?
I have not tried it but in theory I think yes, it uses the same bt connection and api as the app and both app and bridge can also be used on the same lock.
But not exactly simultaniously as only 1 device can have the bt connection with the lock (i think). One of the nuki developers should be able to confirm this.
The Nuki Hub is certainly one of the best and most complete implementations of the Nuki BLE API out there and a fantastic piece of work.
Thanks for your appreciating words @Juergen and thanks to @i-connect for writing the library that enables NUKI Hub to work. I like the fact that the API is well documented, I wish more companies were open like this. There are users now across all kind of home automation platforms, Home Assistant being the biggest community I think (according to number of opened issues), but also iobroker, openhab, FHEM and probably more.
Thanks to supporters and the community we got NUKI Hub to stable state, which was a problem especially in the beginning, and we were able to add a lot of requested features. It’s not always easy to balance between user expectations, technical feasibility and scope of the project, but I’d like to think we did a pretty good job at that so far.
Hi,
I’m considering the Nuki to use with my Ultion locks in the UK, so I can still have the same key for other external locks. I would be looking to integrate into my Home Assistant setup, exposing the lock to HomeKit.
Looking at the recommended ESP32 devices, do the WiFi ones (Atom U/Lite) communicate with the Nuki lock via BLE? I can’t see this listed in their specs?
Do I need an SL3 or SL3Pro to work with the Atom U/Lite ESP32?
Nuki Hub communicates with the Nuki Lock via BLE and uses its WiFi for LAN communications.
For Home Assistant integration, Nuki Hub natively supports MQTT Discovery, so once you configure the MQTT broker to be used, the device will automatically be picked up by Home Assistant with all the relevant entities. True Plug and Play.
As stated on the project’s repo, here’s the list of supported locks:
Don’t worry Will, thanks to the work of @technyon and some advices from the support team (me included) you won’t have to care much about the hw details. Just flash the firmware and then you open NH webpage to configure things. And if you need help, use the GH repo or join the Nuki Hub Discord Server.
@Juergen - it would be great if the Door Sensor protocol could be documented. That would Nuki Hub to push the door state back to the lock by using any door sensing method the user desires (Nuki feature request and Nuki Hub feature request).
Do you think that would be possible? Alternatively, if the bridge/web API can be updated to allow pushing state another way, that would work, too.
Interesting: the nuki bridge seems to already have a ESP-WROOM-02 chip for WIFI + Cypress CY8C4248LQI-BL483 chip for Bluetooth according to this teardown-article: (A peek inside the Nuki Smart Lock - The π Computer Club) maybe some day we see a open-source firmware like “ESPHome Nuki Lock” or “Nuki HUB” ported to the original Nuki Bridge HW :)))
we discussed about this, technically I think it could be done, but we also found out that for ESPs wifi+bt bridging functionalities are very resource intensive, so ESP32 is highly recommended.
It would be actually interesting retrofitting the bridge case with an ESP32 device, like the Atom Lite for example.
