BUG: Wyzecam v3 and v4 no longer work with bridge after auto-firmware update #1438
Comments
|
Also not working with latest wyze-bridge version v2.10.3 |
|
Wyzecam v2 still work and v2/v3 with RTSP firmware still work. |
|
Same issue here, IOTC_ER_TIMEOUT v3 Working: 4.61.0.3 (this is the RTSP firmware, but not running RTSP) |
Can't be a device fw update since my v1 db stopped streaming in the web ui, hasn't had a fw update for a while and current fw was streaming just fine 2 days ago. Also no docker update in years, still on 4.12 after rolling back from 4.18 when I had some issues. I just stopped updating. |
|
Fix is in this thread: #1432 |
|
The fix in that thread does not fix the issue. I have CamPlus Unlimited. I have never received the message referenced in thread 1432. I access my cams thru the Android app, the web app for Wyze, the Docker app and Blue Iris. Nothing changed until today. |
In my case, the network: host in docker fixed the issue, as well as a bunch a other peeps. |
|
Same issue started a few days ago. Running wyze-bridge 2.10.3 on Ubuntu 22.04 under docker-compose (1.29.2-1). Started not seeing cameras in BlueIris where its been stable for many months (or more). Docker logs show [-6] IOTC_ER_FAIL_CREATE_SOCKET error for most cameras on local network (different VLAN). Changed docker-compose.yaml to network_mode: "host" but did not resolve the issue. Container starts up and same connection errors exist. Still testing and reseraching. A few cameras last image shown in wyze-bridge UI are a few days ago, a few updated earlier this morning it seems, but nothing is stable. My wifi camera's are on a separate VLAN. As a test, I just spun up a new RPI4 in that VLAN, installed wyze-bridge under docker-composer and configured for network_mode: "host". This configuration is now working, so confirming it does have something to do with camera's in different VLAN's and docker/host mode networking. Seems camera's must now be in same layer 2 network. |
|
I have several new Wyzecam v4 that have not had firmware upgraded. I plugged one in and it came up in the Wyze app, as I'd expect. The Wyze-Bridge captured one snapshot of the camera view and then would not stream or update further. |
|
My V3 cams have not received an update and have the same issue. Two went down, I restarted Docker container and now none will connect. |
|
Likely upstream firmware updates that caused these issues. All my devices won't stream. When I logged in this morning to check, I first noticed my auth didn't work, and I had to create new API Keys on https://developer-api-console.wyze.com. But while I was re-authorized in Wyze-Bridge, the streams don't work anymore. Guess we will have to wait for an update here, it has been a while. |
|
I can confirm the one camera I have on 4.36.10.4054 works, but the others on 4.36.13.0416 stopped working. BTW a good replacement is the Tapo 120, I still like to keep using my wyzes, but I will not be buying them ever again. Tapo lets me directly connect to them with blueiris even UDM Pro. |
|
Im having the same issues: 2 cams with 4.36.13.0416 do not work, and another cam with 4.61.0.3 works fine. I keep getting [-13] IOTC_ER_TIMEOUT in the log for that cams that do work |
|
My cameras stopped working, but for me switching from bridge to host mode solved it for me: #1435 Thank you @Boundzero |
Doing host mode just broke my view from blue iris for the working camera and still the other 3 cameras... Does it change other settings do I have to redo settings on blue iris? |
|
Switching to host did not have any affect for me . Still getting time out errors and "IOTC_ER_DEVICE_OFFLINE" |
I am running wyze bridge on unraid docker and blue iris in a windows vm. Didn't touch any settings in blue iris, I guess YMMV if this works for other installs. |
This does not look like a neat fix but your investigation is useful. I purposely put Wyze cameras in a seperate VLAN, only allowing connections from main VLAN (where docker-wyze-bridge runs, but behind Docker's NAT) to Wyze VLAN and forbidding the reverse. Today all cameras are down. Based on your workaround, I connect docker-wyze-bridge directly into the Wyze VLAN and it now works. This could be the VLAN issue (wyze and docker-wyze-bridge are in different subnets). But my change also avoids Docker's NAT so it could also be the NAT's issue. For those who do not want host mode (because of potential port conflicts), you may connect docker-wyze-bridge to a macvlan on your physical interface (or vlan interface). BTW now I regret having bought Wyze and realize Tapo is a better option given its official RTSP/ONVIF support and less interests in cloud services. I bought a Tapo floodlight cam a month ago and is pretty happy with it. |
|
I have attempted to setup the net_mode=LAN to HOST. I have a unique setup so perhaps that’s the issue. I am running a Synology NAS with an older docker. I used portainer to make the changes. I realized under advanced settings you can adjust the network mode from bridge to host. Here are my details from another existing thread. Hoping someone has figured a workaround!? I am getting this issue now: WyzeBridge] [MTX] starting MediaMTX 1.9.0 Any solutions would be greatly appreciated! Edit: Thanks for the helpful replies. Based on this it seems this is not going to work anymore unless we can figure out what Wyze did or maybe they did this to prevent this freebie? If anyone has an alternate docker to use, I am all ears! |
|
I also have the same problem, constant IOTC_ER_TIMEOUT errors in the logs. v3 cam with firmware 4.36.13.0416. Everything was working fine until a couple days ago. |
|
People need to include whether they are using docker-wyze-bridge on a Windows or Linux machine or on a HA system. The HA plugin is apparently different from running the bridge on a standard PC. Making the "host" change on my PC version does not fix anything. |
|
I run on a Synology to enable Wyze camera access to Surveillance station. While I can modify the Synology's use of port 5000, which it users for its default Web UI, the RTMP port is not changeable. This makes host networking a non-starter unless I fork the container source and modify the ports that the bridge is listening on. Has anyone confirmed the root causal of the issue yet? |
Changing from LAN (Internal Docker Networking) to HOST (Using the Host machines network) is what you've changed. The NET/HOST solution is not the issue here. As WyzeBridge can connect out to the Wyze Cloud and I can still connect to my two older firmware camera (wz-mini-hacks modified) Looking forward to a working solution. If not I have 13 cameras to convert to Thingino |
Synology has a package, which is what I use the synology for almost exclusively, called Surveillance Station. It uses 1935 for RTMP and is not modifiable. https://kb.synology.com/en-me/DSM/tutorial/What_network_ports_are_used_by_Synology_services |
|
Running Bridge on Ubuntu Linux. I think I'm having the same issue reported by others here. My cameras are online and accessible via Wyze app, Bridge appears to be up and running, but RTSP links do not work. I have a couple of logs. First is just a snippet from the bridge: docker-wyze-bridge v2.10.3 [WyzeBridge] WyzeCam304 will cooldown for 10s. 304 is offline, but the others are online but not accessible via RTSP. That is indicated by the -13 IOTC error reported earlier? And this is from VLC when I attempt to network stream using RTSP link from bridge UI: main debug: no access modules matched No idea what any of this means, but hopefully helps in troubleshooting. Update: Changing to host mode doesn't solve the issue in my case: lua debug: Trying Lua playlist script C:\Program Files\VideoLAN\VLC\lua\meta\art\03_lastfm.luac I am on a single network, all my server and cameras are all on the same subnet. |
|
Okay. I got mine working again. It does have to do with the networking of your container. It is not a problem with WyzeBridge. My setup has an internal Docker network where services like WyzeBridge sit. I use a NGIX reverse proxy to serve their pages on the external address. I kept this. I created a new macvlan network which mirrors my main network on the host port and manually assigned an IP to WyzeBridge. Good luck on your own setup |
Software development cycles in companies like this have to prioritize and we're probably near the bottom. not only that, but the issue isn't with wyze but one of their third party vendors. There are tons of simple workarounds you can use in the meantime. |
Those workarounds don't work for everyone. "Network Mode = host" doesn't work for me, I've even give my container a static IP on my main network as a troubleshooting step and that still doesn't work. |
|
Same for me -> thought I'd comeback after a while - nada |
That's great news. I think the optimistic views here are that the capability users had last year will be restored without substantial effort, or possibly even with none at all (i.e. just a firmware update). Since firmware downgrades have been unsuccessful, this suggests the problem is entirely external. The Wyze developer is saying as much. Your network architecture is fairly specific and perhaps too much of a burden for most users to implement. But I think you are revealing that you found the primary problem is that UDP broadcasts are not received because the Wyze bridge and cameras are on different network segments. Using host networking mode puts the container network back onto the camera segment (depending on user network configurations). This suggests only a local change is needed. My Wyze bridge container is not on the same network segment as my cameras and therefore UDP would never have crossed over. Yet it worked in an identical configuration last year. Have you found that the use of UDP discovery broadcasts is new? This would be very interesting. Thanks for sharing your config and findings. |
I posted more details in #1471 I’ve always segmented my network and devices, so when I needed LAN mode to work, I ran a Wireshark trace and found the right packets. I’d have to dig up the original post, but it was around the time I shared my Unifi config. Once I added the broadcasts to the relay, the bridge was finally able to see and talk to the Wyze cams in LAN-only mode. Most users can get this working again with host networking or a macvlan Docker network. If you’re doing VLAN or subnet segmentation, just run a UDP broadcast relay daemon. If you’re already that deep, it’s a pretty easy fix. I’d be happy to jump in on that thread and can run another Wireshark session to confirm what traffic the cams are sending now. Still hoping Wyze and their vendor come through with a proper fix either right away or through a firmware update. But until then, this setup has been completely stable for me, even in a swarm environment. |
Link fix for your comment: #1471 And ty. |
|
Fixed and ty |
Maybe this is the problem? Wyze has how many vendors handling our videos? And of those vendors, do they have any control over what the vendors are doing? Either way, options like Thingino seem more and more practical. |
I have all my cams running again except my floodlight Pros. Happen to have any working? |
unfortunately i do not. but, you may be able to find out more by doing a wireshark cap and seeing what ports its trying to use. they may be different than the port for the other devices |
|
Anyone have a simple fix to get this working in Home Assistant even temporarily? @xcz011 It's been two months since your last post. Any updates? |
If you are running HAOS, install jdeath fork: https://github.com/jdeath/docker-wyze-bridge (Don't know if you tried this yet, but it's been working great for many of us in HAOS)
Hope it helps! |
|
@N3rd7 great instructions but got to the install part and getting the following error message. Failed to install add-on |
Shoot, this is likely the same error we are facing with the recent update notification that was pushed, which many of us cannot install. This is not an issue when the fork was already installed, we just ignore the update (works great without it). |
|
Does 3.0.6 not work? I can revert. |
Strangely no, I and a few others were getting an error when trying to apply the update. Also fcaiado tried to install your fork for the first time and received the same error as we did. Thank you for reverting! |
@fcaiado, jdeath reverted the recent change so it should now (hopefully!) work for you! Try to install again, but if you still get the error, try the following steps (in case HAOS hasn't registered there is a new version and needs to be "made aware" of the recent change): Step 1:
If error persist, try step 2:
I really hope it will work for you! Cheers |
|
Thanks, @N3rd7, I managed to get it going, at least partly. The HLS stream is working now, but not the WebRTC, RTMP, or RTSP streams. WebRTC was working before this issue started a couple of months ago, but I didn't use RTSP or RTMP much, so I can't be completely sure what state they were in before. FWIW, I had tried this once before without success, but it was this comment that caught my eye and saved me this time.
In fact, it was still there because "uninstall" doesn't remove the original repository and I initially failed to realize the new repository wouldn't show up until I refreshed the browser window. I probably made the same mistake last time. Anyway, I tried the new repository before removing the original and got the results mentioned. @jdeath, any ideas on why WebRTC (or even RTSP) isn't working? |
|
You can always download the code from GitHub. Unzip and copy the home_assistant directory into your /addons/ directory. Edit the config.yaml to any version you want that exists of docker Wyze bridge. Reload addon store. My fork just adds a line to make it host mode. |
|
@N3rd7 Yup that got her installed. Cams now are just showing black screen instead of a frozen snapshot. Seems like @TheMegamind is also experiencing the same result. ;) Thanks for the efforts though gents as truly disappointed with Wyze on this issue. Started acquiring Tapo cams (2 now) as wyze replacements but will have them for a while as I've go 17 of them. |
Food for thought, try to deselect "On Demand" in the configuration of DWB. It did wonder for me, and really doesn't put a big strain on my internet (surprisingly, as I have 19 cameras!). Also, I don't know what you use to incorporate your live streams in HA dashboards, but I use the generic camera integration which uses the rtsp stream. Somehow rtsp stream doesn't work if I try to access it from the DWB UI, but it works when set up as generic camera. Happy to share setup guidance if this can be of any use! |
|
Do you still have to used outdated insecure firmware btw? I know a few fanboys told me this would be fixed 100%. I'm sure the required fair time of waiting has passed. So is this fixed, can I repurpose my old wyze cameras or should I stick to my Tapo ones? |
|
@N3rd7 tried deselecting that didn't seem to make a difference. Tried setting up the generic cam devices so they could be exported to the dashboard but it seems to be timing out so looking through logs to see what is going on. At initial glance it seems to only be connecting to one or two of the cams with the others continually retrying but still investigating. I will say though that prior to this i didn't seem to have the RTSP stream issue you were experiencing as my streams seemed to work fine on the DWB UI. @StoneLegion no this is with current firmware not the old RTSP fw or any of the other hacked versions. You could def repurpose them if this issue ever gets addressed by wyze of other community members as is being attempted here. On the tapo front are you using the ONVIF device for your tapo cams? Found i had to use that for the C120 but also have a C3xx that i think integrates directly. |
Using C120's with Onvif and directly via blueiris and udm-pro... I was shocked udm-pro supports onvif now so that was a bonus. |
|
@N3rd7 just another update. My v4 cams seem to be working fine now (even in the DWB UI using HLS) but my v3, v2 and pan-cams are flaky at best or not working at all. v3 seems to be hit and miss others just seem not to be working. |
All my firmwares are up to date |
Somehow it took a few days to stabilize on my end too. I don't know why but at first I had a few cameras streaming, others not (the worst was the DB V2). And within a couple days, all streamed smoothly. I thought it was my network to be honest (mesh needed to balance the constant traffic across nodes or something), but who knows, maybe it also needs time on wyze end (or their provider) to settle on a stable open connection? |
|
"If" you are using the home assistant addon there was a workaround to load it as a local addon, switch to host mode, and that fixes the problem. All my v4's work now. I am looking for the post now that explained how to do it. There are about 20 of these threads, so it's taking me a minute to locate. |
|
It did not fix it for me.
… On May 16, 2025, at 2:56 PM, Nate Newsome ***@***.***> wrote:
n8icus
left a comment
(mrlt8/docker-wyze-bridge#1438)
<#1438 (comment)>
I'm not sure if it's officially fixed or not, but all of my cameras that had stopped working with this issue have now begun working again without making any changes. Hopefully this means Wyze fixed things on the back end.
—
Reply to this email directly, view it on GitHub <#1438 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARBGBGR5ZLJ7EIGQK5CTU5D26YYGBAVCNFSM6AAAAABXVB4CPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBXGQ3DEOJZGM>.
You are receiving this because you commented.
|
and others
Describe the bug
This morning my Wyzecams did auto firmware updates. They still display in the Wyze app but do not work with the Wyze bridge. Here are the current firmware versions:
V3 - 4.36.14.2589
V4 - 4.52.9.1134
Affected Bridge Version
2.9.10
Bridge type
Docker Run/Compose
Affected Camera(s)
Wyzecam v3 and v4
Affected Camera Firmware
v3 - 4.36.14.2589, v4 - 4.52.9.1134
docker-compose or config (if applicable)
The text was updated successfully, but these errors were encountered: