[SOLVED] Camera Motion Detection Will Not Stay Disabled

[jaydeel]

I'm trying to use only IVS tripwires to trigger some of my Dahua cameras for Blue Iris (via ONVIF).

This is my configuration
1. Event > Video Detection > Motion Detection > Disabled
2. Event > Smart Plan > IVS
3. Event > IVS > Rule Config > Tripwires Enabled



Everything works as just fine... until it doesn't. Randomly it seems, one or more cameras will start triggering on any motion.
When I inspect the settings, I find that motion detection has been self-reenabled.


This does not appear to be camera-specific as I'm using 3 Dahua models and 1 Amcrest, and I've seen the issue with all of them.
And as far I can ascertain, the motion detection setting is not profile dependent (Day, Night, General).

I've "solved" this issue by periodically sending the following Dahua HTTP API command to each camera to disable motion detection (currently every 10 minutes).
http://{camera_ip:port}/cgi-bin/configManager.cgi?action=setConfig&MotionDetect[0].Enable=false

My questions are these:
1. Has anyone else observed this?
2. Does anyone know why this might be happening? Am I overlooking a configuration setting?

 

[wittaj]

Yes, many of us have noticed BI is somehow doing this in recent updates.

Some of my cams are fine and others do this.

He workaround is to set sensitivity low and remove the areas for motion in the camera gui. Not a perfect solution but at least it won't trigger then.

 

[IAmATeaf]

I get this behaviour with some versions of firmware on my 5231-ze cams. Only gets re-enabled after a cam restart. The latest version of the firmware for me fixed this and other issues.

 

[jaydeel]

I get this behaviour with some versions of firmware on my 5231-ze cams. Only gets re-enabled after a cam restart. The latest version of the firmware for me fixed this and other issues

Thanks. I've not tried rebooting. And I've never updated the firmware on my Dahua cams. I'll look into this.

I have two 5231R-ZE cams, two 2231R-ZS cams, and one SD12203T-GN (PTZ).

 

[jaydeel]

Yes, many of us have noticed BI ok somehow doing this in recent updates.

So the prevailing theory is that Blue Iris is doing this to the Dahua cameras? Interesting.
I think I prefer my solution over their suggestions.
I'll follow up with Ken and ask if he's sending the cameras commands other than PTZ/Control-related ones.

 

[wittaj]

So the prevailing theory is that Blue Iris is doing this to the Dahua cameras? Interesting.
I think I prefer my solution over their suggestions.
I'll follow up with Ken and ask if he's sending the cameras commands other than PTZ/Control-related ones.

Several of us never had that happen with a camera until an update from BI.

 

[jaydeel]

Several of us never had that happen with a camera until an update from BI.

Ken replied today...
"... this sounds like some instability in the camera, as Blue Iris does not manage those camera settings."

Today alone, one of my 2231R-ZS cams re-enabled motion detection MANY times.
I just rebooted it and this seems to seems to stabilized it.

I'm going to try firmware updates next.

 

[flynreelow]

is there a down side to using Zone Crossing in Blue Iris instead of the IVS camera event?

 

[jaydeel]

is there a down side to using Zone Crossing in Blue Iris instead of the IVS camera event?

Via the use of tripwires I've been able to practically eliminate false positive triggering events from tree shadows, cloud shadows, and car lights.
And this is after extensive experimentation with Blue Iris zone crossing.

I think it depends on your situation, so YMMV.

 

[flynreelow]

Via the use of tripwires I've been able to practically eliminate false positive triggering events from tree shadows, cloud shadows, and car lights.
And this is after extensive experimentation with Blue Iris zone crossing.

I think it depends on your situation, so YMMV.

good to know

 

[jaydeel]

It really matters if you're using the cpu version of DeepStack; false triggers cost you CPU overhead.

 

[flynreelow]

It really matters if you're using the cpu version of DeepStack; false triggers cost you CPU overhead.

makes sense.

Has Deepstack been working good with you? I still thought people were having many issues with it.

 

[jaydeel]

Has Deepstack been working good with you? I still thought people were having many issues with it.

I’m happy, but it’s taken a lot of trial and error. Whether to “jump in” depends on your personal tolerance for experimenting and tuning. Hopefully soon someone will take a stab at compiling a best practices guide.

For me, the experience improved greatly when I stopped trying to use face detection and custom models. Now I’m just using the built-in objects, and lately performance has also been pretty good at night.

 

[sebastiantombs]

My take on "best practices" so far -

Use the GPU version. Requires an NVidia, CUDA capable, GPU card.
Use short pre-trigger times, as in three seconds or less.
Custom models work.
Face detection is a little hit and miss, but again with the GPU version seems reasonable.
Set confidence level at 40%.
Set additional frames to analyze at five, depending on the scene and how long targets are visible.
DS does have problems with two things that I've seen so far, contrast is important and headlight bloom results in missed detection.

I'm getting around a 99.9% detection rate and good face captures. I haven't worked on a custom face model, yet, because it is a little time consuming. I am running the dark.pt model as well as the "stock", built-in, model with no problems. Detection times with the stock model only are as low as 55ms. With both models running they're in the 150-400ms range.

 

[flynreelow]

My take on "best practices" so far -

Use the GPU version. Requires an NVidia, CUDA capable, GPU card.
Use short pre-trigger times, as in three seconds or less.
Custom models work.
Face detection is a little hit and miss, but again with the GPU version seems reasonable.
Set confidence level at 40%.
Set additional frames to analyze at five, depending on the scene and how long targets are visible.
DS does have problems with two things that I've seen so far, contrast is important and headlight bloom results in missed detection.

I'm getting around a 99.9% detection rate and good face captures. I haven't worked on a custom face model, yet, because it is a little time consuming. I am running the dark.pt model as well as the "stock", built-in, model with no problems. Detection times with the stock model only are as low as 55ms. With both models running they're in the 150-400ms range.

deepstacks doesn't utilize Quick Sync does it?

 

[sebastiantombs]

No, but it does use the CPU and it can spike the CPU with multiple events happening at the same time.

 

[wittaj]

is there a down side to using Zone Crossing in Blue Iris instead of the IVS camera event?

Using the IVS in the camera also keeps the CPU down on the BI computer as BI isn't doing the motion detection. And on certain fields of view with lots of shadows and leaves, even if it isn't a triggered event, windy days can still drive up the CPU usage as it is tracking that motion before not triggering or triggering.

 

[Holbs]

I have had this happen on a 5231, 5442, and my SD4 PTZ.
Kinda irritating, yet something I put with with since totally awesome cameras in the big scope of things.
I will have to do the above mention of low sensitivity work around.

 

[wittaj]

Ken replied today...
"... this sounds like some instability in the camera, as Blue Iris does not manage those camera settings."

Today alone, one of my 2231R-ZS cams re-enabled motion detection MANY times.
I just rebooted it and this seems to seems to stabilized it.

I'm going to try firmware updates next.

We know BI does not manage those camera settings, but people have seen issues like that happen. My camera operated fine for two years and then one of the recent BI updates with DS and SMD and MD got turned on. Strange coincidence that people have seen it with these cameras when using BI, but those that do not use BI haven't experienced it...

If I recall correctly, I think @Wildcat_1 recommends people delete the camera from BI when he is troubleshooting a camera in the camera GUI - do I have that correct and have you experienced similar issues when troubleshooting other's systems?

 

[Holbs]

We know BI does not manage those camera settings, but people have seen issues like that happen. My camera operated fine for two years and then one of the recent BI updates with DS and SMD and MD got turned on. Strange coincidence that people have seen it with these cameras when using BI, but those that do not use BI haven't experienced it...

If I recall correctly, I think @Wildcat_1 recommends people delete the camera from BI when he is troubleshooting a camera in the camera GUI - do I have that correct and have you experienced similar issues when troubleshooting other's systems?

I have not investigated Dahua camera logs much. Would that leave a hint?