I use my WyzeCam with docker-wyze-bridge, to stream the video onto a Telegram channel, however it has stopped being able to connect to the camera, returning IOTC_ER_TIMEOUT.
When I check on my.wyze.com/live, the camera feed just says “Web Connection Failed”, but I can see both my laptop and camera are connected, and I’m still able to connect to the camera in my Wyze app.
Please help me understand what’s changed and how I can continue streaming my camera - it’s the only reason I bought it.
I’ve got the same problem w/ the docker-wyze-bridge, but my web view works.
This seems potentially relevant:
A related topic is also discussing some recent problems with docker-wyze-bridge:
I haven’t personally used this tool, so I’m not going to be very helpful with this particular problem, but I wanted to drop these pointers in case anyone hadn’t seen them.
Welcome to the Forum, @Anuttymous!
Ditto. That’s partially because Docker Wyze bridge is using TUTK to authenticate (and a Wyze dev working on this issue said the problem is related to TUTK) and then stream locally through a P2P connection, while the web portal is using Amazon kinesis which doesn’t have a problem.
Anyway, it’s being looked into by a Wyze dev who has even used DWB himself too.
any updates on this?
Sort of. There isn’t an “OFFICIAL” resolution yet. However, there are a lot of people who got it to work.
Apparently there are 2 potential solutions for most camera models. One cause is a subnet restriction causing IOTC_ER_TIMEOUT
that is mitigated by putting the cameras and the DockerWB on the same network/subnet. Some people were seeing hundreds to thousands of these errors per day until they used subnet workarounds, and that got them up to >99% availability with only a handful of IOTC_ER_TIMEOUT errors in a couple of days. That’s at least useable while waiting for an official fix.
People using DWB with Synology reported they had to change the network to host mode or set the environment variable MTX_RTMPADDRESS to a random number between 10000 and 65000. Then, restart the container, and it will work again.You may need to change the subnet settings in Synology’s network configuration and also adjust the subnet settings for the camera’s Wi-Fi .
Some other people got it to work again with most camera models by flashing the firmware back to an earlier version. I have seen reports of this working for most camera models, but not for V4’s, but it’s worked for basically all other camera models. Definitely worked for at least V2, V3, V3 Pro, Pan V3.
But there should be a final fix coming in eventually, the above are just known workarounds that are currently making things work again for most people.
I’m the wrong person to ask:
Fortunately, @carverofchoice has provided a helpful response!
Welcome to the Forum, @jsnox!
Update From WyzeJason:
Source Reddit:
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.
Source Discord:
I just updated on Reddit to someone about the docker-bridge thing but I will say the same here. We have completed our investigation now and know the cause of the issue. We should be posting more about it very soon.
good they found the issue i gues just matter of days for a fix. wondering if i should try the subnet fix or just wait.
For me, I would probably see what they mean by this first:
We should be posting more about it very soon.
Though, I guess it’s not that hard to reverse the settings if you back up the image anyway, so trying the fix is probably not a big deal.
thanks just added these lines to the yalm and worked
MTX_RTMPADDRESS=0.0.0.0:12345
network_mode: “host”
ports: