Outdoor Lights Triggering Motion Detection
  • New to SecuritySpy last week. Easy setup, just a switch upgrade to POE and a little attic work stringing Cat6 cable and up and running. Changing the IP address on the Dahua 4300s was easy with the tips from the forum. Now for my problem....

    When my porch or flood lights turn on/off it triggers a motion/recording event. I have tried changed the lights dimmer switch ramp time from 0.5-4 seconds with no avail. Also tried the 1s and 2s motion activation schemes. Lowered density on the motion algorithm down to 10% and still have the issue.

    I have Indigo and am headed towards using my AEON Labs motion detector to trigger the motion recording directly from Indigo but would prefer to use the motion algorithm in the camera to get motion further out from the detector as I have a pool out beyond the range of detector.

    Anything else to try before I revert to Indigo?? Thanks in advance....
  • The simplest solution I found for my outdoor lights is to have them set to come on at dusk, thus they are already on and as the sunlight diffuses, then no motion is created.
  • Generally when there is a lot of change happening in the frame it's something that you actually want to capture. Lights coming on is included in this category - flood lights that come on at night are generally motion activated, in which case you will want SecuritySpy to start recording.

    SecuritySpy does have a certain amount of filtering of whole-frame changes (such as lighting and exposure changes) but the threshold for this is set at a deliberately high level, so it errs on the side of capturing rather than not capturing. I think you have to look at the false positives you are getting as an acceptable side effect of sensitivity to real motion.
  • I do start-up lights at dusk, really the only false positives are going to be when we are home and turning the lights on/off during the night. While we are away I should only get 1 false positive when they last turn off automatically for the evening.

    Thanks for your input and thoughts.
  • Ben: could you expose those values to the interface on a per-camera (or better yet, a schedule-able method) so that we could modify them ourselves? It seems that hard-coding these elements reduces flexibility.

    Tulutrick: I've done what you describe with Indigo and my Aeotec sensors and the SS plugin, but it's kind of a hack. I created two cameras with the same source - one is a normal motion detecting feed that SS controls. The other "camera" (same actual IP camera device) has the motion detection sensitivity cranked way down (zero) and is only triggered by Indigo firing an API call to record motion/pictures on that camera. This way I can get both distant events of large objects (vehicles) and time-lapse outside the PIR range, as well as PIR events that might not trigger the motion detection.

    Also of note: I have a few Axis cameras with the built-in PIR, which work quite well and even have bright LEDs that flick on and they make one of several noises (including "psst... pssst" which is my favorite.) Then they call a URL when triggered. I have them pointed at my SS server to the "record" API URL for those cameras, so that they self-trigger a motion record event. The downside due to the way SS's security model works is that now I have multiple cameras scattered around with the root password for SS stored in them, and sending the root password at every motion detection event. Not very secure at all. In fact, it's kind of crazy, and I'm considering abandoning that method entirely because of the security implications.

    JT
  • Hi JT,

    There's a necessary compromise between ultimate flexibility, and usability of the software. If all these parameters were available to adjust it would clutter the UI and make configuring the software frustrating and confusing. So we've attempted to choose default values for these hidden parameters that will work best in a variety of circumstances, based on our extensive testing.

    With the Aeotec sensors - is there a particular reason why you are use two camera instances in SecuritySpy? I would have thought that a combination of SecuritySpy's motion detection, plus the detection from the sensors, would work pretty well when applied to a single instance of the camera.

    As for using SecuritySpy's password in the HTTP calls to trigger motion detection, this is no problem if the traffic is within your local network (LAN). No one can access this traffic from outside your network. If you're worried about this, then simply use SecuritySpy's secure HTTPS server instead.
  • I understand the need to keep the interface simple for users who have smaller requirement sets. But I also have seen Security Spy thrown out because it can't move from "simple" to "complex" which has exactly (or worse than) the same result. There is a difference between "expert" parameters that are accessible to the knowledgable and "hidden" parameters that are inflexible no matter how clever the user is.

    I use the Aeotec sensors for cameras that don't have PIR. I have too many false alarms with the motion detection algos still on my cameras, so I've kind of given up for those entirely as useful alerts that should trigger an SMS. However, they're sometimes more sensitive at distances so I leave it turned on in one camera instance to capture the "edge case" stuff that I might want to review via the browser. The Aeotecs are always accurate, so I create another camera instance with motion detection turned down to zero. When the Aeotec is triggered, that goes to Indigo. Indigo in turn reaches into SSpy and forces a motion detection event, which then sends an email->SMS.

    1) Security Spy is not always talking to cameras on a LAN, and saying that a LAN is secure is a fallacy. 2) Camera vendors are hopelessly clueless or are glacially slow to change, if ever. 3) Security Spy has a bad security model in a limited way. We, your userbase, are powerless against this combination - only YOU have the ability to make it not suck because we can't solve #1 and #2.
  • Hi JT,

    Thanks for the explanation about your use of the Aeotec sensors, this makes sense.

    I don't agree that SecuritySpy has a bad security model. Of course if the communication is done over the internet there is some risk of interception, but this can be surmounted by using secure HTTPS. Over LAN, the only way that someone can intercept the communication between the camera and the computer is if they somehow manage to install malware on the Mac running SecuritySpy, and if that happens you've got bigger problems than exposing your SecuritySpy password.

    In any case, we are of course open to suggestions as to how to improve security. For example, it seems to me that a new permissions option for web server account to "Allow triggering motion detection" would resolve your concerns - that way you could use a special user account that only has permission to trigger MD for the cameras you specify. Do you agree? This would be relatively easy to implement.

    I take what you say about the "power user" settings on board, and will see what we can do about this in a future update.
  • The "bad security model" I'm referencing is having the root/admin user necessary to execute a motion detection event. Ideally (as you mention) having a user which is able to trigger motion but not able to do other things (like delete footage or turn off cameras) would be the best solution.

    As I said, the combination of camera vendors not supporting HTTPS plus the inability to granularly specify certain permissions makes this a bad combination. Splitting out the ability for a non-admin user to trigger motion detection would reduce the threat profile of this problem significantly. If that's an easy fix, then it would be great to see it happen.

    Also: on a LAN it is quite trivial to intercept communications between the camera and the computer without installing malware on the Mac. arp poisoning, DNS poisoning, DHCP intercept, switchport mirroring are all hacks I have seen firsthand in the wild and there I'm sure are many others that I've forgotten or just don't know about yet. These methods can be used to intercept data, or insert/replace data. You know those spy films where they cut the camera cable and play back a tape of yesterday's video so the screens show nothing amiss? The equivalent can be done with IP cameras, even with HTTPS since Security Spy doesn't seem to have the ability to understand permanent certs - it accepts whatever cert is presented, which can be different every time it connects to the camera. Maybe saving the cert signature (at a minimum) after first presentation and then checking thereafter would at least make this a lower hanging fruit (though still not as secure as it could be.)
  • Hi JT,

    Though DNS or DHCP-based attacks wouldn't work when using static IP addresses for all LAN devices (which is what we advise in our various setup guides), and ARP-based attacks require existing access to a device on your network, I do take your point about the need for security, even over a LAN, and of course we are very interested in implementing anything that will help with this and give customers peace of mind.

    Therefore, as discussed, I have implemented the new "Trigger motion detection" web server account permission in the latest beta version of SecuritySpy, which should significantly improve the security of your usage case. Please test and confirm it works as expected.
  • It works! I've tested basics, and the permissions model does seem to be appropriate. Thanks!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!