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
+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
1 Like
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.
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…
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?
This was released publicly on 10th of September and we missed to add it to the Release Notes, but I updated the document now:
So this is the current public version and all features from the Beta have been taken over.
Where can i check when my bridge has been updated?
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
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.
1 Like
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…
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.
I can not give you an update on that yet as date (and scope) depends on feedback from the Beta and on other releases.
ok, thx.
Will keep an eye on it.
@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
Hi!
Only in the second case you should see
"state": 3,
"stateName": "rto active",
when RTO is activated. This should help distinguish it from “someone unkown has rang”. Are you missing that state in your case?
Hi.
Yeah i am getting this event:
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
But when the ringactionState will be set to 1 the state is back to online !?
Sure i can set a timer in my smarthome that rto was active but how long and when should ill reset it.
A better approach would be that the state remains on rto active until ringactionState gets 0 again.
Or is there a way i can distinguish between:
- it was an unkown rang
- it was an rto rang -> dont trigger actions
thx
Hi. I use Android Bridge and I have the beta program activated. How can I use the new features? My version is 1.4.6
Hi Tobias,
I guess the problem is, that the state “rto active” is overwritten by “opening” before the ring begins.
Are these events displayed in FHEM?
Ok, I get 3 webhook calls when I use ring to open:
{"deviceType": 2, "nukiId": 123, "mode": 2, "state": 7, "stateName": "opening", "batteryCritical": false, "ringactionTimestamp": "2020-10-27T07:45:58+00:00", "ringactionState": false}
{"deviceType": 2, "nukiId": 123, "mode": 2, "state": 5, "stateName": "open", "batteryCritical": false, "ringactionTimestamp": "2020-10-27T07:45:58+00:00", "ringactionState": false}
{"deviceType": 2, "nukiId": 123, "mode": 2, "state": 1, "stateName": "online", "batteryCritical": false, "ringactionTimestamp": "2020-10-27T09:04:38+00:00", "ringactionState": true}
So sadly, there seems to be no possibility to see that ring to open is used.
Best option is most likely to keep a variable around that gets set when ring to open is activated and resetted when the state goes back to “online”.
@Nuki maybe it would be good to add some more information to the webhook JSON here?
Stephan, in the bridge api document (1.12.3, June 2021) there’s no indication of the batteryChargeState and batteryCharging json fields. But I remember there was, in a previous document version, or maybe I read it somewhere else?
Thanks,
Alessandro