search

neilenns / node-deepstackai-trigger

Detects motion using Deepstack AI and calls registered triggers based on trigger rules.
MIT License
165 stars 28 forks source link

Handle cache when checking a file to deepstack AI #410

Closed jbolanosg closed 3 years ago

jbolanosg commented 3 years ago

I have several triggers that always look at the same generated files, that is, the same photo is processed by several triggers and therefore the ideal is for the file to be checked only once in deepstack (it would be when the first trigger sends it to check ) ... so when the second trigger sends to check the same file again, it is retrieved from a cache in memory and not as I see in the code now that it is sent to deepstack again.

For example with this configuration where three triggers use the same photos:: imagen

Checking the logs I see that for the same photo it is interrogated 3 times in deepstack and this is because I have configured three triggers that use the same photo ... this is inefficient because deepstack is the most expensive resource.

I reach this conclusion by checking the source code in: https://github.com/danecreekphotography/node-deepstackai-trigger/blob/189132b4f13902306979dce0807b045850255d0f/src/Trigger.ts#L79

https://github.com/danecreekphotography/node-deepstackai-trigger/blob/189132b4f13902306979dce0807b045850255d0f/src/DeepStack.ts#L12

neilenns commented 3 years ago

Your analysis is correct. This was an intentional design decision, trading off code simplicity for a relatively small amount of inefficiency.

jbolanosg commented 3 years ago

I am going to try to integrate although I must say that I am not an expert in nodejs or typescript. I am going to use as a basis the example illustrated on this page: https://medium.com/@danielsternlicht/caching-like-a-boss-in-nodejs-9bccbbc71b9b

If anyone knows what would be the best way to implement the use of cache in calls to deepstack_ai ... I would appreciate your comments.

neilenns commented 3 years ago

The fun of open source is anyone is welcome to fork a repo and hack away. That's how many of my projects start!

Be aware that I'm unlikely to accept a pull request to integrate caching changes, however. It's an amazing amount of additional complexity to save a few 100ms of call time in a situation that isn't particularly common (multiple triggers for the same camera).

jbolanosg commented 3 years ago

Ok good point .... I will try to change my configuration to use a single trigger per photo but detecting more than one type of object and working with the lowest level of reliability and doing a second processing of the message that your platform sends to MQTT .

An alternative would be to move the threshold setting as a property of watchObjects so that it would not be necessary to have more than one trigger for the same photo. An example of this configuration would be "watchObjects" : ["{name:car, threshold:60}", "{name:truck, threshold:40}", "{name:person, threshold:75}"]

neilenns commented 3 years ago

Second processing by MQTT is a great approach and is how I run. Basically use the AI as a first pass, then MQTT for more advanced logic.

Thresholds per watchObject is interesting, I'll think about that.

jbolanosg commented 3 years ago

Thank you for your interest in reviewing our needs ... I am very aware of what you define regarding Thresholds per watchObject.