Hi Guys,
Congratulations for the new Nuki’s! And finally that you can choose for white!
However, have 2 questions.
Does the pro version still have local API? So there is no internet needed to unlock Nuki locally? (in house) you can do that always with you’re WiFi connection.
And the new Nuki makes less noise… Is that 10÷ less noice, or 50÷? Or more? 
Just curious.
I’ve also some questions regarding the new locks:
Thanks in advance!
Not at the beginning. We are still looking into the topic and will let you know here in the forum when we have a clear answer.
Noise is very subjective, depends a lot on the door and surrounding. Furthermore how “loud” you experience your Smart Lock does more depend on how long you hear the noise than the absolute volume it has and how regular it is (stiff doors are much louder than ones with regular load on the gearings). Having said that i would rate it more at 10% rather than 50%. All tester so far said that it sounds more pleasant.
Both have changes, but they are not exactly the same.
Yes. Battery life will be longer in this case (~6 months).
Yes, but you need a battery compartment. 3.0 Pro comes with Power Pack only.
But it’s not advised. Accumulators have a higher energy density than Alkaline batteries, can deal better with high forces and cold temperatures and are more environmental friendly.
The door sensor is compatible with Smart Lock 3.0 & 3.0 Pro and not backwards compatible with Smart Lock 1.0 & 2.0.
See above. Currently only by connecting it to a bridge.
Hopefully Bridge HTTP API find it‘s way to the Pro as well (or MQTT instead?), otherwise Pro will fall out of local Smarthome integrations.
This really would be a step backwards.
I totally agree with @christianTF: I choose Nuki to automate my door because it has the possibility of integrate it into my automation hub (Hubitat Elevation). I even developed myself specific app & drivers to integrate it (ok, it needs some improvements, but hey, it is working … kind of).
If Nuki completely drop the Local API (Bridge <-> Lock), I’ll be very disappointed and, sincerely, my current setup (Bridge+Lock+Opener+Fob+Keypad) will be my first and last Nuki products.
I won’t mind if the Lock 3.0 does not have a local API, but not be possible to control it with at least the Bridge 2.0 Local API will be a, IMHO, a shame.
Hi Marco,
how are you? I was the first tester of your integration on HE. I then moved to Home Assistant, and developed my own integration because the official one was not good. 
When I saw the announcement of the Pro, I was hoping they simply “integrated” the bridge in the SmartLock by having onboard wifi, so they won’t break current APIs, but that doesn’t seem the case. I think they have other plans unfortunately. Local API is not a priority, the “everything-local” community unfortunately is a small percentage of Nuki customers.
Anyway, @Juergen said something that is a good workaround for us: Nuki 3 can be managed through the bridge, so our integrations should still work:
Ciao,
Alessandro
Hi Juergen, some more questions about the bridge:
I know that many users of the integration will ask me about support of 3 and 3 Pro so I’m trying to understand what the options are.
Thanks.
Ciao Alessandro!
Come va?
Yes, I noticed it - I hope they do not kill local API.
I was planning to totally rewrite my integration shortly and I think it will be better wait a little for the news about the path Nuki eill choose.
Stai bene!
Everything ok Marco, thanks, hope the same for you.
Yes, I hope Nuki team will make the right choices regarding Local APIs.
Ciao,
Alessandro
Hi Alessandro !
Thanks a lot for your work !
Fiew question:
Many thanks and best regards
Thierry
The bridge did not change from a technical point of view. So the answer to all your questions is YES.
If we would have done that you would have seen the additional electronics (there is no space inside the Smart Lock) and the batteries would have been empty after 2 days or so.
Adding WIFI to the Smart Lock required to remove other components to free up space, the use of ultra low power components and many power management tricks. When we say that we “doubled the RAM of the Smart Lock”, this means that it went from 64KByte to 128KByte. And there is HomeKit, BLE, TLS/SSL TCP connection, encryption, motor controls, … all running on it. It is a computer yes, but a tiny one with tight resources.
Most of your questions are
Because WIFI requires lots of power just to stay online. With a bridge, the bridge does this heavy lifting, therefore the batteries of the Smart Lock last longer.
Yes, if you want to use the Nuki Apps for remote access. Furthermore if you disconnect the bridge from the internet the Smart Lock won’t get firmware updates and the time of the Smart Lock might drift off.
Yes & Is my door lock compatible with the Nuki Smart Lock? & https://shop.nuki.io ships to canada.
Please contact our support for more detailed information.
This forum is focused on developer related issues.
That’s not a good news: the bridge should’ve been improved hw-wise. It has severe limitations (max 1 connection) and the cost doesn’t justify that low-end hw. The size is big enough to justify better hw components, and it’s powered by means. I really can’t understand why not improving the bridge.
This is a good news. So, in order to make the v3 compatible with all existing sw, the bridge (whichevere version) is enough to guarantee backwards compatibility. This is very good.
You are right, the bridge functions requires it to be always on, and that’s not feasible for the SL that is battery-powered. So, if wifi is not always-on for the SL (to save power), how do I communicate with the SL via wifi? When does it turn its wifi on?
Instead of adding wifi to the SLv3 Pro, Zigbee would’ve been a much better choice (it was planned for v2 since the beginning): wifi is not a protocol designed for battery-powered devices, as you underlined. Plus, on the new bridge, addition of Zigbee+MQTT, both designed for small factor devices not requiring many resources, exactly like the bridge.
I had the chance to speak with your product manager…already gave him these feedbacks.
Thanks Juergen.
Local fw updates and local NTP sync should be available as standard functionalities. If you can update from internet, or sync the clock to the internet, you can also do it locally, it’s only a matter of sw design of the bridge.
WIFI is always on. Nobody every said anything different. Smart Lock 3.0 Pro does not consume more energy in a good network with WIFI always on than Smart Lock 2.0 does without it.
I won’t argue here with you, because this becomes more and more off topic, but think about how many people do not need some sort of additional bridge/hub when adding WIFI vs. Zigbee: Everybody has WIFI, maybe 5% have Zigbee.
Wifi always on in a battery device? Well…I’m curious to know: what is the average duration of the battery pack? Mechanical action + always-on wifi…big hit on the battery…not a good choice.
This is like saying: everybody has a lock: 0.001% have a smartlock, so it’s not needed. Or: everybody has lights, only 1% has zigbee lights. If what you say is true, why is it that zigbee was a feature of SL 2.0? That was one of the reasons I personally bought it. But it was never “enabled”.
(Wifi + Zigbee on the bridge) + Zigbee+MQTT on the lock and you have covered the ENTIRE market, “normal” users and all home automation users, with a much better design, because a battery device with wifi always on is not a good design, IMHO obviously. Wifi was never created for this scope, that’s why protocols like zigbee/zwave/etc. were created.
I have an understanding question, in addition to:
“Is it possible to use the 3.0 Pro in combination with the bridge instead of using the integrated WiFi of the lock?”
The non pro 3.0 version still uses Bluetooth and can connect to the old/current bridge with the current http-api features? So for developers this will be the only useful setup, or? Of course, I’m also not interested that such devices “need to phone home”.
