Of interest to Coral USB users like me perhaps.
Could this not be simulated by blocking WAN traffic to and from the device? I could probably set that up.
The issue I see with that happening, and it’s a big one, is that if the wyze device can’t reach the cloud….didn’t they use to reboot themselves over and over? I will test this and see if that’s the case. If so, it will break the RTSP feed because the entire device will be rebooting….so some extra setting to toggle so the device doesn’t hammer DNS requests that go nowhere because AWS is down? Maybe! Need to test it…..
I really don’t know, but I’ll read whatever test results you decide to post here. 
I can tell you that I did block all inbound and outbound TCP traffic. The camera light started to blink to indicate there is a connection issue.
- RTSP still functions
- The camera doesn’t do a full reboot, but it’s restarting services of some kind, because it will drop off the network for exactly 2 pings consistently. This will also stop the RTSP feed briefly when this happens. Did they change the code so it only reboots services in the camera software instead of a full shutdown? We might need some new logic for when RTSP is enabled and the cloud goes down. Perhaps a setting to “Restart when cloud services are unavailable” … with an option of “5, 10, 30, 60 minutes” or “don’t restart at all”. I can see this being a nightmare if you have 20-30 cameras on your network, cloud goes down, and the cameras loop-restarting things, especially for those who wish to block the cloud once RTSP gets activated (there are some of us that do this). This would spam ones network with retries, and should be looked into!
tagging @wyzedave
I’m curious about how long you ran your test. My understanding of reboots goes back to a note about Cam OG microSD recordings when the Cam has been unable to phone home for ~30 minutes:
I believe @grapefruityoda has done much more work involving the 30-minute-offline-reboot issue specific to Cam v3 and certain firmware versions, which would likely be much more informative for the current RTSP tests, given that they involve only Cam v3 and Cam Pan v3 so far. I’d be interested in knowing if any Cams with the RTSP firmware have this same reboot issue. I don’t have any regular Cam v3s, but I’ve loaded a Cam Pan v3 with the test firmware and could maybe try blocking its WAN access sometime and see what happens.
Probably 10-15 minutes. I can try longer and see if it stops after awhile, but ideally a setting to prevent this from happening would be great. I don’t need my network spammed if I block WAN to my cameras.
Anyone else have an issue installing the beta IOS app? Click link and it asks to install but does nothing.
Well, I don’t know, decided to flash a 2nd Pan Cam V3 with RTSP today, that 2nd one went fine.
3rd one just refuses to flash, maybe its broken 
. Maybe I’m broken. Same procedure and SD as first two.
Still reads & writes to SD normally.
What #3 ends up doing is writing files on the flash SD, and then I reformat it to fat again, copy .bin file to it, then try again, same thing now about 5 times. Gave up.
Well a waste of my time, not ruling out me either. lol
Wyze Garage gas streamed since I flashed it soon after RTSP released.
Just got around to #2 Pan V3, it flashed and setup. Says RTSP is on, duplicated it in my config.yml. Save, Restart etc.
Would not stream at all throwing errors in Frigate web ui logs.
#3 as mentioned wouldn’t even flash. At this point I’m done for now.
I have a wyze cam 3 that has been flashed and it works on VLC but it does not on frigate
I am kinda thinking it’s just rough around the edges RTSP firmware. Which tries my patience a whole lot. Personally.
Decided to try that and mine does stream in VLC.
Don’t know the truth of this, only Wyze knows.
I’ll be trying it tomorrow and I will also know.
Still even if it works, doesn’t explain Pan v3 #3 that won’t flash at all.
Because even when you download the exact same .bin file and flash two “identical” Pan v3 cameras, the new 2025 Wyze RTSP beta firmware does not behave identically on every unit. Here’s why wyze works perfectly with /stream0 while wyze2 (same model, same .bin, same flash process) refuses to connect unless you use /unicorn:
-
The 2025 beta firmware is still buggy and inconsistent
Wyze themselves admit on the beta page and in the forums that the flash can succeed (app says RTSP enabled, you can set username/password) but the camera sometimes stays in a half-old/half-new state. One camera ends up exposing the old-style RTSP paths (/stream0, /live, etc.), the other ends up only responding to the new path /unicorn (and /unicorn/sub). It’s random – literally the same .bin on the same model. -
Wyze never fully removed the old RTSP code
The new beta is built on top of the current stock firmware, and some units fall back to the ancient RTSP server code (which uses /stream0) while others get the brand-new server (which only answers to /unicorn). That’s why your first camera (wyze) still works with the old URL you’ve always used, and the second one (wyze2) instantly 404s until you switch it to /unicorn. -
Thousands of people are hitting the exact same thing right now
Search Wyze forums / Reddit / Frigate Discord for “2025 RTSP beta one camera unicorn one stream0” – you’ll see dozens of posts from the last 2-3 weeks with identical stories: two or three Pan v3s flashed from the same .bin, one needs /stream0, the others need /unicorn.
What even is this AI reply?..
Yep
Hey guys, I want to introduce you to @WyzeEric who has just joined our RTSP task force at Wyze. He’s a super RTSP user and I’m bringing him in to help us turn your feedback into faster improvements to the product. Say Hi Eric. You should also show them what you built at your own house haha.
Pardon my ignorance, but can you steam multiple cams in VLC?
Hello @WyzeEric 
Hope to see RTSP for the V4 en V4PAN soon!
I don’t know, but I imagine there’s a way. I’m trying to stream multiples in Frigate.
But one Pan V3 refuses even though it streams in VLC.
One Pan V3 refuses to flash.