Where did you change the container to use macvlan type?

I was having this issue too. After many, many hours of log reviews and experimenting with different configurations running in both a standalone container, and as a HA Add On, I came to realize that when I change the docker network used by the container to a "macvlan" type, the application runs GREAT!!! Best it has ever run for me in the last year. I'm not sure why this is the case but wanted to pass along this info in case it helps others.

So for me. Host mode they all work, except no webrtc. Switched to bridge. Nothing works. Changed to macvlan with bridge and 2 cameras work and webrtc... So not best results for me. Host mode is the only way to get all cameras to connect, macvlan w/bridge mode is the only way to use webrtc...

I was finally able to get it to work with the local host bridge add-on. My webrtc cameras weren't working initially as well. I noticed it was trying to use port 8554 which was conflicting with the bridge initially; however, removing and re-adding webrtc (after installing the local host bridge) appears to run fine at the same time with the bridge using port 8554. All my webrtc cams were using 8553 prior to this issue popping up. I can't remember for the life of me how I initially had it set to 8553. The reinstall forces 8554, but again still appears to run along side the local host bridge, that's also using 8554.

Thanks for posting this. I tried setting up a macvlan using Portainer and it didn't work, but using your command line did work, and wyzebridge is now back online.

• edit: hmm, maybe it won't work - I can't communicate to the macvlan from other containers on the same host - i.e if I have frigate @ 192.168.200.15 and the wyzebridge on a macvlan using 192.168.200.20 both using the same physical nic they can't ping each other.

*edit 2: so I would need to add all the containers to the macvlan network

create the macvlan

docker network create --driver macvlan --subnet 192.168.200.0/24 --gateway 192.168.200.254 --ip-range=192.168.200.0/24 -o parent=enp1s0 wyzebridge_macvlan

then modify each of the containers and add:

networks:
  whatever-local:
    external: true
    name: wyzebridge-macvlan

services:
        networks:
          whatever-local:
            ipv4_address: 192.168.200.20 # ip of server

On a standalone docker host (not associated with Home Assistant) I created a macvlan using:

docker network create --driver macvlan --subnet 192.168.1.0/24 --gateway 192.168.1.1 --ip-range=192.168.1.25/32 -o parent=enp1s0 wyze_bridge_macvlan_network

in my case I wanted the macvlan to bind to a specific address on my lan (192.168.1.25) hence the --ip-range=192.168.1.25/32 option. Without specifying --ip-range=, macvlan will bind to the first ip address in the subnet. In my case that was 192.168.1.2 which was in use by another device.

then i referenced the network in the network_mode option of my docker-compose.yml :

services:
    wyze-bridge:
        container_name: wyze-bridge
        restart: unless-stopped
        image: mrlt8/wyze-bridge:latest
        network_mode: wyze_bridge_macvlan_network

        ports:
            - 1936:1935 # RTMP
            - 8556:8554 # RTSP
            - 8888:8888 # HLS
            - 8889:8889 #WebRTC
            - 8189:8189/udp # WebRTC/ICE
            - 5010:5000 # WEB-UI

I ran docker-compose up (no -d option) so I could monitor the log messages. Everything worked perfectly. As soon as I removed the network_mode refererence to my macvlan network and restarted the container, I'd get IOTC Timeouts repeatedly and the cameras streams would never come up.

I tried dozens docker-compose scenarios but this was the only on way i could get it working.

I haven't been able to figure out how to do something similar on Home Assistant when docker-wyze-bridge is running as an add_on. I assume there's a docker compose file somewhere burried inside Home Assistant but I haven't been able to figure out where it lives.

Just to add that I followed this and it worked. I didnt realize that I would have to lose an ip in the process (one for my lxc container and now a new one for the wyze bridge docker container) but its all good, and now my V2 works again. Thanks! My eight V3s do not have this issue only the V2

I assume this is on a Linux OS?

On a standalone docker host (not associated with Home Assistant) I created a macvlan using:

docker network create --driver macvlan --subnet 192.168.1.0/24 --gateway 192.168.1.1 --ip-range=192.168.1.25/32 -o parent=enp1s0 wyze_bridge_macvlan_network

in my case I wanted the macvlan to bind to a specific address on my lan (192.168.1.25) hence the --ip-range=192.168.1.25/32 option. Without specifying --ip-range=, macvlan will bind to the first ip address in the subnet. In my case that was 192.168.1.2 which was in use by another device.

then i referenced the network in the network_mode option of my docker-compose.yml :

services:

    wyze-bridge:

        container_name: wyze-bridge

        restart: unless-stopped

        image: mrlt8/wyze-bridge:latest

        network_mode: wyze_bridge_macvlan_network



        ports:

            - 1936:1935 # RTMP

            - 8556:8554 # RTSP

            - 8888:8888 # HLS

            - 8889:8889 #WebRTC

            - 8189:8189/udp # WebRTC/ICE

            - 5010:5000 # WEB-UI

I ran docker-compose up (no -d option) so I could monitor the log messages. Everything worked perfectly. As soon as I removed the network_mode refererence to my macvlan network and restarted the container, I'd get IOTC Timeouts repeatedly and the cameras streams would never come up.

I tried dozens docker-compose scenarios but this was the only on way i could get it working.

I haven't been able to figure out how to do something similar on Home Assistant when docker-wyze-bridge is running as an add_on. I assume there's a docker compose file somewhere burried inside Home Assistant but I haven't been able to figure out where it lives.

Is the .25 address the server or an open/available address?

Assuming this is on Linux, not Win?

For those that have Ubiquiti WiFi, I had to turn of Multicast and Broadcast Control for the SSID. After turning this off and making sure I had the Docker Wyze Bridge configured with Host, the cameras started working and continue to work.

• Does just setting privileged mode also work?

I didn't try that, but I would imagine it might.

check out this thread
#1471 (comment)

I can confirm this worked for me. But bridging and giving the container its own ip address also made webrtc work. It's flawless again.

Oddly, doesn't work for me!

Oddly, doesn't work for me!

Try assigning the container an IP in the subnet or vlan as your cams. Host worked ok for me, but giving it an IP fixed all my issues.

For example

--net='br0' --ip='192.168.88.9' instead of net=`host'

Your usage may vary. And you'd need a bridged interface to reference.

How can I try this fix when using docker-wyze-bridge as an add-on?

Oddly, doesn't work for me!

Try assigning the container an IP in the subnet or vlan as your cams. Host worked ok for me, but giving it an IP fixed all my issues.

For example

--net='br0' --ip='192.168.88.9' instead of net=`host'

Your usage may vary. And you'd need a bridged interface to reference.

What's the equivalent of setting ip in docker-compose files? I tried ipv4_address but it did not work.

I have a detailed write up with swarm and standalone docker engine along with some network settings for those using vlans here #1471 (comment)

you may benefit from using a udp broadcast relay as detailed in one of the comments