[Issue]: Zone filtering with cooldown

[maxoss]

Description

I think I've found a bug regarding zones and cooldown time. When entering a zone I expect a notification. In the first trace no zone is identified in the MQTT message. After the first MQTT message I received 4 more in 90 seconds. Only the last message has the zone indicated Because the cooldown is set to 120 seconds I never receive a notification. I think this cooldown should be bypassed when the first zone indication is received.

Version

0.12.0.4e

Automation Config

alias: Frigate Notifications (0.12.0.4e)
description: ""
use_blueprint:
  path: SgtBatten/Beta.yaml
  input:
    camera: camera.camera_oprit
    notify_device: 38e5b43d96cf57270382a9b58f8b0ea2
    base_url: https://home.*****.duckdns.org/
    critical: "true"
    alert_once: true
    update_thumbnail: true
    video: >-
      {{base_url}}/api/frigate{{client_id}}/notifications/{{id}}/{{camera}}/clip.mp4
    color: "#f44336"
    android_auto: true
    zone_filter: true
    zones:
      - oprit
    labels: []
    cooldown: 120
    title: Camera oprit
    message: "{{ label }} detected - {{ camera_name }}"
    debug: false
trace:
  stored_traces: 40

Frigate Config

mqtt:
  host: 10.0.0.14
  port: 1883
  user: mqtt
  password: *****

go2rtc:
  streams:
    #rtsp_cam_record:
    camera_oprit:
      - rtsp://****:*****@10.0.0.24:554/cam/realmonitor?channel=1&subtype=0
    rtsp_cam_detect:
      - rtsp://****:******@10.0.0.24:554/cam/realmonitor?channel=1&subtype=2

cameras:
  camera_oprit:
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://127.0.0.1:8554/camera_oprit
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/rtsp_cam_detect
          input_args: preset-rtsp-restream
          roles:
            - detect
    record:
      enabled: true
      retain:
        days: 3
        mode: motion
      events:
        retain:
          default: 10
          mode: motion
    snapshots:
      enabled: true
      timestamp: true
      bounding_box: true
      retain:
        default: 30
    motion:
      threshold: 80
      mask: 0.163,0.935,0.163,0.987,0.284,0.987,0.284,0.935
    zones:
      oprit:
        inertia: 1
        coordinates: 1226,471,1153,720,174,720,0,400,0,335,303,172
    objects:
      track:
        - person
        - cat
        - bicycle
      filters:
        person:
          threshold: 0.78
        bicycle:
          threshold: 0.78
        cat:
          threshold: 0.7
    review:
      alerts:
        required_zones: oprit

detect:
  fps: 8

detectors:
  ov:
    type: openvino
    device: CPU
    model:
      path: /openvino-model/FP16/ssdlite_mobilenet_v2.xml
model:
  width: 300
  height: 300
  input_tensor: nhwc
  input_pixel_format: bgr
  labelmap_path: /openvino-model/coco_91cl_bkgr.txt
version: 0.14

Any other relevant information

No response

[SgtBatten]

The zone change should have been enough to trigger the automation in a subsequent loop.

Are the 4 messages you refer to the one event of 5 total events.

[maxoss]

4 new triggers which restart the automation. Only last trigger has the zone change so not in the loop of the first triggers

[SgtBatten]

Ok.

Don't think we can help this one much inside the blueprint.

If we try to bypass the cool down when the first zone notification is received it would apply any time and therefore the cool down would be useless. You might as well disable it in that case.

If we set the zone as a condition earlier in the automation, the loop will never keep looking for the zone change, so also a bad solution.

I suggest you do one of two things.

1. Build your own Boolean filter using the custom filter field that works as a cooldown but with more complex logic based on notifications being sent (tested against standard conditions in the blueprint)
2. Upgrade to frigate 0.14 and use the alerts functionality combined with the 0.14 version of this blueprint #216 so that those first 4 never trigger the automation.