Waited half a year for this „PRO“ version with integrated wifi and finally got it today, so I wouldn‘t have to use another bridge for the other side of the house. Couldn‘t believe after setting it up that they got rid of the local http API - unbelievable! I use Home Assistant and just require very simple API or webhook functionality like lock/unlock, status and maybe battery state. MQTT would also work just fine. What‘s an absolute no-go for me is to use their cloud API or going back to a bluetooth bridge. Terrible, still in disbelieve and really hope they are making progress on implementing MQTT quickly!
I bought a Nuki Pro for the exact same reason as many people here: local control over WiFi, without the need of a bridge. I’m a big fan of Home Assistant, and want everything to work locally.
The default Nuki integration for Home Assistant only works with a bridge, regardless of what model you have (which defeats the purpose of having WiFi on device). I found a custom integration that can use Nuki Cloud to pull the status of your lock, but obviously that requires a constant internet connection, which is a no-go for me: https://github.com/kvj/hass_nuki_ng
Another option is to use ESPHome to create your own bridge with a cheap ESP32 microcontroller and directly integrate your lock with Home Assistant: https://github.com/uriyacovy/ESPHome_nuki_lock
It’s a bit hard to setup if you haven’t used ESPHome before but once it’s up and running, it’s great. Your lock pairs to the ESP32 board, which in turn relays your lock state to Home Assistant via local network. It’s also a lot cheaper than Nuki’s own bridge.
Personally, I will be returning the Nuki Pro and swap it out for the regular model.
Just ordered an ESP32 wroom dev board for under 10 bucks on amazon. Will probably keep the PRO in hopes they realize an MQTT integration as I‘m not happy to keep adding more and more devices. Use a lot of newer Shelly 1 Plus for different relay use cases. They also have an ESP32 w/ bluetooth. Will look into ESPHome and Tasmota to combine those for relay applications plus see if on same device I could utilize the bluetooth functionality.
Hi @Juergen, is there any outlook or current state of the discussion you can share with the community regarding the potential future MQTT integration?
I think now since the deliveries of the Pro has resumed the requests for it might increase strongly.
Same here, bought the Pro in order to get rid of the bridge. During setup I discovered only then that Home Assistant can’t control the lock anymore since it doesn’t have the API. What a shame.
I don’t want to be the bringer of bad news, but I contacted Nuki support about this and they said “it’s not on our roadmap”.
Just bought the Nuki 3.0 Pro because it integrates directly with WiFi. However, now I discover that it cannot be integrated with Home Assistant because the lock has no local API.
I see that this feature has already been requested. Any ETA on that? I really need this integration. Without it, I will return the Nuki I’m afraid.
thank you for your message!
Unfortunately at the moment the requested feature is not on our roadmap. But we are happy to forward your suggestion as a feature request to the responsible colleagues.
We are not able to tell you if and when we will be able to implement the requested feature.
If your cancellation period didn’t expire yet, you can arrange everything yourself in the My Account area in the Nuki web shop.
That being said, I don’t want to bash on Nuki too hard. It’s the first IoT product that I came across that works without needing an account or connection to the cloud. It’s “local-first”, which I really appreciate! I also love that they publish their BLE specification. That’s very rare.
@Stan81 Good find! Seems like a few people have been building unofficial Nuki bridges.
About Tasmota/MQTT: I personally prefer ESPHome, because I have flashed it to all ESP8266 or ESP32-based devices (including many 1st gen Shelly’s).
I agree with what you say about “adding more and more devices”, so I added the Nuki bridge functionality to my ESP32-based air quality monitor. Works like a charm!
MQTT support for SL3P is in the works, but I don’t know the estimated release date.
As mentioned above there is a separate working group here in the forum that works on this topic. They have reviewed a draft specification. If things go well there will be a limited beta later this year (which does not mean yet that it will ever make it into a final release → we do not comment about our roadmap puplicy).
Well, we do not comment about our roadmap in the public. So i would take that answer with a grain of salt …
Thanks for your comment. Given some of the other comments in this group are very negative, it should not be forgotten that Nuki offers plenty of APIs (local and cloud based). More than any other Smart Lock. Smart Lock 3.0 Pro did also not drop any APIs. You can still use everything that was there before, even the cloud API without the need for a bridge. Only if you want an IP based local API (= Nuki Bridge HTTP-API), you still need a bridge.
No, nobody has forgotten the enthusiasts. We wanted to bring the first battery driven Smart Lock with built in WIFI on the market in Europe and this is what we did. It required lots of efficiency improvements to achieve this. Fitting all features of a permanently powered bridge in there was never the goal. If we would have forgotten about the enthusiasts we would have e.g. not taken the extra mile to allow the pairing of a bridge with SL3P at all.
If you pair the SL3P with a bridge you will have the longest battery life of any Nuki Smart Lock on the market, because of the more efficient electronics inside it.
Hi @Juergen, thanks for your reply! I’ve had my Nuki for little over a week now, and honestly, it’s a great product. Installation is a breeze and auto-unlock is a game-changer for us.
I did end up returning the SL3P and got the regular SL3 instead, mainly for the price difference. However, your comment made me doubt that decision. How big is the battery life gap between the SL3 and SL3P? Could you give an estimation (in months or in percentage?). Is the gap big when you don’t use WiFi or a bridge?
I also added a Nuki Powerpack, so I guess that also makes a difference.
Thanks for replying to us here!
And I want to reiterate that I think you guys are doing a great job. A lot of “smart locks” make compromises that I just can’t live with (like replacing the entire cylinder or even door handle). Nuki is the only one that’s plug-and-play and actually has a decent set of features.
This is a bit off topic here, but anyway:
This depends from many factors, but just as rough guide the standby power based on the SL2 (with integrated door sensor):
100% = SL2
100% = SL3P (with WiFi on)
70% = SL3
45% = SL3P (with WiFi off)
But standby power is just a fraction of the overall energy consumption which mostly goes into turning the motor. How much this is depends a lot on how often you lock/unlock and how hard it is to turn the key. Here is more info about this
PowerPack batteries store more energy than Alkaline batteries. Because they can deal with higher currents better too, this ends up in almost 2x the lifetime compared to Alkaline. Lithium batteries are the cells with the highest energy density available in AA format.
I have the 3 pro version. How can i turn off wifi and work with the bride only? For battery saving…
If it is connected with the Nuki Bridge, WIFI is turned off automatically.
+1 … http API is a must for smarthome connections w a variety of suppliers
btw - any rough indication by when this feature might be supported on 3.0PRO?
After trying several things for days I wanted to share my experience with the community.
My original goals:
- Battery operated smart locks on 2 doors
(1 backdoor to the house, 1 garage side entry door)
- Automation possibility by integrating with Home Assistant.
have been using HA for years and it is in my experience the most versatile and flexible home automation solution available that works with pretty much everything (and it’s free!)
- no internet connectivity of the locks or any potential bridges due to security reasons (and as such no cloud API). Locks would be in a separate VLAN for IoT devices and only required protocols allowed for communication with HA.
- preferably no Wi-Fi to BLE bridge as I already have so many devices and brigdes do not appear to be technically necessary any more (see Shelly as a good example with i.e. their battery powered motion sensors that have a superb battery lifetime even though they constantly communicate through Wi-Fi in my house)
- building my own lock is not an option as my wife would say it looks to ugly (…in the garage maybe)
My initial assumptions:
- after some research Nuki appeared to me that they serve the needs of smart home enthusiasts very well with all the APIs they offer, this developer page with an active community, no need to sign-up for an account and no subscription fees, and some claims suggested that devices would work offline (which they do), etc. - So it was a no-brainer for me to go with Nuki.
- It had to be the Nuki 3.0 Pro with integrated Wi-Fi. At that point and given everything I thought I’d know of Nuki by then I just assumed that a local HTTP-API would be available through Wi-Fi - I could not imagine at that time that this would not be provided - what else would be the point of adding Wi-Fi to the lock itself.
- finally was able to order 2 Nuki 3.0 Pros after they were on backorder for pretty much the first half of 2022
- Found out that they only work with the web-API, or through the Bridge, or alternatives via some custom made bridge solution where I didn’t want to initialize invest much time on.
- Local home-improvement store (Hornbach) had serveral older Nuki Bridges on sale for 48 Euros since they discontinued to sell Nukis. Bought 2 of them, found out that:
- one was a very old 2016 v1 release, however it worked fine and investing some hours the firmware update to the latest 1.x release was eventually possible (but disappointed that the hw release was so old)
- second bridge was a 2018 hw release with also a very old initially installed fw. Updates would only work to an “intermediary 2.3.0” bridge fw release and from there on it was stuck. Forcing updates using the bridge http-api with the /fwupdate command did not work, tried and tried different things for about 3 days.
- however, both bridges anyways worked and I could integrate the locks to Home Assistant using the custom integration hass_nuki_ng also mentioned by @savjee above. But response times were a bit slow and the locks only updated their status after about 30 seconds. Not sure if this had to due with the older bridge releases or if it was due to how the custom HA integration was programmed.
Also the bridges constantly tried to access some Nuki servers, even though maybe just checking if there are new fw release after disabling the web-api and “API fast discovery” which also took a little while to figure that the later one is even doing. But the bridge logs were quite busy throwing errors and in general I am not a big fan of not being able to disable something like that and me needing to accept all these firewall log events. Crap!
- now being disappointed in the whole Nuki Bridge solution I returned both of them. Especially after that experience I thought spending 200 Euros for two brand new Nuki Bridges was a bad joke - also knowing that all that is in there is a little ESP chip and the software is really only intended for people who just don’t care about how things work.
- tried the ESPHome solution on 2 Nodemcu ESP32 dev kits for 7 Euros each as @savjee suggested above, and the other alternative I posted earlier in this thread. The best outcome turned out to be the ESPHome solution with the fastest response-time and only offering exactly what I needed to reach above mentioned goals. (Link, again: https://github.com/uriyacovy/ESPHome_nuki_lock)
- now I still need to build or print a small case for the ESP32 dev kits as those are just hanging from a USB power supply at the moment. But it all works fine for me now - except that I really didn’t want to spend nearly as much time to reach the simple goals I had in mind, and that I have 2 more devices with the ESP32 chips that would normally just not be necessary.
For the future I really hope that Nuki will put the MQTT implementation on the roadmap so that other users will have an easier experience - and that I and others can get rid of unnecessary Wi-Fi/BLE bridges.
I think if the MQTT implementation makes it into the product the Nuki would be a well-rounded solution that would both gear to regular users who don’t care about technology and security aspects too much, and at the same time be great for us smart home enthusiasts. A HTTP-API on the Pro lock itself would of course also be great, either that or MQTT. Such an implementation would only need to cover basic features like optional encryption, sensors for lock state and battery level, commands for lock/unlock/unlatch - that’s it. People using such a local API have typically no need that the products integrates directly with i.e. door sensors or fobs, as everyone with a decent smart home solution like Home Assistant would integrate such features within Home Assistant directly.
Another thing that needs improvement, even though now totally off-topic, is that the power pack needs to have Li-ion batteries instead of NiMh batteries, of course with a corresponding power/charging regulator PCB in the power pack. This would dramatically increase the operating temperature range. I still have to find a solution for that for my garage door once winter comes around.
Sorry for the long read. And don’t get me wrong - I like the Nuki brand still very much. It is the best brand for smart locks that exists in my opinion and I will continue to follow Nuki closely. Absolutely fantastic support and dev team as well with great people like @Juergen who is always offering good insights and very quick replies. Thank you!
The MQTT API for SL3P is available in Beta since some time and we’re searching for beta users.
If you would like to participate, please send a request to join this user group: Mqtt (closed group) - Nuki Developers