Forwarding Frigate events to Ntfy #635
Conversation
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #635 +/- ##
==========================================
+ Coverage 42.10% 42.39% +0.29%
==========================================
Files 83 83
Lines 3826 3854 +28
==========================================
+ Hits 1611 1634 +23
- Misses 2215 2220 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Observing programming errors happening within the `is_filtered`, `get_topic_data`, and `get_all_data` functions, and their callees, was painful. Let's be more verbose now.
This will instruct the `file` service plugin to write the payload in binary mode.
Use `cam-testdrive` as a camera name across the board.
Use `goat` as label across the board.
Dynamically compute name to snapshot file, based on `camera` and
`label`, using a filename template string like
`./var/media/{camera}-{label}.jpg`.
Excellent! Thanks for adding your suggestions, I will try to bring them in. May I ask you to also share your walkthrough? It may be useful to spice up the README, specifically if you are using a setup based on Docker, which I did not take into consideration yet. And of course, this is the area where things may still want to be improved, with respect to your comments about addressing the filename/URL of the attachment. Specifically, it would be so kind of you could provide walkthrough steps for me how to get the Ntfy part running. I've never used it, and it would be sweet to also bring it to the README. Edit: I will try to get an Ntfy instance running later, based on 1, and bring it to the README. Footnotes |
| click=f"https://frigate/events?camera={event.camera}&label={event.label}&zone={event.entered_zones[0]}", | ||
| attach=attach_filename, | ||
| ) | ||
| return ntfy_parameters.to_dict() |
There was a problem hiding this comment.
In order to quickly patch propagating the corresponding file reference to Apprise/Ntfy as filename instead of attach. Untested!
| return ntfy_parameters.to_dict() | |
| params = ntfy_parameters.to_dict() | |
| params["filename"] = params["attach"] | |
| del params["attach"] | |
| return params |
There was a problem hiding this comment.
Forget about that unless we've made any progress on switching to HTTP PUT, see #635 (comment) ff.
|
I've just familiarized myself a bit more with Ntfy, and found that example how to attach a local file 1. It looks like Ntfy has all the machinery in place to accept and store files, and provide them again via HTTP, so this is indeed what should be leveraged here. Is it only the current Ntfy implementation based on Apprise, which is not permitting to use the feature like that? Footnotes |
|
I've not further explored this space more deeply yet, but I quickly want to share some pointers. Maybe this can contribute to improve the implementation, both for mqttwarn, and Apprise.
So, could using // WithAttach sets a URL that will be used by the client to download an attachment
func WithAttach(attach string) PublishOption {
return WithHeader("X-Attach", attach)
}
// WithFilename sets a filename for the attachment, and/or forces the HTTP body to interpreted as an attachment
func WithFilename(filename string) PublishOption {
return WithHeader("X-Filename", filename)
}Footnotes |
|
TLDR; To actually upload data from the client, we should use the HTTP PUT request method offered by Ntfy. InvestigationsI've discovered the Python client implementation ntfy-wrapper. This is the corresponding code which implements the "attach" feature. From the comments, we can learn that either Proposal
This effectively means I propose to use the "Attachments" feature of the Ntfy server to implement this feature. In this way, the client, in this case mqttwarn, will include the attachment within the request to Ntfy, so Ntfy does not need to resolve the resource from an external URL. The improvement here is that we do not have to care about how to make the image available per HTTP 2.
Please let me know if you see any problems with this approach. Footnotes |
There aren't any problems with your approach necessarily, but there are potential blockers elsewhere. To reiterate/condense these:
I initially suggested sending the attachment through the request body in the OP of this issue, before I realized Apprise most likely didn't support it. I see three options to improve the situation:
|
|
Yeah, I am actually looking at the second or third option you've mentioned, other than also telling @caronc of Apprise fame about it.
Please help me understanding this detail. Personally, I've not discriminated between "snapshot image" and "thumbnail" yet, but I am not a user of Frigate. As far as I was concerned, images are arriving now in mqttwarn using the code we added to unblock receiving binary payloads, and that data was what I was looking at. Please educate me if and how this |
|
Frigate seems to be excluding I have no preference on whether the thumbnail or full snapshot (internally and previously known as clips) is used. Snapshots are usually very small in resolution anyway. |
|
Excellent, thanks. By the way, have you been able to figure out in which order both messages (event vs. snapshot) will be published? |
|
As far as I can see the image usually arrives after, though I can't confirm if it is actually being sent after or not. This seems to end up working fine in my environment, as the latency for Ntfy to send the HTTP request seems to take just longer than publishing and saving the new screenshot. |
I've expected the same. However, this detail is important. What does |
examples/frigate/frigate.ini
Outdated
| [frigate/cam-testdrive/goat/snapshot] | ||
| targets = store-jpeg:cam-testdrive-goat | ||
| [frigate/cam-testdrive/squirrel/snapshot] | ||
| targets = store-jpeg:cam-testdrive-squirrel |
There was a problem hiding this comment.
This section may be condensed, depending on your taste, see Templated targets » Example 2.
There was a problem hiding this comment.
It was needed to accompany this by a corresponding frigate_snapshot_decode_topic() user-defined function, see d8a2e45.
|
Hi again, I had to take a step back and deactivate the snapshot -> attachment forwarding, in order to get a test suite in place with b6ac3fa, which now covers the rest of the story. Within that, we are running end-to-end integration tests with an Ntfy instance now, provided by Docker. I will merge this now, also in order to be able to bring in GH-636. There will be a subsequent iteration, which will bring back the attachment forwarding. Please don't stop submitting your suggestions as we go, I love them. With kind regards, |
About
@sevmonster came up with an interesting use-case, aiming to subscribe to events from Frigate, and forward them to Apprise/Ntfy.
Details
A special property here is that there are two message types, for events and snaphots, where both will have to be correlated or synchronized somehow, so the solution must be stateful in one way or another.
What's inside
This patch brings in the configuration and adapter files into the
examplesdirectory (thanks, @sevmonster!), and may also include corresponding commits to unlock one thing or another. The corresponding README can be better consumed in the rendered variant.References