Detection Zones with CamPlus - Detection OUTSIDE Zones

I have CameraPlus…

I have setup my detection zones in the camera (V3 w/Socket)

The issue is that the street and neighbors which are NOT in the detection zone are being detected for motion etc… and I thus get a plethora of falses… which I don’t want…

I’ve rechecked the detection zone on this camera is set up correctly still - IT IS.

I’ve checked on the software for this on my main phone (android) and my tablet (android), again, all zones are correct… The street and neighbors drive is outside the desired detection zone.

This I think may be tied to Camera+ as after I turned this on for the camera, the falses started… It seems something is not in sync some where???

Ideas to resolve?? Thanks!

1 Like

Is the Event Upload in question notifying you of “Motion” or is it tagging the object as an AI Smart Detection Event?

Is there a possibility of posting a screenshot of the DZ and also a screenshot of the Motion Event that tagged the object in motion with the Green Motion Tracking box?

One of the issues with the DZ when it is run thru the Cam Plus AI Engine on the server is how big that Motion Tracking box is. If any portion of the box overlaps into the Included DZ (not just the object in motion), the entire object within the box is fair game for AI Tagging.

Also, with Cam Plus, the AI Engine on the server does NOT recognize motion. So, once a Motion Activated Event upload starts, it will tag any object, even stationary ones, with a Smart Detection AI Object tag if it looks somewhat like the object. There is a possibility that it is some other stationary object inside the Included DZ being tagged.

Also, what Firmware does your V3 have running? The last update created DZ issues. A new FW fixing this was released today.

It shows as Motion and Vehicle or Persons etc…

Hmmm… I am looking at one of the the thumbnails for an event, and hmmmm… that green box for detection… might be crossing into a zone square… hmmm…

Is this a known bug???

Hmmmm… no I don’t think I am posting an image like that PUBLICLY… If can I upload on my server and send a user/pass I can do that… but security imagery like that in public… afraid not…way to possible that imagery like that and user name etc. are tied together etc… Sorry… In private I might…

That V3 is at

And considering the grief I had tonight getting the Doorbell firmware to upload/update… I think I am holding off on any more firmware updates… I though the thing was bricked honestly… but I’ve managed to get the Doorbell current and its online…

No worries on posting the DZ and all of you aren’t comfortable with that.

Since the uploads are going thru the Cam Plus AI Engine and being tagged, I would say that some portion of the rectangle that is placed around any object tagged is overlapping into the Included DZ. When this happens, the contents of that object rectangle are also included. This is their Overlap Logic. It is in place so that if a partial AI object, person or vehicle, passes thru a portion of the included DZ, it gets tagged.

It isn’t a bug. That is the way it works.

Best solution is to add a block or two to the DZ.

I have several Cam Pan 3s that have the exact same issue. I have one tilted down to exclude street traffic. And, I excluded a boundary by the street. However, it will pick up motion in the street and AI tags it as a vehicle. This is happening multiple times a day. Refer to the screenshot. I can upload video events as needed to help resolve this.

All may PanV3 cams do this and I have them stationary with Scan and Track off. I have had to pad my excluded DZ w\ extra boxes to keep it from tagging out of the DZ.

The only way to tell w\ your DZ screenshot is to see a screenshot of the Smart Detection AI tagged event that shows the object being tagged and the green Motion Tagging box that is marking the area within the Included DZ.

That LOGIC is flawed. Period… and if that is the case then it should be an OPTION TO DISABLE it or I just may pull the plug on Cam Plus as it appears this is when the false positives started.

And I definitely would call this a HUGE BUG.

I’ve REDUCED the DZ’s to the barest minimum to be of use… any further reduction would be a security issue, as in useless.

The only other corrective action I can see is would be to relocate the location of the camera, but the cable for the Light Socket that this camera controls is not long enough for that. Thats one of the reasons its positioned where it is at.

I think that “logic” needs some fine tuning, and turned off or user disable in the software some place.

I cannot argue with that. There has been much discussion within user circles about how this is reducing the effectiveness of the features.

Unfortunately, it can’t be classified as a bug since each feature is working as it has been designed. This one is a design conflict between features and has only been uncovered recently.

Not necessarily. Because of the overlap logic, only a small fraction of the total object needs to break into the DZ to be included and tagged. No longer does the object need to be fully within the DZ to produce a positive ID. But, it does make setting the DZ accurately a very difficult task in high motion areas. I have not seen any deterioration in accurately tagged objects within the DZ, but I have experienced an increase in tagged objects on the edge of the DZ that I wanted to be ignored.

I understand that if a portion of the object passing through the DZ is detected by the AI it will record and alert.

However, I can upload numerous videos showing that cars are in the street and they are fully excluded from the detection zone butt triggering an AI alert and recording.

I have tilted the camera down as far as possible to keep it from even seeing the street. Nonetheless, it’s still detected motion.

This is the meeting the needs I have for the camera. I set it to record continuously, but only alert me when there is motion. this allows me to go back and review for things going on but I do not need to be alerted for.

Also, the ring doorbell includes a look back feature. That is a user suitable length. meaning that if a detectable event occurs, the user can define a period up to 20 seconds in time before to add to the beginning of the captured event to add context to what is going on and to improve the usefulness of the video. You are also able to define the entire length of the video rather than having it stop when the detected motion stops.

So if a delivery person arrives, presses the ring doorbell then sits there motionless for a while waiting for someone to answer the door. It will continue to record rather than going into a cool down period and then you miss the end of the delivery.

I am a retired mechanical engineer that was a global director of hardware for a large company for decades. I will be glad to be part of a solution for these products.

1 Like

Actually, not even a part of the object has to go into the DZ. in my case, there is a turnaround at the end of the road by my house. when the headlights of the cars turning intrude into the DZ, they trigger the alert, the head rotates the capture the entire motion of the car driving back up the street.

So it appears that the AI is not separating “any motion” from detected objects. It is simply capturing based on any motion and then continues to do so if it sees a detectable object.

1 Like

It sounds like you are using a Pan Cam with the Track Motion on. Since the headlights produce a change in the pixelation shading within your DZ, the cam will turn to track that motion. When it does this, your set home position, for which the DZ is set, is no longer useful as it is now blocking out the same pixels but on a moving FOV. Since the cam continues to move to track that motion, it will invariably maintain that object within the Included DZ and tag the object.

Videos aren’t necessary. What is helpful is a screenshot of the actual object that shows the green Motion Tracking box within your DZ.

That is correct. As I explained in another thread, the actual physical object being fully inside the Excluded DZ is not the factor determining if it is tagged. It is the size of the rectangle that is being superimposed over that object by the cam. If any part of the rectangle overlaps the Included DZ, everything within that box is considered included and will be tagged. If, on your screenshot of the object within the DZ, there is any green Motion Tracking box placed by the cam caused by the object, the AI Engine is evaluating the object for tagging. The cam only allows you to see the the portion of the box that is within the Included DZ. The AI Engine evaluates the entire box.

Even though you may have your Event Recording settings restricted to Smart Detection Events, this is not restricting the cam from uploading all motion events. The cam has no way of knowing if the event is an AI event or not. It has no onboard AI. It uploads every motion event to the server. If there is a pixelation change meeting your sensitivity threshold, it uploads regardless of what is in the FOV. The server AI then evaluates every frame. If it positively identifies a Smart Detection object and tags it, it saves the video to your Events List. If it doesn’t, it deletes it. Since you have the Track Motion enabled, the cam will follow any motion, not just AI motion, and continue to upload throughout that process.

[quote=“SlabSlayer, post:8, topic:279003”]
Unfortunately, it can’t be classified as a bug since each feature is working as it has been designed. This one is a design conflict between features and has only been uncovered recently.[/quote]

I won’t agree with that at all. Its flawed and thus a bug… and thats all I have that would likely stay posted to say about it.

Nope… thats just using the flaw to work around / with the flaw and accepting the flaw as the correct action… Nope.

I will not agree to that being the correct operation mode…

One of a couple of things are going to happen:

  1. Wyze removes this fubar’d “logic.”

  2. I REMOVE the camera from the CamPlus AI and let the camera do its own detecting as that was fine till I turned on the CamPlus

  3. I REMOVE WYZE… and thats very very very VERY CLOSE to happening after this FORCED MANDATED FIRMWARE UPDATE! Let me tell you PO’d doesn’t cover the words I have for that move! There are nuns and priests in Italy 6K miles away who are on life support after my tirade! :slight_smile: :wink: I don’t do automatic updates on my distros for a good reason! They 9/10 includes bugs which borq up things! I let others do that testing.

I ditched Ring mostly for their crap not connecting and staying connected well… and no I have a dedicated AP for this stuff. Well located… ( I do RF related work for $$$) etc… wyze plugs sitting on the ground have worked flawlessly from the day installed…

Considering I just dropped $150 to scarf up the stuff likely going to disappear I want…it may all end up in the garbage.

YES you would be correct, I am not a happy camper… and I can tell you right now that telling my boss or our customers that the logic is great wonderful as designed. When the feedback is 180 degrees the opposite, would get me fired from that job!

So I will review what I plan to do here very shortly… I may just keep the thermostat… I’d really thought that with the success of the plugs last Xmas and over the last year or so wyze was the solution for most things, thermostat, sprinkler, add in the the security stuff… I even have work arounds for their “missing” sensors…Plus temp in area x = fan on, temp x = fan off etc…

So we shall see… ice cracking…

Let me provide some feedback…on this… I agree this info would be helpful…


IF you think I am posting that sort of stuff in a PUBLIC FORUM?!!?!? You are out of your mind! Never going to happen! Nope.

Now if wyze wants to provide a SECURE PRIVATE MEANS for this information to be provided… Then lets here about it… but till then… Nope.

As well as I don’t provide information which could locate me and considering that I can see similar devices its very possible neighbors and bad actors are present here… Again, nope.

Any way… I can tell from your replies what the issue is… This detection is just too large and the “magic” green box falls into the zones… and thus reducing the zones to stop this is the “solution.” Again, I will say no. That just accepts this is not a flaw… Wyze may consider this a non flaw, non bug, working as designed… These post show its clearly not.

So I am going to try a little, and I do MEAN LITTLE REDUCTION in the zone to see where this goes… I STILL THINK this is a REDUCTION TOO MUCH in the zones… but as this is still in sort of my “beta” camera wyze (pun! :slight_smile: :wink: :stuck_out_tongue: ) I will try it out for test…

We will see…

A bug is when a particular feature is not working as it is specifically designed. This, unfortunately, is working exactly as they designed it. Is the design flawed? Yes. I believe so. And I believe it is because of the specific type of AI object anchoring they are using.

The method Wyze currently uses is a tradeoff between fine boundary constraints and speed of detection.

The current AI Wyze developed in house appears to be a single stage AI model that uses basic bounding boxes to anchor objects. Single stage models are much faster than two stage models, however they seriously lack in the ability to distinguish the fine boundaries of objects or multiple grouped objects. But, because of their speed, they are preferred for real time applications such as Wyze is producing.

The Wyze AI uses an incredible amount of real estate when drawing that massive bounding box rectangle over the object rather than using only the pixels within which the object is residing. This is the heart of the flawed design. The bounding box used to anchor the object is much too large and significantly decreases the effectiveness of using the DZ while increasing the effectiveness of the Overlap logic. This results in the an increase of true AI detections in areas designated for no detection. If they were to tighten up the bounding box anchoring, it could very well improve DZ accuracy but may decrease Overlap logic accuracy.

There are multiple examples of better models to anchor objects rather than using bounding boxes which introduce non-object area into the Included DZ. But most of these require far more computational power and also more time to process. Wyze is recording video at 15 and 20 fps. The AI model applying the object anchoring logic needs to be able to keep up with that frame rate. Many of the most accurate AI models using far more sophisticated object anchoring logic only run at between 5 and 10 fps and would be far too slow to provide real time AI Object Detection. They also require far more server horsepower.

The issue being discussed here is far more complicated than “fix it, it’s broke”. There are layers upon layers of dynamic limiting factors that must be considered when even the smallest modifications are made to the logic. I certainly want the AI model to be better. But thru understanding even the smallest bits about the technology, its capabilities, and it’s complexities, I can begin to understand why it is proving difficult for Wyze to dial in.

You have already read my response to that Wyze decision. I saw your like :heart:. Thank you.

That is what Direct Messaging is for. User to User direct. Not public. Most users in high traffic residential areas don’t have cams placed in areas that aren’t already viewed by the public on a daily basis or contain security sensitive information. All my security cams are highly visible to the public. I want it that way. Seeing the cams is a much greater deterrent than having an attack dog.

But, again, that is a personal decision. I can respect that.


This is an example of a car during the day triggering an alert. It is completely outside of the DZ. However, it is in the FOV of the camera. In thought the whole point of an excluded zone was to keep from getting false alerts


You posted an example of your detection zone. An example of a motion trigger is an event with Motion Tagging turned on so we can see what the cam identified as the trigger (green box).

Like this, or even better the event video:

Click on the link to the screenshot directly below the visible picture

THanks! Please post the 13s event video that corresponds to 2023-11-04 09:50:05.

How do I save and upload a video clip?


1 Like