Hi folks,
Recently updated my wyze v3’s firmware to 4.36.13.0416 ferom 4.36.9.136 recently after the forced update…and unfortunately this is why I am not fond of updating. It seems like after the update my v3 is having issues where the record light gets stuck on after recording motion. It will record, send the event as designed…but the record light gets stuck on. I checked to see if this was a notification issue and cleared it but the light wont return to blue. Never had this problem on the previous firmware.
I have tried rebooting but to no avail. Is anyone else suffering from this problem? Is an older firmware not affected by this issue? Any guidance here would be appreciated. thank you.
1 Like
After that big of a jump in firmware, I’d recommend factory resetting and re-adding the cam. If you don’t delete it from your app/account, it should re-inherit all/most of its settings.
Others who have made that jump from the RTSP firmware everyone was holding onto to the new required one (either via the 3 or 4 OTA updates or the single SD card manual update) have found a factory reset necessary for one reason or another.
I suppose that is the next thing to try. I do still run wz_mini on my device for local root and some funcationality but dont need the RTSP. The big jump causing settings issues is fair, just a weird issue to begin with. when I have some time I can try a reset and see where things go perhaps…if anyone else has seen this let me know as the current firmware claims to fix this issue, yet its occurring.
I didn’t realize it was a bug reported by others, but I’d still give it a shot. It isn’t a bad idea regardless considering the big jump in firmware.
However I would also test removing your SD card (and thus the Wyze Mini Hacks bootloader) reboot the cam, and see if that resolves the problem. May even have to factory reset after doing that - I’m not sure if that bootloader leaves any traces on the camera itself after reboot. Many could not get their cameras to boot/upgrade the firmware at all when that was installed, they appeared to be bricked until they removed it, so I’m surprised you got this far. As I’m sure you know anything after the 9.136 firmware “may” support that bootloader, and from what people here have seen, it doesn’t really.
I did the reset last night and so far it is ok, however the issue itself is intermittent in my experience with it. I will continue to monitor and see if it comes back. I think if were good for about a week I can call this fixed.
Can safely report that this fixed it. Might be right on the firmware upgrade rocking the boat. Wyze Mini hacks DOES infact work. Calling it “incompatible” is a bit misleading. The root shell functionality of it still infact, works fine. Furthermore, what is in the firmware flash kernel wise and in wz_mini is in fact the same kernel :). The rtsp functionality is the only thing that is broken, and its libcallback ability.
In short, yes i wanted to wait a bit and make sure all was well before reporting but since the reset, I havent seen the light issue come back.
On their site they say firmwares beyond the 136 are not officially supported and “may” work. Many here found that attempting to upgrade the firmware with the bootloader on the SD card prevented it from working and appeared to brick the cams (though removing the card and rebooting fixed it). So I’m not sure I’d exactly call it compatible either…
I still would wager to not call a broken firmware update an incompatibility. Usually those installing that, its expected to be more knowledgeable going in.
I know how the script works is an exploit in the v3 bootloader which is hardware (there is no way for wyze to patch it out) and that could cause the strangeness when updating. In any case, the solution seems simple. remove sd card, do update, reinsert sd card. used that method personally with no issue and wz_mini works fine.
FWIW also, they have a way now to spoof firmware version so the legacy firmware (for now) lives on.
A few of the threads here contradict that, which was the whole issue. It turned into an “oh by the way I’m running mini hacks” very late in the thread and after lots of blaming Wyze for bricking their cams…
By all means, those with the desire/requirement to run it, go for it, the caveat is don’t blame Wyze when their firmware update process is interrupted by a custom, unsupported bootloader you put on. One should know to remove that until fully updated, then check and see if it still works after.
In any event, on the topic at hand, this issue was not wz_mini. It was being caused by the icam binary which is launched by wyze and manged by them. All the hack does, is load a custom kernel which allows them to launch busybox, and whatever scripts they wish to run.
For what its worth I have been through the source, and have even contributed back to that project. The hack does nothing to firmware updates NOR the icamera binary which wyze runs. If the update is breaking imo, its wyze’s fault. As although the software IS custom, unless the user has enabled the option to disable firmware updates (and any update fails with that setting enabled, but will install if disabled). There was a big mess here when this generation of firmware launched. Though it HAS improved, it is not what id call stable. Some of these bugs feel like literal amateur hour. Ask google or ring if they have these problems? they don’t.
This is literally because wyze in an effort to kill a way to bypass their paywalled system moved all the libraries on the device from independent files on the system to a monolithic binary that runs on the device, thus sacrificing stability.
IMO the real fix to fix this would be for wyze to impliment a checksum into their firmware updater. Download the WHOLE file, THEN compare the checksum with a copy on the web, if they match, update. if not, fail. But there needs to be a guardrail here. I for one, will NOT be updating again until forced. At the moment my device is stable, thanks to a modification I was forced to do to improve usability and stability it is MORE secure than stock (wz_mini has an iptables module in the kernel, stock does not). Furthermore, examining the update, it appears features in the stock firmware that now exist seem to be pulled from hacks like wz_mini_hacks.
In short my issue here, was wyze, not the modification. My record led is a pretty basic function and should work.
I was more referring to the failed firmware updates that lead people to think their cameras had bricked (which I suppose the solid red light could have contributed to). Once they removed or formatted the SD card, all was fine. Even the ones that seemed to be bricked came online after removing SD card and factory resetting or even just rebooting.
I don’t know anything about the wz_mini other than it intercepts the bootloader to allow it to access portions of the OS that weren’t meant to be. I can’t say who is to blame, but people posting that Wyze firmware bricked their cams, when it works perfectly fine without the Wz_mini SD card inserted, seems pretty inaccurate to me. The fact that those people were holding on to very very old firmware versions to make the hack work, which then required multiple firmware updates to get to “current” also complicated things. Obviously Wyze isn’t testing firmware to see how it interacts with 3rd party unsupported hacks, or even testing upgrading from several year old firmware to current (which, we now know actually works fine, it was just that most people on that old firmware were on it because they were running a 3rd party bootloader/firmware).
As you say, anyone doing unsupported stuff with their cams should at least have the knowledge to know they’ll need to be cautious with upgrades, do some research, and there may be some glitches or road bumps along the way.
Welp. at the time of this writing I thought it was good, but i just witnessed the camera having issues again 
this time i came home from running a quick errand out, and while the camera seemed to set my away settings correctly, coming back did not go through the first time (at least it failed ON this time and not OFF)…my trigger script reported no problems, so the problem mustve been the cloud/api side. However after the event occurred, the record light became stuck on again and required me to reboot the camera to correct. I have made no changes to the camera after resetting it.