Wyzecam pan v3 doesn't return to detection zone position if motion tracking enabled

After setting up my detection zone and saving, the camera will return to the correct position after manually changing it. However, if motion tracking is then enabled, it will no longer return to the detection zone if moved manually. I have a V2 pancam which works as it should, if detection zone is enabled, it will return there after 10 seconds regardless if motion tracking is off or on. Anyone else seeing this problem?

Thanks, Rick

Welcome to the Wyze User Community Forum @rick15! :raising_hand_man:

I have a Detection Zone set in my Pan V3 with Scan off and Track Motion on.

When manually adjusting the cam using the pad controls, the cam returns to the set DZ view after 15 seconds. However, there is currently a bug being looked at that returns the cam to the DZ set position… Just a few pixels off each time.

4 Likes

Did you ever figure this out? I have two brand new Pan v3 with the same symptoms.
DZ Enabled, pan/scan disabled, track motion enabled.
Manually move the camera, warns me that it will move back, does not.
However if it then tracks motion, it will return to DZ home position after.
Toggle off track motion, returns to DZ home 5 seconds later.

With track motion disabled it works as it should (though it is 5 seconds, not 15 as it says in the warning).

I would try making waypoint 1 the same view as your DZ and see if it returns to the same location.

It already is. I tried deleting all waypoints too and same behavior. Re added just 1 single waypoint which is the same as the DZ and no change.

Obviously if I tap the waypoint it returns, but not really the desired behavior, I want to make sure if I inadvertently move the camera while trying to zoom (happens), or if the person I’ve shared the camera with moves it, it will go back to the DZ/Waypoint automatically.

I just retested this on all four of my PanV3 Cams. Odd behavior.

I am running Beta Firmware 4.50.4.4767 on all four cams on Android App 2.44.1.327. Each has identical settings: DZ On and Set, Scan Off. I usually run with Track Motion Off, however I enabled it on all four for this test.

Two cams gave the 15s warning, I manually manipulated the position, and both returned to the DZ set Home FOV after 15s.

However, the other two did not return to the DZ set Home FOV. The instant I tapped the Scan button off, they returned to the DZ set Home FOV.

I then repeated the test on those two cams, this time setting one Waypoint, enabling Scan and Track, going back into the DZ to turn it back on since enabling Scan will automatically disable it, returning to the Live Stream and manually manipulating the cam position. Since Scan was on, the cam returned to the Waypoint (same as the DZ set Home position) in 5s.

Even more odd, I then turned off the Scan feature, leaving the Track On, and now those two cams are returning to the DZ set Home position after 15s.

It is difficult to pin down a bug when it is occuring intermittently. It may be something server side that isn’t picking up that there is a DZ Home position set with the Track On and the toggling of DZ when the Scan feature turns it off resets the server settings. :man_shrugging:

Tried several iterations of that process and none result in being able to have the camera return to DZ FOV after manual manipulation, unless I turn on pan/scan with a single waypoint. I guess that sort of works, the issue there is it returns somewhere between 1 and 5 seconds (or whatever the pan/scan interval is). The 15 seconds would be far more preferable. Dunno maybe I need to factory reset the cams since they did firmware updates after I set them up.

1 Like

Also interesting that you mention server side. I’ve noticed a few times that a rule won’t run (or rather, the opposite of the rule won’t run). For example since my front door cam (OG) has enough street lights to never go into night mode, but I want the spotlight to turn on if someone walks up at night to illuminate their face (and deter them if they are up to no good), I have a rule set to turn the spotlight on for 1 minute when it detects motion. But several times now (on two different OGs actually) the light will turn on and stay on indefinitely until I go in and manually toggle it off. I was kind of assuming that maybe these instructions are sent from the cloud and for some reason the second one isn’t making it sometimes, perhaps fluctuations in wifi or just something sever-side that isn’t firing the second instruction. I’ve yet to see the light not turn on, just sometimes doesn’t turn off. I would have thought rules and other stuff like that would be sent to the camera for local use, but perhaps not.

Would seem really inefficient if it needs the server to tell it to return to DZ position after 15 seconds instead of just having that instruction locally…

I’ve also thought that there were some times when the motion detection seems delayed or doesn’t happen at all. I’m starting to think these cams are far more reliant on communicating with the server than they should be…

Is this why they’re so inexpensive, they have no CPU at all and rely on every instruction to come from the cloud?

The two cams of mine that experienced this behavior are the farthest from a node and have a lower RSSI value than the two that work all the time.

I am wondering if, rather than a server side issue, it might be a cam connectivity issue that isn’t allowing the cam to communicate with the server appropriately.

Did anybody resolve this issue yet because it’s not working on my camera either… This is getting old with wyze!! is it really is!!!I am about to throw them all in the garbage

The next Firmware Beta looks to be promising.

This is the last info published by Wyze:

Ok good thanks …Seems like the bug is only when u tap the arrow on the keypad …If u do a sweep with out pulsating the keypad its ok …Very odd ,but like I said dont tap the arrow in manual mode and it will be ok …Thats atleast a temp walkaround …

2 Likes

My Wyze pan cam does that sometimes. Detection zone dont seem accurate. It keeps tracking cars on front street even if not on set detection zone.