v0.4.0 Roadmap & Testing / Feedback

[0x2142]

Hey everyone! With v0.3.5 released earlier this week, I'm going to start working next on a slightly larger v0.4.0 release. So I wanted to share what I am planning to add - as well as open a thread here for feedback for anyone who is interested in testing.

As a quick reminder - until release, any changes will be pushed into the dev branch. The dev code & images may break some things, and so please take care with using them.

Anyways, here's the current planned list:

• Support for Frigate Alerts via the /reviews MQTT topic (Design Gap: Audio events are not covered by /events topic OOB #53, Infrequent notifications #108, Filter by alerts/detections (Frigate 0.14+) #147)
  • During development, /events will still be the default unless you specify otherwise
  • Currently thinking that once v0.4.0 is released, /reviews will be the default - but open to feedback on this
• Initial support for a REST API (Improvement: REST API #125)
  • [-] Initial support for web-based config viewer (Config editing will likely come later, but we'll see how far I get with this) (Very simple configuration Editor #124)
    • I'm going to defer this until later for now
  • Re-work config validation to support both of these
• Multiple notification configs per provider (Feature: Multiple consumers for a single "Alerts" notifier #43)
  • Include notification filters (example: if we detect a person in a specific zone, use this provider/profile, etc)

I'll post updates here as I make progress. And of course, the list above may change.

➡️ If you're interested / able to test - please provide feedback or issues in this thread.
➡️ For any new feature requests, please open a new issue & I can evaluate whether to include it into this upcoming release.

[bobemoe]

Added #153 for your consideration. Many thanks for the awesome project :)

[0x2142]

Just pushed a dev build that includes support for /reviews via both MQTT and web API polling. These changes also include a lot of rework on how initial event processing is being handled, in order to try and consolidate a lot of code between the 4 total ways we get info from Frigate now (events via MQTT, events via API, reviews via API, reviews via MQTT). There are also quite a bit of changes to the default notification templates in here as well. While I have tested a lot of this after the changes, there may still be new issues with things that worked previously - so please let me know if you find any issues!

If you would like to test this, there is a new top-level config section called app with a mode toggle. events is still the default for now unless you manually specify reviews as shown below:

app:
  mode: reviews

Also as a note, this will only generate notifications based on Alerts within Frigate. In order to also notify on Detections, there is a toggle for that under the alerts config section:

...
alerts:  
  general:
    # Set this to `true` to also notify on detections
    notify_detections:
...

[mjalindahl]

So far, so good. I am using the new app>mode: reviews and there's at least feature parity to what was there before, so that's good. I'll wait to see if I get alerted via a stationary object (which frigate-notify seemed to do before, whereas HA blueprint and the new frigate native didn't).

I'll keep you posted! Thanks!

(I saw another request for sounds in Pushover - I absolutely vote +1 for that! Based on that and this new /reviews addition, I would feel confident in switching my two servers' notifications over to solely using frigate-notify.)

[bobemoe]

Using the new mode: reviews, I'm now only getting one notification per review, which makes sense and aligns with how reviews work. However, this changes my previous behavior where I received notifications for each new object or zone change, providing useful indicator of amount of activity. I see notify_once: true reduces this, but I liked the extra notifications. Ideally, notify_once should still control this behavior, allowing notifications on updates when set to false, as it did before.

[0x2142]

Hi @bobemoe - Thanks for the feedback. So I've been playing around a bit with the /reviews topic over the past few weeks & threw together a quick utility to log MQTT review messages & their associated event / detection data. Previously with the /events topic, I would get a message from Frigate with a new event, and possibly an event update, then finally an end message. So for new and update messages, I would re-evaluate whether to send a notification based on what changed vs the configured filters. However, largely it sounds like the frequency of notifications here is more than most people would like.

With /reviews, the same concept of new, update, and end exists - but the review MQTT message just contains a list of detections within each review & I have to manually go look up those events separately via the API (perhaps I could also keep track of those MQTT events separately & correlate them, but for the time being I'm not doing that since I would likely need to cache & store a lot more event info).

In my testing/logging so far, I've only ever gotten a review MQTT message for new and end events - I have yet to see an update message. So currently, my logic is to receive the new event & go look up the associated detection(s). Each detection is then processed through the typical list of filters. I'm not 100% certain under which conditions I would get an update message to the review - I assume only if there was an additional detection, and not necessarily if there were updates to the underlying detections.

So at this point, I've been debating whether to try and keep track of the individual detections & re-check them for updates until I receive an end message for the review? But again, I do wonder if this would generate more notifications than some would like to receive - and therefore somewhat negate the benefit/idea behind the review items.

Anyways - Just wanted to provide a bit of background on what I've been seeing & thinking. Open to feedback if you or anyone else has thoughts!

Edit: I also see that in the latest dev build, I didn't add processing for review update events since I hadn't been getting any. But I'll add that in for the next build & I would be curious to see if that changes anything for anyone

[bobemoe]

Yea me to! I've been logging with MQTT Explorer and I've just set up a "test camera" (MediaMTX rtsp server) so I can loop a clip and observe how everything reacts to the same conditions with different versions/configurations. Not had chance to play with it much yet though.

I agree multiple notifications is probably more than most would want when expecting functionality to be analogous with Frigates reviews, though I see no harm in allowing it with notify_once, (maybe a better default for it now would be true) and it sounds like you adding processing for review update events may well bring this back.

Think there might be some potential for confusion with the terminology "detection". A review item can have a severity of detection or alert. But then I see in the MQTT data a list of detections. I guess these are objects? I need to dive in a bit deeper.

Regarding the logic, I assume you must process the review updates in case its severity changes from detection to alert as it enters a zone? Think I need to look, at the code, can you point me to the where this is processed for both /reviews and /events

[bobemoe]

Still haven't had time to play with my "test camera" but I have been running reviews mode for a while now. Its functioning as expected. I almost decided I liked it with just the one notification as soon as the review event begins, but I then missed a critical event where someone I thought was not going to enter the property ended up coming further in than expected and I wasn't notified. Have you been able to "fix" notify_once yet by adding those extra update notifications? I do need this to be able to script priorities for the notifications for that use case where they enter another zone or combination of zones. I'm still on the first dev build but just about to update to the latest...

[0x2142]

I did add in the update processing with my changes that I pushed yesterday. So far in my testing, I still haven't come across any review events where I see an update message come in - but maybe my area just doesn't have enough interesting detections 😅

[0x2142]

New dev image building now... A bit of an overhaul of how I've been handling config file validation (#163). Hopefully shouldn't break anything - but there's always a risk 😅

[0x2142]

Been a lot of start & stop lately depending on time I've had to work on this. Merged the early REST API stuff into dev today.

I still need to add / update docs for this, but it can be enabled via the app config section, then exposing the port via docker:

app:
  mode: reviews
  api:
    enabled: true
    port: 8000

Docs are available at /docs and there are a few things available today:

• GET or PUT to /api/v1/config to retrieve or update the config
• GET or POST to /api/v1/notif_state to retrieve or enable/disable notifications from frigate-notify
• POST /api/v1/notif_test to send a test notification through any configured providers
• POST /api/v1/reload to reload the config
• GET /api/v1/status to retrieve app and notification provider status
• GET /api/v1/version to retrieve app version

[0x2142]

Updated dev image with support for multiple notification profiles per provider. Docs here if you would like to try this now.

Still have some cleanup & documentation work to do - but current plan is to release v0.4.0 in the next 1-2 weeks. If you run into any new issues with the latest dev build, please let me know here so I can fix them before release! Thank you!!

[stinkyplant]

Nice. I like the filters, but is there anyway to filter objects per zone. For example if I want my driveway to notify for cars, but I want the street to notify for usps it will also alert for cars (usps is a sub label for cars). So, currently I can't monitor the street zone as it will alert for all cars, not just driveway cars.

[0x2142]

You could do this by setting up multiple alert profiles, one for each scenario.

For example, if you were using Discord as an alert provider:

alerts:  
  discord:
    - enabled: true
      webhook: https://discord.com/api/webhooks/<webhook>
      filters: 
        zones:
          - driveway
        labels:
          - car
    - enabled: true
      webhook: https://discord.com/api/webhooks/<webhook>
      filters: 
        zones:
          - street
        sublabels:
          - usps

[stinkyplant]

perfect! Will this overwrite the current global label filters/zones?

*** nvm I found the doc. "!!!info Global event filters are processed before alert-level filters." will test this out!

[0x2142]

v0.4.0 has been released 🎉

Thanks for your help, feedback, and testing!!