BUG: web-rtc not working #1429
Comments
|
My V3 has also stopped working. Giving a "[-13] IOTC_ER_TIMEOUT" error in logs.
Not working on any protocol though. Working fine with Wyze mobile app and with Scrypted's WYZE plugin. |
|
I started to see the same on all 3 of my v3 cams today. Cam feeds are fine in the Wyze app. Cam firmware: 4.36.13.0416 |
|
Same Firmware and bridge version. I have auto firmware off on app, but shows my firmware is up to date. I thought I had an available firmware update last I looked months ago. Wonder if they force pushed a firmware update... |
|
Found a fix for mine. Been working fine for years under same settings, but mrlt8 mentioned wyze pushing updates about local networks being more strict. I run UNRAID, was under a regular bridge connection. I swapped the container to now a br0 connection with dedicated IP. This fixed my camera. |
|
Same problem here today. My floodlights, v4, and doorbell cams all went down in the last few hours. |
|
long time user just posting to add same IOTC_ER_TIMEOUT as everyone else, started hours ago as well, 4 cameras, all v2 wyze fw 4.36.13.0416 |
|
I can confirm that moving the docker-wyze-bridge and an affected camera onto the exact same LAN mitigates the issue. In my case, this required 2 steps:
YMMV but this does seem to be related to Wyze locking down access to cameras across network boundaries. |
|
I am seeing the same issues as well. I have 1 V2 and 2 V3 all experiencing the sameL
my bridge is running as an addon in HA. HA is running on an rpi4b that is on the same LAN as the cameras. restarted addon several times, checked configurations, rebooted entire HA instance multiple times. No result. |
|
@domeng83 @grinddking try the workaround that @delmlund pointed out if you can. Move all components onto the same LAN directly. Also, can anyone else confirm start time around 10:20 UTC today (2/21)? I saw all my cameras go down after that point. I'm curious to know if it affected all users at once or was gradual. |
|
Same issue here, IOTC error. I was able to move to the host network setting for the Wyze-Bridge container (as @shawnsi mentioned), rather than a bridged connection. This worked and it is back up and running. Portainer:2.21.4 |
|
Just weird they were able to make this change without pushing new firmware. Unless they baked in a environment variable/flag for this a while ago and turned it on last night. Weird. |
Unsure on an exact time. I was notified ~4:40 am Friday (UTC) that stream wasn't working. |
@shawnsi how can we define this configuration if we're running as an HA addon? Also, looking at my logs in HA I think approximately 10am utc is around when my cameras went down. |
|
Bump. Same for my 9 wyze cameras. Starting to diagnose.... @delmlund would you mind giving a bit more details on what you did? TIA |
It might be worth mentioning 2 things.
|
|
@domeng83 I'm not familiar with running as an HA addon. The key seems to be having docker-wyze-bridge run on a network interface on the same LAN network as the camera(s) you connect to. |
|
Well, guess its time to ditch the last Wyze cam i have. :) Garbage. |
@aodoine what do you mean by "I am not using Wyze Docker"? Are you not using the docker-wyze-bridge software somehow? |
@wilsonjeff72 try using docker host mode if you can. It seems that network virtualization in docker alone can result in this camera connectivity problem. |
Can confirm, running in host mode instead of bridge fixed it as well. No need to map to a new dedicated ip. Can still sit behind a server. |
Yeah that did it, thanks :) |
|
@mrlt8 there was some sort of change further restricting network sources that can open the wyze cam streams earlier today. If this proves to be an intentional change it may require updates in this project to explain and support the limitation going forward. The change here, at minimum, is docker Edit: to clarify, I don't think |
|
When i add When running the console only has these logs, and nothing more: Without that setting in my docker-compose file, I at least get the attempt to connect to the camera: Any guidance is appreciated.. thanks! |
|
@iamle0pard are your cameras on the same network as the docker-wyze-bridge? That seems to be a requirement which I had to reconfigure for as well. I noticed IPs like 192.168.4.51 for cameras and 192.168.65.3 for the servers which may be different networks technically depending on your own configuration. |
|
I can confirm that adding: to my docker-compose.yml file took care of it for me as well. |
Thanks for the quick reply! Yeah, they are all on the same network from what I can see. I do have the eero Max 7 mesh setup as well as a number of eero 6 devices to extend my WIFI network, but it's all one large mesh. Eero really limits what we're allowed to do in terms of splitting up the network, so I assume it's just one large one. I wonder if they all have to be within the same CIDR or IP subnet range like 192.168.4.x or something similar EDIT: My wyze-docker-bridge is on a PC with 192.168.4.104 as the IP and my Wyze Cam V3 Pan has an IP of 196.168.4.51, so I would think they should be fine connectivity wise. |
Where can i find this file to edit? Sorry the newby here. :) Im using HA addon |
|
@pedromfa it's an option for |
Ok but were is that file? docker-compose.yml |
|
I cannot seem to get the fix to work properly. I am using portainer (with docker on a synology). Do I need to remove the existing environment variable: NET_MODE=LAN (remove this line?) This still gives the IOC error. I also tried to adjust the container within portainer to start up with —network host. This container won’t start. I also had to update my API keys/ID. Thanks for your help folks! Edit: Found the Network settings under the advanced section of container. I am getting this issue now: WyzeBridge] [MTX] starting MediaMTX 1.9.0 Any solutions would be greatly appreciated! Edit 2: Based on a reply It seems that my Synology Surviellance Station uses port 1935. Looks like this solution is not going to work for me or anyone else with my particular setup. Does anyone know any alternatives if this is ever going to be resolved? |
Yep mine were offline this morning as well. Changed docker config to "host" mode and they are all back again...? |
Leave it lan you have to change network mode to host. |
|
|
I think it's clear at this point that there is no magic fix, and anyone claiming setting to "host" mode or whatever is only temporary and you're lucky you get it functional for the few hours it decides to work again. |
|
Between host mode and spinning up go2rtc in a docker I have about 5 seconds delay. Otherwise with how the delay grows until it craps out. |
|
following for any updates. |
|
I created a macvlan network with a single IP inside my Wyze Bridge Container and assigned that network to the bridge. I did that within a couple of hours of the issue arising (after seeing reports that it was working with host networking). I've been running error free with the macvlan network for 5 straight days. I originally created this thread regarding a different issue.... web-rtc was not working for me (I could only stream HLS in the GUI and elsewhere, Webrtc wouldn't open, it would just spin). That was an issue for me prior to the IOTC problem. Once the IOTC problem happened, I lost all connectivity from the cameras to the bridge. However, after creating the macvlan network to solve the IOTC issue, my web-rtc issue resolved as well. Now...if somebody has a trick to make web-rtc work with frigate without throwing a bunch of errors, let me know. I played around with it a little, and its amazing in terms of latency. There's almost no lag at all. Its actually better than my tapo c120 with native rtsp interface to frigate. Less than a second delay. However, it fills my error log with all kinds of issues. I cant rely on it. |
|
Just to comment same, but I've got my cams in a IOT vlan. I don't plan on moving them just to make this work. Hopefully another work around or update can fix it. |
|
It's interesting, when I switch to host mode, I lose the web-ui port remapping from 5000 to 5001 that I had set up. i.e. there's no way to see the wyze-bridge web-ui. Then I also get the "ERR listen tcp :1935: bind: address already" in use error in my logs. I never needed to uncomment that RTMP line before, but trying it now didn't help either. Stopped my frigate container, and that freed up 5000 and 1935. The web-ui shows current streams and no IOTC errors |
|
I think you're misunderstanding how bridge and host networks work in docker. In host mode you can't remap your ports. You can remove all your port mapping in your yaml compose file. However, the required ports need to be open (not used by another service) on your host machine. If they are utilized by another service you will have a conflict. In docker bridge mode you can remap what ports you want open on the host. In order to get the wyze bridge working..... If you can't or don't want to shutdown or remap the other service that is using 1935, you can always create a macvlan network like I did. That will allow you to create an IP address in your subnet (different than your host). You will essentially be running the wyze docker bridge in docker host mode on a new IP address separate from your host IP address (so you won't have a port conflict on your host machine) |
|
Doing some packet captures, it looks like Wyze has fully shifted to it's new steaming system, AWS Kinesis Video Streams, which wyze-bridge doesn't currently support. @knightzac19 has added support on his fork, https://github.com/knightzac19/docker-wyze-bridge/tree/add-kvs-webrtc-support. In my testing, host mode or macvlan networking is now required. I've pulled everything together. See #1446. |
|
I got this working based on info from others. And trial and error. Host mode worked to connect to cameras, but not web-rtc. Bridge, ipvlan or macvlan only 2 cameras connect and web-rtc works. Finally custom network comes in. I assigned the container an IP from my network that was available. All cameras connect and web-rtc connect. Odd thing is I have to use my host IP for wb_ip... If I put the actual wyze bridge ip in webrtc does not work... |
Thank you! Does this branch also include the fix for Home Assistant add-on? I looked quickly ad didn't see the addition of network_mode: host in config.yml, but I might not be looking at the right place. Right now I'm using jdeath's branch and it works great for my system, not sure if I should update? |
|
[letrain02].... Strange... Not my experience with macvlan. I had 5 Wyze v3 and pan v2s running on a MacVlan network within docker. Webrtc was working for all cameras since the issue first occured and I spun up the macvlan 9 days ago. No issues whatsoever. I couldn't get Webrtc to work with frigate without generating a lot of errors in the logs, but that's a different and more longstanding issue. The Wyze Bridge GUI worked fine with web-rtc. I'm using past tense... as my MS-01 broke yesterday, and is now en-route back to China :( Also a separate but very unfortunate issue. |
Honestly, I didn't update the docker-compose templates to include the "network_mode: host" or macvlan because I didn't think about it but one of them is necessary (at least it was for my network). |
|
For the less techies like me,can we run this branch by modifying the line - image: mrlt8/wyze-bridge:latest? If so to which repo/image? |
I was, but now I have a much better understanding. Hadn't used host mode anywhere else before. Thanks for the walk through! |
|
Same. I ended up dumping em all for tapo. I've played so many games to make them work over the years, I'd had it.
Wyze said they'd had an issue with their p2p vendor that they believed was causing this.
Get BlueMail for Android
…On Mar 1, 2025, 08:04, at 08:04, scoob8000 ***@***.***> wrote:
scoob8000 left a comment (mrlt8/docker-wyze-bridge#1429)
Just to comment same, but I've got my cams in a IOT vlan. I don't plan
on moving them just to make this work. Hopefully another work around
or update can fix it.
--
Reply to this email directly or view it on GitHub:
#1429 (comment)
You are receiving this because you were mentioned.
Message ID:
***@***.***>
|
|
Can you still use a phone app with the tapo cams whilst still having a rtsp
stream?
My only application for the wyze cams is for stuff like keeping an eye on
the dogs while we're out. But still record to my NVR setup
…On Sun, Mar 2, 2025, 8:28 PM jman9895 ***@***.***> wrote:
Same. I ended up dumping em all for tapo. I've played so many games to
make them work over the years, I'd had it. <br> <br> Wyze said
they'd had an issue with their p2p vendor that they believed was
causing this. <br> <br> Get BlueMail for Android <br> <br> On Mar 1,
2025, 08:04, at 08:04, scoob8000 ***@***.***> wrote: <br> >scoob8000
left a comment (mrlt8/docker-wyze-bridge#1429) <br> > <br> >Just to
comment same, but I've got my cams in a IOT vlan. I don't plan <br>
>on moving them just to make this work. Hopefully another work around
<br> >or update can fix it. <br> > <br> >-- <br> >Reply to this
email directly or view it on GitHub: <br> >
#1429 (comment)
<br> >You are receiving this because you were mentioned. <br> > <br>
>Message ID: <br> >***@***.***> <br>
—
Reply to this email directly, view it on GitHub
<#1429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE4EZHYIGT34H6D35N2BNV32SOV3VAVCNFSM6AAAAABXPR6QGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJTGA2TGMRWGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: jman9895]*jman9895* left a comment (mrlt8/docker-wyze-bridge#1429)
<#1429 (comment)>
Same. I ended up dumping em all for tapo. I've played so many games to
make them work over the years, I'd had it. <br> <br> Wyze said
they'd had an issue with their p2p vendor that they believed was
causing this. <br> <br> Get BlueMail for Android <br> <br> On Mar 1,
2025, 08:04, at 08:04, scoob8000 ***@***.***> wrote: <br> >scoob8000
left a comment (mrlt8/docker-wyze-bridge#1429) <br> > <br> >Just to
comment same, but I've got my cams in a IOT vlan. I don't plan <br>
>on moving them just to make this work. Hopefully another work around
<br> >or update can fix it. <br> > <br> >-- <br> >Reply to this
email directly or view it on GitHub: <br> >
#1429 (comment)
<br> >You are receiving this because you were mentioned. <br> > <br>
>Message ID: <br> >***@***.***> <br>
—
Reply to this email directly, view it on GitHub
<#1429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE4EZHYIGT34H6D35N2BNV32SOV3VAVCNFSM6AAAAABXPR6QGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJTGA2TGMRWGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
i have a couple of tapo c120's. They work great. Yes, you can use the phone app and the rtsp stream concurrently (i was using the rtsp stream into Frigate 24X7). I dont know if you are using frigate or not, but the C120's have much less delay than wyze cams/wyze bridge. They are pretty darn close to real time. As I mentioned above, I did experiment with interfacing the wyze bridge to frigate using webrtc, and I actually felt that it might actually be ever so slightly more real time than the tapo c120s using native rtsp. Its unfortunate however, because the wyze-bridge doesnt play nicely with Frigate when using web-rtc. So right now, the C120 wins out, and feature wise, it blows the wyze cams out of the water (local AI detection, native RTSP, etc, etc). They are really good cams for the money. I won't buy any more wyze. |
|
Thanks. Similar. I run blue iris. I'm going to give it a few days
and see what happens. Just saw in another thread there is a wyze
engineer looking into it.
…On Mon, Mar 3, 2025, 12:26 AM Doug ***@***.***> wrote:
i have a couple of tapo c120's. They work great. Yes, you can use the
phone app and the rtsp stream concurrently (i was using the rtsp stream
into Frigate 24X7). I dont know if you are using frigate or not, but the
C120's have much less delay than wyze cams/wyze bridge. They are pretty
darn close to real time. As I mentioned above, I did experiment with
interfacing the wyze bridge to frigate using webrtc, and I actually felt
that it might actually be ever so slightly more real time than the tapo
c120s using native rtsp. Its unfortunate however, because the wyze-bridge
doesnt play nicely with Frigate when using web-rtc. So right now, the C120
wins out, and feature wise, it blows the wyze cams out of the water (local
AI detection, native RTSP, etc, etc). They are really good cams for the
money. I won't buy any more wyze.
—
Reply to this email directly, view it on GitHub
<#1429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE4EZH5KL52J4MLIWBJCKRL2SPRXPAVCNFSM6AAAAABXPR6QGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJTGMYTEMZSHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
[image: Doug411]*Doug411* left a comment (mrlt8/docker-wyze-bridge#1429)
<#1429 (comment)>
i have a couple of tapo c120's. They work great. Yes, you can use the
phone app and the rtsp stream concurrently (i was using the rtsp stream
into Frigate 24X7). I dont know if you are using frigate or not, but the
C120's have much less delay than wyze cams/wyze bridge. They are pretty
darn close to real time. As I mentioned above, I did experiment with
interfacing the wyze bridge to frigate using webrtc, and I actually felt
that it might actually be ever so slightly more real time than the tapo
c120s using native rtsp. Its unfortunate however, because the wyze-bridge
doesnt play nicely with Frigate when using web-rtc. So right now, the C120
wins out, and feature wise, it blows the wyze cams out of the water (local
AI detection, native RTSP, etc, etc). They are really good cams for the
money. I won't buy any more wyze.
—
Reply to this email directly, view it on GitHub
<#1429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE4EZH5KL52J4MLIWBJCKRL2SPRXPAVCNFSM6AAAAABXPR6QGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJTGMYTEMZSHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Read your post then checked my 2 cams. the one that is working is on the same LAN as the docker and the other that's not working is on my IOT. sucks that I need to move it off the IOT lan to make it work. |
It also has to do with if your a Cam Plus subscriber. If you are, host mode and network infrastructure changes alone won't reliably fix the issue. Wyze has moved Cam Plus subscribers to another streaming solution that is being worked on with #1420. If I was a betting man, I would bet that they're eventually going to move everything over so that they don't have to keep up with two setups. |
|
@ihatemyisp That's not entirely true, the KVS solution actually is only for peeps who wanna use the web interface to view the cameras. I checked my non-pro cameras and they work with KVS just fine. |
It's quite odd because all my cams (V2s, V4s, Floodlight V2, V3, OG, Pan V2s) are on my Cam Plus subscription and none of them function reliably without KVS. Sometimes they connect, sometimes they don't (through the direct webrtc feed from non-kvs enabled wyze-bridge). It doesn't matter if it's host name, macvlan, or docker proxy. Wyze has always been finicky like that though. |
as a noob, how does one apply the kvs solution? I look at your git page and the docker-compose sample looks no different referring to mrlt8's latest? doesn't it need to refer to your fixed version? |
|
Hi there @Doug411! It looks like many users are suddenly experiencing connectivity issues with Wyze cameras and the Wyze Bridge, indicated by the The most promising workaround so far is to ensure the Wyze Bridge and your cameras are on the same local network. Several users have resolved the issue by:
If you're running the bridge as a Home Assistant add-on, the add-on likely uses host networking by default. Focus on verifying the camera is on the same LAN as the Home Assistant instance. You might try temporarily connecting the camera to the main WiFi network (if you use a separate IoT network) as a test. If none of these workarounds help, please provide the following information to help diagnose the issue further:
Let's try to pinpoint the root cause and find a more permanent solution. Hope that resolves your issue! |
|
The issue I was reporting pre-dated the IOTC issue. I was able to connect via the GUI using HLS not webrtc. My post got commandeered by the IOTC issue when it occurred as the IOTC issue occured a half a day after my post. As I've already discussed in the thread, I solved the IOTC issue within a couple hours of it first occuring, by creating a macvlan network and assigning an IP address in my subnet to the Wyze Bridge container. Cooincidently, after I changed over to Macvlan, my web-rtc issue resolved. I've also stated that although web-rtc is working in the GUI, I haven't had a lot of luck using web-rtc to interface to frigate. I have been able to make a connection. Latency is fantastic (much better than RTSP), however it is unstable and produces a lot of errors in the error log. I've seen much older posts that indicated that there is still some re-work that needs to be done to make the integration stable. I found the link for the Wyze Bridge rtc connection in the go2rtc documentation (IP address:5000/signaling/camera (using the web-rtc address from the Wyze Bridge gui didnt work for me at all Has there been any progress on a more stable integration with go2rtc/frigate? |
and others
Describe the bug
I am running the bridge in docker. I am running the latest qsv build (but have tried non qsv builds, and builds going back several releases. I can get the HLS stream to work in the GUI, but I cant get the web-rtc stream to work in the GUI or the browser. In both cases, I get a spinning circle that lasts indefinitely, and the stream never loads. I have the web-rtc port mapped, and the IP address of the bridge set in my docker compose.
Affected Bridge Version
latest-qsv (although i've tried going back many releases)
Bridge type
Docker Run/Compose
Affected Camera(s)
Wyze version 3,
Affected Camera Firmware
No response
docker-compose or config (if applicable)
The text was updated successfully, but these errors were encountered: