Multiple proposed changes to resolve retriggering and increase configurability #7
+1,188
−202
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
This is still a work in process but I made a couple minor and and couple larger changes across the script, let me know if you like any of the ideas as I am more than happy to clean them up but in this current configuration it does seem to work better for me.
Change every processing of an event to use a thread vs a process, I see little benefit from a process and it may just be harder to manage down the road.
Resolve "stationary" objects from re-triggering a new detection
Resolve "updated" but already processed events from being triggered again. My guess is the following code was meant to prevent this case:
if "summary" in payload["after"] and payload["after"]["summary"]:
Unfortunately I don't see how that would've been hit as the summary is being published to the MQTT_SUMMARY_TOPIC but only the MQTT_FRIGATE_TOPIC is subed
There is a longish standing issue that often times a single 'object' will trigger multiple almost identical events. Frigate actually has a task that cleans these up in the UI but the result I was seeing was that processing of multiple identical events with different event_ids was occurring.
The above issue, and all the general issues of multiple or unneeded event processing is being handled by two global TTLCache dictionaries
I additionally saw a large amount of errors on my frigate server from api requests for a video clip before one was available. Additionally when the script was able to get a clip, it was often too short or incomplete. For this reason I introduce the following options: (these are not meant to be used all together but instead gives a few choices of how the event is processed)
Added configurable parameters for some additional values you can checkout in the sample config including: resized_frame_size, max_response_token, max_frames_to_process, min_frames_to_process, low_detail, update_frigate_sublabel.
I added a small system message to the GPT api request and slightly modified how the prompt is being generated. I was seeing an issue that GPT responses were not consistently proper json, with these changes it seems to be a bit better?