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 |
Jason is a trustworthy source at Wyze. If he says it, you can usually bet on it. |
|
Thank you mrlt8 for the wonderful work you've done on this project. It's tremendous that it has quite literally bridged the gap for local users using wyze products and you're efforts have been greatly appreciated. Having said that, Wyze has never treated local usage as first class. Evidenced by the number of issues, generally, this project and others trying to use Wyze with the likes of frigate etc. have had...as well as the fact that RTSP functionality is still beta, has never been included in an actual product out-of-the-box, and requires manually flashing devices. For those of you still searching for alternatives I recommend the previous advice WRT TP-Link Tapo devices. In the past two weeks I have replaced all my Wyze cameras with Tapo equivalents and the migration has been as painless as possible. RTSP right out of the box. Works on different subnets. ONVIF without a fuss. Additionally, they are cheaper than Wyze. My replacements:
The image quality isn't as great and the FOV is smaller but the trade-offs for stability and assurance my cameras will keep working locally, always, has been a small price to pay for peace of mind. |
|
You all realize that tp-link will probably be banned by the US government because of security concerns? I'm absolutely not a wyze fanboy, and if I had it to do all over again, I'd go all local cams... Sorry, I'm just tired of all of this. Especially the push for tp-link, and the defense of wyze. They both suck for local only cameras. They're meant to make money selling your usage. That's the price to pay for cheap hardware. Good luck all. |
Now here some silly fanboy crap. If they ban it Wyze will be banned to as the hardware comes from the same place lol. The firmware is other and I'm fine with a ban... Since I don't use the cloud features and use the local account because Tapo actually supports that unlike Wyze lol |
|
Fanboy? I hate both. Do some research. Good luck. |
|
Bring the nonsense to reddit. This is a technical forum. |
But they're not.... so... Yeah this is dead. No sense in keeping this going other than to point other unfortunate souls to a working solution. And the working solution is???? Tapo |
Hold your breath for that fix. In the meantime, if you came on just to tell us you're waiting another month, move that nonsense to reddit. This is a technical forum. |
Did you not see the update across discord, reddit and the one relayed in this thread? |
Buddy I've been with Wyze since day one. One thing I've learned from them is when they say they're working on something chances are you'll see a partial fix in 6 months. Didn't you just see their announcement? They put all their time and effort into selling more garbage fluff rather than ever actually fixing everything they've already put out there. Not to mention this ENTIRE bridge is used to amend their garbage product to HA. Other cams work natively. |
Extremely early adopter here as well. I agree with you 100% Their motives have changed over the years. |
|
Don't trust wyze since 2020 and I witnessed a crappy beta device pushed out to retail in a shameless money grab, and then come out with an updated version less than a year later with most of the improvements and fixes beta testers had suggested and requested. No a company I care to support. I have that one crappy cam and abandoned the rest. Got 2 orig bulbs and plugs still working via homebridge. But I'm done with their cams. I'll use my db cam til it craps out but will never buy another wyze cam. Too many other options. Saying they identified the cause is one thing but assuming they truly are "actively working" on a solution sounds like wishful thinking. |
|
I have been lurking around this thread since I discovered the bridge was malfunctioning. I have watched this thread move away from trying to solve/identify the problem to simply bashing Wyze. A change in how Wyze streams its cameras to its cloud has broken this software. I'm not sure how it relates to this thread here. mrlt8 is the project owner and built this service outside of Wyze. Looking at how this discussion has devolved, why does anyone create open-source projects like the Wyze bridge? @mrlt8 I have tried the many suggestions above to get my WyzecamV3 back online with the bridge. I have moved the bridge and the cameras to the same network and tried varying versions of firmware. I did find that Scrypted wyze plugin is still operational at the latest firmware for the camera. The camera still needs to be on the same network. Is there a way to compare the two projects to see the difference between the two platforms. |
Scrypted's bridge is having the same issues. Wyze knows what the issue is and will be rolling out a fix soon. WyzeJason updated the community last week. |
Just stop. It's been a problem for over a month. "Shortly" doesn't belong in this conversation. Also, you're the one who whined that this is a technical forum. So take your ridiculous, endless defense of Wyze elsewhere. They have shown repeatedly that they don't care about security, and that alone illustrates that they don't care about their customers. |
|
Can we please keep this discussion on-topic? This is about the resolution of the issue affecting the Wyze docker bridge. Extraneous posts about other products and unrelated complaints are are not helpful. There are other places to post that stuff. |
China has lots of bots to downvote you ;) Oh and me too now ;) |
Other products are related when this has been broken for over a month. |
|
Hi All, |
|
Really trying to follow along here for actual updates. it's tough. I hope it is fixed soon. |
|
Sadly there isn't much. Wyze supposedly working on it. The rest are all
folks talking about moving on, and workarounds that aren't realistic.
Low priority for me. My only cams are for watching the dogs while away and
a bird feeder.
…On Thu, Mar 27, 2025, 6:41 PM tuftsanti ***@***.***> wrote:
Really trying to follow along here for actual updates. it's tough. I hope
it is fixed soon.
—
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE4EZH6UOCAGCYCYHZOUDLT2WR5B5AVCNFSM6AAAAABXVB4CPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJZG4YDGNJVHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: tuftsanti]*tuftsanti* left a comment
(mrlt8/docker-wyze-bridge#1438)
<#1438 (comment)>
Really trying to follow along here for actual updates. it's tough. I hope
it is fixed soon.
—
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE4EZH6UOCAGCYCYHZOUDLT2WR5B5AVCNFSM6AAAAABXVB4CPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJZG4YDGNJVHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Exactly this. |
Yes I totally agree we should say and repeat then re-quote these over and over about staying on topic ;) |
Yes, precisely |
|
Bye bye |
You can join the official discord too. There is a tech channel and the devs pop in and out. The last update was less than a week ago from Jason and he said they pinpointed it and are workign on it. He is a solid source at wyze. Primary PR. |
|
I just asked for clarification in discord that a fix is really planned. From what I've seen there, they only mentioned the cause but haven't said anything about a fix. Obviously everyone needs to evaluate their own requirements on how to handle this but it's been an awfully long outage/degradation scenario. This obviously is not a priority for Wyze. A 6 week outage is incredibly unusual for a tech product/service that actually intends to fix it. |
The post did specifically say they are working on a solution, but yes, this defintely isnt a major priority for them. It's Dev API access for a side project of 0.001% of their userbase. I appreciate them putting money into such a small userbase and hope their current stated roadmap of more local-only accress options pans out. 6 days ago "I just got an update from the team, we have concluded our investigation and found the cause. We are working on the solution now and should have something soon." |
|
My IT security policies do not allow a Docker container to use host network mode. A compromised container in this mode allows access to the host network stack. Network isolation is a good thing. |
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: