One Camera / 2 Motion Masks - Trigger Rules / Schedule
Greetings,
I have a single camera that is duplicated so I am able to use 2 different motion detection masks based on time of day. I use scheduling to alternate between the two configurations. I noticed that when the schedule executes and switches from one mask configuration to the other a movie is triggered/captured using the configured pre/post capture settings. I initially thought that perhaps it was the pre/post capture settings between configs overlapping so I added a delay between the respective start and stop times of the configs. That did not make a difference.
This is not a problem per se. I am just curious as to what is triggering the capture. Is it the application of the different mask that acts as the motion trigger when the schedule executes or other?
thanks
Comments
-
This sounds unusual - simply arming the camera based on a schedule should certainly not trigger recording. Could you please email us one of these files, so that we can take a look and see if we can determine why its recording was triggered? If it's too big to email you can use wetransfer.com to send us the file. Thanks.
-
Hi,
Thanks for the info. I only recently began utilizing schedules and presets so it is quite possible that a configuration error on my part is involved. I am still in the Beta stage of how to utilize sSpy, the camera/s involved, motion sensors and Hubitat all in light of my visual environment. (There is a lot of noise. shadows, winds, small animals and the occasional human). I have checked and reworked scheduling/presets so sSpy is alternating between the 2 camera configs every 15 minutes to expand the database of events. Previously the camera switch was occuring twice a day which is really not much to go on in light of the many vagaries. I am going to leave this run for 24-48 hours and will report back.
Clarification: Pre/Post Capture is configured 120/120. When the schedule switched cameras; the resulting capture was 120 minutes in duration not 4 minutes as my initial post implied.
as always - thank you
-
If you have lots of motion, and the switch is happening only twice a day, then it could just be a coincidence that a trigger is happening around the time of the switch. A schedule switch just by itself should certainly not trigger recording - only actual motion should do that.
120 is an unusually long pre-capture time; a more usual setting for this would be 3-5 seconds. The purpose of this feature is so that you can include in the recording the period of time just before the trigger, capturing any important activity that happens just beforehand that isn't enough to trigger recording - for example, a person in the distance walking towards the camera. So I would recommend reducing this to 5s or perhaps 10s at the most, unless you have a good reason to want a much long time.
Note that both the pre-capture and post-capture values are in seconds, so with 120s pre and post, a brief motion event will create a 4-minute recording.
-
Yes, I was thinking it may very well be a coincidence as well hence the temporary re-scheduling to obtain more data points.
The long pre-capture time is because the video capture is prompted by a motion/contact sensor monitoring a pet door. (The motion/contact sensor is the most reliable means I have discovered of monitoring the door's activity and the cat's coming and goings.) The long pre-capture allows the family to see the route the cat took to make its journey home. It also allows us to view the arrival path/s of other animals that visit. I could set sSpy to record continuously but this method self-edits the footage for me.
I realize the capture time values are in seconds.
"so with 120s pre and post, a brief motion event will create a 4-minute recording." << This fact is of particular intrigue to me now. I noted earlier today that when a video capture coincides (coincidentally or ?) with a scheduled camera change the recorded video is only 2-minutes in length when in theory it should be 4-minutes? I need to review some more footage to see if there is a pattern or a trigger prior to the schedule change.
-
Update - Resolved.
I set up scheduling so as to catch more data points. As Ben suggested "it could just be a coincidence."
It ended up being a happenstance of coincidence and convergence. The camera configuration used during daylight hours is set to motion capture. Its motion detection mask covers the complete image area as the visual environment is extremely noisy. Motion captures are triggered by a Hubitat Hub using a combination of motion and contact sensor rules. The night time camera configuration also utilizes motion capture. However its motion detection mask is configured to watch for "all motion" in defined regions in addition to being triggered by posts from the Hubitat Hub.
Events were occurring such that the Hubitat would trigger a motion capture while at the same time the night time camera mask might also be triggering a motion capture. This convergence would routinely coincide (more than I would have imagined) just before the schedule presets were changing active camera configurations. The elongated pre/post motion captures defined (120/120) was the icing on the cake so to speak as the pre and post recordings overlapped when the active camera configuration was switching.
Ben. Thanks for your time and patience and assistance.
-
Great to hear that you have resolved this. When multiple different events can trigger recording it's sometimes a bit difficult to determine what has been the cause of a particular recording.
In terms of the pre/post-capture and movie length (assuming a brief non-repeating trigger): at the moment that the camera's motion-capture mode is armed, no pre-capture buffer that has been built up yet, so if a recording is triggered at exactly this time, you should expect a 2-minute recording. Only after the camera's motion-capture mode has been armed, waiting for a trigger, for more than 2 minutes would there be enough data in the pre-capture buffer to result in a 4-minute recording. So this could explain the shorter movies that you have seen. But as I mentioned I would really recommend using a far lower value for the pre-capture buffer!
