Wyze Cam Pan v3 - Does not return back to home position

No doubt the Pan 3 looses it waypoint at various times and be slightly off or way off. I have 4 and they all do it to a certain extent. The ones that tend to detect flying bugs, so they move more trying to track them seem to drift off more than some I have that does not do as much panning. The more they pan the more often they drift off. I’m not an expert, but this is probably an issue with the hardware so I’m not expecting a firmware fix. Probably will have to wait for a Pan 3v2 to truly fix the problem. I love and recommend Wyze cameras but I also say they are not perfect. At this point I would not recommend the Pan 3 because of the waypoint drift, since this is sort of the point of a Pan type camera. My sad solution is don’t set the pan to move or track. If it doesn’t move it does not drift. I only pan manually if I want to look at a different spot than my one set waypoint.

1 Like

From my observations it appears to be fixable in software. From what I can tell the servos provide no feedback on position (those are much more expensive) so the software needs to calculate and keep track of the position, and currently that calculation is off (or variations in the servos are not getting incorporated into the calculation). This is why when you calibrate the motor or restart the camera it bottoms out at the extreme positions and you can hear it struggling for a few seconds, that is the software figuring out where the “end” is. If the v2 uses a servo with X,Y position tracking and feedback, I’d expect it to cost 2-3x as much. But much of that is guesswork and conjecture since I haven’t torn the camera apart or looked at the firmware, it certainly sounds like Wyze is confident they can fix it in firmware though.

Even 3d printers with stepper motors calibrate this way. They likely need to introduce automatic calibration while the camera is in use and hits a stop. It needs to be able to calibrate itself from all 4 stops back to home. I’m thinking this is why it does it more when inverted because the down stop isn’t used much. The up stop is likely used a lot in that position but might not be utilized in software properly to calculate home. This coming from a programmer who knows nothing about their software though.

I am leaning toward a hardware design deficit in the vertical axis motor that they are trying to compensate thru firmware. Teardown hardware components posted above:

I am leaning toward this conclusion based on the updates being posted:

implement the new strategy to the production line, collect more data points about the hardware deviation that is leading to drifting, and then release a new firmware that will adjust to improve the performance of the existing devices.

I think people have tried it and so have I. Makes no difference. Probably the motors always step at the same speed but the distance is just shorter with each activation. May actually be worse and it starts and stops more to travel the same distance. The pan and follow is the same from memory.

Officer: I pulled you over because you were going 60mph in a 40mph zone.
Me: But officer, I wasn’t planning on being out that long.

Just posted…

1 Like

Yeah I’m not a mechanical engineer but I’ve torn apart several 2D printers to harvest parts before disposing and they all use stepper motors, often several of them have a ring with holes and LED emitter/sensor to act as a counter for position tracking. There are motors/servos that track very precise position data and feed that back digitally but you’ll only find that in like CNC machines etc. It sounds like these cameras may not have any feedback mechanism at all other than trying to calculate voltage applied x time = position and obviously it is not perfect.

Without tearing apart the camera it feels like the X/horizontal is a gear drive and the Y/vertical is a belt drive (I’m assuming that rectangle on the side houses a belt). So obviously a lot more chance for slip on the belt portion but should not typically be an issue, I think both probably go back to tolerances and variations in the calculations.

Odd that they seem to specifically be talking about pan/scan when motion tracking causes it just as much. But I guess it is the same issue either way. I don’t use pan/scan, I just have a few waypoints set (including my “home” position) for ease of looking around, but home doesn’t put it back to its original home.

One observation, if I reboot the camera, and it does its calibration, it returns to the “slightly off home” position, but if I tap the home waypoint it goes to where it is supposed to be. So the calibration is doing something and getting things back where they should be, but it has somehow stored the last position of the camera accurately, and knows that it is not the same as the home waypoint. Odd.

The horizontal axis is direct drive, the vertical axis is ring gear drive as mentioned in my post above.
The side arm is just a support mount for the Cam. It is a conduit for the wiring. There are tear down videos on YouTube you can watch.

Yes. Because it is a mechanical failure, any Pan or Tilt movement will cause the drift… manual, track, or scan.

Fair enough, I haven’t taken it apart or watched any videos, just when installing it I noticed vertical moved fairly freely when not powered on and horizontal was much firmer. I believe I did try centering the USB connector by turning it a tad manually and thought I heard gear noise but probably not remembering correctly.

It seems to be a combination of the fact that gear lash (a bit of slop) is causing things to be different when moving in one direction or the other, plus differences in tolerances on various motors combining to cause the overall problem. So not necessarily mechanical failure in my mind, just limitations and so far not being able to compensate for those limitations with firmware.

Without any sort of feedback mechanism it will never be perfect. The only thing I could think is if the camera could take an image and compare that when returning to home to be able to center itself. But that likely would be error prone too, things change and move over time.

Honestly if it got to the point where it is a tiny bit off and it recalibrates/re-centers itself to the right spot once a day, I’d be happy with that. One of the things I’ve noticed is there is no way to tell the camera what you want your “home” position to be. So you basically use a waypoint for that. If you recalibrate the motor it returns to center X/Center Y, would be nice if you cold tell it what you want its “always return to” spot to be.

Absolutely spot on! Without positional sensors, the firmware thinks the motor and gears did exactly what it was told to do. Since there is a mechanical reason that isn’t happening, there is no way for the firmware to register the physical offset error and correct. Worse yet, cumulative offset the more it moves. While the initial reset calibration is designed to find 0,0 based on the mechanical rotation stop feedbacks in place and then do an initial reposition to home, there are no positional feedback inputs after that.

I considered a digital mapping feedback as well and came to the same conclusion.

If you are using Waypoints in Scan, you have up to 4 home positions.

If you are using the Detection Zone without Scan, it is the FOV when the Detection Zone was saved.

If you are using Tracking without Scan or DZ, the home position is the last position you manually placed the cam in.

Agreed, I am not using pan/scan just motion tracking, but have basically set a waypoint to act as “home” so I can tap it and put it back. The issue is that waypoint becomes more and more off from where it should be, and after a reboot, I have to tap it to get the camera to adjust to the correct position (which it has apparently re-discovered during calibration). Would be nice to be able to tell it - after reboot or calibration (or after inactivity) this is where you should always go, instead of the CenterX/CenterY position. It is easy when zooming in and out to move the camera a bit so “last position” being “home” doesn’t really work since you may have inadvertently moved the last position.

Not a major issue, just getting used to the nuances. I didn’t realize that detection zone became your “home” so that is a potential solution for me, there is a tree I need to block out anyway, so that along with whatever fix is coming may be what I’m looking for to get it to go back to the right place always. Just not sure if you manually move the camera, or reboot it if it isn’t on that spot, if it will return to that or not (haven’t tried yet).

Nope. That’s what I documented earlier in the thread. Set the detection zone, then tested manual Pan\Tilt, then tested Scan, then tested Tracking. The drift caused the DZ to be askew from original. It doesn’t matter what initiates the Pan\Tilt motion, Home always drifts.

Yeah sorry I wasn’t clear, what I was wondering was if detection zone was enabled (without pan/scan) if it would return to that original position after manually moving the camera. I just set a DZ, and it warns me when moving the camera that it will return after 15 seconds. But then it doesn’t. Turns out if you have motion tracking enabled, it stays at that manual position until it tracks some motion, after which it returns to the detection zone position. Strange. If you don’t have motion tracking enabled, it returns after about 5 seconds. Guess if I’m going to keep them I’ll just learn the nuances. I mean this was a prime day impulse buy and they were cheap, I wanted an NVR with 4K and hard wired but really didn’t want to drop that kind of cash, so figure this was a good interim step at least.

You know, why not have a user interactive calibration routine to calculate the necessary offsets for each camera. It would be implemented in the app and provide the values to the camera. Similar to how touch screens used to have to be. Put a red dot or circle with crosshairs over the image, user centers it on something easy to spot, camera pans left and back, user re-centers, pans right then back, user re-centers, up, down, etc. App calculates the offsets and feeds them back to camera. Seems like it would be more effective than a one-size-fits-all offset based on an average from the production line. Of course it would require app development which is probably outsourced but given all the time and effort put in so far, I’m sure the fix hasn’t been cheap to this point.

Same issues here. No surprises.
However, to make my life a little easier, I set a single waypoint so, after a reboot, my camera returns to the place I want it to be.
I have DZ and tracking on.
Reboot Daily (when I remember).

If things don’t get solved I will go back to a static cam. Too much of a pain.

I set a rule at sunrise everyday my cameras restart I have no issues


Great idea. I may need to get one now that there is a solution. It a shame you have to do the reboot.

First the positive. Had two of these for a couple of months now with Cam +. I am blown away how rare false detections are, and how well people and vehicle detection works. We have had two other major brands in recent years, and both are easily fooled causing false notifications. Probably should not say the names, but one starts with R.

After a recent very brief power outage, the camera home position changed to all the way panned to one side. Not a big deal to reset, but a bit of an issue. Wonder if anyone else has encountered this?

The camera needs to know when it is in the home position by a bit map image comparison and the stepper home location needs to be set at the privacy location if the images are not similar form the current to the last transit home. I noticed my cameras if bumped out of position ( stepper axis slip). The position and image won’t be the same indicating the stepper has lost home position. If this is the case the camera should be sent to privacy position and home reset and then sent to the home position where it checks the image similarity for the know home. A poor camera mounting and or a significant change in the home position image could present a problem. Homing using a image comparison validation.