I’ve been using version 4.36.9.139 for some time now. I initially tried upgrading to the version 4.36.10.2864 when it was released, but was since recalled due to major issues in event recording - which I experienced, resulting in manually flashing to downgrade. Since then, I’ve been notified of another upgrade to 10.4054, but am now experiencing connectivity issues to the camera, which I now need to manually downgrade again.
While there are new features in newer versions, I’m primarily concerned about not falling behind on security updates. However, its hard to assess the urgency of any security updates as the release notes are not descriptive to a severity. I’m also interested in reliability in keeping the reliability in the camera, and willing to compromise being somewhat out of date.
My current process seems like it will need to be the following: get upgrade notification, wait a month or two, check if post-production problems are mentioned in the release notes, then consider upgrading only then. I’m wondering if there could be a better way to hop from one stable release to another, like pinning releases that have had minimal reported issues, and having that be an advanced option to choose from (even if its a pro-only feature).
I normally wait on App versions and camera firmware updates until I read more positives comments on this forum.
My strategy can also be hit or miss. Some have had problems with v3 firmware 4.36.10.4054, but it has been working fine for me and I have not needed to restart my cameras in over a month and a half.
Welcome to the Wyze User Community Forum @Badger389183!
Please expand on this. Where will these releases be pinned? Who is deciding what constitutes “minimal reported issues”? Beyond the already available option to decline updates, what “advance option to choose” do you envision within the app?
I have been on the immediate firmware update train since the .10 version of the firmware first introduced the granular AI notification toggles and the fix for the 256GB SD Card recording limitation. However, the biggest change from .9 to .10 was the security updates… Whatever these were.
I have been updating 16 V3 cams to Beta Firmware thru every Beta release since .10 was introduced. I currently have all of them on the most recent Beta.
My V3 cams are my most distant cams with the worst RSSI. Yet, I have experienced no connectivity issues. I have had two of my most distant cams get a bit laggy loading, but a router reposition to improve the RSSI fixed that. Any connectivity “offline” issues I did experience was when I had them on a rinky dink WiFi router long ago. I fixed that by putting the cams on Smart Plugs scheduled to cycle the power every night. It seems that keeping the IP fresh in the router or keeping the cam RAM fresh goes a long way toward maintaining the cam’s attention span. I have upgraded routers twice since then but have not stopped the plug power cycle routines. I have also added V3 cams since then that are not on smart plugs and they do not have any connectivity issues.
Internally by Wyze team. Its not like there is a way to have the community pin releases in the app. I suppose its possible to make a community list but I’m sure if that would go untested or without debate.
Who is deciding what constitutes “minimal reported issues”?
The only group that can make solid confirmation on that would be Wyze. I don’t have access to the operations reports of Wyze, so I am unable to accurately answer this question. With that, I’m sure they have compiled reports of the number of issues and severity in a given release. There is clear evidence of this, look at the Firmware Release Notes. You’ll see that some releases have notes that say "We’re slowing down the gradual release for this firmware while we check on some reported issues*, and some don’t have any warnings on them. So Wyze already has some indicator of whether or not a release was stable or not.
Beyond the already available option to decline updates, what “advance option to choose” do you envision within the app?
I suppose I’d imagine something like “Auto ignore non-pinned/stable releases” or something of the sort. It could always be possible to upgrade to the latest version regardless, but it’d be nice to only be notified after a release has had some success.
I don’t have a fully scoped out figma or a full feature design, but stable releases aren’t an uncommon feature is software nowadays, and it seems like this use case probably matches what most of us want.
Whenever there is a new Beta Release Firmware or App Betas, the release announcement gets posted here in the forum (and on other socials) to the Beta category for Beta Testers to give feedback. There isn’t much Wyze Team interaction there unless it is a major issue and the Devs need logs submitted to investigate. But, there are Wyze eyes on the feedback.
When a new public production firmware or an App update is released, it is posted to the Wyze News category for the same sort of feedback. Many of these are pinned for a time until Wyze unpinns them.
Unfortunately, the level of detail provided in the Firmware Update web page is the same as what is posted to the top of the threads here in the forum. Wyze isn’t going to publish an assessment on the level of stability of a release update. If it goes south, they just halt the release and go back to developing the fix.
Watching the release topics here in the forum or other socials gives users the opportunity to review feedback for themselves so they can make an informed decision about updating.
I usually see the new releases in the forum before I get the update option in the app. But if your cam gives you the update option, you can decline it then find the release thread so you can read all about it before updating.
All of that makes, and the only way to really see if a firmware is stable or not is to peruse forums, wait some time, and check if the release notes have an issue. I figure that Wyze wouldn’t like to mark stable releases, as it would make users feel like to feel like production testers rather than getting stable updates.
Honestly, my idea is to write a script that automatically skims the release page and determines the latest “stable” release by checking it doesn’t have any warnings or issues after 2/3 months, and maybe link comments/threads with the same version in the title/first post to dig further if needed. Not that this is exactly a foolproof stable plan, but seems like it greatly automates the basic decision making and research (for me and many people). I feel like that logic would be the equivalent of the “testing” releases in Debian, and right now we get the equivalent “unstable” Debian releases from Wyze.
I guess to follow up, I really don’t mind spending time deciding whether upgrades are worth it for my software. For example, I have a router running OpenWRT and I consistently check release notes, visit threads, keep track of specific bug reports, new features and updates, and so on. There are breakages in that software that require perusing the forums, but the number of devices they support without any sort of telemetry is quite impressive. That is an FOSS project, and all of those individuals contribute their free time to build the project, so it makes some sense. Further, I can see all issues down to the fine detail to the lines of code, so there is the ability to completely audit the entire change log if needed (can’t say I have the skill for that right now).
Wyze, on the other hand, is for-profit and proprietary, and I have a slightly higher expectation of stability when there are paid developers consistently working on a product, especially if information is limited. If I experience two failed upgrades back-to-back for a single camera, and I have to peruse forums instead of release-notes (to my fault, this release did say some reports, which missed my eye) and in-app notifications for my device, it seems like that is a UX improvement for Wyze to consider. This is just my experience, and I’m sure I’m just unlucky and that the firmware works fine most of the time. But my needs for upgrades on more critical devices are almost always in the following order: stability > security > features. Maybe even having the release notes be available in-app would reduce my time of research even if a little bit?
It is really just semantics, but Wyze operates releases on these three levels as well. The only variable is the non-standardized benchmarks implemented by the Devs as to what constitutes “Stable” so that the release can be elevated.
Alpha Testers are working in the “Unstable” range with the Devs prior to any Beta announcement here in the forum or other socials. They have their own feedback vehicle to Wyze.
Beta Testers are working in the “Testing” level and reporting feedback to Wyze here and in other socials. I am a Beta Tester.
Any production release that comes thru the app for general consumption is in the “Stable” category, although some would dispute this. Again, it depends on the decision by the Devs on the importance of the update as to what acceptable risks there are in elevating it to the Stable Public Release. There aren’t really any universal industry standards or restrictions for when that decision is made.
I am with you on the expectation that production releases be as close to bullet proof stable as possible. This is an area of discussion throughout the forum and a concept that Wyze has, IMO, not fully embraced. Whatever the factors contributing, the speed to release seems to be more of a factor than stability. I believe the testing program needs to be more robust, have more direct discourse with the Devs, and have higher gateway benchmark standards.
Makes sense. The faster release cycle likely has to do with the push for new features rather than a strong focus on stability (for-profit makes sense, as pushing new features out means possible revenue gain).
If a release makes it to the Stable category and is pulled from the shelf, I think that is an indicator that Stable isn’t really stable but really “almost stable production testing ready” - where slow rollouts are done, and statistics are gathered over time, and then they work on fixes for that in the following release(s). The Release Notes seem to tell this story as well, especially with the suite of updates following 4.36.10.2864. Hence, my idea of automating the process of “tell me the latest release without release note issues that is at least 2-3 months old” seems like it would be a strong indicator of the actual stable releases
but I’m sure if that would go untested or without debate.