Filter by alerts/detections (Frigate 0.14+)

[bobemoe]

Is your feature request related to a problem? Please describe.
Since Frigate 0.14 events have been divided into alerts and detections. I have configured Frigate to only consider certain objects/zones as alerts and categorise the rest as non essential detections. I am however still getting notifications of both!

Describe the solution you'd like
To be able to filter out the detections.

As well as filtering these detections out completely it may be nice to send them as a lower priority so the end user app can filter them out appropriately there with different popups/sounds etc. I feel this is almost a separate FR as priority could also be set based on Zones/Labels too, and I'm not sure if/how all the different alerting methods handle priority!

Describe alternatives you've considered
I'm pretty sure it is possible to recreate the alerts/detections functionality I have defined in Frigate using the Zones/Labels filters here in frigate-notify.

Or maybe a custom template could do all this including the priority as long as all the original MQTT vars are there.

Both methods feels a bit duplicative and will of course get out of sync when I change things in Frigate.

Additional context
I haven't considered much yet how this would be structured in the config. I'm new to Frigate, never actually used pre 0.14, and am still setting up so as I become more familiar with the config I may post some further thoughts here.

[freefd]

@bobemoe, can this comment cover your requirements for Ntfy?

[bobemoe]

@freefd ah yes, some logic like that is exactly what I was considering would go in the template to enable customising the priorities! Thanks for the link, would have taken me a while to realise it needs to be in the headers, it would probably work as a good workaround to re-prioritise the detections, will have a play, thanks.

I still think some extra config options would allow this to be done more slickly now Frigate has split events into detections and alerts, and allow it to follow what is defined in Frigate. At minimum maybe:

alerts:
  zones:
    unzoned: block
    alerts: allow
    detections: block

Once I've polished my workaround I'll probably have better config suggestions.

[freefd]

@bobemoe,

At minimum maybe:

alerts:
  zones:
    unzoned: block
    alerts: allow
    detections: block

^^^ Here you are mixing different things in terms of physical meaning: zones, signaling and consequences.

First of all, we need to understand the difference between Alerts and Detections from the Frigate perspective. To me, I would consider Alert as a consequence of Detection that has fired by some rule.
Because Detection can be just a movement (i.e., the wind blowing the van with Ellie away), or it can be actual human recognition (i.e., suspicious activity of a man with a machete in the backyard).
Technically, both of these events Frigate can represent as a classic event to the MQTT bus, but the second one will be recorded as Alert due to some configured rules on the Frigate side.

[bobemoe]

Ok, maybe that config needs to be up a level, but yeah you are right we need to know how Frigate handles this and what is published to MQTT. I will dig in a little...

[bobemoe]

So it seems nothing about the alert/detection status is published in frigate/events.

A new topic frigate/reviews was introduced in 0.14 that tracks the review item from start to finish and publishes its alert/detection status along the way. https://docs.frigate.video/integrations/mqtt/#frigatereviews

I don't think this is going to be a quick feature :/ Implementation would either need:

1. Cross referencing events with reviews to get the status, or
2. Using reviews instead of events, which I guess would be a backwards compatibility nightmare!

[freefd]

@bobemoe,

2. Using reviews instead of events, which I guess would be a backwards compatibility nightmare!

See #80 (comment)

[0x2142]

Just chiming in here to say that I haven't forgotten about supporting Frigate alerts via the /reviews MQTT topic - it's just been a busy couple of months for me & so I've mostly been focusing on minor fixes and improvements as I find the time. I've looked at it briefly a few times, but need to spend some time trying to figure out the best way to implement alongside what has already been built.

That being said, I've got a small handful of bigger items that I want to work on but have had to delay for a while (including this). So my current plan is that once I publish the next release (v0.3.5), I'll start focusing my time on working toward a larger (v0.4.0?) release to support a lot of these things.

[bobemoe]

@0x2142 ahha you're already on it! Sorry I did not realise yet. Your priorities sound sensible.

I am sure I can workaround for now with a combination of Zone/Label filters and conditional logic in the headers.

Look forward to seeing support for the /reviews topic, I can see it will bring some nice features. Thanks for the awesome project. Let me know if/when you want it testing, I'm sure I'd jump on a dev/beta and try it out :)