Nuki 3.0 Pro without bridge

Add-ons Bindings
42

Thx for this hint, I bought the 3.0 Pro last week and opted in for the beta firmware to try mqtt.
I had a hard time to make the mqtt connection as it is hardcoded into the firmware (broker must be accessible through mqtt.local, this will be changed in the final firmware to be a user setting).

This are the available topics:

nuki_mqtt

Everything is working fine so far.
Be aware that your lock automatically sends data to the nuki servers when using the beta firmware.

43

Hi,

tried the steps mentioned here but the connection to my Lock 3 Pro is not working via HTTP binding. I am running on OH 2.5 for several reasons so the nuki binding is not helpful in my case.

I have added the thing and the items but nothing happens and also no entries in my log. Any suggestions?

44

I show my working configuration:

Thing:

UID: <hidden>
label: Nuki portone blindato
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  headers:
    - accept= application/json
    - authorization= Bearer
      <hidden>
  baseURL: https://api.nuki.io/
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: POST
  contentType: application/json
  timeout: 3000
  bufferSize: 2048
channels:
  - id: Stato
    channelTypeUID: http:string
    label: Stato
    description: ""
    configuration:
      stateExtension: smartlock/<hidden>
      stateTransformation: JSONPATH:$.state.state
  - id: Comando
    channelTypeUID: http:switch
    label: Comando
    description: ""
    configuration:
      onValue: '{"action": 2}'
      offValue: '{"action": 3}'
      stateExtension: smartlock/<hidden>
      commandExtension: smartlock/<hidden>/action
      stateTransformation: JSONPATH:$.state.stateāˆ©MAP:nuki.map
  - id: Batteria
    channelTypeUID: http:number
    label: Batteria
    description: ""
    configuration:
      stateExtension: smartlock/<hidden>
      stateTransformation: JSONPATH:$.state.batteryCharge

Transformation nuki.map:

0={"action": 3}
1={"action": 2}
2={"action": 3}
3={"action": 3}
4={"action": 2}
5={"action": 3}
6={"action": 3}
7={"action": 3}
254={"action": 3}
255={"action": 3}

Hope this helps

45

Blockquote I would expect that not every call to web api will wake up the smart lock

I would expect that to. I contacted Nuki support and they also thought it should not wake up every time. But iā€™m pretty sure the locks do wake up everytime a polling occurs.

I can do about 2 weeks with a lock in stead of about 5 months. So I turned off the binding for 2 days and the battery didnā€™t drop anymore. This is the main problem with the api as you said.

Funny thing, I had the polling time every 15 minutes, so 4 per hour, 96 per day. The lock normaly wakes up about 10 times a day. So it could be using 10 times more energy. 5 months = 20 weeks / 10 = about 2 weeks :joy:

I enabled the binding again and set a polling time of 0 seconds and refresh delay of 15. It iā€™m pretty sure the drain stays away with this configuration.

And now iā€™m waiting for the release of the new firmware with MQTT :smiley:

46

Hi everyone,

after carefully reading this thread and also a couple of FAQs on the Nuki website, Iā€™m a bit at a loss with making a buying decision!

So far, I have understood following:

SL3.0:

  • supported by a dedicated openHAB-binding in combination with the Wifi Bridge
  • powered by 4xAA batteries (AA-capacity 2000-3000 mAh/cell)

SL3.0pro:

  • No dedicated openHAB-binding, as WEB-API of WiFi-interface is incompatible to WEB-API of WiFi-bridge
  • 2500mAh (@4,8V) NiMH rechargable power pack
  • A WIFI-bridge can be connected to SL3.0pro, if backward-compatibility is needed
  • HTTP-binding can be used (without WiFi-bridge) as workaround
  • Status transmission is an issue, as status information needs to be polled periodically, which increases the power consumption notably
  • power consumption can be decreased by using BlueTooth on the physical layer instead
  • power consumption can also be decreased by using MQTT on the application layer, beta firmware for the lock is available on the developerā€™s website

Independendly:

  • a github-project (NUKI-hub) is available, implementing a ESP32-based ā€œWIFI-bridgeā€, that binds any SL3.0 (whether or not Pro) via bluetooth. The lock is managed via MQTT (over WiFi/Ethernet).
  • commonly used rechargable AA-cells (1,2V) are available at low prices and capacities > 2500mAh

Provided my summary is correct, it is probably not a bad idea to stick with the ā€œoldā€ SL3.0!
NUKI-hub sounds very promising and if it does not turn out to be an alternative (for whatever reason), there is still the WIFI-bridge.
On the other hand, issues of compatibilities or power consumption of the newer SL3.0pro could be overcome by flashing firmware with MQTT support
Then again, the power pack of the pro-version is not really a game changer: get 4 rechargeable AA.cells for the SL3.0 and you might end up with even higher capacity

Any ideas, advice or corrections?

Best regards,
-bernie

47

I think this is all correct. Only one small remark:

Yes the bridge is a fallback but it is quite expensive. If youā€™re ready to spend another 100ā‚¬ then itā€™s fine of course. NUKI-hub however works very well so I donā€™t think youā€™ll need this fallback anyway.

1 Like
48

I am using the SL3P since 8 weeks now and the power pack is down to 54 % (still first charge). That includes all the ā€œplaying aroundā€ from the first two weeks.
The lock is used 6 to 10 times a day, so I expect at least around 16 to 18 weeks battery life. That is pretty good in my opintion.

Native MQTT support with the beta firmware works very well.

I would go for the SL3P :grinning:

1 Like
49

I had to remove the Web API to solve the battery drain. They still where empty after max. 2 weeks. But I was thinking, when the Refresh Delay and Polling are set to 0. the Polling should stop and the locks wouldnā€™t wake up anymore? Only the polling at 0 still did drain the locks. Or should I use a very large number, 1440 minutes and 86400 for a day for example.

I only use openhab to Lock and unlock the doors despite the status of the locks, so I donā€™t need any form of polling or status updates from the locks.

50

I would also go for the SL3.0 Pro. I had some power issues but itā€™s mainly due to the web api. MQTT is coming to the locks and is for a couple of months in BETA and that is working pretty good I read on the Nuki forum.

The locks are pretty good, the only thing I notice is coming home and the app sometimes doesnā€™t react fast enough to open the doors before I arrive at the door. I also own the keypad with fingerprint, so itā€™s not a real issue. I think the SL3.0 has the same problem.

51

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.

52

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.

53

You can do it e.g. from rules DSL:

item.sendCommand(REFRESH)
1 Like
54

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
55

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.

56

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
57

Thanks a lot! I did not know that. I didnā€™t use mqtt before for sending commands.

58

did you already found out whatā€™s going wrong with your example?

59

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

60

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.

61

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