You want RSTP without flashing firmware, you got it - but not thanks to wyze

So, this is not an new solution, been around for about a year, but I just stumbled on it.

Issue it solves:
Wyze is not RSTP compatible unless you flash unsupported RSTP firmware, with limits web function and requires SD card in camera all the time.

Requirements: The ability to run docker and a bunch of storage. Can be done with PC, but thats a bit of an eco-unfriendly solution. Initially I set it up for testing on a PI (not a solution currently if you dont have a PI as they are incredibly expensive right now). After sucessful testing, I moved it to a synology NAS box and use synology surveillance software that comes with it (although extra licenses are not cheap beyond the couple three licenses that come with the NAS.

Running mrlt8 wyze bridge in a docker container. Uses the wyze API to bridge streaming cameras and hooks a RSTP protocol to it. From author, and I can confirm accuracy:

Docker container to expose a local RTMP, RTSP, and HLS or Low-Latency HLS stream for ALL your Wyze cameras including the outdoor and doorbell cams. No third-party or special firmware required.

It just works!

Local cameras stream locally without additional bandwidth.

Now with a Web-UI - view all your cameras in one place!

Based on @noelhibbard’s script with kroo/wyzecam and aler9/rtsp-simple-server.

Setup in PI was rather quick for testing, since I didnt have to muck about with firewall settings, setting up in synology a bit more complicated as you have to punch through the firewall. All 7 of my cameras showed up - no issue. All seven of their RSTP addressed map to whatever RSTP software you like and only accessible on local LAN UNLESS you config you software to punch through to WAN with DNS address. For me, local is good enough.

I used docker-compose method detailed on git for configuration, worked a treat once I figured out synology firewall settings.

No additional network bandwidth required, ability to locally view cameras in ANY rstp app. Works with last three and current firmwares (as of 16-oct-22), not sure if wyze will disable with new firmware, cross fingers they dont. App and all functionality of cam/cam plus stuff still works.


should mention that windows 10 home and edu version will not work with the docker

Not true, PITA and not as simple to setup, but:,Ensuring%20the%20Prerequisites,runs%20smoothly%20and%20without%20interruptions.&text=Install%20Hyper-V%20on%20Windows,and%20R%2C%20then%20enter%20OptionalFeatures.
I wouldnt run the bridge on a windows box anyway, unless a low powered version - it gets expensive.

If you are going through the process of RSTPing cams and setting up recording, etc - using a windows box seems to be unwise. Fun for testing and [Mod edit] around with IT stuff though.

[Mod Edit] Word removed to conform with Community Guidelines.

Thanks,I will forget it and wait till someone gets it working

get what working ya git? It works, just requires some effort. If you want docker working in windows, just upgrade to pro (like 20 or free depending upon your install),5717.html


@conklin1000 thanks for this. I was able to get it running in my Home Assistant running on Pi4B. The only gotcha was that I was using Time-based 2FA so I had to disable 2FA and re-enable, and in the process acquire the secret key that the Wyze app gives during this process, which the solution needs.
One thing I found is that the feed from my Wyze Video Doorbell shows up rotated 90 deg counterclockwise. I know this is OT for this forum, but might you know how to fix that?

Scrolling as a new forum member. (Never commented or posted prior to now)
Your patience is appreciated! :slight_smile:

Rotating camera view is in the advanced settings inside the wyze app. Open the camera of which you need to adjust, top right corner expand the settings. There you’ll find “rotate camera.”

I’ve been using this for a few weeks to get my Wyze Cam v3s connected to Zoneminder. Works really well for video, but adding the audio causes issues. I’d love to see Wyze bring back the RTSP support in the firmware, but 'til then this is my solution. I found it really easy to use, but I’m running it on Linux, and have been running Docker for a few years for other purposes, so had some experience to work from.

I’d love to get the audio going. The errors in Zoneminder are as follows:

The developer of wyze-bridge says it’s the way the camera is sending the video/audio as wyze-bridge does not re-encode. If anyone here had any thoughts I’d love to hear them.

This may or may not be a problem for your app. Iknow that the Wyze API has been flooded heavily due to certain 3rd party applications. Wyze has said they may have to disable the API if it continues to be abused. Something like 92% of the traffic coming from a small small amount of wyze users. That app disabled camera API calls for the sake of not excessively using and abusing their system, and in return Wyze helps with integrating the API for everything else. I havent checked your code yet or how often it has to do API calls, but if it does a lot, you may need to shut it down.

1 Like

I hate how Wyze never seem to care to block apps that spoof access to their servers. Tinycam is doing it for years now. These docker/home assistant people have really no decency bridging a service that just isn’t designed to support it.
No idea why Wyze didn’t create from the start a decen’t API and sell access to developers like every half decent company do. Instead they let unscrupulous nerds wasting resources and give crappy service to PLUS users that actually pay for it.

1 Like

| cheeroip
November 11 |

  • | - |

I hate how Wyze never seem to care to block apps that spoof access to their servers. Tinycam is doing it for years now. These docker/home assistant people have really no decency bridging a service that just isn’t designed to support it.
No idea why Wyze didn’t create from the start a decen’t API and sell access to developers like every half decent company do. Instead they let unscrupulous nerds wasting resources and give crappy service to PLUS users that actually pay for it.

You miss the point. Wyze should have allowed RTSP via their firmware, but they’d rather sell camera viewing as a service (Cam Plus!). That is why they have only for CamPlus.
So someone who doesn’t want to pay for CamPlus can have this feature via 3rd party apps. What’s wrong with that?
I have CamPlus, but accessing my cameras this way uses no Internet bandwidth.

For me all I wanted was a camera I could connect to my Zoneminder server I run at my home using RTSP/ONVIF. I’d thought the Wyze Cam was a product that did that. It’s becoming abundantly clear I was mistaken.

No worries for me. The research begins anew for an appropriate alternative.

Oh, I get it, But Wyze is trying to run a business not a charity and they get to decide what works best for them, Maybe you’re missing the point :grin: (what a rude thing to say btw).
As much as I love the idea of RTSP it just disrupt their whole ecosystem.
It’s obvious and expected that these camera can’t handle streaming to 2 different locations at same time (local RTSP and to Wyze server for the cloud thing).
The problem is that having an RTSP enabled by default would just make their cloud service works even worse than it actually is.
I don’t know who actually decided to officially support those RTSP firmwares and why. There is no way that was going to be a win scenario for Wyze. It’s not that they can start calling their userbase stupid for not realizing that their network performance would effect cloud performances.

Yes you were clearly wrong and I don’t know what make you believe otherwise.
Wyze never tried to trick anybody into believing that they were the right solution for your needs.
It seem you’re blaming them for giving people more options but they can’t make miracles.

I have no idea how the service described in this thread (docker/bridge/home assistant) is pulling data out from the camera but they ask for Wyze mail/password [to spoof access to Wyze servers?] just to create a local RTSP server. That, to me, seem an incredibly stupid idea that make little to no sense at all.
An IT rube goldberg machine just to satisfy a nerd itch.
More power to them but why then start thread like this and badmouth Wyze on their forum?

No internet? I’m not technical enough to understand what they are doing inside that Docker. How do they get data from the camera?

It just works!
Cameras stream locally without additional bandwidth.
docker run
-e WYZE_PASSWORD=yourpassw0rd
-p 1935:1935 -p 8554:8554 -p 8888:8888 -p 5000:5000
To me look like they “just” fake their way into Wyze server and handle all the streams from there.
How that would not need additional bandwidth?
Only because something is possible doesn’t make it right.
Sometimes I have the feeling that Wyze doesn’t even run the cloud side of their business.
Why do they allow developers to access their servers like this?
The open source community should be way more critical about these kind of projects that just seem to abuse private companies resources and services.

Please take it down a notch. These are local P2P video streams. Other than the authentication and the occasional handshake, there is very limited load on Wyze resources. There is no stealing of Wyze bandwidth. My TinyCam logins take exactly as much resources from Wyze as running the Wyze app on the same device. I imagine the open source projects are similar. (Excessive API calls for triggers and routines may be a different story.)

1 Like

’m sorry if you felt personally attached by some of my uninformed assumptions but feel free to keep your notch where ever you prefer.
I just think that it is very bad practice to ask users to let a 3rd party service use their Username and passwords to simulate access to a private server.
I always being pretty critical about the TinyCam dude.
Seem to be a russian dude on a working VISA in USA that sorta reverse engineered Wyze login or he had access to leaked code?
I think at time Wyze was using a ridicule scheme using phone IMEI to authenticate users.
That’s the reason why Tiny cam was only working on phone with the official APP installed.
Then Wyze hired the dude for like 6 months while, at same time, was selling his own service in direct competition with Wyze cloud.
No idea what the whole deal was about and what the situation is now.

My assumption is that that bride get the all the stream from Wyze servers and not just “authenticate for the handshake” (why would it need the authentication for?)

At least TinyCam just mimic the Wyze app so the load was acceptable but that bridge SEEM to run a local server that access EVERY CAM 24/7 from Wyze servers.

There is no “service” using it. There is no TinyCam server involved. It’s your Android device logging in with your Wyze credentials. He may or may not be copying them elsewhere - he says he’s not. I suppose network packet captures could confirm this.

I don’t know any details but as far as I determined the Wyze reverse engineering was performed and open sourced by an independent group, and Alexey merely used it in his existing product.

I don’t even know what you mean but SMS is still a valid method for the optional* Wyze 2FA.

Again, not an issue unless you’ve enabled 2FA.

This is true from what I have heard. I too don’t know any current status.

Nope. You know how I know that? Because Wyze servers don’t GET any video feeds to begin with, unless they are being fed event recordings on a CamPlus plan. Even for live viewing, the streams of video go from camera to viewing device, not to Wyze servers. So the various open source projects wouldn’t have any way to access every cam’s stream 24/7 by downloading from Wyze servers. That’s just not how their P2P works.

@Cheeroip Do you always try to make points while being a jerk about it? Your comments were meant to be inflammatory, right down to the HA nerds and Russian student jab. THAT’S the reason someone would take it personally; because its pretty clear that was how you intended it to be taken.