Wyze Bridge and Unifi Settings that won't hose your network

[maxfield-allison]

EDIT 03-04-2025
It looks like a change in the firmware versions has forced a situation where you must have the wyze bridge and your cameras on the same VLAN/subnet/broadcast domain. I am currently running wyze bridge in swarm with a macvlan connection and working on a work around for it.

EDIT 02-23-2025
references to the issues currently ongoing with iotc err timerout
#891 (comment)

EDIT 10-30-2024
New Recommendations

Optimized Configuration for Wyze Cameras to Reduce Channel Utilization on UniFi and Other Networks
Upon extensive testing and reconfiguration with the latest Docker Wyze Bridge version, I've found a set of optimized settings that provide a stable connection without overwhelming the channel utilization. For reference I have about 4 access points, mostly AP 6 Pro's, and roughly 15 Wyze cameras that run the gamut as far as generation goes. All Cams are connected to a VLAN/SSID specifically for my security related devices. I will present my recommended configurations below:

Docker Compose:
The docker compose settings are kept relatively straightforward:

wyze-bridge:
  container_name: wyze-bridge
  restart: unless-stopped
  image: mrlt8/wyze-bridge:latest-hw
  deploy: # Only only needed for HW-Accel build
     resources:
      reservations:
        devices:
        - driver: nvidia
         device_ids: ["0"]
         capabilities: [gpu]
  ports: 
     - 1936:1935 
     - 8556:8554 
     - 8888:8888 
     - 8889:8889 
     - 8189:8189/udp 
     - 5010:5000 
  environment:
     - WB_IP={YOUR_HOST_IP}
     - ON_DEMAND=False
     - IGNORE_OFFLINE=true
     - FPS_FIX=true
     - ENABLE_BOA=true
     - QUALITY=HD60
     - H264_ENC=h264_nvenc # Only only needed for HW-Accel build
     - NET_MODE=P2P
  networks:
    - t2_proxy
  security_opt:
    - no-new-privileges:true

Note: Host ports had to be rewritten since I'm running Frigate on this docker host as well for the time being. (EDIT: you could also use the MTX environment variables to adjust the ports iirc). The environment configuration H264_ENC=h264_nvenc is only needed for HW-Accel build.

UniFi Access Points Settings:
The settings for your UniFi AP's are as follows:

Managed by global AP settings: Checked #optional, but easier for my case
Nightly Channel optimization: Checked #optional but again, easier to manage in my incredibly congested wireless environment
Minimum RSSI: 68dBm #Optional, play around on your AP's to limit roaming
Interference Blocker: Checked #optional, highly dependent on your wireless environment
Band Steering: Set to prefer 5g #doesn't affect our configuration but works well for me

Global AP Settings:
2.4 GHz Radio Channel Width: 20 MHz
Transmit Power: Custom 16 dBm
5 GHz Radio Channel Width: 160 MHz
Transmit Power: Auto

Specific Wyze cam SSID and VLAN Settings:
2.4GHz: Checked
5 GHz: Unchecked
Client device isolation: Checked
Proxy ARP: Checked
Multicast Enhancement: Checked
Multicast and broadcast control: Checked #this seemed to be the secret sauce for me
Auto DTIM: Checked
Auto Data rate: Checked
PMF: Disabled
Security: WPA2

On all intermediate switches, ensure that Spanning Tree Protocol and LLDP-MED are checked, mostly to guard against our own hubris. I also isolate this port in my switches.

The primary firewall is virtualized OPNsense in HA with firewall rules that block any inter-VLAN traffic from the security net but allow only the required protocols through to the VM running the Docker node. I am not utilizing IGMP snooping at all on any of the primary or intermediary devices. All of my wyze cams are on their own vlan which is served up by the unifi AP's.

I have implemented storm control on the Mikrotik switch that serves as my primary hub at a value of 25% with good effect. you could probably do the same on your unifi gear but I haven't measured my packet flow to determine a solid rate limit yet.

It's also good practice to force the wyze cams to connect to the closest AP in a multi-AP configuration to (attempt) to prevent them from bouncing all over the house, so to speak. You can do this by finding the device in the client list of the unifi controller etc. and locking it to a specific access point.

I've now been running this configuration with great success for the past several days. I'll give it a week and then start switching frigate over to use the wyze bridge streams instead of gtxaspec/wz_mini_hacks/

[maxfield-allison]

[maxfield-allison]

24 hours later, have started adding cam pan v3's into the system and 0 issues to speak of. Still have low-moderate channel utilization and the network flooding seems to be completely stopped by Multicast and broadcast control: Checked

Now moving all of my cameras around and rationalizing the setup. Need to update all of the devices still running wyze mini hacks to latest firmware and adjust my frigate config for the new streams. Will be experimenting with using substream for detection with frigate and a USB Google Coral on Wyze Bridge instead of the "native" rtsp stream from wyze hacks

[maxfield-allison]

@mrlt8 after I see others experience with these settings and confirm they are sound, I'll create a PR to update the docs.

[maxfield-allison]

I was able to determine part of the issue lies within my Mikrotik CRS305-1G-4S+ switch. enabling unknown multicast flooding on the ports my opnsense firewalls connect to along with a 50-75% storm rate seems to have had a positive effect on the consistency of the camera connections to the wyze bridge and AP's.

[maxfield-allison]

"ENABLE_AUDIO=True" sends everything straight into the same behavior, so let's avoid that for the time being.

[keawepoo]

"several minute delay" - as in video or audio? If its video I have the same issue...

[mrlt8]

"several minute delay" - as in video or audio? If its video I have the same issue...

@keawepoo Is that with the dev branch?

The audio would typically fall behind the video. There seems to be an issue with the time stamps from the camera which is causing muxing issues with the audio.

[maxfield-allison]

For me it's the video. I didn't listen to see if the audio was affected as well. This was on latest-hw. Still running on dev now but haven't reenabled audio yet

[mrlt8]

Is that by any chance with a 15FPS camera like the v2?

[maxfield-allison]

sorry for the delayed response but on the latest hw dev version, I have audio enabled and everything is as rock solid as its ever been

[maxfield-allison]

recently adjusted a few things, mainly the wifi network for the security devices I have.

it seems that adding the minimum data rate control has freed up a ton of channel air time.

[drivenbymetal]

Holy cheeseburgers batman! This just saved me from ripping all of my wyze products out! Thank you so much!!

[maxfield-allison]

Holy cheeseburgers batman! This just saved me from ripping all of my wyze products out! Thank you so much!!

i swear as soon as money is no longer a major issue or my wife and I build a house and can absorb the cost intro the mortgage, Im going with US firmware flashed Dahua cams from empire tech and still ripping these wyze cams out. for the price, they kick ass though.

[TristanBrotherton]

Have there been any other discoveries on this front? I have a really solid network setup, but my Wyze Cams work like absolute crap, even when next to the AP. I've implemented all the settings you've documented above. With the exception of the Data Rate Control as it caused all cameras to disconnect.

[maxfield-allison]

this is almost exactly the same topology that I was running until recently. I would double check that you have multicast and broadcast control turned on for the network the cams are connected to. if that (SSID) network services other devices, be aware that this setting will prevent things like chromecast or sonos from functioning correctly unless you whitelist their device MAC in the wifi network settings.

from your ping output, it looks like there are tons and tons of rebroadcasts occuring. I'd change the compose from
- NET_MODE=P2P to - NET_MODE=LAN
and see if that affects it. check the container logs and ensure the cams are connecting using lan mode.
I do find it odd that implementing data rate control caused a complete disconnect. In my environment, I did end up dialing back the setting to more like 6Mbps because I saw some similar behavior but this setting seems to help with channel utilization.
Other than that, there is still more investigation to be done into how these unifi AP's handle these devices differently than standard consumer gear.

I'm in the process of migrating all of my services to a proxmox 3 node cluster running 6 docker swarm VM's so once that's done, I'll begin troubleshooting this situation again. at this point my inclination is there are probably more settings we can change in the AP's themselves that aren't exposed by the controller gui.

[TristanBrotherton]

Thank you sir, I was able to set the data rate control to 6mbs now, but i still have no real improvement with the cameras cycling between 5ms to 5000ms ping times and being very unstable.

[TristanBrotherton]

My latest suspicion is that WMM may be causing the issue. I've found a full list of settings available here:
https://gist.github.com/modest/d6ffb2cdd5e38b213f24c29be38e3b1d
I've been looking at: https://web.archive.org/web/20210128000700/https://help.ui.com/hc/en-us/articles/205223330-UniFi-Can-I-make-persistent-changes-to-UAP-s-system-cfg- to apply them though I have no idea if the current UniFI firmware honors this documentation that has gone from their website.

[maxfield-allison]

as far as I'm aware, and I can't find the original source at the moment, WMM is listed in your wifi SSID settings as UAPSD.

[TylerDIREC]

Are your AP's configured for 20mhz as well as different and nonoverlapping channels on the 2.4 GHz (1,6,11)? When you do a channel scan are those 2.4 ghz channels showing high interference? Are other devices on the 2.4 experiencing this same issue with high ping at the same time as you ping the cameras? The symptoms you are describing with the varying and high ping rates to me is indicative of a few things. 1. Misconfigured channels causing overlap and traffic collisions on the WLAN. 2. A broadcast storm. i am leaning towards 1 as a broadcast storm would eventually cripple the entire network for both wired and wireless clients. There may be some settings which would be causing this in the controller / WLAN setup as well. Check yours and my replies below and compare to what you got configured and let us know.

[scoob8000]

I just came across this thread and am in the same boat. I didn't notice any issue until I added v3 based cameras. My older wyze cams (v2, and pan work flawlessly). I have a doorbell cam, and just added a floodlight cam and am having a heck of a time with them. Really jumpy frame rates, and my pings look much like what others are posting.

I'm running a couple AC Lites and a AC Pro. Made the unifi tweaks mentioned above and it seems to have helped slightly, but still not good.

maxfield-allison, I do have enable audio turned on. Does turning that off really fix things, or at least for now?

I haven't tried changing it, or NET-MODE yet. I run docker on a qnap nas, and it's pretty bastardized. Seems like anytime I modify a container, I end up having to rebuild it from scratch. It doesn't seem like like changing things by hand, or via portainer.

[EDIT] I've set enable audio to false. Doorbell cam seems to be better, but the floodlight cam is still only 1-2FPS and ping times all over the place.

[maxfield-allison]

Enable audio definitely screws up everything for me. Changing the quality
also definitely helps.

[scoob8000]

Audio didn't seem to make much difference for me. I have not added a quality variable. Not sure what the default is. Is your =HD60 any noticeable difference from whatever the default is?

FWIW, I'm also running opnsense, and have all my cams/iot stuff in their own vlan. The docker wyze bridge is in a different vlan. Did you change anything in opnsense, besides allowing ports thru the firewall?

I poked around my switch too. It's a older, semi smart dlink. No storm control options. There is some IGMP snooping stuff, but it's all disabled.

[mrlt8]

I believe IGMP snooping tends to help on some networks.

[keawepoo]

Whats the network for? and does everyone get
"☁️ Connected via RELAY MODE! Reconnecting"??

version: "2.4"
services:
    wyze-bridge:
        container_name: wyze-bridge
        restart: unless-stopped
        image: mrlt8/wyze-bridge:latest
        #2.3.5
        ports:
            - 1935:1935 # RTMP
            - 8554:8554 # RTSP
            - 8888:8888 # HLS
            - 8889:8889 #WebRTC
            - 8189:8189/udp # WebRTC/ICE
            - 5000:5000 # WEB-UI
        environment:
            - WYZE_EMAIL=Why@gmail.com
            - WYZE_PASSWORD=PASSWORD
            - WB_IP=192.168.1.107
            - ENABLE_AUDIO=False
            - SUBSTREAM=True
            #- MQTT_HOST=
            #- MQTT_AUTH=
            #- MQTT_TOPIC=
            - ON_DEMAND=False
            - IGNORE_OFFLINE=true
            - FPS_FIX=true
            - ENABLE_BOA=true
            - QUALITY=HD60
            #- H264_ENC=h264_nvenc # Only only needed for HW-Accel build
            - NET_MODE=P2P
        #networks:
            #- t2_proxy
        security_opt:
            - no-new-privileges:true

[maxfield-allison]

network mode is to force a direct connection without going through the relay which is going to be sketchy at best in my experience.

[keawepoo]

100% noob here... How do I setup the network?

[maxfield-allison]

100% noob here... How do I setup the network?

Net_mode env variable to LAN or P2P.

[keawepoo]

Well when I use P2P it all fails.... LAN works...

[maxfield-allison]

thats odd. I would check again now that some updates have happened. p2p should still use LAN and failback to p2p if that doesnt work

[TristanBrotherton]

Hi everyone, I had some pretty serious issues that have now been resolved with a new early access firmware from UI. This was the response I got from them. I have ten or so cameras that were previously almost unusable and are now excellent.

I suggest you to update any one of the Access Points to the [early access version 6.6.33](https://community.ui.com/releases/UniFi-Access-Point-6-6-33/9b0180a4-2eca-4c57-9b78-f6408cb0712a) as it has major improvements related to connectivity. Once updated, connect a camera device to the Access Point and monitor, to see if this is resolved.
For reference on updation, Check out [this article](https://help.ui.com/hc/en-us/articles/204910064).
To access the early access version, ensure to enroll for the early access program under https://account.ui.com/profile.

[maxfield-allison]

Gonna give this a shot first chance I get. Thanks for the heads-up. Please let us know if you encounter any bugs with it!

[maxfield-allison]

got it updates. doesn't seem to help much but also doesn't seem to hurt either. haven't experienced andy obvious regression.

[maxfield-allison]

another new early access release just came out. so far no major issues.

[scoob8000]

I just signed up for early access, does it take awhile to be granted access? I'm not seeing any early access releases yet.

[scoob8000]

So far so good with audio on. My doorbell cam freaked out once and needed to be rebooted, but besides that once it seems to be good.
Even my floodlight is happy. It was giving me the most headaches before.

Sidenote, is anyone here running a v3 pro? I've been thinking about getting one and trying to swap the cam on the floodlight with it to get a better picture. But, with that comes more bandwidth.

[scoob8000]

Been 5 days and so far so good. My doorbell cam had issues once or twice but rebooting it from the wyze apo fixed it. The weird thing, when it would act up, the score in the controller for it would reflect that.

[TylerDIREC]

I like the write up, thank you for sharing :)

I'll share my unifi setup(s) for my IoT networks as well. Note that I do not keep CCTV on a separate VLAN for the time being. I have 6 V3 cameras deployed to this 1 site across 2 APs. These cameras connect to the bridge which is at a remote location. They are a U6-Mesh and a U6-LR. An item of importance when it comes to balancing the cameras across AP is the # of spacial streams on the AP for the 2.4 GHz network. In my case I have 2x2 on the Mesh and 4x4 on the LR. The cameras are a 1x1, meaning the 4x4 AP can talk to 4 cameras all at the same time without having to "queue or drop" packets up or down. Mind you this communication happens so fast and the AP can handle more than 4 clients (cameras) on the 2.4 network.

Next is channel over lap and co interference. For 2.4 GHz always always use 20mhz channel widths and only use channel 1,6,11 to avoid overlap and co interference in a multi AP deployment. As you have done as well set your transmit power to custom (to match the clients) anywhere from 12-18 dBm.

Note that I do have other SSID's. IGMP Snooping and Multicast DNS is enabled on all networks. (This is where broadcast control comes into play so the network doesn't get flooded) as I have devices on the IoT network that need to be seen by other devices for Airplay, Airprint, all that fun stuff. Anywho:

Note: Some IoT devices do not play well with these settings when adding new devices so they need disabled temporarily I this order:

UAPSD - Power Savings - for a CCTV network only I would leave this off. Having it on does not affect my cameras ( I have a V3 pro at another site halfway around the globe (Same settings) that connects into the bridge and then into Blue Iris and its Near Real Time.

Hide Wifi name, client isolation, multicast control, multicast enhancement. Note. If you lose connectivity with other devices across vlans once these are enabled then disable "Multicast Enhancement" to restore connectivity.

Proxy ARP - Reduces airtime and allows the AP to answer requests as opposed to a client on the WLAN.

Add MAC addresses that you want to allow broadcast traffic from to other WLANS / VLANS - important for MDNS so devices on other WLANS/ VLANS can see whats in the IoT network. In my network, the homepod sometimes jumps onto the ioT network if I am adding a new device or forget to forget the network after adding new devices. The printer lives on the IoT network and gets printed to from the trusted lan and locked down guest network.

802.11 DTIM Period - this is basically how ofter the AP is pinging the client in seconds. No need to ping the clients every 1 second to see if they are there. This reduces airtime.

Minimum Data Rate Control - Having set to 12 + for 2.4 GHz prevents older client (802.11b) from joining the network. Should one of these clients come on the band then the entire 2.4 network is brought down to its level (the weakest link) which is not good and will effect throughput substantially, etc.

I keep cameras locked to the AP i want them on as well.

As you can see the network supports other 2.4 clients as well.

AP Settings: Note that i use 40 mhz channels due to not wanting co interference / non over lapping channels between the AP's

Band steering i set at the AP and not at the wifi network level as they are 2 different settings. The one called band steering at the SSID config will force clients to 5hz and work to keep them there, the one at the AP level is more friendly when using a shared SSID across 2.4 and 5 ghz.

LR:

Mesh:

Here is the other site that has the single V3 Pro: this is run by a single UDR:

The wyze bridge itself runs on a ubuntu server 22 LTS CLI only on a hyper-v guest VM on a host that has an i7 dual processor with HT. 2 core and 2 gigs of ram dedicated to the guest. The bridge is ingesting 12 feeds total. only 2 feeds are local to the network where the bridge lives.

For when I do migrate the Wyze devices to their own VLAN and SSID here is what I would set my wifi network up as initially:

(IPTV LAN) = Replace with CCTV LAN

I would then look into implementing Client device isolation and Multicast Enhancement. I wouldn't be worried about setting "wifi speed limits" for wifi or at the VLAN with a traffic rule as these are on 24/7 and use less than 4mbps upstream each. For updates, I wouldn't set a down limit unless you have bandwidth limitations from your isp and need to manage traffic in that way. If so I have a 20/20 wifi and a 20/20 internet traffic rule in place ready to apply to the WLAN and the VLAN. As the sooner the client can get its update the sooner it is no longer using that airtime and it frees up for other clients reducing congestion.

Here are my settings in the bridge:

version: '2.4'
services:
wyze-bridge:
container_name: wyze-bridge
restart: unless-stopped
image: mrlt8/wyze-bridge:latest
ports:
- 1935:1935 # RTMP
- 8554:8554 # RTSP
- 8888:8888 # HLS
- 5000:5000 # WEB-UI
environment:
- WYZE_EMAIL=1@2.com # Replace with wyze email
- WYZE_PASSWORD=PW # Replace with wyze password
- ENABLE_AUDIO=True
- FILTER_NAMES=
- FILTER_BLOCK=True
- SUBSTREAM=True
- QUALITY=HD255

Hope this helps as well :) - T

[maxfield-allison]

implementing some of your options here on my network now. I also had most of them set but unchecked them or set to defaults for testing purposes. once I had everything working at least somewhat better than before I was afraid to touch it lol

[TylerDIREC]

Awesome! you are certainly right on having things misconfigured. That can either bring the network to its knees and not in a good way or result in weird things happening with connected clients. From what I can see of your WLAN deployment your're on the right track with regard to customizing the transmit power in order to keep adjacent AP's from hearing one another too much. I feel you will see greater benefit as well by taking a look into the channels each AP is set to as well as reducing 5ghz down from 160mhz channel widths. Work to "honey comb" your channel layout between 1,6,11 on 2.4. Once you introduce the 4th AP set it to channel 1,6, or 11 which will result in a continuation of the pattern and the least amount of overlap from the AP of the channel number you are setting on AP 4.

Same concept on the 5ghz. I would recommend going to 40mhz channels. For some perspective on a wifi 6 iPhone (2x2) at the AP or in the next room depending on building materials and transmit power you should be able to push and pull 500 Mbps easily and upwards to 700mbps+ on 40mhz over the 1gbps wire to the LAN. Channels to use for 40 mhz are 36/44 OR 40/48 to avoid overlap in the lower range, 149/157 OR 153/161. Where you have all AP's at 160mhz channels all the AP's are essentially broadcasting on the same wireless channels (36-48+ and 149-165+) which can cause confusion for client devices, severe reduction in throughput/ QoS/ dropped packets for clients on other AP's that can hear each other if a device on AP 1 is using all the channel doing a heavy download etc. (high channel utilization) You can tune your transmit power down on 5ghz as well to be 5-7 higher than what you have 2.4 set to in order to keep your cell size the same for each AP. you want to have a little bit of overlap for each channel so devices roam seamlessly.

Here are other settings I have on my other Networks:

2.4/ 5ghz shared SSID: (Multi AP Deployment) Mixed devices - No real rules for what is trusted vs non trusted. Basically the buy the new wifi router and put it in and make an ssid network settings. (Add Mac for devices you want to allow broadcast). Sometimes I use mixed WPA2/3

5ghz Trusted/ Main LAN: (Laptops, Phones, Tablets) - Note in a Multi-AP deployment I turn on fast roaming when using a 5ghz network only and monitor clients.

GUEST:

Guest Captive Portal:

Allows mDNS from the guest network (224.),
Allows Guest clients to access the printer and selected casting devices. (172.16/172.100) all casting devices will show up but client can only connect to the ones authorized.

Traffic Rule: used in addition to the wifi limit. (lets the router throttle before ever hitting the wire of the AP)

and a fun landing page for good measure :D

Firewall for Guest:

Create group with all Gateway IP EXCEPT for the guest gateway iP and the gateway IP of the router (if you add the GW of the router it breaks the captive portal. The system already has policy in place to block guest access to the core. but for extra security...

Create a group with port 443, 80 and 22 to ensure guest clients cannot get to the management interface or SSH to the core.

Let us know how things go for the performance of your network with the changes or if you have any questions :)

[scoob8000]

The mimo thing makes sense. I'm gonna get a used AC Pro to replace the AC Lite that all my cams are connected to. I really was looking at the U6, but the price and I have no wifi 6 devices

…

On Thu, Oct 5, 2023, 9:56 AM Maxfield Allison ***@***.***> wrote: implementing some of your options here on my network now. I also had most of them set but unchecked them or set to defaults for testing purposes. once I had everything working at least somewhat better than before I was afraid to touch it lol — Reply to this email directly, view it on GitHub <#891 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4EZH7WGNCZSGUZ4E7UJCDX524CRAVCNFSM6AAAAAAZ3VRFBGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TCOJYG42TM> . You are receiving this because you commented.Message ID: ***@***.*** com>

[TylerDIREC]

i'm sure we are years away from 2.4ghz wifi 6 supported cameras if they ever even become a thing cause why not just go to 5ghz :P. I've yet to see a wifi 6 2.4 only supported device on 2.4 GHz. The only thing I have seen is cell phone that have wifi 6 sometimes use the 2.4 GHz network with support. but they move back to 5ghz when in range on a mixed network.

You could augment the AC Lite with the AC Pro for a Multi-AP deployment and then balance out the load :) I know my deployment is overkill for what I have it loaded with. I would just use 1 LR for everything should there not be a need to cover 1/2 acre outside with 5ghz. So I have them working as follows: The LR for the 4x4 as it is servicing 4 cameras in close proximity, more IoT devices in its area and outside while while the Mesh is serving 2 cameras in close proximity and more daily use of phones tablets, laptops indoors in the main living area of the house and it reaches out front outdoors to where wifi is needed. Place your Pro where there are more clients and heavier usage. (Cameras, Peoples devices etc) or where it will service your cameras/ clients the best with the additional spatial streams. If possible do not wall mount it. Ceiling or place face up on a table in a room/ ignore everything ubiquiti or anyone else says about wall mount for further range or ceiling for higher density. this video gives a good explanation on the why of that :) https://www.youtube.com/watch?v=uz17IfqQNK4

p.s - I find that my V3 Pro uses less bandwidth than my V3's

[scoob8000]

hah I just snagged an AC Pro for $40 to replace my lite. Funny about wall mounting, I actually had mine sitting on 3d printed legs that make it look like a UFO. But the one that most of my Wyze devices connect to, I made a bracket to hang it on the wall and angle it in the direction I wanted. I actually picked up a couple db at the one most troublesome cam. But partially I because I didn't have a good spot in that room for it to sit.

Not to get too off topic, but is the video on the v3 pro noticeably better? I keep thinking about ordering one and trying to swap the cam on my floodlight to one. These are really just secondary cams, I have 4k poe's covering most of the property.

[TylerDIREC]

Cool! I love the visual of the little ufo holders :)

V# Pro:

V3:

[scoob8000]

So something odd. I just changed the min data rate for 2.4 to 12Mbps, and my doorbell is not happy at all. Keeps going offline. It is only a few feet from the AP. -42dbm, currently RX at 13Mbps, tx 39Mbps.

Floodlight cam seems to be fine.

I just dropped the minimum rate back down just to see if it changes anything. The v3 doorbell has been my biggest PITA since I got it.

[TylerDIREC]

That really sucks! cough cough Wyze! That means that the device must fall within the B protocol. Becasue of this 1 device ALL the clients on the 2.4 must now run at rates to match it (11mbps). Therefore bringing the 2.4 network down to 802.11b rates for all devices. i am not sure if this will affect the entire network or just the single AP that is having to service the device.

https://www.intel.com/content/www/us/en/support/articles/000005725/wireless/legacy-intel-wireless-products.html VS

Some options.

1. Lock that device to a single AP to percent it from roaming and other devices as well which will be okay using the max 11mbps data rates. All should be okay as the cameras each use max of 4 up which is really what matters.
2. Testing is required and not sure if this will actually not affect the other SSID (I feel it will). Create a new SSID for lower rate items only and only broadcast it from the AP(s) that are necesary.
3. Make no changes aside from setting min data rate to 11 and monitor device performance/latency/ packet loss/ connectivity channel utilization etc. May need to drop lower until it behaves. The network should still be okay at these rates its just unfortunate that it cannot operate at the higher data rates/ standard. - this is what I personally would do first.

[scoob8000]

I'm stumpped. I dropped the min rate back down, doorbell is connected at 39rx and 72tx and running fine. I'm going to bump the min rate back up to 12 and see what happens. Maybe it was some fluke thing after applying the settings. I do have the doorbell locked to the ap that is close to it also FWIW.

I'm guessing that min rate is just the end devices RX rate we see. I see a handful of iot devices with a good RX rate but TX of 1Mbps but those devices are working fine and have a good RSSI.

[EDIT]
I just tried setting the min back to 12, and within 20 minutes the doorbell was offline again. Power cycled it, and it stayed online for a few minutes then died. It's definitely capable of higher data rates, but the rx will eventually drop. I have the minimum set to 2 right now, and will see if it stays online

Both dropouts in the signal score is where I had set the min rate to 12.

[TylerDIREC]

May be a bug/ defect in unifi then where it is not recognizing that device as compatible with 12mbps beacons. or the device truly is using beacons less than 12 mbps. It is disconnecting when you set unifi to 12 because the setting on the controller (12) is forcing it off the network.

[scoob8000]

Well a little update after a few weeks...

I've become totally disgusted with the wyze floodlight and I have removed it. The video from it was lackluster at best.

However I'm still having issues with my doorbell. It has great signal (-45dbm) but I've been noticing it dropping. I have it in my Blueiris setup recording, and like clockwork it goes offline every 20 minutes for about 2 minutes.

I'm not sure if the doorbell is dropping off from the wireless, or there is something else at play. I still have 2 other wyze devices on the bridge that don't have any issue but they are not v3 based devices.

EDIT: It is a WYZEDB3, and I have audio disabled as well. Connection is LAN
From the logs.. Not sure if that skipping smaller frame bit is anything of issue or not...

[WyzeBridge] 🎉 Connecting to WyzeCam Doorbell - Front door on 10.40.40.120
[front-door] 📡 Getting 180kb/s HD stream (H264/20fps) via LAN mode (WiFi: 99%) FW: 4.25.1.314 🔒 (DTLS) (2/3)
[front-door] WARNING: Skipping smaller frame at start of stream (frame_size=4)
[WyzeBridge] ✅ '/front-door stream is UP! (3/3)
[WyzeBridge] 📖 New client reading from front-door

[TylerDIREC]

With the latest updated to the bridge are you still having these issues? Note that if you do need to drop your cam network down to 11 mbps beacons that devices can still transfer above that.

[RUHavingFun]

I did only two of these suggestions and it has made a huge difference. My guess is the second item made the most impact.

1. I manually set "Minimum Data Rate Control" to 12 for both.
2. I enabled "Multicast Enhancement"

I will test later, and report back, to see which of these two was the key. The multicast option converts to unicast if it can, that seems like it could have a great effect if it is able to do so on the camera traffic. The rate option limits what can connect, and for me I just wanted to make sure no old 802.11b items were still connecting on the SSID's I have setup for the cams. To me this seems like it would have the least impact as I do not think I have any old things, but I will now be checking to see if I dropped anything.

I did not do "Multicast and Broadcast Control", which is the one I had set out to do, because I did not yet want to mess with determining which things on my network would need to be excluded. I may look at doing this later when I have time.

I later also disabled the audio for good measure.

        - ENABLE_AUDIO=False

[TylerDIREC]

Best way to test is 1 option at a time :) ... I'm finally in the process of migrating to a dedicated CCTV VLAN/SSID. I would have went with PPSK yet I'm not confident it has all the kinks ironed out. Pretty sure in my testing having it enabled broke Bonjour and AirPrint and I'm not taking the time to dig into that :D. Got some new V4's on the WLAN so will post a comparison of that here soon. So far so good tho. 8 Cameras total 2X V4 1 utilizing 801.11ax and 5 V3's and a Pan V3 feeding into Blue Iris. No issues.

Something else I have set in my network is "Port Isolation" is enabled on all switch ports that feed an AP. Essentially stopping LAN->WLAN broadcast so airtime doesn't get eaten up by that traffic.

All of this is using 25-35 mbps over the network, not a lot at all

[maxfield-allison]

Updating the main post with a link to this comment.

Since I created a macvlan network and added wyze bridge and frigate to it, I've seen way more consistent behavior for the streams from the cameras. I still have wyze and frigate communicating via a docker network but Wyze Bridge is using the macvlan (instead of swarm ingress in my case) to talk with the cams over LAN which has dramatically lowered my TX retries and channel utilization.

I've settled on the following configuration for the SSID used specifically by my security camera infrastructure

I found out that band steering behaves differently depending on where you enable it. I've ensured it is only enabled on the AP's and not on the SSID Configuration. source

Minimum RSSI, channels and interference blocker are, of course, set on a per environment basis. Globally the 2.4GHz transmit power is recommended to be set between 14-16dBm

[maxfield-allison]

One other recent adjustment and discovery.

If you are running more than a few ap's, the wyze cams wifi chip is incredibly stupid and it will not roam no matter what for an extended period of time. I have updated my configuration to set each of these devices with an IP reservation along with a relevant hostname. Then in the client view of the unifi NetApp, lock each camera to the Access point it is closest to.

I also increased my ap density by running drops to a couple of the far reaching locations and putting my old ac lr and nano had to use. Now, practically no issues whatsoever.

Most important thing is to lock each cam to the closest ap.

[maxfield-allison]

another quick tip:
restart the cameras from the wyze app between large changes in settings and let them reconnect to your network totally fresh. this has cleared up a lot of the issues I've been tracking.

[bpapa9013]

I'm still working on testing the individual changes to see what fixed it, but after Wyze changed whatever they changed a couple days ago. The solution for most was determined to be to give the wyze-bridge container host networking.

I had previously followed this guide/thread for optimizing Unifi networks to work with the cams, and had setup my network/wifi settings accordingly, but I had to disable some additional network configurations in order for my cams to begin working again after giving the wyze-bridge host networking.

I changed/simplified a ton of settings all at once because I didn't think any of those changes would actually work, so now I'm working on going back and individually testing all the things I changed to see if I can isolate what particular feature or setting it was that fixed it.

Have any other Unifi users noticed that simply applying host networking to the Wyze-bridge container isn't resolving their issues with connecting to their cams?

I have tested about half of the things I changed, and likely won't get to testing the rest until tomorrow evening, but I will post back if I am able to find the specific thing that fixed it for me.

[FeatherKing]

im still having troubles and would appreciate if you kept testing.

im also on Unifi with an IoT Vlan. i dont know if i followed this guide, but ive had this setup for over a year or more. Ive had a discussion going here

i tested moving a raspberry pi to vlan 100 and im running wyze-bridge on the pi itself, no docker at all, and it still fails to connect to the cameras on its same vlan. I would need to get on a ladder to change these cameras wifi to my main ssid/vlan (scanning qr code 👎) so i havent done that yet.

i had wondered about random unifi settings but i cant imagine it should matter too much with the devices on the same vlan. idk at this point.

[scoob8000]

I'm not sure what has changed for me but (knock on wood) my cameras are working fine. No changes in docker, and have returned most of my unifi settings back to defaults. The two most problematic devices were the floodlight and door bell and I got rid of those. I only have a v3 pro, v4, and one original cam now. But even those would act up from time to time but have been solid lately. My docker runs on my nas and they call the network modes something different. I believe macvlan is the correct term for what I'm running. My wyze bridge gets a ip from my firewall like any other device physically on that network. All cams are in a separate iot vlan as well.

…

On Sat, Feb 22, 2025, 9:42 PM bpapa9013 ***@***.***> wrote: I'm still working on testing the individual changes to see what fixed it, but after Wyze changed whatever they changed a couple days ago. The solution for most was determined to be to give the wyze-bridge container host networking. I had previously followed this guide/thread for optimizing Unifi networks to work with the cams, and had setup my network/wifi settings accordingly, but I had to disable some additional network configurations in order for my cams to begin working again after giving the wyze-bridge host networking. I changed/simplified a ton of settings all at once because I didn't think any of those changes would actually work, so now I'm working on going back and individually testing all the things I changed to see if I can isolate what particular feature or setting it was that fixed it. Have any other Unifi users noticed that simply applying host networking to the Wyze-bridge container isn't resolving their issues with connecting to their cams? I have tested about half of the things I changed, and likely won't get to testing the rest until tomorrow evening, but I will post back if I am able to find the specific thing that fixed it for me. — Reply to this email directly, view it on GitHub <#891 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4EZH7UPTZPSMQKUU7WHTD2REYSXAVCNFSM6AAAAAAZ3VRFBGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRYHEZTOMI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[bpapa9013]

Were you previously using the Multicast and Broadcast control setting? Did you already have your wyze-bridge host added to the exceptions list for that setting? Or did you recently disable that setting entirely when you returned your "unify settings back to default"?

[maxfield-allison]

FYI there is a separate issue ongoing
this is an issue in docker in some other applications since an update but it also still affects people after downgrading due to iptables changes. this is a pull request fixing it
moby/moby#49511
moby/moby#49518

then theres the deeper discussion here
#1430

and someone's solution here
#1432 (comment)
this thread is also continuing since its only providing some specific workarounds for specific environments.

Im sure there are fixes on the way but some of these options may help you guys

[FeatherKing]

this isnt a docker networking issue. for one, i am not on 28.0

Server: Docker Engine - Community
Engine:
Version: 27.4.1
API version: 1.47 (minimum version 1.24)
Go version: go1.22.10
Git commit: c710b88
Built: Tue Dec 17 15:45:36 2024
OS/Arch: linux/amd64
Experimental: false

for two, i have run the python app for wyze-bridge directly on a vm and raspberry pi and they have the same -13 error without docker even installed

[maxfield-allison]

after i posted this and did more reading its looking like it was a change on the qyze side of the house that basically forces all of your cams and the wyze bridge to reside on the same network for the connection to succeed

[bpapa9013]

Regarding the recent issues:
@FeatherKing

I found that in addition to making sure the wyze-bridge and all cams are on the same subnet, and giving the wyze-bridge container host mode networking; you also must add the docker host to the "Multicast and Broadcast Control->Exceptions" if you are using the MaBC feature.

I am running HA/wyze-bridge/frigate all in separate containers (no HAOS, or addons or anything in that direction). I presume adding the HAOS host to the MaBC exceptions list would also be necessary, but just a guess I have no way of testing that.

I don't recall reading in this thread that that was ever explicitly necessary before, but I certainly could have missed it. But I am quite sure I never had that setup before now.

[FeatherKing]

so for my raspberry pi (no docker network involved). ive confirmed that allowing it on the MaBC list connects to the cameras, and taking it off the MaBC list breaks it. Ive got packet captures of both of those scenarios. im going to work backwards now and move a docker container to the VLAN via ipvlan or macvlan, adding the container to MaBC, and see if i can get it working in docker.

still a hack, but maybe it can get someone else going.

[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

[bpapa9013]

I am still getting a bunch of weird log data that seems to indicate that the cams are rather rapidly connecting/disconnecting:

`[WyzeBridge] 📖 New client reading from cam-name

[WyzeBridge] 📕 Client stopped reading from cam-name`

But Frigate seems to be happy with the streams and doesn't appear to be stuttering at all so far as I can tell from the recordings/alerts/etc.

[ItherNiT]

Thanks for the yaml, you can include the wyze-bridge network if you still want the original host IP

networks:
  vlan_6:
    driver: ipvlan
    driver_opts:
      parent: eth0.6
    ipam:
      config:
        - subnet: 192.168.6.0/24
          gateway: 192.168.6.1
  wyze-bridge_default:
    name: wyze-bridge_default
    external: true          
 
services:
    wyze-bridge:
        container_name: wyze-bridge
        restart: unless-stopped
        image: mrlt8/wyze-bridge:2.10.3
        networks:
          - wyze-bridge_default
          - vlan_6

[maxfield-allison]

Hey what ports were you seeing used for multicast and broadcast? I have an opnsense firewall and already use the udp broadcast control package to pass some multicast traffic between subnets for things like chromecast. Im betting if we can narrow down the port and multicast address in use or alternatively the broadcast traffic, then we may be able to set up a solution that works for anyone with an advanced network instead of relying on host like those with a single subnet.

[bpapa9013]

As an aside here, more generally about Unifi networks and Wyze cameras, I don't think Wyze cameras work with multiple preshared keys per SSID (but I swear they used to). I recently tried to re-setup my original camera VLAN/network (which I removed when all these recent issues started) as a preshared key on my main SSID and the camera I was trying to connect (like reset/setup connect to new network via the Wyze app setup process) to that VLAN via the same SSID just now and it absolutely positively refused to connect with the spoken audio error "Unable to find that specific network name" or something to that effect (tried it like 4 times). I'm fairly certain that this used to work, I've been using the multiple preshared keys on the same SSID pointing to either my native subnet or another VLAN for well over a year, and I swear these cams used to be able to connect to it no problem. Dunno if it will cause a problem if it is setup after the cams are connected, but it's def now an issue with connecting new cameras.

[bpapa9013]

I tried reconnecting this cam to my native subnet on the shared SSID (where the bridge host is) a few more times after posting above (but before I deleted the alt vlan and disabled the multi preshared keys on the same SSID) and experienced some REALLY WEIRD behavior with the cam.

I deleted the cam from the wyze app, then attempted to connect it to the default subnet on the shared SSID, the cam gave me the audio error that it couldn't find that network name, but it actually did connect and was picked up by the wyze bridge and started streaming. But since it never completed the setup process in the app it just used the default model name for the cam, but it never showed up in the Wyze app. I even logged out and back into the app in case the app needed a full refresh to see it.

I have no idea how or why that would happen, but just thought it was super weird behavior that I would report here. I have no idea if this might shed any light on the recent issues, as this seems to be some kind of bizarre Wyze specific issue that likely doesn't have anything to do with the wyze-bridge or docker networking, like I said just really weird.

[maxfield-allison]

I appreciate this report. It really seems like wyze is starting to pull back from the community and start trying to force people into subscribing. even if one of their representatives comes and says the opposite here, if he's a dev, then probably not fully aware of the business decisions going on at the top. TUTK and wyze could potentially be in bed on this with all the devs having plausible deniability and other focus points to work on.

/end conspiracy.

[airbornetrooper82573]

I got my. 2 v4 to work again in Wyze Bridge and frigate with this post. Seems like Wyze is trying to push back on folks not wanting to subscribe. Now that I've. dove into Frigate and HA, I'll probably be replacing my wyze cams here soon. Just too much of a hassle to fix. every time a new firmware releases.