I ordered two V3 cameras from Amazon. I’m trying to flash RTSP firmware, but no matter what file or SD card I use, after the purple LED is displayed, it blinks red indefinitely and does not get past that. This was on a fresh and paired camera. I also formatted the SD card using the SD Card.org formatting utility.
I move demo_wvc3.bin to the root on the SD card, power on while holding setup and wait for the purple LED, then it eventually goes into an indefinite blinking red state. Am I missing something or have V3 cameras been recently blocked from RTSP?
RTSP was eliminated years ago, and the last nail in the coffin was when Wyze updated to new authentication a couple months ago and the old firmwares (which supported RTSP) stopped working completely.
There are options out there but you’ll need a NAS or PC running docker/container and software to stream the video constantly and convert it to RTSP.
That doesn’t explain why the firmware loading process via SD isn’t working, unless these new cameras come with an updated bootloader which prevents it. I configured a camera and it updated, but the other one I did not even configure and it does the same thing.
@carverofchoice and @grapefruityoda may have more info on it, it was discussed here recently when they forced an update and everyone who had been sticking to the really old un-secured firmware had to upgrade and finally give up the RTSP.
I tried to manually flash an older firmware supported by wz mini hacks and I get the same result, endless red flashing. It appears all firmware downgrading is prevented by this new update, which V3s purchased on Amazon must have.
I believe the latest version that worked was from 2022, and since that version no longer can connect to Wyze, it wouldn’t be useful even if you were successful. Not sure if downgrade is possible or not, but you’d be left with a cam that you can’t configure so wouldn’t be any point anyway.
There are other ways to do it, like using Tinycam or similar to stream your video and convert it to RTSP. It isn’t as efficient but it is doable.
It was my understanding that only the Roku version of the V3 cams received the Secure Boot “Upgrade”…Wyze V3’s should still be able to be flashed to RTSP firmware as far as I am aware.
Now it is true that the forced V3 update did prevent the minihacks project and some similar ones to stop supporting RTSP. I assume that is what dave27 is remembering. He’s totally right that the SD card add-on hacks lost some of their utility after the forced update, including RTSP. But the RTSP firmware itself should still be functional and work okay as far as I recall.
The forced Wyze update and some firmware update versions also would not allow people to roll back to earlier main firmware line versions prior to that update, but I don’t recall some my home assistant peers mentioning their Wyze RTSP stop working or they’d be pretty outraged.
My first thought is that you might be accidentally following the wrong instructions because the Instructions on the Wyze webpage actually have a Mistype in them right now. Step 4 and 5 are incorrect. Currently they say:
4 Ensure the unzipped folder is named “demo_wcv3.bin”.
If not, rename it.
5 Drag the folder to the root directory of the microSD card and then remove the card from the computer.
That is wrong. You do NOT change the folder name or drag the whole folder onto the SD card. You pull out the .bin file out of the folder and put that on the root of the card. But then I saw you said that is what you did.
This is something else that is sometimes important for some reason:
Note: We recommend using a 32 GB microSD card in format FAT32 for firmware flashing.
I don’t know why, but sometimes if you use different size SD cards or exFAT, it won’t work. Some cameras will work fine with other cards, but some won’t. So if you’re using a different card, that may be why.
If you can’t get it to work by flashing to the official Wyze RTSP, then consider looking at Thingino project to get RTSP on your cams. I’ve heard great things about this.
Here are the instructions for the 5 different variations (there are different combinations of SOC & WiFi modules in some V3’s) of the Wyze Cam V3 models:
Also, where did you get the RTSP firmware from? a trusted source? I’ll copy for you my list of options I have been collecting that people use to RTSP for Wyze cams just in case any of it is useful, including the links directly from Wyze:
RTSP Options
Common 3rd Party Solutions to get RTSP on Wyze Cameras:
This App has historically supported ALL Wyze cams, but can only be used on Android. Many people use either an old Android phone or an Android Emulator on a computer to run it constantly. The creator/Founder became a Wyze Employee in 2020.
Scrypted now natively supports Wyze to get RTSP, though most people in their Discord server recommend just using Docker Wyze Bridge instead to get the cameras into Scrypted, it is included here for convenience.
Note that this project may lose some functionality with some of the newer firmware, and while you may be able to revert back to older firmware, you may put your security at risk by doing so.
Note that this project may lose some functionality with some of the newer firmware, and while you may be able to revert back to older firmware, you may put your security at risk by doing so.
Open-source Firmware for Ingenic SoC IP Cameras, which includes Wyze Cam Pan 1, Wyze Cam 2, Wyze Cam Pan 2, Wyze Cam 3, Wyze Video Doorbell 1, Wyze Cam Pan 3 (conditionally supported and has Secure Boot which could render your camera unusable). Make sure you download the firmware that matches the camera model, SoC, image sensor, Wi-Fi module, and flash chip size.
You can follow this video and script to identify which firmware you’re supposed to get for your particular camera (which hardware revision your camera is): https://www.youtube.com/watch?v=SX637mrp0R0
Isn’t it now only possible to configure/set up/etc the cam using the newer firmwares? Or I guess if you ONLY want RTSP (no Wyze app) then using the older firmware is a viable option (but how do you configure options for night mode etc in that case?)
Maybe I’m recalling wrong but I thought the whole reason it won’t work on the newer firmwares was due to the fact that they lock the bootloader or at least prevent something from intercepting it on boot (sort of the same thing), which is why everyone was sticking with the old ones (until the forced update).
Totally possible I missed a thread of someone reporting this. I found recently that my forum account is hiding a large percentage of unread posts from me.
I just don’t recall anyone being kicked off the rtsp firmware or losing access to those cams yet offhand. But there could be some workarounds they’re leveraging.
If anyone has evidence the rtsp firmware stopped working, please direct me to such reports. I suspect it still works though and changes were only made to the primary firmware branch.
I do know that there are a bunch of missing features and security updates in the rtsp firmware though, so it’s a big “use at your own risk” type of thing. But I haven’t personally been made aware that this side branch stopped working yet, just that lots of newer subscription features weren’t supported.
The main issue was that people were trying to leave the mini hacks on the SD card and doing the forced firmware update causing it to fail, but even once they realized to remove that they found that obviously the mini hacks doesn’t work anymore, at least not for RTSP and was causing other symptoms too.
Not sure about the “official” RTSP firmware but one has to assume if they are forcing out some new authentication mechanism or encryption key, etc it would affect all older firmwares.
Oh yeah, the 2 hacks versions broke a long time ago. Wyze actually addressed this in one of the AMAs, that they didn’t target the 3rd party mod intentionally, but unfortunately there was some vulnerability they had to patch and the patch broke this ability for this one. It didn’t affect the official rtsp firmware though, and Wyze said they weren’t trying to block 3rd stuff, and would continue to actively allow them, but they can’t promise their normal security updates won’t sometimes interfere. They can’t guarantee or account for every 3rd party thing out there since they aren’t the ones who made it, but they reassured us they aren’t targeting any or trying to make them not work. On the contrary, they went out of their way to ensure such things can continue more securely with API key and Key ID, etc.
If they ever stopped this, I’d probably mostly have to switch to another company because I need external access. I can understand and don’t mind too much that they haven’t built everything themselves, as long as they at minimum allow others to do it. I use most of my Wyze stuff with 3rd party projects, so I’d be devastated and highly criticizing them if they started targeting such things intentionally.
So even though the “official” firmware is so old it is still able to authenticate with their servers, change settings on the camera, etc? Or maybe it never did that, I’ve never used it, was it like a “local only” firmware where you configure through SSH or something?
It does authenticate with their servers. They purposely still unofficially support it… Or rather, support is the wrong word. They discourage it but purposely made sure to make special allowances for it to continue to be used even when they blocked part of the main branch continuing to authenticate.
That’s the downside of wise the official wyze rtsp firmware. It is still cloud dependent for some of the authentication… At least for initial booting up. After that it can be 100% local as long as it maintains power.
Interesting, I think the reason given for the forced firmware update was updated security/authentication. You could no longer do anything in the app on those cams until you updated. And those people were running firmware newer than the “official” RTSP one.
Guess they left a less secure back door for the RTSP one. But its days may be numbered…
I’m sure someone out there is capable of putting together a firmware that just has a simple web interface to configure the cam and streams RTSP to an IP of your choice, but probably not a huge demand for it.
Yep. The security and authentication issues they were fixing were fairly frivolous in my opinion. There are public CVEs published about them, but basically the reason I didn’t care or worry at all is because they basically required the person to have access to your local network first. So basically there was no risk of some remote hacker being able to Access my camera footage in any way. Only me or my family who have access to it already. Oh no! The horror! People made a whole bunch of drama about something completely frivolous in my opinion. If you have somebody on your network without permission, then you have way bigger problems than them viewing your cameras. That will be the least of your issues in both the short-term and long-term.
Don’t get me wrong, they still needed to fix the issues, but in my opinion they were fairly frivolous issues that 99.99% of people didn’t need to worry about unless They had their cameras in their bedroom and bathroom and watching their computer screen while using some kind of shared public Network without encryption like a VPN or device isolation. But again, if you’re doing that, you’ve probably got bigger problems… So again, it was mostly theatrical clickbait fear mongering, but they still had to do fix it for the sake of “best practices” and to appear all the non-technologoical panickers who wouldn’t understand the details of why it didn’t really matter but got told by the clickbait that they should panic. They just didn’t understand technology enough to know why they were fine. And honestly maybe some of them weren’t. For all I know there are a lot of people who still give access to their non secure Wi-Fi for free to every stranger with no device isolation or encryption or anything. But I still think those people have much bigger problems they don’t know about yet.
So the known problems Wyze fixed were easily solved with any single over of the following:
Use a password on your Wi-Fi (and don’t give it to strangers)
Use device isolation (ie This is typical for a guest Network. So even if you share your Wi-Fi with guests, if you have them use the guest Network, they won’t be able to access anything else on your network. Or if you put your cameras on device isolation then nothing else can interact with them either. So either way any kind of device isolation makes the issues moot.)
Don’t put cloud cameras in your bedrooms, or bathrooms (or highly privacy sensitive areas)
If you do any ONE of the above things (two of which are extremely obvious common sense) then the issues they fixed didn’t even really matter at all.
So, wyze presumably delisted the rtsp firmware from their website because it didn’t get the update to fix those local only risks. They discourage people using it, but they haven’t banned it yet. And honestly the risk is totally frivolous IMO. But because there was so much panic and fear mongering over it, they forced the main branch to get the fixes. I don’t blame them. I think they deserve credit for not banning the rtsp firmware too. I actually expected them to and they never did. I’m guessing it’s mostly because they would have a lot of public outcry if they banned the rtsp firmware instead of just fixing it, and they didn’t want to spend the resources to fix it, so this was a compromise of. We won’t ban it but we suggest you don’t use it because we can’t afford to continue to upkeep it. But, honestly, if someone uses any common Sense at all, it’s not a big deal IMO.
Not putting them in private areas and having an isolated IOT or guest network are two things I constantly recommend. Cloud cams are vulnerable, no matter how frequently they’re updated.
Having them on an isolated wifi does result in video streaming via AWS/wyze servers but I have not noticed any issues with that. People with slow upload speed might. It is possible in some routers to modify the firewall and AP isolation to allow the streaming to go direct but personally I’d rather have it totally isolated and have not seen any performance benefits to the direct streaming. Of course, Wyze would probably prefer you not stream through their servers when not needed, but that’s their problem
I don’t think it actually goes through their the Wyze servers or AWS that way either. It’s a direct peer-to-peer connection has other people have confirmed. My guess would be that it goes to the ISP server and then back to your house again, But it could be getting routed in some other different way. Regardless, it is definitely going through the internet, which means it’s going through some other servers, and likely has some delays. But if millions and millions of cameras were going through wyze’s servers for AWS, there’s no way they could continue to offer remote live streaming without a subscription. Basically, what happens is they use the tutk SDK to authenticate and have the phone and the camera establish a peer-to-peer connection and that’s the extent of it going through Wyze… Just the authorization and establishing the P2P routing (whether that be local or through the internet), after that, Wyze any let’s go of anything else having to do with the stream entirely. That’s why once you authenticate through the internet, if your connection is local, you can continue to stream locally. Even if you disconnect the internet afterward. It’s still authenticated through the internet, but the stream is local because that’s how the P2P was established during its authentication. It still does basically the same thing if you’re connecting remotely through the internet as far as wyze is concerned. They still do the same thing, they approve both devices to talk to each other and establish what P2P connection they’re going to use and then the Wyze server lets go.
I verified this myself a long time ago. It’s possible things changed recently, and I’m not going to test again because it’s too much of a pain in the butt now that I have so many cameras constantly uploading to the cloud. But in the past, when I only had a few cameras. All of the cameras but one turned off motion uploads to the cloud, and then constantly streamed the camera for a while to see if it would send the video through AWS like it did for the cloud uploads, but it doesn’t, or rather it didn’t. It’s too much work for me now to try that again though. 50 cams is a lot. I guess I could actually still do it since I have a more advanced router that tracks the traffic on individual cameras instead of just the whole router. SO I could turn off the motion to a camera to make sure it doesn’t ever do any cloud uploads, then live stream it for over an hour through the internet, and check to see if that camera had any AWS uploads over the last hour. I’m pretty sure I’d still get the same result as I did a couple years ago though. They would be crazy to change from not having any live streaming costs (excluding initial authentication of course) to suddenly having to pay tons of live streaming costs for no good reason. They would go broke. There are way too many millions of free users who stream a lot. It wouldn’t be sustainable.
They also confirmed that’s how it works anyway. They explained that’s why they limited the web portal. Live streaming to subscribers only. Because the web portal costs them per camera stream through Amazon. Kinesis, but live streaming through the app has nearly no costs for them (even remote streaming), so they can allow free users to do that Since it’s peer-to-peer And the web portal is not.
Regardless, I agree with the rest of your general statement about how it’s better to do those things. Some routers, will even allow you to do device isolation bottle wow. Specific exceptions between certain devices. For example, on my network I can HAPA VLAN with either VLAN isolation or individual device isolation for every device on that Network, and then allow certain specific devices like my phone to be able to tunnel into either a specific device or that VLAN and connect to any of those devices. So nobody else would be able to because it would have isolation from everybody else. But I override that so that I can access them locally with a traffic rule.
