MQTT - Doorbell Message never set back to 'false'

[nkringle]

Describe The Problem: Firstly, I don't know if this is a bug or if it should be a feature request. Basically, I am using the MQTT topics to get metrics into prometheus/grafana. (I'm creating a dashboard for the number of vehicles driving/people walking/doorbell rings.) In the case of motion and smart detections, the MQTT topic is set to true when the event fires from the doorbell, and is set back to false (and an MQTT event is fired) after the defined event timeout (motionDuration). The doorbell does not set the topic back to false.

This specific inconsistency is where I am wondering if this is a bug, or a feature. :)

To Reproduce: With a G4 doorbell, Homebridge, MQTT enabled and publishing to a topic, and listening to a topic, ring the door bell and observe that the MQTT topic unifi/protect/<Mac>/doorbell is set to true and never reset. Trigger a motion event and observe that the MQTT topic unifi/protect/<Mac>/motion is set to true and then is set to false after the motionDuration timeout. Trigger a smart motion detection event (person or vehicle) and observe that the MQTT topic unifi/protect/<Mac>/motion/smart/vehicle is set to true and then is set to false after the motionDuration timeout.

Logs: Logs from Homebridge are not applicable in this situation.

Logs are not applicable or necessary in this situation.

Homebridge Configuration:

        {
            "controllers": [
                {
                    "address": "192.168.x.x",
                    "mqttUrl": "mqtt://192.168.x.x",
                    "name": "UDM-Pro",
                    "password": "removed",
                    "refreshInterval": 10,
                    "username": "removed"
                }
            ],
            "motionDuration": 5,
            "platform": "UniFi Protect"
        },

Screenshots: Doorbell MQTT: (Notice the history tab - the topic is set to true and never set back to false.)

Smart Vehicle MQTT Topic: (Notice the history tab - after 5 seconds the topic value is set back to false.)

Environment:

• Homebridge Version: 1.3.8
• Node Version: v14.16.1
• Homebridge-UniFi-Protect Plugin Version: v4.4.3
• UniFi Protect Version: 1.20.0
• UniFi Protect Controller Type: UDMP
• UniFi Protect Controller Firmware Version: 1.10.4
• Apple Device and iOS / macOS / iPadOS / tvOS Version: tested using 2019 MacBook Pro macOS 12.0.1. Homebridge runs on a 2014 Mac mini, macOS 12.0.1.
• Operating System and OS Version: macOS 12.0.1

[hjdhjd]

It’s working exactly as designed. The inconsistency is unintentional, but serves a purpose.

The ring event can be fired multiple times in rapid succession, the motion event can’t be - there’s an enforced time duration in between motion detection events, for instance. Doing a rapid series of ring on/off events would be confusing - so we only inform when the ring event occurs. Creating a mechanism to deal with duplicates is up to you on the MQTT end.

Hope this helps shed a little light on it.

[nkringle]

That's fine - I wasn't sure and figured I'd ask before I put a lot of work into dealing with it on the MQTT side. Thanks for the quick response!

[hjdhjd]

Of course. Thanks for reaching out.

[github-actions[bot]]

This issue is locked to prevent necroposting on closed issues. Please create a new issue for related support requests, bug reports, or feature suggestions.