[Bug]: MQTT stationary messages incorrect in certain scenario

[jkoopmann]

Checklist

• I have updated to the latest available Frigate version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in incognito mode to rule out problems with any third party extensions or plugins I have installed.

Describe the problem you are having

I am using MQTT messages for object detection or rather object direction detection and analyze the messages in node-red to trigger certain things in my smart home. Today I noticed the following:

Object lifecycle of a car:

1. car detected 12:10:09
2. .. update messages since the car entered other zones .. all correct
3. car became stationary 12:10:26
4. car left 12:14:11

The car actually started moving out of the area so I would have expected a "car became active" first. But for whatever reason that did not occur. That might be the first bug. But to me the problem is MQTT end message:

{
  "type": "end",
  "before": {
    "id": "1746007809.338274-y4rmqm",
    "camera": "Garage",
    "label": "car",
    "sublabel": null,
    "false_positive": false,
    "start_time": 1746007809.338274,
    "end_time": null,
    "current_zones": [
      "Garage_Auffahrt"
    ],
    "entered_zones": [
      "Garage_Parkplatz",
      "Garage_Auffahrt",
      "Garage_Treppe"
    ],
    "stationary": true
  },
  "after": {
    "id": "1746007809.338274-y4rmqm",
    "camera": "Garage",
    "label": "car",
    "sublabel": null,
    "false_positive": false,
    "start_time": 1746007809.338274,
    "end_time": 1746008056.730029,
    "current_zones": [
      "Garage_Auffahrt"
    ],
    "entered_zones": [
      "Garage_Parkplatz",
      "Garage_Auffahrt",
      "Garage_Treppe"
    ],
    "stationary": true
  }
}

That in the "before" part stationary=true makes sense. However if something disappears it should be clear that it cannot possibly be stationary anymore. :-) So I would have expected stationary:false in the after part of the MQTT end message and I believe that this is a bug.

The issue is that I filter out all messages with stationary:true in the "after" part since I am not interested in stationary objects. In this case the car was reported to be "incoming" but then never as "leave".

I could temporarily work around this by not filtering for stationary=false or by increasing the timer for stationary but it still feels incorrect.

Steps to reproduce

1. Have an object enter a zone/camera
2. Let it become stationary
3. Let it leave (best without it getting active)

Version

0.15.0-6cb5cfb

In which browser(s) are you experiencing the issue with?

all

Frigate config file

irrelevant

docker-compose file or Docker CLI command

irrelevant

Relevant Frigate log output

irrelevant

Relevant go2rtc log output

irrelevant

Operating system

UNRAID

Install method

Docker CLI

Network connection

Wired

Camera make and model

HikVision

Screenshots of the Frigate UI's System metrics pages

Any other information that may be helpful

No response

[hawkeye217]

This isn't necessarily a bug. An update message requires a number of factors to be sent.

How fast and how far did the stationary object move before it left the frame?

Additionally, the object lifecycle does not necessarily mirror MQTT messages on the events topic, they are completely different components.

However if something disappears it should be clear that it cannot possibly be stationary anymore.

This isn't necessarily the case. If the object detector loses an object in a frame and subsequently does not detect it in any other frames, this kind of situation could occur. A simple case would be tracking a person sitting in a chair in a room, and then the lights are turned off. A stationary object does not need to become active in order to be ended.

[hawkeye217]

Frigate GUI also does not show the event.

This would be because of a config setting.

However: If an object that was stationary and then is discovered as "left" the type in the after-message should be stationary:false (the object at the time it LEFT was not stationary otherwise it would still be there)

See my edit in my reply above.

[jkoopmann]

Frigate GUI also does not show the event.

This would be because of a config setting.

It usually is shown for all my cameras. In this case I suspect it really is because the car had already nearly left the cameras view, became stationary and then minutes later drove off. What setting do you have in mind? I am happy to adjust this as it might mitigate my problem as well. All stationary values are default.

This isn't necessarily the case. If the object detector loses an object in a frame and subsequently does not detect it in any other frames, this kind of situation could occur. A simple case would be tracking a person sitting in a chair in a room, and then the lights are turned off. A stationary object does not need to become active in order to be ended.

I see what you mean. Let's take your example: The person was detected, became stationary, lights go out and for the necessary amount of time it is not detected anymore so an end message is send. This means that if the light goes on again the person would be handled as a new object id, would it not (I seriously do not know). If it does - which I would understand - then it is indistinguishable whether or not the person really left the picture and minutes later came back (in which case stationary:false would be correct) or if it simply was not discovered and came back. Even in that case I (!) would expect frigate to assume the person left and hence set stationary to false.

Anyhow. If you do not want to change this because of the different view I will just have to adjust the filtering to not filter stationary:true end events and hope that this get's rid of my problem....

[hawkeye217]

In this case I suspect it really is because the car had already nearly left the cameras view, became stationary and then minutes later drove off.

That would make sense. I probably just misunderstood you initially in assuming that the entire car event was not tracked and visible in the UI.

This means that if the light goes on again the person would be handled as a new object id, would it not

This depends how long the light was off, but generally your assumption is correct. A new tracked object ID would be created that would be initially active and then take on the stationary: true attribute after the configured number of frames with no movement.

[hawkeye217]

I will just have to adjust the filtering to not filter stationary:true end events

An "end" message inherently carries the assumption that Frigate does not see an object anymore, so I think adjusting your logic is the path I would take as well.

[jkoopmann]

To give you more context: The driveway is rather long and people going down the driveway have no way of determining whether or not someone 400m at the other end of it is currently moving up. And there is NO way for two cars to pass each other. So I am using frigate to detect if a car entering the driveway/street below and have a traffic light at the top of the driveway.

What happened: One person came up the driveway. Parked there to get some stuff and then 4 minutes later took of and drove upwards. That is why I am also using end events to trigger the traffic light timer. And in this case there was no trigger which had me baffled.

With the adjusted filtering it should work and the worst thing that could happen is a two minute red traffic light false alarm...

[hawkeye217]

Makes sense. Great use case!