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.
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.
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:
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.
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.
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.
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.
“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”.