Beta Testing for Wyze Cam v3 RTSP Firmware Now Available!

Yup, as I mentioned in an earlier post I spent a bit of time trying to get ssldump working to decrypt the requests/responses between the cam and the API servers just so I could spoof the request/response cycle but could not get it compiled on my router. Aside from the hosts already mentioned the cam also tries to resolve - possibly for video processing or machine vision - retrieving/storing something in an S3 bucket

It’s interesting that the cam tries to resolve, It’s not even any of google’s APIs. I have a hunch it may be using the google homepage as a way to test internet connectivity - if it receives a timeout from such a commonly used service then it assumes internet connectivity is gone, and tries to re-establish connectivity by reconnecting to wifi.
Following on from this it may be worth it try have the google domain resolve to a custom server in the internal network that responds with data and a 200 OK for any GET requests. You’d probably want DNS resolution rules per MAC unless you never want to use in the household.

1 Like

This is great info and thanks to @MikeA , @zedramus , and others for sharing, even if it’s essentially a fool’s errand at this point. I do wonder why no 3rd party version has emerged.

Yeah, would require a lot more effort than I’m going to put into it. Probably right about the Google call. I tried pointing that to a local server as a quick test too. Still needs more to stay connected. Which isn’t all that surprising given that it’s normally connecting to their P2P network, checking credentials, subscription status, etc. Still appears to be trying to do all of that even in the RTSP version. They likely just added the RTSP functionality to the same code without necessarily adapting everything required to function completely independently.

Kind of interestingly, if you let the cam out for a moment then most of the calls out stop. When I’d looked once before you can see that once connected it sets up some outgoing and incoming port connections. I can see the returns trying to come in from outside on my router. If blocked, those can’t happen but the calls to set them up seem to stop. Still now and then checks the NTP. The one call that I see that seems persistent after is that about every 35 seconds it tries to get to So maybe whatever is missing could be found there.

I don’t see the calls to the hosts that you note for the cam when blocked even after it’s let out briefly. For another cam running unblocked that I let out to test I do see similar connections made to:

I altered the leading part of the names with xxxxx at the end since that may point to mine specifically. And again I’m just looking at calls made out through my local DNS by name and I’m not looking all that hard so likely missing some things.

1 Like

Ditto on appreciation for the recent efforts. It proved quite quickly to be well beyond my current pay grade considering my last venture into such analysis was nearly 30 years ago with NGCs Sniffer on a Win95 box – well before Ethereal was even introduced. Figured loading Wireshark onto my laptop, coupla filters…, just like riding a bike, right? Silly me. LOL

So it does seem like the firmware may just be using a round-robin approach to satisfy it’s NTP requirement per MikeA’s tests. Regardless of all the other observed requests, there can only be so many requirements for maintaining an online state.

As for any of the rest just being a fool’s errand, it could also certainly be viewed as a curious quest to make the Cam v3s with RTSP firmware behave like actual RTPS cameras requiring only minimal (or zero) contact with WAN resources once initially registered – which they would already be via the app anyway. Flash the RTSP firmware version and have an RTSP camera by simply activating RTSP mode, Hang it on a private network. Done. Period.

From the Wyze marketing perspective, it seems like they would sell a lot more of these little rascals if the RTSP function wasn’t dependent on all the rest of the non-essential API baggage…, much of which is presumably Amazon Alexa and Google Assistant related to their specific functions along with all the sensing, notification, and control features which don’t necessarily apply to typical RTSP use.

Hell, I’m still trying to figure out how to achieve a consistent stream of any kind, let alone anything close to real time. Nothing close to even 15fps without bouncing up and down in one second intervals. But boy does it look good trying! I’m obviously thinking clock related and thought maybe it was the timeline display, but can even see what seems like a clock pulse at the bottom of a stream without the timestamp displayed.

Anyone know if it matters what the base firmware version is before flashing the RTSP version? The cams I have were bought used and I never checked the firmware before flashing the RTSP version. There are 4 cams on their own dedicated N450 LAN segment with nothing else anywhere near their channel. I can’t imagine the performance I’m getting being accepted as the norm. My ancient 15fps 720 Swann rig looks smooth by comparison.

Still pecking at it, but the initial fun isn’t far from becoming disappointment if what I’m experiencing is actually all I should expect with these things. If it is, I certainly don’t see what all the Wyze Cam fuss is about – aside from the price.

TIA for further enlightenment. I really do want to like them more than currently is the case.

1 Like

Basic performance on mine is OK. I see 15-20 FPS consistently regardless whether blocked or not. Bit rates are kind of low at ~100-125 kB/s and can drop to 30-ish range on an indoor cam with nothing happening in the scene. Do have the problem with them dropping off every 3-5 minutes. Not critical cams for me and they come right back up so not that big of a deal in my case. I also see the pulse that you mention on one of mine. Night vision is great but they pump the gain up so much to get there and with lots of compression so the overall image beyond that is kind of bad in very low light and with a more complex scene.


In case you haven’t looked at the RTSP firmware page in a while, seems that Wyze is probably going to discontinue support:


Thanks for the feedback. In my quest for a greater understanding of what’s already been covered in this thread, I actually read the whole thing from beginning to end yesterday.

What did I learn? Not even the vaunted Blue Iris can effectively work around the abominable implementation of RTSP in this firmware release. Furthermore, it can actually be brought to its knees on the most powerful hardware platforms by simply enabling the audio on one of these ‘RTSP’ cameras. Impressive – if the real intent of the firmware was to undermine Blue Iris and infuriate BI users.

Otherwise for the firmware itself, the shortcomings aren’t worth the hassle if the purpose of changing is to convert one of these cameras into a standalone RTSP IP device, because that’s not what it does. It simply adds a pseudo RTSP feature to the existing firmware – very poorly.

And they’re going to discontinue support? I certainly didn’t find any evidence here that they ever provided any.

A shame really. So close to a wonderful little RTSP camera…

1 Like

At least the download link still works. Get it/Save it while you can.

1 Like

Thanks for the reminder Dave. I grabbed the 2020 V2 and Pan Cam versions too.

Glad I only picked up one camera. When I saw the V3 had a RTSP firmware I thought for sure this time it would become a standard feature… Guess not…

There will certainly be sources available even if Wyze completely pulls the plug on this disaster. Not sure why anyone would want it after reading even a few posts in this thread. Sure wish I would have before spending so much time with it.

So has anyone determined if one version of basic firmware is more suitable than another for flashing over with the beta? I’m still sorta wondering if there’s something there that may be at the root of my particular dissatisfaction with the v3 beta performance.

Short of going back to square one with the latest stock firmware and starting over, I’ve pretty much covered most of the other bases except spending $70 on software trying to make a $35 camera work.

I’d consider going with some v2s, but understand they have their own particular Q/C issues even though their RTSP implementation seems to work much better, albeit limited to 15fsp from what I understand. I’d love to see 15fps out of my v3s.

Good idea on the v2 and Pan Cam firmware, tho. Who knows what they’ll do next – or not.

In case someone needs the MD5 hash of the unmodified RTSP firmware .zip in the future when downloading from mirrors:

MD5 ( = 9a6b59f0c143d7a031adcf27ae52de0a

1 Like

This would indicate development of the RTSP firmware which by all accounts doesn’t exist. Where can one obtain

The V2 and the original PanCam can run Dafang. It completely eliminates Wyze from the equation and runs RTSP with boot from the SD card. I’ve played with it but cannot give any real info on performance.

1 Like

Saved the download link while I can, I really hope this isn’t the case.

For those of you who may not be familar with it I would suggest looking into GitHub - mrlt8/docker-wyze-bridge: RTMP/RTSP/LL-HLS bridge for Wyze cams in a docker container it may be able to solve some of your issues.

1 Like

Been using this to integrate into my existing local Hikvision NVR, works perfectly. Each update it’s becoming more stable.

I have been using this and am actually moving away from it with the RTSP firmware, it’s been great but hasn’t been the most reliable recently and especially for the doorbell too it has a lot of issues.

I’ll probably keep it installed for helping with the ports when I put RTSP on the cams.

I have this installed on homeassistant on an Rpi4. I do test it out on one camera (of 8) when there is a new update. It’s an evolving alpha-level implementation, it’s a great idea. It doesn’t have the stability of tinyCam and it takes 20% of the CPU and drives up the operating temperature of the Rpi by 10 degreeesF. It would be nice if Wyze embraced this Bridge the same way they embraced tinyCam, i.e. hire the developer :wink:

1 Like

Well yeah, but don’t forget the phrase “embrace, extend, extinguish” either. :wink: