I’ve decided It’s taken Wyze way too long to address this so I’m just going to give Wyze cams one star o reviews everywhere. I have nine wise cams around my house and it seems detection zones are completely failures. It should be easy to write an algorithm to compare pixels within a zone and ignore pixels outside of the zone but somehow they are not smart enough to be able to do that. I do understand things like shadows and things people don’t think of can trigger Motion, but I am talking about things way outside detection zone, that are even marked with a green box showing this is what triggered the motion, when it is nowhere near the selected detection zone and it happens nonstop on every single one of my cameras. This is 100% complete failure by Wyze. Again, Wyze should be smart enough to write an algorithm to look at pixel changes within a specific area and ignore pixel changes outside of that area. Does anyone have any explanation for this incompetence from Wyze? Maybe they could set an option for hard detection zone boundaries. What’s the point of the detection zones if you ignore them in your algorithm?
Separate from this, I have a Wyze cam pro whose light seems to go on continuously throughout the night, but I show no motion events or anything. It just randomly goes on over and over, and over again. Maybe somebody could explain this too.
FYI, the green motion tag is often completely independent of of the detection zone on most of the cams (I say often because there are a few cases on one or 2 camera models I’ve seen where the motion tag will never highlight anything in the non-detection areas, but most of the camera models do). Seeing the green motion tag on something outside the detection zone does not necessarily mean that motion is being considered for an event trigger or AI object detection recognition.
I can explain a little how the detection zone generally works a little differently from how many people assume it works. Let’s say that someone has a detection zone set up based on this random view that I pulled off the Wyze website (from a review):
- The green zone is the detection zone.
- Yellow is a person who is 30-50% in the zone and half or more outside the zone.
- Blue is a car driving by, completely outside the detection zone,
- Red is the camera’s estimate of the motion tag or parts that could possibly be related to the motion object (called the object “bounding box” outline…to get an idea of what I mean, it’s similar to what you see when you turn on the Green motion tag for the cameras to have it highlight an object in a green box…it’s not an exact fit/outline on the object, but a box shape that goes out a little farther).
The detection zone will trigger for the yellow guy and detect it as a person even though half the person is not in the detection zone, because the AI will consider a full object even if part of it is outside the detection zone, as long as some part of the object’s bounding box is within the detection zone.
Similarly, even though the blue highlight car is 100% outside of the detection zone area, the camera may consider the whole red highlighted area as part of the car and consider that within the detection zone area and the AI would also detect that car because part of the estimated bounding box was within the detection zone even though 100% of the car never was. So in this case, it can detect something fully outside of the detection zone in certain cases. To compensate for this, it is often suggested to give an extra buffer and shrink the detection area down an extra layer or 2 to help ensure undesired bounding box overlap into the detection zone is less likely.
In some cases, it is possible that the main motion is outside the detection zone, maybe even across the street, but then wind blows some foliage around and while it may not be as dramatic as the motion across the street (so the green motion tag stays mostly on the more dramatic motion elsewhere), it might be enough to trigger an invisible bounding box to overlap into the detection zone.
It is hard to say exactly what is happening in your situation or to give recommendations to compensate for it without seeing some examples. If you are willing to upload a sample event along with a screenshot of your current detection zone, I’d certainly look it over, and some other users might have some further suggestions based on our experience working out similar issues.
Same with the spotlight issue, it would be helpful to see an example.
I agree with your frustration towards the level of failure with detection zone of any model cam without any subscription service. Despite whatever numerical value assigned to Motion Detection Sensitivity, any and all motion within the zone does not trigger an event.
ALL of my v2, v3, OG, & Pan V3 without a paid service plan, instead are set to record to SD, motion within the zone never triggers an event.
ALL of my cams with a paid service plan have NO issues triggering a motion event within the zone.
Here are two examples from this A.M. from a v3 & OG, both without paid service, recording to SD. The driveway is covered by side-by-side cams. First set taken from the right the OG, the second taken from the left, the v3. Neither cam motion was triggered (no “cool downs” or other situations) and motion is set to 60% for both.
These motion failures occur 98% of the time, randomly the v3 will function correctly and capture the motion event, roughly twice a month…
Motion detection and zone related issues have been a ongoing issue for so very long (years), but as time passes it becomes more obvious to the correlation between advertised product feature & services revenue.
(note: the preceding statement is obviously just my opinion)
How do you know that motion inside the detection zone isn’t being recorded on the SD card? Because you didn’t get notifications? Check your SD card.
I think “cooldown” still applies in this case. This is the reason, I think.
Except for a few cameras, detection zone processing happens wholly on the server, not on the camera itself. Since there is no subscription, the 5-minute cooldown applies on notifications.
to better clarify, i have all my cams set to continuous record to SD, which they do. Motion does not trigger an ‘event’, so no instance of that motion will appear on “Events” tab, and no notification occurs.
This setup is the same configuration I’ve had since i started with Wyze, and all the various functions worked as expected until a few weeks/months ago.
As for “no cool down”, you are correct with the limitation is still imposed when recording to SD, i was only stating at the time of the examples i shared, there were no other moments or activity occurring as I packed up my car, was too early in the A.M. for movement of anything in nature , and the time between packing up car on right cam, and driving off on left cam, occurred roughly 20min apart.
this is only one example, the zone/event failure to detect motion occurs more than a dozen time a day on each of the identified cams.
(hope this helped)
Clarification: There’s no limitation, there’s no cooldown when recording to SD. What I stated is that some SD recordings won’t have accompanying notification, because when there’s no subscription, notification is still subject to cooldown.
(The following isn’t all directed toward you p2788deal, I know you already know much of what I’m about to say due to your experience/expertise, including about bounding boxes, etc which aren’t something you brought up, but I am also posting some of it generally for the thread topic for the other observers to understand. Just wanted to make sure to clarify)
FYI, detection zone processing is primarily local. A couple of years ago, Wyze updated the detection zone on some/most camera models to also be passed on to the AI server so it would know what to analyze/ignore, since it used to analyze the entire view and thus give a lot of false positives. But the initial motion event within the detection zone is still determined locally. It’s just slightly more complicated than only pixel changes within the detection zone as tests have demonstrated that it also checks for the extension of the object “bounding box” that may overlap into the detection zone, even when the pixel changes themselves never do. It is further complicated by the fact that the green motion tag detection sensitivity appears to be completely independent of the official motion sensitivity settings, and it is usually completely independent of the Detection zone (most models have the motion tag ignore the detection zone). So, it may not always actually be showing what the trigger for motion REALLY was. Instead it can be regarded as more of a visual aid to help you see what has the most dramatic motion on the screen.
To see what I mean about the motion tag only showing the most dramatic motion, on most cams, they only allow a single motion tag (the V3Pro is an exception as it allows multiple simultaneous motion tags because it has a multicore & better processor, etc). So with the other cameras, you can get close to it and hold up both your arms at a right angles, now without moving your shoulders, just shake one of your arms wrists to spin your hands back and forth like “jazz hands” as they call it. As long as none of the rest of you is moving much, the motion tag will either jump back and forth between the 2 hands or stick with just one hand which appears to be the most dramatic. If you then slow one hand down, it will usually motion tag only the fast moving hand. Then if you stop that fast moving hand, it will switch the less dramatic movement. Then you can try slowly bobbing your head and see the motion tag surround your head. Then go back to furiously waving your hands and the motion tag will prefer the dramatic motion.
The point of the above exercise (which I have done on many of the cameras in the past to understand the motion tag functionality and limitations), is that the motion tag does NOT necessarily actually show us what triggered an event, nor does it always show us everything that is actually being registered motion. Instead, it appears to highlight what seems to currently be the most dramatic pixel changes in a nearby grouped area irrespective of detection zones, detection sensitivity, and not comprehensively highlighting all valid motion.
For the above reason, the motion tag is helpful, but it is not a definitive or reliably valid instrument can be the sole source of an event-triggered hypothesis, though often it is correct and it does help us explain to non-programmers the concept of what an object bounding box is and how it extends a ways beyond the actual object itself. This is why I often tell people to tun on the motion tag when they say a car is triggering events even when it is outside the detection zone, because it often helps them see that the object bounding box is dipping inside the detection zone, even when the car itself never does.
But, that initial motion event within the detection zone is actually usually decided locally within the camera.
The weird part is that there is evidence that some of the detection zone UI may have something to do with the backend lately since some people have reported the detection zone reverting to the single rectangle instead of the grid view, and Wyze fixed it without even a firmware or app update, indicating that there is something in the backend that can affect detection zones. I believe this is why some people believe the detection zone is not on the local camera. However, this actually appears to be the fact that the UI itself has some parts which are remotely modifiable without an official app update (similar to HTML code that the app looks up on the server everytime you browse to that page) and some of those UI changes can determine the detection zone boundaries that get encoded locally. But that is not indicative of the detection zone being analyzed remotely, just that the UI for determining the local encoding has a remote element to it. A little confusing, I know. But the main idea is that the detection zone itself is local, and those boundaries are passed on to the AI to tell it what it is allowed to analyzed and count as a positive detection.
I’m not aware of the underlying details, but there’s going to be some edge processing no matter what, because how can the camera know when to write to the SD card. But the point I was trying to stress is that people might equate not getting an event notification (when there’s no subscription) means there was no SD card footage recorded.
Oh, I totally agree that the push notiications and the SD card events are totally unrelated. It is possible to have SD card events record without a notification and possible to get multiple notifications for the SAME SD card event.
For example, if I stand in front of a camera (without cam plus) and do jumping jacks for 20 minutes, I might get 5-6 notifications even if the SD card just has a single “event” that it records.
Also, if my cat walks by the camera and I get a notification for it (starting the 5 minute cooldown), and then 2 minutes later I walk by the same camera, there may not be any notification (since it hasn’t been 5 minutes since the cat walked by), but there would still be an SD card event for when I walked by even though I wasn’t notified about it.
Well…. I’ve experienced something new & unexpected. Doing my routine Wyze checkin, I’ve discovered my “troublesome” cams have suddenly started to function as expected.
- Motion events are triggered only within the set zoned area, and those events are now listed within the events tab.
- Notifications were previously turned off when my troubles started, and with this new discovery, I turned notifications back on and they are correctly firing off only as I have them sent.
- Recordings for these SD record only (no paid service) cams were set to continuous, so I can only report they are recording (assuming if zoned motion events are listed on the events tab correctly, recording should follow the same)
After writing my last post, I wanted to see if resetting the zone for each cam would help; But instead of just changing the toggle switch off/on, I cleared the previous selection by pressing the “clear” command before I toggled Off the switch.
The “clear” command only appears after a selection change occurs, so you need to make a selection change before it reveals beneath selection box . Clearing reverts to screen with how-to instructions
Then backed out of settings and returned to switch toggle On and established a new zone selection, ‘save’ and backed out to commit my re-established settings.
Thinking about it: my last attempt did a better reset or clearing of previous values? It makes sense that toggling the setting off and back on (in my case) only changed to activation state, wasn’t until previous selection was cleared, establishing new selections to be saved (possible error with previous selection settings or corruption )
Whatever magic occurred (or maybe “Skynet” read our frustrations and decided to take corrective actions with my cams? )…Not sure, but I’m pleased either way!
I figured sharing my findings and efforts may hint or help someone else.
~Cheers
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.