I’d like to request changes to and direct attention towards a behavior that was introduced with Wyze Cam Pan firmware v4.10.3.50 and persists to this day. Specifically, this…
Tethering cloud recording standards to the local storage essentially nullified the point of local storage in my opinion - at least as it pertains to Event-based vs Continuous recording. As we all know, the 12sec cloud clips and 5min cooldown periods are the standard M.O. for Wyze Cams out of the box. Local storage would always operate outside of the cooldown periods and capture footage that existed during the interims.
I very much preferred how local storage operated at firmware v4.10.3.40 and prior in that it acted like a safety net, knowing that cloud recording would miss lots of action by design. Not interested continuous recording, CMC, or other subscription services. I would simply be very pleased at the ability to choose the original method of local recording.
Event recording to the SD card still will record all events the cool down does not apply to the SD card. The post you have referenced is also from 9 months ago, so the changes he was referring to happened 9 months ago.
However, I still observe the same reduced Event-based footage behavior at later firmware levels. Something is still in play imo. I’ve observed it on numerous occasions and nothing published in any subsequent firmware release notes indicates any rollbacks that would affect or mitigate diminished recording levels.
Continuous recording works as expected, but Event-based has never been the same since beta fw v4.10.3.46. Pretty sure what Loki described above still persists by design. Feel free to give me an example that would indicate contrarywise…
I only know how it works for me now, April was about the time I started buying WYZE products.
I have 2 cameras set up with an SD card recording ‘Events Only’ they record videos to the SD card in a series of 60-second files, basically one each minute. If there is motion at any point withing that minute it will save the file, if there is no movement it discards the file. This leaves you with a series of recordings with motion, the shortest video being 60-seconds.
Yessir, that had been precisely my experience right up until firmwares beyond v4.10.3.40. Move forward and all I get consistently are smart alert clips. Very rarely would my cams write footage based on their own motion detection whenever I attempted using later firmwares. This is why I’ve asked for an explicit toggle to choose the previous standard.
I began with Wyze last February and my cams’ daily footage went to nearly nothing by end of March. Stuff that was normally there simply disappeared. My understanding is that beyond .60 you cant roll back reliably any more either due to structural/feature changes. For example, I started my Dad off @ v4.10.3.108 and then .169. Tried reverting him to .40 remotely with result that the cam only had a black screen for live footage. Oddly, it still recorded smart alert clips with full picture. Had to ship him a new microSD card w/.169 and talk him thru the manual firmware update procedure via phone.
That is interesting, because the way I described are the way mine work today on the current firmware. You are saying yours has not worked that way for quite some time.
Correct, sir! And mine would not be working the way they (and yours) currently are if I hadn’t kept them at backlevel firmware.
I’d be curious to know your results if you ever have opportunity to put two identical cams side by side with one at the current firmware level and the other at v4.10.3.40. I would be willing to perform such a test if Wyze saw fit to loan me a known working lab cam.
Here’s where cloud standards were first applied to local recording… Never seen anything to the contrary of it either:
My sense has always been that this was implemented to either support Person Detection accuracy, incentivise folks towards CMC, or simply to be consistent. I’d love to feel confident climbing aboard the current firmware train, but past testing + recent bad press = very reluctant me to “fix” what ain’t broken…
EDIT-1: Based on what you’ve described, it almost sounds as if local recording works OK if you START OUT on later firmware, but breaks for some of us who had been using firmware from before the change. I know that most cams ship with MUCH OLDER firmware oob, but if you immediately upgrade it BEYOND .40 before using it, perhaps local recording starts out on better footing…
My Wyzecam Pan will not record even though it’s set to record continuously. I have all of the settings the same as my smaller Wyzecam which records continuously no problem. I have switch sd cards, formatted on my computer and still will not record. I’m on my second Wyzecam Pan in one month. And to top it off this one does the same spinning dance every 10 minutes or so. I guess I should have stayed with the little camera.
Curious to know if formatting the microSD using the app/cam has any impact?
Thus far, I’ve been in contact w/2x users with similar issue as I’ve described… one directly and the other within another thread. The person I’ve corresponded with directly backleveled his firmware to the version I suggested and it resolved his Cam Pan motion recording issue.
You are now the 3rd end-user I’ve discussed this with, besides a couple of mavens and @WyzeJasonJ herein. Something odd definitely happened at a detection threshold/permissions level once they moved beyond .40. I’d suspect more folks have had this problem than realize/notice it -OR- they use continous recording which defeats the purpose of motion-based recording. It also seems unique to the Cam Pan and not the Cam v1/2 so only a certain percentage of folks would have it anyway.
Although I appreciate my Cam Pans for their functionality, Wyze has largely become a sunk cost for me in that I no longer update the app or firmware. Once these cams start kicking the bucket I’ll have to evaluate whether to replace them or move to another system, unfortunately.
This entire thread pertains to the long-standing can pan motion detection bug resolved last summer. Expected performance restored during July 2021 (firmware v4.10.7.798) after more than 2 years at back level firmware as a workaround.
