Opener - ring detect sensor not working

[bklaesener]

Hi, my "ring detect" sensor is always shown as "unknown" on the MQTT device page.

According to the MQTT debug log, the payload should be either "ring" or "locked" (see below).

Instead, each ring action returns a "continous mode" payload, which appears to match the "lock/state" state_topic but does not serve the purpose of the sensor:

---

Transmitted messages:
Downstairs Door ring detect (binary_sensor.downstairs_door_ring_detect)
MQTT discovery data:
Topic: homeassistant/binary_sensor/xxxxxxxx/ring/config
Payload
device:
identifiers:
- nuki_xxxxxxxx
manufacturer: Nuki
model: Opener
name: Downstairs Door
name: Downstairs Door ring detect
unique_id: xxxxxxxx_ring_detect
device_class: sound
state_topic: nukiopener/lock/state
payload_on: ring
payload_off: locked
platform: mqtt

Subscribed topics:
nukiopener/lock/state
10 most recently received message(s)
Received 10:56:23
QoS: 0
Payload: ContinuousMode
Received 16:33:50
QoS: 0
Payload: ContinuousMode
Received 16:34:07
QoS: 0
Payload: ContinuousMode

---

If this is due to a misconfiguaration on my part I would be grateful for a hint.

[technyon]

I have an idea what's going wrong, and it's most likely because you're using continuous mode instead of ring-to-open. The ring detection is unfortunately not documented. I had to take a guess and could observe that whenever a lock state update to "locked" is sent when it's already "locked", a ring is detected. Since you're using continuous mode, the lock state is never locked, and thus a ring can't be detected. I'd need to figure out how this is supposed to work when continuous mode is active.

[bklaesener]

Thanks, I now read up across different forums on your previous endeavors to implement the ring detect sensor. It appears that Nuki chose to only make ring detection available via the HTTP Bridge API - too bad.

I note that I get a sequence of at least two, sometimes three "ContinuousMode" messages within 10 to 12 seconds for each press of the doorbell button:

            {
              "payload": "ContinuousMode",
              "qos": 0,
              "retain": 0,
              "time": "2023-08-04T09:04:12.498879+00:00",
              "topic": "nukiopener/lock/state"
            },
            {
              "payload": "ContinuousMode",
              "qos": 0,
              "retain": 0,
              "time": "2023-08-04T09:04:14.555939+00:00",
              "topic": "nukiopener/lock/state"
            },
            {
              "payload": "ContinuousMode",
              "qos": 0,
              "retain": 0,
              "time": "2023-08-04T09:04:22.609038+00:00",
              "topic": "nukiopener/lock/state"
            },
            {
              "payload": "ContinuousMode",
              "qos": 0,
              "retain": 0,
              "time": "2023-08-04T09:28:45.179987+00:00",
              "topic": "nukiopener/lock/state"
            },
            {
              "payload": "ContinuousMode",
              "qos": 0,
              "retain": 0,
              "time": "2023-08-04T09:28:56.402881+00:00",
              "topic": "nukiopener/lock/state"
            }

I am not sure why it is a sequence of messages - it may depend on the length of the press (which, however, was never more than 1.x seconds).

So maybe you could try adapting your current detection mechanism (state "locked" updates to state "locked") to also pick up updates from "ContinuousMode" to "ContinuousMode" (and disregard any further "updates" happening within x seconds of the initial one).

[technyon]

Yes makes sense they implemented it in a similar way, but those repeating messages are strange. The question is how long to ignore them.

[mundschenk-at]

As a complication, might this also be affected by the ring tone suppression setting?

[bklaesener]

Yes makes sense they implemented it in a similar way, but those repeating messages are strange. The question is how long to ignore them.

I did some more test runs. Each doorbell button press triggers 2 or 3 (never only 1) "ContinuousMode" messages. The last message is logged within 2 to 14 seconds of the first. So a 20-second cool-off period counting from the first message would seem relatively safe.

There are single message events, too, but they are never triggered by "manual" actions, only by "system" (nukihub) or "button" actions (or - strangely - are logged without any trigger and with no corresponding entry in the Nuki app log).

[bklaesener]

As a complication, might this also be affected by the ring tone suppression setting?

I do not have ring tone suppression activated, neither globally nor in connection with Continuous mode. Should I test with active suppression?

[mundschenk-at]

Yeah, I think that would be helpful.

[bklaesener]

Ok, will do more tests tomorrow and report back.

[bklaesener]

A few more observations:

• It does not appear to make any difference whether or not ring tone suppression is enabled.
• Contrary to my previous observation, "system" and "button" actions do trigger multiple consecutive messages under the nukiopener/lock/state topic; single messages are generated only when there is no actual trigger event.
• Based on more than a dozen tests, the longest period from the first to the last nukiopener/lock/state message remains at 14 seconds, which was a single outlier. In most cases it is a maximum of 5 seconds.

In the meantime I have implemented a ring notification that works while continuous mode is active with the following automation in Home Assistant:

alias: House Door unlatched by doorbell notification
description: ""
trigger:
  - platform: mqtt
    topic: nukiopener/lock/state
condition:
  - condition: template
    value_template: "{{ is_state('sensor.downstairs_door_trigger', 'manual') }}"
action:
  - if:
      - condition: state
        entity_id: timer.opener_trigger
        state: idle
    then:
      - service: timer.start
        data: {}
        target:
          entity_id: timer.opener_trigger
    else:
      - service: timer.finish
        data: {}
        target:
          entity_id: timer.opener_trigger
      - service: notify.mobile_app_xxx
        data:
          message: House door unlatched by doorbell
mode: parallel
max: 2

The timer.opener_trigger entity is a timer helper with a defined duration of 20 seconds. Its state is either "idle" or "active".

When a message under the nukiopener/lock/state topic is received for the first time, the timer is started. While continuous mode is active, the message is always "ContinuousMode", so there is no need to filter for message content. It is, however, important to filter for the trigger sensor value being "manual" in order to catch only actual doorbell button presses and not other opening actions.

When a second message within a 20 second period is received (i.e. while the timer is active), the timer is stopped and the notification action is executed.

[JinKanzaki]

This is interesting because I have a new puppy and have to get him outside sure regularly because he isn't house-trained. As such, I've had continuous mode active for a while now and the ring detection works the same regardless.

[bklaesener]

Interesting. So what messages are you getting under the nukiopener/lock/state topic? Must be "locked", because @technyon stated that is the only message the ring detection sensor listens for.

Maybe the behavior is influenced by the Opener configuration. I only have a "dumb" buzzer (just a button, no intercom) and a independent doorbell, so my Opener configuration is simply "Brand: -", "Model: -" and "Doorbell cable connected: yes".

[mundschenk-at]

Please don't forget that you are only monitoring the MQTT messages sent by Nuki Hub, not the actual BLE messages sent by the lock/opener.

[technyon]

It's very annoying this isn't documented at all. My new guess would be that the opener sends the last status again - although I'm not sure why this would happen multiple times.

[FrankSchoene]

Has there been any progress on this topic? I would love to have ring detection while "Continuous Mode" is On.

[iranl]

Continuous mode is now a separate MQTT topic and should not be reflected in lockstate anymore since merging #296. So this problem should be fixed in the next release.

[iranl]

Should be fixed in the current release

[technyon]

Closing for now. @bklaesener Please recheck with release 8.33. If the problem is still there, we can reopen the issue.

[bklaesener]

Unfortunately, neither the new binary sensor "ring_detect", nor the new event "ring" are triggered by door bell presses in my setup (continuous mode).

What works now with 8.33 is to monitor the "nukiopener/lock/state" MQTT topic for the payload "open". But this does not seem to feed into either of the binary sensor or event in Home Assistant.

[technyon]

ok, will reopen the issue.

[iranl]

Seeing as the changes in 8.33 now allow the lock/state to become "open" while continuous mode is active this should be an easy fix.

Looking at the Nuki Opener API a combination of the "Open" Lock State and "manual" Trigger should represent a ring (for both continuous mode and RTO?).

@bklaesener: Can you confirm that trigger changes to manual and state to open when ringing while continuous mode is active?
And can you confirm the same for when RTO is active (and continuous mode is disabled)?

I'll prepare a draft PR in the meantime

[bklaesener]

With continuous mode activated, the trigger sensor does indeed change to manual when ringing but then keeps that state, also for subsequent ring events, until the door opener is activated in another way (e.g. by pressing the button on the device – button).

The lock entity state is always unlocked, unchanged by any ring event, and never open.

So I am not sure your approach is going to work. As I wrote above, what works without fail (and also without false alarm) as a ring-to-open event indicator (in continuous mode) is checking for the payload open under the nukiopener/lock/state MQTT topic, which goes back to locked after the event. It seems that this is not properly passed on to the lock entity state.

[iranl]

The Home assistant lock entity is not changed by ring and should not / cannot be changed by it.

The logic to signal a ring to the Home Assistant event / MQTT topics is part op the Nuki Hub code and PR #315 should make sure that a ring is published to MQTT / Home Assistant if the state of the Opener changes to open (reflected in nukiopener/lock/state) and trigger (reflected in nukiopener/lock/trigger) is equal to manual

You can download the build that is created by GitHub which includes these changes from https://github.com/technyon/nuki_hub/actions/runs/8145083443/artifacts/1295917525

Please try the binary in this build and report if these changes are succesfull.

[bklaesener]

Ok, I guess I misunderstood! With the new firmware, ringing makes the ring_detect binary sensor change to "Detected sound" for 9 seconds. That had not happened before.

[iranl]

Good to hear.

Would be great if you can report in a couple of days if any false alarms are detected using this binary while your opener is in either continuous mode or RTO and if rings are always properly detected in both continuous mode and RTO.

If no issues are found i'll change the PR from draft to ready for review so @technyon can review and hopefully merge it for the next release.

[bklaesener]

Will do!

[iranl]

I do have a follow up question (please bear with me, I don't own an Opener):

Would it be usefull for the Home Assistant ring event sensor (added in #299) to have different events for:

1. A ring while RTO and Continuous mode are disabled (and thus the ringing of the doorbell will not open the door) e.g. "ringlocked"
2. A ring while RTO or Continuous mode are enabled (and thus the ringing of the doorbell will lead to the door opening) e.g. "ring" or "ringopen"

@technyon: I don't like reflecting "ring" in the MQTT lock state as it isn't really a lock state (state remains locked in situation 1 and becomes open in situation 2, ring is not a (intermediate) state the opener can have).

Seeing as ringing is now reflected in a seperate MQTT topic will you accept an update to this PR which will only reflect a doorbell ring in the mqtt_topic_lock_ring MQTT topic and not in the mqtt_topic_lock_state topic?

Might be a breaking change for those that have the ring lock state as part of an automation in their smarthome, which will require manual intervention to change these automations to make use of the mqtt_topic_lock_ring topic.

[bklaesener]

That does seem useful, especially because the the ring_detect binary sensor already does the job of notifying all ring events, so the ring event sensor currently does not seem to have a specific purpose.

Please note, though, that the ring event sensor has not detected any ring event for me, yet. It has been triggered only by restarting the nuki hub. At all other times the state is unknown.

[iranl]

@bklaesener: I've updated the PR to fix the event sensor.

It should now detect a ring event with a type of "ring" when open and "ringlocked" when locked.

Would you be willing to test the latest binary: https://github.com/technyon/nuki_hub/actions/runs/8162257175/artifacts/1299827462

[bklaesener]

Thank you, @iranl, tested and confirmed. Great job!

[iranl]

@bklaesener: Any more insights after a couple of days use? No issues? False positives/negatives?

If not I'll convert the PR to ready for review.

[bklaesener]

No issues at all, go ahead!