Beta Testing for Wyze Cam v3 RTSP Firmware Now Available!

ive disabled internet access through my router for the v3 w/rtsp fw, still working as normal w/blue iris and the android app ip cam viewer(v7.4.6). was still working through the wyze app up until i power cycled the cam, then the wyze app states cam is offline.
blue iris and ip cam viewer still working though

I’m unable to locate the v3 RTSP firmware. The Wyze support pages seem to be down. Anyone know where I can locate the firmware?

And now Wyze is forcing us to log into Zendesk to see their support article. Looks like the RTSP page is behind this wall now. What a terrible company.

I just tried the original link for 4.61.01, and it worked for me:

The current version is, but maybe if you install .0.1 it will upgrade itself afterward.

1 Like

Interesting. I’m even logged in to the support area, but still can’t access any of the RTSP firmware support articles.

what if you just click the link I posted above?

Would also have the RTSP URL info used with the v3?

Clicking the link above in Chrome on a Win10 laptop directly invoked the Win interface option to choose a download destination for the file from an about:about URL. No other web interface, link, or landing page involved. Took a few seconds to resolve, but the file is there and accessible directly – al least today about 60 seconds ago.

1 Like

RTSP firmwares don’t update OTA, you have to manually apply the updates.

You need to download them first.

I’ve never tried this, but one idea that might work is to use multiple DynDNS accounts, e.g.,, etc., all behind the same public IP.

Then you could have forwarded to, forwarded to, etc.

It would require a more sophisticated router, but that’s how a lot of virtual web hosting works.

But, as I said, this is just an idea, and I’ve never tried it.

FYI. in blue iris i kept loosing video feed and would just show the last image b4 video loss and would have to restart camera via blue iris.
enabling watchdog in blue iris would enable reconnects to camera but i noticed alot of disconnects. noticed this issue when i moved camera outdoors making it further away from my router. got closer to the camera using my old wifi router connected to my main router,
hardly a disconnect since but i kept watchdog enabled to reconnect.
wyze v3 cameras have a weak wifi signal imo

I’m new to these cams and bought 4 Wyze Cam v3s specifically for their RTSP possibilities and still getting my feet wet. Stumbled across this thread in the process of searching for info and welcome any additional resources of substance on the subject. Seems like everyone is a Beta Tester Expert with a thread.

And this was actually intended as a reply to the deleted post by SeaStream offering some additional support to the successful operation of the RTSP cams without the requirement of constant connectivity to the Wyze cloud.

Anyway, here’s my two cents on the Cam v3 RTSP functionality in an isolated LAN environment. Testing was pretty basic. Set up cams with cloud support (as is absolutely necessary for initial configuration and registration of the devices). Physically disconnect my router from the broadband modem and turn off data service on my Android device containing the Wyze Android app to eliminate any possible way for the devices to call home for anything whatsoever.

RTSP still functions without internet connectivity on a Wyze Cam v3 using the firmware, – as it should, actually. The Android app also still provides RTSP viewing and limited local functionality.

Provisioned RTSP Cam v3s are recognized and can be added to and managed by third party platforms to the extent of the particular platform’s capabilities. My particular exercise was done with TinyCamPro on a v.5 Firestick. Doesn’t get much more basic.

Cameras will survive a soft reboot (power cycle) and eventually come back online, but are desperately looking for a time server for obvious reasons. They will initially display the date and time they were first provisioned and valiantly try to make sense of that for another reboot or two. In my case, they eventually displayed the correct date (which was likely residual), but still needed NTP sync from somewhere (probably anywhere) to ultimately stabilize. They locked right in once they saw a valid NTP source. Would be interesting to know how often that’s required since they are obviously allowed to drift to the extent of having a ‘sync’ feature available in the supporting app/firmware. Regardless, providing a NTP source would be trivial.

Aside from the NTP issue and the occasional firmware upgrade (ahem…), there doesn’t seem to be any obvious reason why the RTSP firmware cams can’t operate independently and indefinitely on private LANs supported by third party solutions.

Has anyone snooped the queries from the cameras? I’m running pfsense 2.4.4 as my edge router, and it has an NTP server built in (you just have to turn it on). If I knew what it was asking for, I’m could probably spoof an NTP response from my pfsense box, and that might make it happy.

Shouldn’t need to spoof anything. A NTP server on the internal network should work if all the cam needs is a response to a query…, unless it’s looking for a specific source. Network Time Protocol (NTP) (Building Internet Firewalls, 2nd Edition)

I wanted to do more testing so I deleted it :slight_smile:

There should be no reason why they can’t since rtsp is meant to be local here.

But, I’m having difficultly getting it to stay working while fully blocking the internet. Rtsp dies within 24 hours if I fully block it.

It might be that I’m blocking too much so am currently trying to test rtsp ports open with those defined.

For some reason, I block the ports here that should connect to the server and Wyze app will continue to connect remotely so am not fully sure what’s going on there. If I take a wide range, it gets blocked.

(I see someone above shows an 8883 which isn’t on Wyze list there.)

However, rtsp stays working for many hours so I would have expected that its not being blocked. Either way, with the current test, I can reopen rtsp and it works while remote is blocked. So will see what happens probably tomorrow.

It is difficult to say what ports people are letting through as well or whatever and how that’s interacting. If internet is blocked then remote viewing of the cam from cellular data connection shouldn’t happen.

If you’re saying that you remove the outside modem and it keeps working then its likely that I’m getting too much blocked and for whatever reason, its allowed for x amount of hours despite remote not being this way.

However, disconnecting the modem, you will have all ports still functioning. That’s a bit of a different thing. Most people cannot disconnect their internet so the router must block the device. Somewhat invalidates the test.

If you get it to stay working while still having an outside internet connection on the network, let me know how or don’t. Your choice.

By the way, I’m not competing with you as to who’s right and who’s wrong. Just not doing testing that way and I know what I see. Your test is valid under that use. That’s fine. Its good to know :smiley:

(Also my test has a router in between and a router at the internet. The cam is connected to the AP router and blocked ports at the internet one. This could also change the results in theory.)

Further info to validate: I rebooted the router and rtsp still works. Remote does not. Thus local only. Tomorrow, will know for sure. As it stands, rtsp is not blocked. If I was wrong previously or not, will update this post, just below this line.

I adjust the ports further to increase openness and it already went offline. Going to try with the other router.

You need some way to tell the camera what NTP server to look for. Which there’s no way to specify with the RTSP beta.

I ran Wireshark once to see what traffic the cam generated, There’s a long list of common NTP servers that they attempt to access when they can’t get to one. I’d have to look again to get the exact list but most are fairly common. So should work assuming that pfsense can redirect a host name (e.g., back to a lookup request from within the network.

I guess I’m not totally understanding your objective. The contention was that the RTSP cams required internet access to function. They clearly do not. There are different ways to eliminate WAN access to test that. I chose the simplest way to make the determination.

If the objective is to have a dynamic environment to selectively operate the cams either publicly or privately, simply hang them off their own wifi router and toggle port functions to suit your purpose – or not. That’s likely the way I’ll handle NTP when it’s all said and done…, with any luck.

My limited testing seems to indicate the only ‘heartbeat’ required on a private LAN to keep the cams online is to simply provide a response to a NTP query. No more. No less. No complicated port considerations involved. Any default ports that are open for cloud based purposes would be irrelevant in a private LAN environment anyway. More testing is obviously required to drill into it a bit further, but NTP seems to be key at the outset in my limited tests.

If the objective is to now keep the cams alive while completely port blocking their access to the internet on a WAN accessible LAN, well…, why?

I’ll do some time server testing in the morning if time permits. With any luck, the cams will be happy with whatever their queries return from a local NTP server. Otherwise, spoofing whatever proprietary nameserver info is in the firmware may indeed be a way to go…, depending on what one’s objectives happen to be with these things… on any given day. I personally just want mine to be independent RTSP cams on a private network managed by third party solutions to the extent that such can be a viable option.

If further discussion in this particular area can help anyone else, cool. I’m certainly not here to argue about my own contributions.

But the camera doesn’t ask, “Does anyone know what time it is?” and then accept any answer.

The camera asks, “Hey,, what time is it?” or “Hey,, what time is it?” and waits for an answer from one of those named sources.

We need to be able to answer on behalf of a named server by spoofing it internally.

1 Like