Skip to content

After action, delay X seconds before it can be triggered again.

CaliObserverCaliObserver
edited January 2014 in SecuritySpy
One of my cameras is near a dirt road. When a car drives by it is usually coming to my place so it appropriately triggers a motion action. Since I have this setting, after action, delay 180 seconds before it can be triggered again, I expected the dust settling after a vehicle comes would not set off more motion only one minute later, but it does. This is at night so the IR is lighting the dust, but action should not trigger again within the set amount of seconds. Am I misinterpreting the setting?

Comments

  • BenBen
    Hi - this setting applies to the Actions only, not normal MD recording. So while the Actions won't run for another 180 seconds (email notifications, sounds, scripts etc.), SecuritySpy will still record video if it detects motion. It's unfortunate that the IR lights are lighting the dust right in front of the camera and triggering the motion detection for a short time, but it sounds like this isn't a regular occurrence so I hope it's not a big problem. The only solution I can think of is to use a separate IR light a short distance away from the camera, and turn off the camera's own IR lighting.
  • CaliObserverCaliObserver
    OK I see I was at least misunderstanding that setting. Thanks for clearing that up!
  • jtoddjtodd
    This happens to me quite a bit as well. Rain and moths are frequent offenders that create long strings of false motion detection, one right after the other, especially at night. Maybe a progressive dampening effect would solve this? Flap dampening is a problem that has been solved in lots of different computing environments with various algorithms.

    Perhaps: If more than X events in Y seconds, then wait A*X seconds before turning motion detect on again, and reset only after B seconds of quiescence, where B is a function of X&Y. During dusty or rainy or windy conditions, this could lead to a progressively more sparse set of captures being taken across the interval when there were many false alarms.
  • BenBen
    It's a good idea in principal, but anything that is done to limit the detection of events which cause a lot of movement in the frame (e.g. a moth flapping in front of the camera) in this way will inevitably lead to important events being missed when you would really want them recorded. Generally you want to algorithm to err on the side of false-positive events rather than false-negative ones, to minimise the chance of missing anything important.

    The solution to these problems is intelligent image analysis, so that the software would be able to tell the difference, for example, between a moth and a human. This is difficult to achieve and expensive in terms of the CPU time required to do the analysis. SecuritySpy's existing algorithm is fast and works in most situations, which is why we haven't done such a thing in SecuritySpy yet, but it's definitely something we will consider for the future.
Sign In or Register to comment.

© Vanilla Keystone Theme 2024