Setting refresh delay to 0 will disable automatic state update after sending command. Setting poll interval to 0 will disable periodic polling and the only way to get current device state would then be using REFRESH command.
Ok, will try that.
How could I use the REFRESH command if I wanted to? Could be nice to update the battery status once a day for instance.
You can do it e.g. from rules DSL:
item.sendCommand(REFRESH)
1 Like
Since firmware version 3.5.11 the MQTT api is now available also in the release version.
It is not yet possible to use the current app version to provision the credentials to the broker, the fixed credential mode must be used. Please see the MQTT api docs how to do it:
1 Like
I’ve got the update 3.5.11 and connected the lock to my Mosquitto server. I’m getting updates from the lock, such as Lock state, name, battery.
But I can’t send commands. I tried it via a MQTT client and i’m succesfully locking and unlocking the door. But Openhab doesn’t lock or unlock the door.
Thing mqtt:topic:nuki:voordeur "Voordeur"
(mqtt:broker:nuki) @ "Huis"
{
Channels:
Type string : state "Slot Status" [ stateTopic = "nuki/********/state"]
Type number : lockAction "Slot commando" [ stateTopic = "nuki/******/lockAction"]
Type string : name "Slot naam" [ stateTopic = "nuki/******/name"]
Number VoordeurCommand "Commando" { channel="mqtt:topic:nuki:voordeur:lockAction" }
Does anyone know what i’m doing wrong? I tried also string but the lock just doesn’t react.
You need a command topic, not a state topic to send commands.
The item type needs to be a String itemtype.
On your sitemap you may use something like this for your String item:
Selection item=Nuki_LockAction mappings=["1"="unlock","2"="lock","3"="open"]
1 Like
Thanks a lot! I did not know that. I didn’t use mqtt before for sending commands.
did you already found out what’s going wrong with your example?
i successfully tested your example and it works for me (Nuki 3.0 pro without bridge).
I can send it to on and off (door will be locked/unlocked).
Hint: I use a door with “Windfang” and therefore unlocking is not enough, it has to be moved/unlocked for a few seconds more so that the door really gets opened - and not just unlocked.
therefore I need another action, but I will try to find out which one works
Take a look at the web api docs:
1=unlock, 2=lock, 3=unlatch
With your example the switch item sends 1 for unlocking and 2 for locking. You need 3 for unlatching.
I strongly recommend to use the MQTT Api, which is available since the firmware release version 3.5.11.
It is a lot easier to set up.
thx for very fast reply. I will try to use “3” for unlatch.
I also wanted to setup or use MQTT (i have openhab + mqtt already running) and I also use the newest firmware. But up to now I cannot find the configuration in my android app “Nuki => Meine Geräte verwalten” => “Smart Lock” => nothing with QMTT, also nothing in “Funktionen & Konfigurationen”
Firmware says: 3.5.11
therefore I see no chance where I can put the IP of my mqtt broker/server
It is not yet possible to do that through the app. There is only a fixed credentials mode in the firmware, but there is a tutorial in the MQTT api docs how to set this up:
hi! i also have some drain issues with my SL3.0 PRO.
Im using the web connection to manage the airbnb. I know it is not what you are doing, but did it solve the issue after you disabled the web interface?
im planning to disable the web connection if this would solve the battery drain issues
In the lock itself I left the web connection enabled, just to be able to control the lock from the internet with the app. But I disabled the Openhab binding and removed the API connection from the web API. I went from 1,5 week battery to about 3 to 6 months I estimated, with MQTT enabled. Both my locks are still not empty so it’s a rough guess😊
1 Like
ok, in my case it sounds like i need to disable the nuki web and also the airbnb connection to achieve a similar battery improvement then. I will try for a few weeks to disable it to see if it improves the battery drain issue. To bad cause they even sell this airbnb connection as a 69€/ year and it is buggy…
Yeah, I think that’s the only option. The Web API does poll a lot and keeps the lock awake.
I also had another problem, couple of days I suddenly had massive drain (40% in 2 days). Problem was with my Wifi. I own 2 Asus mesh routers. I linked one of the locks to one of the routers, but forgot the other one. At first this wasn’t a problem but suddenly it drained, I think the lock began to switch between the two routers and was waking up all the time because of this. I linked the lock to one of the routers and the problem was gone. Web API was disabled on both locks when this happened.
Must say, MQTT is perfect and causes no drain. Maybe it’s not an option for you, but if it’s possible, I would look in to it. The Android beta app now has the option to configure MQTT from the app. And I think iOS also has this option available.
I do have 2 routers with the same SSID. Mine are both Apple airport extreme. One of the routers is 1meter from the lock while the other is around 15meters.
The battery on my nuki drains 100% in around 5 days, it started 1 month after i enabled the airbnb management.
What is super annoying in my case is that when the battery is drained for let’s say 5 days, the NUKI will loose some of the configuration. Eg: the name is gone, the PIN won’t work anymore ant it thinks it is connected to a door sensor.
the solution is to factory reset and make a new setup with new PIN, new users, setup the keypad again. Such a pain.
I have posted a configuration example using MQTT with a Pro lock without a bridge. Maybe this is relevant for you all: Configuration example for Nuki 3.0 Pro Lock working with the MQTT API (no bridge)
Hi everyone,
after the Nuki Cloud failed yesterday,
I became painfully aware that the Nuki 3.0 Pro with MQTT is not a complete local solution so far. :-/
The Nuki reconnects wifi all the time if it can’t connect to the cloud, to “fix” possible network problems.
As a result, the MQTT connection (which should actually be a completely local control solution) no longer works.
This doesn’t just affect cloud outages at Nuki.
You also have this problem if you have internet disruptions or if disable internet access for the smart lock in the router.
Anyone who is affected (or simply bored ;D) is therfore very welcome to vote on this feature request in the Nuki forum:
In addition, you are also invited to leave a comment that this behavior is really annoying 
.
I really hope that the problem will be addressed if enough “attention” is paid to it.
They had the same problems with the bridge at the beginning, where the local HTTP API also caused problems.
The Wifi reconnecting was replaced by a check to see if the default gateway (which is likely to be the router / DHCP server for most people) is reachable iirc.
If the default gateway is reachable, the bridge is happy and does not reconnect wildly.
Hopefully this will be solved similarly for the 3.0 Pro …
2 Likes