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”.
The Smart Lock 3.0 and 3.0 Pro can both be used with a bridge. And yes, currently there is no local API that allows direct interaction with the 3.0 Pro’s integrated WiFi. However, there is already a feature request for this and it’s not impossible to make this happen.
You said, there is a difference between the 3.0 pro and the normal 3.0 regarding the motor/gear. What are these differences? Is one more silent or long lasting or battery efficient?
You said, the 3.0 pro consumes about the same amount of energy with wifi on as the 2.0. What about the standard, non pro 3.0. Is it similar to the 3.0 pro with bridge or better or worse?
Ok. Thanks. But as I want to purchase and use the device within this decade, I’ll go with the nonPro version. It’s also not impossible that they get the fusion reactor working, some time
