For a silly example, proof of concept:

Hey Nick, just my two cents as I tried to implememt it in the past but failed.

I think for this to work well we need some kind of ExternalTriggerTracker process. It should track the lifecycle of triggers and add events to the event queue.

Lifecycles would not be needed for stuff like:

• image/snapshot
• recording with fixed duration

But I think it is needed if one wants to:

• retrigger a recording and therefore extending a length
• send a stort - stop recording signal
• dynamically change recording length

I couldnt design such a class with its one tracking queue the last time I tried with the time I had.

Hey Nick, just my two cents as I tried to implememt it in the past but failed.

I think for this to work well we need some kind of ExternalTriggerTracker process. It should track the lifecycle of triggers and add events to the event queue.

Lifecycles would not be needed for stuff like:

• image/snapshot

• recording with fixed duration

But I think it is needed if one wants to:

• retrigger a recording and therefore extending a length

• send a stort - stop recording signal

• dynamically change recording length

I couldnt design such a class with its one tracking queue the last time I tried with the time I had.

Always open to a different arch for the solution, but I'm curious why and what benefits that would bring. I see what you're saying about advanced control of extended recording behavior, but currently frigate native events don't offer these types of advanced recording behaviors so I personally don't think that is necessary at least for an initial version.

I think a large subset of the users requesting this just want a way to key events and save the recording clips for that, and the specific extend recording feature are very edge / advanced use cases. I could certainly be wrong and may be missing some context.

Perhaps there's a more advanced iteration of this that could be implemented after.

Specific recording is already supported by my PR given that there's a separate create event and end event API, the recording length is inherently dynamic to the manual event API structure

An arg for a fixed recording length could also be added as optional if users just wanted to simply have a static recording length

I mean, could very well be me thinking to complicated.
With the event ID as return value the caller could very well care for the events lifecycle themself.

Other than transfer the logic in its own module to enable MQTT endpoints I will have to try it out for further feedback.

Thanks for taking a stab at it!

I mean, could very well be me thinking to complicated.

With the event ID as return value the caller could very well care for the events lifecycle themself.

Other than transfer the logic in its own module to enable MQTT endpoints I will have to try it out for further feedback.

Thanks for taking a stab at it!

Yeah, still got recordings to get sorted out (I think my Timestamps for start_time are wrong) so then should be in a fully testable state.

Also need to figure out if this is something the HASS integration can implement or will be strictly for advanced users.

I wasn't sure about MQTT, there aren't any other similar APIs in MQTT yet so I wanted to make sure it should go there too.

And thanks for providing feedback! Like I said I think this should hang until release 12 so there is time for fleshing it out more

Using the frame times definitely keeps the event IDs the same and is working well, but recordings still aren't kept despite has_clip being true, not sure if there is a specific call I need to do to ensure the related segments are moved out of cache

I don't think this approach will work. I was planning to address this by putting an event in the same event queue used here: https://github.com/blakeblackshear/frigate/blob/master/frigate/object_processing.py#L633

The EventProcessor will pick it up from there and everything else such as recording retention and database writes will be handled just like any other event.

I don't think this approach will work. I was planning to address this by putting an event in the same event queue used here: https://github.com/blakeblackshear/frigate/blob/master/frigate/object_processing.py#L633

The EventProcessor will pick it up from there and everything else such as recording retention and database writes will be handled just like any other event.

Okay I see, what I had mostly works except recording which I can see would be very clunky to actually get going. Plus it would ignore the retention and other settings and be more difficult to reconcile with future changes.

I'll work on refactoring this PR with that approach and see how it goes 👍

✅ Deploy Preview for frigate-docs canceled.

Any progress on this PR? I would love to be able to use this

I was just about to open a new feature request for creating new events using the api..
Awesome work @NickM-27, thank you.

Would it be possible to add a timeoffset so the clip would include X seconds before the api call?

@sinamics that is not so simple, due to the segment retention in recordings if the user does not have 24/7 recording enabled (or if they do and the mode is not all, and no motion happens) then the absolute most that could be set is 10 seconds and even then it is likely to be less.

It would be possible to use the existing pre_capture config

understood. The pre_capture config would be sufficant enough for my usecase.

understood. The pre_capture config would be sufficant enough for my usecase.

feel free to submit a PR if you'd like, otherwise I can at some point this week

im not that familiar in the backend, so you are welcome to take a look whenever you get time.
In the meantime, if I'm able to make progress on this myself, I'll certanly create a pr

I'm sorry for the blonde question but how/when do I find a documentation or example on how to trigger a recording or event or whatever via API?

this is only available in 0.13 beta for now, you'll check the docs there

Been testing this feature and it's working great. although... Would it possible to be able to trigger the manual event via mqtt ? or to at least have the newly created event published on mqtt so a HA can capture the event's information and be used for other purposes such as send a push notification with a clip or snapshot of the manually created event?

Would it possible to be able to trigger the manual event via mqtt ?

MQTT is not suitable for this type of action

at least have the newly created event published on mqtt so a HA can capture the event's information and be used for other purposes such as send a push notification with a clip or snapshot of the manually created event?

the vast majority of information that is contained in the /events topic on mqtt is not relevant to custom events. and for the other parts, you as the user already know because the user is the one sending this event.

I have no way of knowing the event's id except after it has been added to frigate and the only way to watch the event is through the frigate-card or by going directly into frigate. it would be very handy to be able to somehow get the event information once in the frigate db so it can be the clip or snapshot can be attached to a push notification vie HA.

I've been trying to find a way to get the event's info into HA without success...

I have no way of knowing the event's id except after it has been added to frigate

the event id is contained in the response of the create api, which is covered in the documentation

{
  "event_id": "1682970645.13116-1ug7ns",
  "message": "Successfully created event.",
  "success": true
}

I totally missed it... I was able to get to this feature by scattering around the source code... as in the main documentation (I believe for 0.12) is missing... so D'oh moment for me.....
Thanks a lot for sharing this...