Evelen wrote: ↑Tuesday 09 January 2018 0:02
The problem with this is that ispy think lights turning on and off is motion
Motion detection results from image pixel variation estimates, so this issue is always there as well on cams embedded motion detection, when used. This can only be mitigated carefully tuning sensitivity/level and selecting motion detection zones less subject to this kind of changes... but not always!
For instancen cams that can switch day/night mode are not very "clever" on this: Usually, you get lots of false captures because the dumb guys who designed the firmware didn't provided the feature to switch motion detection off automatically for a few seconds when switching day/night!
On my side, as I don't want to have continous video flows using bandwidth on my LAN, I only used motion captures to FTP. Some cams (I have an Edimax the provide the feature, another from same manufacturer + other Dlink that do not) provide the ability to trigger an http link on captures that should be able to feed a Domoticz virtual PIR in the same way as iSpy directly from the IP cam.
But as it's quite uncommon, I prefer to rely on a service I wrote that monitors cams FTP subdirs every 10s (to have something still responsive enough & have time to do the in-loop processing) and, if files are found, is able to switch Domoticz associated cam virtual PIR for 10s using json http API.
It's also able to email captures (can be configured to do so only on absence, checking security panel status) in an encrypted archive + do some basic image check (more sophisticated stuff, like running another layer of motion check on camera FTP'ed motion images, would not run in the allocated timeframe on a PI, especially with several cams) to filter out those that are almost black (most of those resulting from day->night switch) for cams that provide the IR cut feature.
As well, most reliable cams on motion detection side are those able to provide separate images (instead of short videos). Don't ask me why, this is what I observed from my devices. They also allow better implementation in a security system as number of images in a time slice can be used as an estimate of motion (idea behind this: A bird passing by will not trigger many images compared to someone attempting to break your door): In a system that use an additive weighting mechanism for, lets's say 1mn time slices, were each sensor is allocated a weight... cam virtual PIRs can set a weight resulting from capture nb.
Idea behind this is an internal sensor have a base weight that immediately triggers the siren, external ones only have a fraction of it (so they must trigger several times or several sensors must trigger in the 1mn slice before cumulative weight reset) to reject false positives.
=> whatever the solution, some amount of post processing will be needed because motion detection is never perfect. Doing so, my advice is to make it per cam configurable as they will all behave differently depending on model and location.
