WYZE_CAKP2JFUS (wyze v3) stopped connecting, WYZEC1-JZ (wyze 2) works fine

[FeatherKing]

i have 6 wyze cameras and all 4 of my WYZE_CAKP2JFUS (wyze v3, fw 4.36.13.0416) stopped working in the last 6 hours. i have 2 wyze v2 (fw 4.9.9.2351) that are still working. ive restarted every part of the network, container, and cameras but only the wyze v3 ones fail to connect.

Just curious at this point if anyone else is seeing this before i keep digging.

I am running docker-wyze-bridge 2.10.3 and havent made any config changes in some time. I can connect to all the cameras with the offical wyze ios app. I also restarted them all through that but nothing has helped. I installed ping and some other tools and I've confirmed connectivity inside the container to these ips.

logs repeat like this for the 4 V3 cameras

wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - Deck on 10.0.1.11
wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - HAG Cam on 10.0.1.34
wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - HAG Driveway on 10.0.1.60
wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - Driveway South FloodCam on 10.0.1.21
wyze-bridge | [WyzeBridge] [deck-v2] Snapshot timed out
wyze-bridge | [WyzeBridge] ☁️ Fetching 'cameras' from the Wyze API...
wyze-bridge | [WyzeBridge] [API] Fetched [7] cameras
wyze-bridge | [WyzeBridge] 💾 Saving 'cameras' to local cache...
wyze-bridge | [WyzeBridge] 172.19.0.23 - - [21/Feb/2025 06:39:28] "GET /snapshot/deck-v2.jpg?1740119951829 HTTP/1.1" 307 -
wyze-bridge | [WyzeBridge] 172.19.0.23 - - [21/Feb/2025 06:39:28] "GET /static/notavailable.svg HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] [hag-cam] Snapshot timed out
wyze-bridge | [WyzeBridge] 172.19.0.23 - - [21/Feb/2025 06:39:36] "GET /snapshot/hag-cam.jpg?1740119951828 HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] [deck] Snapshot timed out
wyze-bridge | [WyzeBridge] 172.19.0.23 - - [21/Feb/2025 06:39:40] "GET /snapshot/deck.jpg?1740119951829 HTTP/1.1" 304

[stuartcummings]

Yes I'm also seeing the same issues. IOTC_ER_TIMEOUT

[BIHatch]

I'm seeing a similar issue.

[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Garage Cam on 192.168.86.26
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Side Entrance Cam on 192.168.86.24
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Back Yard Cam on 192.168.86.36
[WyzeBridge] 🎉 Connecting to WyzeCam V2 - Levi's Room Cam on 192.168.86.31
[side-entrance-cam] [-13] IOTC_ER_TIMEOUT
[garage-cam] [-13] IOTC_ER_TIMEOUT
[levis-room-cam] [-13] IOTC_ER_TIMEOUT
[back-yard-cam] [-13] IOTC_ER_TIMEOUT

[Anc0dia]

same here, two cameras went offline. same error as above. 2 x v3, firmware 14.2589 & 13.0416. everything works using the wyze app.

[lumper5]

Yes. This is happening to me as well:

[front-yard-cam] [-13] IOTC_ER_TIMEOUT

[front-yard-cam-sub] [-13] IOTC_ER_TIMEOUT

[WyzeBridge] ⏰ Timed out connecting to Cat Cam.

[cat-cam] [-13] IOTC_ER_TIMEOUT

[cat-cam-sub] [-13] IOTC_ER_TIMEOUT

• Both of my cams, a v3 and a WyzePan both stopped working with the bridge at the same time. Just after midnight, local time, on Feb 21.

[1fastt2]

I'll add to the group, same issue.

[FeatherKing]

several related comments in this issue

[elijah286]

Same here. Cameras keep showing 'IOTC_ER_TIMEOUT'

[FeatherKing]

something bigger is going on i think
https://forums.wyze.com/t/v3-cameras-all-off-line-whats-going-on/322846/31
https://www.reddit.com/r/wyzecam/comments/1isvml2/all_wyze_devices_offline/

[elijah286]

I don't think so, as all my cameras are still working just fine in the Wyze app

[shawnsi]

I did attempt to recreate the failure for investigation. I intended capture network traffic on my side to attempt to reverse engineer the wyze change.

Summary of findings so far:

• IPv4 packet TTLs are 64 which seems fine, likely not a limit on network hops for traffic
• When running in default network mode there is no traffic sent from my container to the camera (even after seeing "Connecting to ..." message with the correct IP in logs)
• The IOTC_ER_TIMEOUT message occurs before any traffic is sent to the camera from docker-wyze-bridge (see last point)

Packet Capture Steps for Peer Review

Here is the tcpdump command I'm using to capture traffic from the docker host machine (10.0.0.145 is the camera):

$ sudo tcpdump -i any -w /tmp/camera.pcap host 10.0.0.145
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^C0 packets captured
18 packets received by filter
0 packets dropped by kernel

Out of caution, I also used docker exec -it wyze-bridge /bin/bash to drop into the running container and generated network traffic. That did cause packets to be captured by the command above so I'm pretty sure the tcpdump is valid. Similarly, when in host network mode the tcpdump captures a full camera handshake and streaming traffic locally.

IOTC_ER_TIMEOUT cause

I'm still reverse engineering here, but my hunch is that this is reliant on wyze managed endpoints before camera connection. If so, they may be stopping the process upstream somehow before this software can even reach the camera.

[cdnninja]

Your failed packet capture actually is also showing packet loss in the first few lines. Looks like our response isn't getting to the endpoint.

[shawnsi]

Wireshark will show packet size. One thing I noticed when looking at the screenshots above is that both sides send MSS in the successful side. In the failed conversation one side presents MSS however the docker image doesn't respond with an MSS value. Maybe that is further up in the screenshot though.

If MSS negotiation is failing this could be packet size related as I would suspect additional packet tagging is occurring within docker when not in host mode.

Both convos set MSS, no? I'm getting out of my depth but I think that's only on SYN packets.

[shawnsi]

Your failed packet capture actually is also showing packet loss in the first few lines. Looks like our response isn't getting to the endpoint.

Agreed

[cdnninja]

Wireshark will show packet size. One thing I noticed when looking at the screenshots above is that both sides send MSS in the successful side. In the failed conversation one side presents MSS however the docker image doesn't respond with an MSS value. Maybe that is further up in the screenshot though.
If MSS negotiation is failing this could be packet size related as I would suspect additional packet tagging is occurring within docker when not in host mode.

Both convos set MSS, no? I'm getting out of my depth but I think that's only on SYN packets.

On the broken one 1485 has an MSS value but the ack of 1486 does not.

On working 8178 has MSS and 8237 also has MSS.

I would be interested to see the capture files from both working and not to be able to compare the payloads. They are different sizes.

[shawnsi]

Wireshark will show packet size. One thing I noticed when looking at the screenshots above is that both sides send MSS in the successful side. In the failed conversation one side presents MSS however the docker image doesn't respond with an MSS value. Maybe that is further up in the screenshot though.
If MSS negotiation is failing this could be packet size related as I would suspect additional packet tagging is occurring within docker when not in host mode.

Both convos set MSS, no? I'm getting out of my depth but I think that's only on SYN packets.

On the broken one 1485 has an MSS value but the ack of 1486 does not.

On working 8178 has MSS and 8237 also has MSS.

I would be interested to see the capture files from both working and not to be able to compare the payloads. They are different sizes.

That's true, but 1485 is ACK only. 8237 is SYN, ACK and therefore has MSS.

[Vpsjbsrn]

same issue
I have V2 Cam (2) V3 cam (5) and V3 Pro Cam (1) all getting same error

[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam1 on 192.168.83.17
[WyzeBridge] 🎉 Connecting to WyzeCam V3 Pro - Cam2 on 192.168.83.18
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam3 on 192.168.83.12
[WyzeBridge] 🎉 Connecting to WyzeCam V2 - Cam4 on 192.168.83.14
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam5 on 192.168.83.16
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam6 on 192.168.83.15
[WyzeBridge] 🎉 Connecting to WyzeCam V2 - Cam7 on 192.168.83.13
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam8 on 192.168.83.11
[Cam1] [-13] IOTC_ER_TIMEOUT
[Cam2] [-13] IOTC_ER_TIMEOUT
[Cam3] [-13] IOTC_ER_TIMEOUT
[Vam4] [-13] IOTC_ER_TIMEOUT
[Cam5] [-13] IOTC_ER_TIMEOUT
[Cam6] [-13] IOTC_ER_TIMEOUT
[Cam7] [-13] IOTC_ER_TIMEOUT
[Cam8] [-13] IOTC_ER_TIMEOUT

[Vpsjbsrn]

when I installed RTSP old firmware on 1 V2 Cam it is automatically working with wyze docker bridge. stream is UP for 1 camera.

[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam1 on 192.168.83.12
[WyzeBridge] 🎉 Connecting to WyzeCam V3 Pro - Cam2 on 192.168.83.18
[WyzeBridge] 🎉 Connecting to WyzeCam V2 - Cam3 on 192.168.83.14
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam4 on 192.168.83.16
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam5 on 192.168.83.15
[WyzeBridge] 🎉 Connecting to WyzeCam V2 - Cam6 on 192.168.83.13
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam7 on 192.168.83.11
[WyzeBridge] 🎉 Connecting to WyzeCam V3 - Cam8 on 192.168.83.17
[Cam3] 📡 Getting 180kb/s HD stream (H264/15fps) via LAN mode (WiFi: 84%) FW: 4.28.4.51
[Cam3] 🔊 Audio Enabled [Source=S16LE/8,000Hz]
[Cam3] [AUDIO] Re-Encode for RTSP compatibility [codec_out='pcm_mulaw']
[WyzeBridge] ✅ '/Cam3 stream is UP! (3/3)
[WyzeBridge] 📖 New client reading from Cam3
[WyzeBridge] 📕 Client stopped reading from Cam3
[Cam1] [-13] IOTC_ER_TIMEOUT
[Cam2] [-13] IOTC_ER_TIMEOUT
[Cam4] [-13] IOTC_ER_TIMEOUT
[Cam5] [-13] IOTC_ER_TIMEOUT
[Cam6] [-13] IOTC_ER_TIMEOUT
[Cam7] [-13] IOTC_ER_TIMEOUT
[Cam8] [-13] IOTC_ER_TIMEOUT

[shawnsi]

Is this issue getting worse for anyone that already mitigated today? I'm seeing rolling camera reboots and intermittent outages now even on the same LAN in host mode. 😓

[anthonyseto]

I just spent the last 2 hours pulling my freaking hair out with the same errors and then decided to jump to this forum to find it's not just me. Having the same issue. I tried starting with a fresh container image, new API key....not luck. Getting the following error:

wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - DrivewayV3 on 192.168.42.110
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:00] "GET /api/sse_status HTTP/1.1" 200 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET / HTTP/1.1" 200 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET /static/bulma.css HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET /static/bulma-toast.js HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET /static/site.css HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET /static/loading.svg HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET /static/site.js HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:19] "GET /api/sse_status HTTP/1.1" 200 -
wyze-bridge | [WyzeBridge] ⏰ Timed out connecting to DrivewayV3.
wyze-bridge | [drivewayv3] [-13] IOTC_ER_TIMEOUT
wyze-bridge | [WyzeBridge] ☁️ Pulling "drivewayv3" thumbnail to /img/drivewayv3.jpg
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:30] "GET /img/drivewayv3.jpg HTTP/1.1" 200 -
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:17:31] "GET /img/drivewayv3.jpg HTTP/1.1" 304 -
wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - DrivewayV3 on 192.168.42.110
wyze-bridge | [WyzeBridge] [drivewayv3] Snapshot timed out
wyze-bridge | [WyzeBridge] 192.168.0.203 - - [22/Feb/2025 05:18:05] "GET /snapshot/drivewayv3.jpg?1740201469469 HTTP/1.1" 200 -
wyze-bridge | [drivewayv3] [-13] IOTC_ER_TIMEOUT

Can't get a new snapshot or any RTSP streams to work. As such my connection to Scrypted fails along with HSV. I can access my camera from the Mobile App, but if I log into the Wyze WebUI for checking, it fails to connect as well. I generated a log for Wyze support.

[Vpsjbsrn]

for Wyze V3 Cam: keep up to date firmware and add SD card with wz_mini_hacks file. it will automatically work with docker bridge. my 1 camera i tried this and it is working fine.

[anthonyseto]

tell me about this wz_mini_hacks file...?

[Vpsjbsrn]

https://github.com/gtxaspec/wz_mini_hacks

[cyberfingers]

I too am having the same issue. I called Wyze support 206-339-9646 and they had me send them a screenshot and said that their engineers would look into the issue. If I get any responce from them will certainly let Y'all know.

[FeatherKing]

to rule out docker, ive made an ubuntu vm on my camera vlan, installed wyze-bridge and all its dependencies and am now running wyze-bridge with no docker. All my V3 cameras fail, V2 cameras are fine. My theory is a change in the P2P portion of this TUTK library old thread probably related to locking down to the local subnet.

Admittedly my VLAN makes my setup more complex, but my next test would be to connect a real non-bridged device to the camera vlan and run wyze bridge again. qemu VMs are still using a bridge and host networking wouldnt so im guessing some network virtualization is breaking this p2p connection for v3 and newer cameras.

[FeatherKing]

moved a raspberry pi to the same wifi as my cameras. no docker, running the app directly on the pi and it cant connect to v3 cameras (v2 works fine). There shouldnt be any virtualization in my connection flow at this point but it still doesnt connect to the v3 cameras.

definitely not only a docker problem. maybe two separate problems

• network virtualization issues (bridges, macvlan, etc)
  • which is why host mode helps some
• possibly logic to lock to a specific subnet
  • (maybe 192.168/16, whereas my cameras are on a 10/8)

(screenshots showing the raspberry pi mac address at the wifi ap view and also on the host. no virtual mac addr)

[FeatherKing]

started seeing this in my logs today (i dont remember seeing it before)
"Error opening input files: Server returned 400 Bad Request"

wyze-bridge | [hag-driveway] [-13] IOTC_ER_TIMEOUT
wyze-bridge | [hag-cam] [-13] IOTC_ER_TIMEOUT
wyze-bridge | [driveway-south-floodcam] [-13] IOTC_ER_TIMEOUT
wyze-bridge | [deck] [-13] IOTC_ER_TIMEOUT
wyze-bridge | Error opening input files: Server returned 400 Bad Request
wyze-bridge | Error opening input files: Server returned 400 Bad Request
wyze-bridge | Error opening input files: Server returned 400 Bad Request
wyze-bridge | Error opening input files: Server returned 400 Bad Request

[Vpsjbsrn]

Solution: #1432 (comment)

[FeatherKing]

that isnt a solution

[Vpsjbsrn]

As far as my rtsp work I am fine, until we did not get root cause or fix this solution help me to get RTSP.

[FeatherKing]

saying "solution:" is pretty broad. there are still many scenarios where this didnt fix things (windows, haos, vlans, etc)

[FeatherKing]

TLDR: until there is a real fix, wyze-bridge has to be on the same subnet as your cameras, and somehow multicast traffic is to blame for these issues

Alright, ive "fixed" mine and narrowed down the cause a little more (no true fix). but i am now working in docker without host networking.

my docker host is at 192.168.0.23 and my cameras are on 10.0.1.2, but i am running wyze-bridge on top of 192.168.0.23 but it has an IP at 10.0.1.2. I am not using host networking.

• i could not find a way to run wyze-bridge on a different subnet from the cameras
  • i expect the P2P library (tutk) has some kind of check for its own subnet before connecting to the local video stream
• docker host mode is not required, but there is some kind of multicast/broadcast traffic for the subnet validation
  • im guessing the default docker bridge is screwing up whatever check is happening. host mode would put multicast traffic right on the physical network rather than many layers of docker networking. My "working" setup makes me think avahi in the container might help but i havent tested
• if you use unifi (or have granular control over multicast/broadcast traffic), you must explicitly allow multicast from the MAC address where the wyze-bridge is running
  • i tested this with multiple devices (with and without docker). in Unifi the setting is under WIFI > (ssid) > Multicast and Broadcast Control
  • if you have this enabled, the wyze-bridge MAC must be in this list
• i was unable to get macvlan working with vlan 100
  • i expect because macvlan operates at L3 that this is a firewall on my end somewhere messing it up. someone should be able to use macvlan to put wyze-bridge right on the same subnet as their cameras (and not need host networking)
• ipvlan in L2 mode (the default) worked for me with vlan 100
  • the docker network driver creates the tagged interface automatically
• im not sure how macvlan and ipvlan behave in docker desktop for windows/mac, but could be worth trying.

my working docker compose (replace enp1s0 with your interface and 100 with your vlan id)

networks:
  vlan_100:
    driver: ipvlan
    driver_opts:
      parent: enp1s0.100
    ipam:
      config:
        - subnet: 10.0.1.0/24
          gateway: 10.0.1.1

services:
  wyze-bridge:
    container_name: wyze-bridge
    image: mrlt8/wyze-bridge:2.10.3
    restart: unless-stopped
    networks:
      - vlan_100
    logging:
      driver: journald
    ports:
      - 8554:8554 # RTSP
      - 8888:8888 # HLS
      - 8889:8889 #WebRTC
      - 8189:8189/udp # WebRTC/ICE
      - 5000:5000 # WEB-UI
    devices:
      - /dev/dri:/dev/dri
    environment:
      - SNAPSHOT=RTSP60
      - H264_ENC=h264_qsv
      - WB_IP=10.0.1.2
      - MTX_WRITEQUEUESIZE=1024
      - WB_WEBRTC_URL=https://wyze.replace.me/
      - WB_HLS_URL=https://wyze.replace.me/
      - MQTT_HOST=mqtt.replace.me:1883
      - ENABLE_AUDIO=true
      - AUDIO_CODEC=AAC
      - WB_AUTH=false
    ulimits:
      nofile:
        soft: 20000
        hard: 40000

[kanemari]

TLDR: until there is a real fix, wyze-bridge has to be on the same subnet as your cameras, and somehow multicast traffic is to blame for these issues

Alright, ive "fixed" mine and narrowed down the cause a little more (no true fix). but i am now working in docker without host networking.

so this 'ipvlan' networking driver in docker, does it use the NIC in the host directly without creating an internal bridge? sort of like a virtual driver that creates another IP on the same card? so in a way its like host mode as there is no internal NAT - but you arent sharing the IP with the host, just the NIC, so you can avoid all the port conflicts with a separate IP address?

Ive never needed to use it since all my dockers are in VM containers and its easier to add in 2 virtual NICs in the HW config rather than create another virtual NIC within the VM OS itself, but it looks like a decent solution for the non-virtualised. good to know docker can do that!

[FeatherKing]

ipvlan can operate at layer 2 or layer 3. macvlan is at layer 3. the difference is in routing in the layer 3 layer.

ipvlan in L2 mode is basically giving the container its own ip without any other bridge ip routing in front of it. fairly similar to adding another virtual nic to the vm.

i expect there is some dumb-check by the p2p library to see the subnet of the app and then match the subnet of the camera. if they match they are allowed to talk. I cant figure out why multicast is involved, maybe it blasts a payload out to the cameras but i havent looked through my packet captures yet.

[PCjabber]

Thanks for this info! I didn't need to use a different VLAN, and my Docker host is on the same subnet as the cameras. My network config section looked like this:

networks:
  subnet_120:
    driver: ipvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.120.0/24
          gateway: 192.168.120.1
          ip-range: 192.168.120.60/30

That assigned my container a 192.168.120.60 IP, and after changing Blue Iris config to look at the new IP, all of my cameras are working properly. Thanks again!

[FeatherKing]

further evidence that its multicast/broadcast or udp related. I use ubiquiti gear and my cameras are on an IoT vlan where broadcast is limited to airplay/chromecast/etc. When i add the wyze-bridge to that list, the cameras work, when i remove it, wyze-bridge cant connect to the cameras.

i took some packet captures
when broadcast is allowed, the connection is short. a couple UDP packets both directions and things work (first pic)

when broadcast is blocked, you can see multiple UDP retries (second pic) and the connections never work

[shawnsi]

@FeatherKing just wanted to confirm, you still can't use seperate subnets for cameras and the wyze-bridge, right? I tested multicast and udp across subnets successfully but still can't get a camera connection across.

Nice dig overall here, many thanks. It lines up with my observations too. I'll look to adopt your ipvlan driver example to get away from host network mode as well.

[FeatherKing]

correct, subnet has to be the same for wyze-bridge and cameras right now, but wyze is aware now

[c0f]

Hi, @FeatherKing my devices are on a Ubiquiti network as well but they're not on a separate VLAN, my whole network is in VLAN 1.

In the WiFi settings for the SSID my cameras connect to I have the following settings:

• Advanced: Auto (which grays out the options below)
• Multicast Enhancement: unticked
• Multicast and Broadcast Control: unticked

I'm happy to change these settings if it helps verify your theory.

[FeatherKing]

i would expect if you enabled "Multicast and Broadcast Control (MaBC)" your cameras would stop working. I tested that quite a bit. its a fast change and does not require the unifi ap's to re-provision. seems to take effect immediately. MaBC blocks everything and allows you to allow specific devices based on MAC address.

for me:
MaBC enabled + no wyze-bride mac = fails
MaBC enabled + wyze-bridge mac = works
no MaBC should work (since it would allow everything by default)

what i cant explain is why it breaks them. Im not seeing any broadcast or multicast traffic in the tcpdumps. later i might look at the local unifi AP and see what it changes on the device when that setting is enabled. I expect i will find an iptables rule that blocks UDP in some way.

[jk111]

There looks to be directed broadcast traffic from the wyze bridge container.

[FeatherKing]

interesting i dont have that in any of my captures but that is what i was looking for. since broadcast traffic cant traverse subnets without help, im assuming that the p2p library added this and it isnt falling back to the old logic

[johnnyv5]

Forgive my ignorance, but I am having issues with RTSP streaming. Getting the IOTC_ER_TIMEOUT as well as i/o error on the stream. I want to try changing the IP of my Docker Wyze Bridge server. And that is where I am stuck. From the logs of the Docker Wyze Bridge the IP is 172.30.32.x and my local subnet is 192.168.1.x. I do not have VLANs setup on my network. Where do I go to change the server that the wyze bridge is on? I am running HA on an intel small form factor PC.

Core. 2025.2.5
Supervisor 2025.02.4
Operating System 14.2
Frontend 20250221.0

I have Docker Wyze Bridge installed as an add-on. Any help would be appreciated.

edit:

I tried installing the modified add on that changes the host_network to true but that did not solve my issue.

[appelboom]

Just reconfigure Docker Wyze Bridge to run network_mode: "host" in your config (See #1432 (comment)

[wyze-dragonslayer]

This worked for me. Got the firmware from wyze

Using HA with Frigate. Wyze cam v3 on IOT vlan and bridge on LAN.

Core. 2025.2.5
Supervisor 2025.02.4
Operating System 14.2
Frontend 20250221.0

I have Docker Wyze Bridge installed as an add-on. Reflashed 4.36.11.5859 firmware on wyze cam v3
demo_wcv3_4.36.11.5859.bin.zip
#1438 (comment)

I let wyze know that his firmware worked for me and I hope they can fix the issue soon for the rest of my other wyze cams.