You’ll forgive me for remaining cautiously optimistic. They are saying that the bricked devices that are missing existing data that allows it to handshake properly, we’re going to downgrade of a specific firmware version, then during the attempts to handshake it will automatically start a firmware upgrade and then re-write the missing data? ok, I hope they really are gonna make that happen.
1 Like
How did you generate the list of nodes ?
My guess is that you mounted the generated JFFS2 (part,dat) file first., How? By using Emac’s script?
Then how did you get a list of overwritten .product_config files inodes? isdel or something?
I wonder where they got that idea.
Sad state of affairs when consumers have to fix the devices themselves.
Quite a coincidence indeed that Wyze announced news firmware addressing bricking after customers posted a path to a bandaid fix in their forums…
Lets not kid ourselves though as good as the provided fix is, it is really only a band-aid because it doesn’t address the root cause. That being said I am definitely not going to criticize said band-aid as this is WAAAY better then waiting for cams to brick while out of warranty and have no other option but to expand landfills…
I am super glad for the IIW of this world that at least help bringing balance where others screw up.
1 Like
No, I used jefferson utility. -v option lists all the inodes. Then I had to modify its source code to print the contents of all versions of the given inode (and not just the last one).
Mine never did come back on. I finally had to call Wyze and they’re going to send me a replacement and told me to just recycle the “broken” one. Not going to attempt to do anything with it since I know nothing about the insides of it.
Was your camera still under warranty?
Yes. They’ve already sent the replacement out.
1 Like
I have several V3’s that were bricked by the beta firmware update a couple of weeks ago. I tried following instructions from @IIW to get the .product_config size, regardless of where I put the “ls -la…” line the lsinfo.txt always has the following:
total 0
drwxr-xr-x 2 1000 1000 3 May 13 2022 .
drwxr-xr-x 22 1000 1000 283 May 13 2022 ..
So, no file are listed…
Anything else I can do revive these?
Thanks.
Try adding
mount -t jffs2 /dev/mtdblock6 /configs
line before ls -la ...
Thanks. That got the files listed. But, unfortunately, the size of .product_config is not 0 and equal to the size of MD5.xxx.config.
Then there is some other issue. May be you could recover the cameras by trying to update to different firmware versions from SD card (you should not have wz-mini-hacks on the card if you want to do it), but you probably have tried it.
The better way to troubleshoot it would be to connect serial port and see what errors it prints out during the booting (or by executing logread command), that might give some hints about the issue. But that would require disassembling the camera.
Woohoo!!! One cam back three more to go!!!
I have figured I might as well go ahead and backup the iproduct_config for my still working cams so I checked one cam only to find that its config file was also 0 bytes while still in working order! 
Any thoughts/theories as to how can this be? I don’t necessarily expect you to know but you appear to be the most knowledgeable in the forum. 
The only thing I can think of is that they started to use MD5.XXXXX file when .product_config is not available. Or there is something happening when you are trying to copy the file (while the file itself is correct). Could be that the permissions are set so that you can’t read it. Could try to do
chmod 777 /configs/.product_config
before copying it.
Ok maybe it was a fluke or code-18 on my part…
For everyone else I would STRONGLY suggest you do a backup of your .product_config while your cam v3 are still working!!!
All you need to do is to replace the IIW command :
ls -la /configs/ > /opt/lsinfo.txt
sync
to
cp /configs/.product_config /opt/.product_config
sync
That way [Mod Edit] you will be able to recover by restoring your backup “.product_config” file by using the following command (if you have saved your “.product_config” backup file on the root of the SD card) :
chmod 777 /configs/.product_config
cp /opt/.product_config /configs/.product_config
sync
This will avoid you having to setup WSL in Windows or any other Linux flavour thsat is out there and jumping through Linux hoops using Jefferson just to attempt to recover from a deleted file.
With that kind of backup I feel safe going all out updating all my cams.
MOD NOTE: Post edited to conform to the Community Guidelines.
How is the backup done? Also, you said to replace the IIW command to something else. When is that done?
Thanks.
The backup.m is done by following IIW instructions ( Wyze cam V3 stuck on solid red light - #256 by IIW ) and then replacing the following in his instructions :
ls -la /configs/ > /opt/lsinfo.txt
sync
With
cp /configs/.product_config /opt/.product_config
sync
This command copies your .production_config file on the root of your SD card.
1 Like
Thanks to @IIW assistance, I have a functioning camera again. Thanks again to @IIW for the great writeup and help again! Much appreciated!
1 Like
I went through the process and got something similar. My .product_config was size 428, same as my MD5.xxx.config file on both of my v3 cams. So they remain bricked still. I was able to claim an extended warranty for 1 of the cameras via credit card but the other one fell outside the extended warranty period.
Weren’t they going to release a quick update that would bring these bricked V3’s back to life? Did that ever happen?