Delayed MQTT Motion

[CodeFatherG]

Describe the bug

The motion being communicated over MQTT is delayed. The aim is to use the motion to turn on the front lights which are not battery powered therefore saving on battery but the time to detect motion in MQTT is so long that it is unusable.

As soon as I walk into frame the camera lights up and starts recording but the motion automation in home assistant takes up to a minute to trigger and turn on the lights.

To Reproduce

Steps to reproduce the behavior. Example:

1. Create this configuration file:

bind = "0.0.0.0"

# Define RTSP user
[[users]]
name = "admin"
pass = ...

# Front Camera
[[cameras]]
name = "front_door_camera"
discovery = "local"     # Discover local
username = "admin"      # Camera user
password = ...    # Camera on board pw
address = ...       # Reserved ip of camera
uid = ...        # Camera UID
stream = "Main"
idle_disconnect = true          # Disconnect on idle for battery
  [cameras.pause]
  on_motion = true # Should pause when no motion
  on_client = true # Should pause when no rtsp client
[cameras.mqtt]
  [cameras.mqtt.discovery]
  topic = "homeassistant"       # Enable Discovery with the following controls
  features = ["Floodlight", "Camera", "Motion", "Reboot", "Battery", "Siren"]

[mqtt]
broker_addr = "127.0.0.1"       # local broker
port = 1883
credentials = ...

2. Launch Neolink:

version: '3.8'
services:
  neolink:
    image: quantumentangledandy/neolink:latest
    command: ["/usr/local/bin/neolink", "mqtt-rtsp", "--config=/etc/neolink.toml"]
    container_name: neolink
    ports:
      - 8554:8554
    volumes:
      - $PWD/neolink.toml:/etc/neolink.toml
    restart: unless-stopped
    network_mode: host

3. docker compose up
4. monitor motion entity in home assistant

Expected behavior

The motion be communicated to MQTT not long after the camera has started recording (indicating that it has detected motion).

Logs

Logs

The log contains two motion events confirmed in mqtt both with varying results. The first motion was close to being acceptable delay. The second was as with every other test I have ever ran, up to a minute.

Logs are too long, sorry but I didn't want to cut them up in case of context

neolink_motion_logs.txt

Versions

Neolink software: 82524a12b2a218b8d088029e19158ed9f44de9b8 release Reolink camera model and firmware: v3.0.0.2773_23100910

[CodeFatherG]

Correct me if I am completely wrong, but it looks like we subscribe to push notifications to hear of motion, but then make a connection and read it out of the camera to confirm there is motion, then publish it?

If so, perhaps the optimization is to publish motion on notification?

[murtaugh82]

I would also find it very practical if the push notification including payload (motion, person, ...) were sent immediately via mqtt before the camera is connected. This would allow automations to react much faster on this basis.

[QuantumEntangledAndy]

Correct me if I am completely wrong, but it looks like we subscribe to push notifications to hear of motion, but then make a connection and read it out of the camera to confirm there is motion, then publish it?

If so, perhaps the optimization is to publish motion on notification?

It was done like this because of the way push notifications are start only events. We don't get information when they stop.

Consider this issue,

• push notifications is recieved
• you naively set motion to started in the mqtt
• you connect to the camera
• however the motion stopped already because of the delay
• no motion stop event is sent on the camera
• mqtt reports motion incorrectly now

The way it currently works with not reporting motion until we are logged in is simpler and less error prone.

There are ways around this of course but they require tracking state and perhaps adding timeouts for motion detected by push notifications and are not something I have motivation to work on right now. PRs are welcome though.

[CodeFatherG]

• push notifications is recieved
  • Motion is set because you are told that motion is set
• you naively set motion to started in the mqtt
• you connect to the camera
  • You connect to the camera to verify the motion
• however the motion stopped already because of the delay
  • Motion has stopped, report motion is over
• no motion stop event is sent on the camera
• mqtt reports motion incorrectly now

The benefit is faster motion trigger, the disadvantage is slower to know if it ended. I personally think it is exponentially better to know motion faster than no motion. Most motion activated events have some timeout anyway (eg my motion sensor lights are 2 min) to account for intermittent detection.

I have to be honest, I am not following on why it would be an issue to do this and delay the no detection event.

[CodeFatherG]

Here is the process I was envisioning and I know I am not the expert on this library, you are, but I am failing to see where your example above falls over other than the delay to switch motion off?