Configurable retries on fetching Frigate clips

[rsteckler]

This provides two new configuration options to solve errors in the automation traces when frigate clips can't be downloaded because they aren't on disk at the time the event ends.

• frigate_retry_attempts: Specifies how many times to retry fetching the frigate clip (default unchanged at 2)
• frigate_retry_ seconds: How many seconds to wait between each retry (default unchanged at 1)

[valentinfrlch]

I try to keep the action call as simple as possible (I think it already looks pretty intimidating). I would personally just increase the default retry_attempts to 5. I am not familiar enough with frigate to know for sure, but in the mqtt message there is a key "has_clip". Do you know if that just means that eventually there will be a clip, or if the clip actually exists (and can be fetched)?

Basically, I think the issue you point out needs to be solved, just not sure if there isn't a better approach to this that doesn't involve creating new inputs.

[rsteckler]

has_clip just means that the camera was set to record at the time the event happened. It doesn't mean the clip is ready and actually I believe you can have has_clip == true and still never get a clip because of recording zones.

In any case, there is a feature request open for frigate to send an event when the clip is ready. Until then, the correct time to wait is a function of the segment time at frigate, the total duration at frigate, and the overall speed of the frigate system. In theory you might have to wait up to <segment_time> seconds for the final clip to be flushed to disk AFTER the end event. In practice, it's faster than that. The default segment time in Frigate is 10 seconds.

In my humble opinion, a default of 6 retries at 2 second intervals is right for most people. That will guarantee basically 100% of clips are ready, doesn't really block anything or over-stress the system if they never get created, and is fast enough so that if it fails the first time, the second attempt is pretty quick afterwards. An even more responsive progressive backoff would be better, but I think that's overkill here.

Also in my opinion, the extra parameters are a non-issue. You've separated the expert users from the casual users by providing a blueprint. I intentionally didn't add these parameters to the blueprint so your casual users will never know they exist. But your expert users will appreciate them and won't be intimidated. If it still concerns you, you could further separate them by adding them to an expert_options section of parameters and collapse them in the documentation inside of an Expert section or dedicated page.