Bridge Beta FW 2.7.x / 1.17.x

[Stephan (Stephan Lendl)]

@PatrickR Thanks for all your feedback. We will take a look at this and get back to you directly if further details would be helpful.

[Stephan (Stephan Lendl)]

@benzman81

Can you update the bridge api documentation

We only update the official documentation for features which are public for everyone (as things could still be changed/taken back and we want to have as little outdated documentation out there as possible).

If there are things which are still unclear to you from my examples to test with your integrations, please PM me your questions.

[ooooli (Oliver G)]

I got the beta firmware 2.7.0 on my Bridge and version 1.5.1 on my Opener.
The RingAction state is working very well. I use ioBroker in combination with Alexa and it’s now notifying me, when someone is at the door and I’m in a room, where I normally don’t hear the Opener sound.
Very good extension! Looking forward to see this in the default firmware.

[Thyraz (Tobias)]

Also got the RingAction working my SmartHome (Fhem).
Can’t tell you how much I waited for this feature.

Battery state in percent is also working fine.

[Hinti]

I have beta firmware 2.7.0 on my bridge and version 1.5.1 on my opener.
The RingAction status works perfectly. I use it in connection with “digital stream”. I can now flash the lamps in the room and play messages via SONOS, etc.

Many thanks for the implementation
Question why was it resolved via status (true / false). If you could evaluate in the future between 1 and X ring.

[Stephan (Stephan Lendl)]

Updated the topic as the latest Bridge Beta firmware now also supports the new Keypad battery critical state

@MatthiasK

get the Keypad battery state
(needs Smart Lock Firmware 2.8.3/1.10.1, Opener Firmware 1.5.2 and Keypad Firmware 1.7.0 or higher)

Note, that this requires devices to run the latest firmware and you may need to apply for Beta for those devices to receive the update.

See:

Smart Lock 1.0 Firmware 1.10.x Beta

Updates: Smart Lock 1.0 Beta 1.10.0 Battery in percent calculation (can currently only be tested with the Bridge API for Bridge Firmware 2.7.0./1.17.0 or with Homekit) Smart Lock 1.0 Beta 1.10.1 Handling of Keypad Battery Notifications (can currently only be tested with the Bridge API for Bridge Firmware 2.7.0/1.17.1) and with the Keypad Firmware 1.7.0

Smart Lock Firmware 2.8.x Beta

Updates: Smart Lock 2.0 Beta 2.8.0 Performance improvements Several minor bugfixes Smart Lock 2.0 Beta 2.8.1 Battery in percent calculation (can currently only be tested with the Bridge API for Bridge Firmware 2.7.0./1.17.0 or with Homekit) Smart Lock 2.0 Beta 2.8.2 Improvement of the general mechanic performance of the Smart Lock 2.0 Smart Lock 2.0 Beta 2.8.3 Improvement of the general battery type handling Handling of Keypad Battery Notifications (can currently only be tested with…

Nuki Opener firmware - beta release notes

Important Notes: In case you have a functioning setup, we do not recommend installing new beta versions. Beta versions are sometimes used to address and test certain intercom issues that may be inappropriate for others. Please also note that beta users will be removed from the beta after a certain period of time (usually 1 month). In case you have problems completing the configuration, doorbell recognition or electric strike actuation of your Nuki Opener, you must perform a reconfiguration (Ad…

Keypad Beta FW 1.7.x

Updates: Keypad Beta 1.7.0 Handling of the Keypad Battery State (can currently only be tested with the Bridge API for Bridge Firmware 2.7.0/1.17.1) and with the latest Smart Lock 1.0/2.0 or Opener beta Firmware

[Muetzenfrosch (Björn Weber)]

Thanks a lot for integrating the opener ring actions callback! This is really really appreciated!!!

Any idea, when this beta will become a public release version?

Thanks again,
best regards
Mützenfrosch

[popy (Tobias Diendorfer)]

+1 would love to see an bridge/opener release with the ring feature.

Any news when this will be released?

Don’t want to fiddle around with the betas.

Thx

[Phuturist]

@MatthiasK

get the Keypad battery state
(needs Smart Lock Firmware 2.8.3/1.10.1, Opener Firmware 1.5.2 and Keypad Firmware 1.7.0 or higher)

I have Bridge firmware 1.17.1, keypad firmware 1.7.0 and SL2 firmware 2.8.3. Yet the keypad battery state is not added under the /lockState endpoint. What am I missing?

[EDIT]
OK, looks like actually using the keypad once after the update to 1.7.0 adds the battery status.

[Mucki (Markus)]

I checked my Nuki Bridges and both of them showed me Firmware Version 2.7.

Is it already the stable version? Because I did not subscribed the beta program…

[popy (Tobias Diendorfer)]

Also saw 2.7.0 is on my bridge
Now just the opener release is missing for the ringing feature.

Any info when this goes stable?

[Stephan (Stephan Lendl)]

This was released publicly on 10th of September and we missed to add it to the Release Notes, but I updated the document now:

Nuki Bridge Firmware Release notes (public releases)

This is an overview of the latest public firmware releases for the Nuki Bridge. You will always find the latest release on top. Bridge FW 2.7.0 / 1.17.0 (10.09.2010) Bridge API: get the battery in % for a Smart Lock (needs Smart Lock Firmware 2.8.1/1.10.0 or higher) Bridge API: get callbacks for door Opener ringactions which did not trigger a state change (“someone unknown rang the bell”) (needs Opener Firmware 1.5.1 or higher) Bridge API: get the Keypad battery state (needs Smart Lock Firm…

So this is the current public version and all features from the Beta have been taken over.

[Mucki (Markus)]

Where can i check when my bridge has been updated?

[Stephan (Stephan Lendl)]

You can not exactly check when the update was done.
In general the Bridge checks for an update 1 hour after a restart and then all 24 subsequent hours.
If it was not unplugged lately you can at least see since when it is running the latest version fur sure by checking the “uptime” value in /info.

See also
https://developer.nuki.io/page/nuki-bridge-http-api-1-12/4#heading--info

[popy (Tobias Diendorfer)]

In my case i am using fhem with the nuki module which shows the bridge version.
Sadly did’nt find an easy way to check it in the nuki app without reconfiguring the device.
Maybe @MatthiasK can help here.

@MatthiasK: Any news when Opener 1.5.1 release goes live? Would love to test the “someone unknown rang the bell” feature.

[Mucki (Markus)]

Thanks, i asked because my security system with native Nuki support does have some serious problems since some days/weeks.
I‘m no developer but i asked myself if the security system can‘t handle some of the new callbacks…

[Stephan (Stephan Lendl)]

@Mucki

I‘m no developer but i asked myself if the security system can‘t handle some of the new callbacks…

I can not rule this out.
In a correct implementation an additional field in the respsonse JSON should make no trouble at all, but I have already seen implementations where it indeed caused some trouble. That’s why we have Beta phases for changes for the developers to check/adopt if needed.

[Stephan (Stephan Lendl)]

@popy

Any news when Opener 1.5.1 release goes live?

I can not give you an update on that yet as date (and scope) depends on feedback from the Beta and on other releases.

[popy (Tobias Diendorfer)]

ok, thx.
Will keep an eye on it.

[popy (Tobias Diendorfer)]

@MatthiasK
Got the firmware updates now as stable and i have a question regarding the new ringactionState.

Currently my setup is as follows:
Ringing & door wires <> opener <> bell and relais in paralell (hue dimmer switch connected to the relais).
The hue dimmer switch gets “pressed” by the relais, my smarthome let alexa say “Someone ring the bell”.
So if RingToOpen is active, the opener is recognizing the ring and prevents the bell from ringing and (relais) alexa from speaking -> good.

I want to ditch the relais and dimmer switch and switch to the new ringactionState.
As i said i got the updates and did a log on an “someone unknown ring”:

2020.10.05 12:13:19 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 1 - state: online
2020.10.05 12:19:44 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 1 - state: online
2020.10.05 12:48:38 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 1 - state: online
2020.10.05 12:50:30 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 1 - state: online

Looks good this i can detect and use it as trigger and do my smarthome actions.
And the log when state is “rto active”:

2020.10.05 20:32:44 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 0 - state: rto active
2020.10.05 20:32:49 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 0 - state: opening
2020.10.05 20:32:55 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 1 - state: online
2020.10.05 20:33:21 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 1 - state: online
2020.10.05 20:33:25 1: act_VR_Klingel_Nuki: ringactionState/event: ringactionState: 0 - state: online

Sadly i get “ringactionState: 1” and the state is NOT “rto actve” so i cant prevent my smarthome actions because it seems like a “someone unknown has ring”

As stated in the rest api docuimentation 20200902NukiBridgeAPI1_12.pdf ringactionState:
Flag indicating if a ring-action is currently occuring or not (reset after 30 seconds)

With the current behaviout i cannot distinguish between an “Someone unkown ring” and “rto active and opening ring occured”.

So my question is:
Am i doing something wrong or is this the expected behaviour of “rto active” and ringactionState if an RingToOpen was active before.

Thank you
Tobias