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

[maxfield-allison]

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.