[Feature Request]: Minimum score condition/filter

[Will-Bassett]

Hello, thank you for the great blueprint. I think the below would be a valuable addition and I suspect not too difficult to add.

Describe what you are trying to accomplish and why in non technical terms I want to be able to filter out events below a certain score so they are not sent as a notification at all.

Describe the solution you'd like I would like a configurable minimum score value field exposed. If an event falls below this score then a notification will not be sent for that event.

Describe alternatives you've considered The event threshold values in frigate itself could be adjusted to not trigger event creation at all, however I am using Frigate+ and working to train a model so I would still like events to be created within Frigate, I just don't want to receive notifications for ones with a lower score that are likely false positives.

Additional context As referenced above, I think this will be particularly useful for Frigate+ users trying to train a model.

[SgtBatten]

I began adding each filter that was requested but the list was getting long so we made a customer filter that can handle any template. You can employ this using the custom filter in the beta currently

[Will-Bassett]

I began adding each filter that was requested but the list was getting long so we made a customer filter that can handle any template. You can employ this using the custom filter in the beta currently

@SgtBatten Thanks for the reply. After playing around with it some I don't think this will work as intended though... at least not without some other supporting functionality. I'm still learning but what appears to be happening is that the event is created with a lower score and then later updated with a higher score as Frigate's recognition of the object improves. However it looks like the blueprint only captures the initial score value. So my assumption is the blueprint would need to have functionality added to watch for updated score values to really make this work as intended. Any thoughts or other suggestions?

[SgtBatten]

The blueprint processes the updates also so it would get the updated score. We use updated information for lots of purposes in the second half of the automation which loops.

There's an example of extracting the top score here https://github.com/SgtBatten/HA_blueprints/blob/main/Frigate%20Camera%20Notifications/Guide%3A%20Configuration%20Options.md

[Will-Bassett]

The blueprint processes the updates also so it would get the updated score. We use updated information for lots of purposes in the second half of the automation which loops.

There's an example of extracting the top score here https://github.com/SgtBatten/HA_blueprints/blob/main/Frigate%20Camera%20Notifications/Guide%3A%20Configuration%20Options.md

@SgtBatten Thanks for the example. That is the same syntax I've been using with no luck. If I lower my check value to below the initial score it works but it doesn't seem to work with higher values that Frigate eventually gets to and are subsequently reflected in MQTT. That's what made me think the score wasn't being updated but if you are saying it is then I'm not sure what I'm doing wrong.

Maybe I'm missing something? Here is my YAML:

alias: Frigate Notifications (0.12.0.3c) - Driveway
description: ""
use_blueprint:
  path: SgtBatten/Beta.yaml
  input:
    camera: camera.driveway
    notify_device: -removed-
    attachment: snapshot.jpg
    update_thumbnail: true
    critical: "true"
    silence_timer: 60
    custom_filter: "{{ event['after']['top_score'] |float(0) > 0.95 }}"
    button_3: Silence
    button_1: View Clip
    button_2: View Snapshot
    mqtt_topic: frigate/events
    debug: true

To test it wasn't my syntax I changed 0.95 to 0.50 and it worked fine. However, Frigate and MQTT reflect top_score values of 0.97+ in later updates so 0.95 should work though... Any ideas why it isn't?

[SgtBatten]

My initial thought is that something else needs to make the update loop want to send a notification, and then the condition needs to be met.

So if the event was super short, it's possible no reason to update was triggered. I'd really need to review the individual mqtt messages in conjunction with the debug outputs in the trace to see what the automation was processing each loop

[Will-Bassett]

My initial thought is that something else needs to make the update loop want to send a notification, and then the condition needs to be met.

So if the event was super short, it's possible no reason to update was triggered. I'd really need to review the individual mqtt messages in conjunction with the debug outputs in the trace to see what the automation was processing each loop

@SgtBatten I would think the result value change of the custom filter should be enough to trigger sending a notification in itself? I guess maybe that isn't how you intend it to work though?

Not sure what you deem "super short"... Should have been at least 15 or 20 seconds I would think... maybe closer to 30 even? In the context of a security camera event though I would think this would be pretty common... on average maybe even shorter? Fairly confident I did an even longer (several minutes) test with the same results though.

Anyways, not sure if you're interested/willing in continuing to look at this and potentially making a change or not? If so I'm happy to provide whatever information you want/need. If not, I can probably fork it and make it work for my specific use case... though I suspect not good enough to PR (if it was something you'd even accept anyways). At the moment I either get 0 notifications or a flood of false positives... so not really usable for me currently, unfortunately. Just trying to get a feel for how I should proceed. Either way, thank you.

[SgtBatten]

Enable debug and please share the trace of a false negative

[Will-Bassett]

Enable debug and please share the trace of a false negative

@SgtBatten Thank you for continued help on this. Attached is a trace of a false negative, as requested. Frigate shows this event lasted a little over a minute and reached a top score of 99%. I believe the initial score was 88%.

Let me know if you need anything else.

trace automation.frigate_notifications_0_12_0_3c 2024-03-22T17_06_30.681514+00_00.json

[SgtBatten]

Can you please try this @Will-Bassett

You'll need to manually copy the blueprint into home assistant. If you overwrite your existing beta file and then refresh automations it should update to version d of the beta. https://github.com/SgtBatten/HA_blueprints/blob/custom-filter-patch/Frigate%20Camera%20Notifications/Beta

[Will-Bassett]

Can you please try this @Will-Bassett

You'll need to manually copy the blueprint into home assistant. If you overwrite your existing beta file and then refresh automations it should update to version d of the beta. https://github.com/SgtBatten/HA_blueprints/blob/custom-filter-patch/Frigate%20Camera%20Notifications/Beta

@SgtBatten I've only run a few tests but so far this looks to be working as expected now! Thank you so much!

I will report back if I run into anything in the next few days but I suspect its good to go now. Thanks again!

Edit: I do seem to be getting a lot more updates of the same event (re-pushed via notification) than I recall now though. Is that intended? I do have it set to update the snapshot so maybe that is it? But I would have expected 1-2 updates at most. I was getting quite a few more than that (at least 6 or 7+ I think) with latest version though. Can post another trace if need be.