Wyze Bridge and Unifi Settings that won't hose your network #891
Replies: 19 comments 63 replies
-
"ENABLE_AUDIO=True" sends everything straight into the same behavior, so let's avoid that for the time being. |
Beta Was this translation helpful? Give feedback.
-
recently adjusted a few things, mainly the wifi network for the security devices I have. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Whats the network for? and does everyone get
|
Beta Was this translation helpful? Give feedback.
-
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.
|
Beta Was this translation helpful? Give feedback.
-
I just signed up for early access, does it take awhile to be granted access? I'm not seeing any early access releases yet. |
Beta Was this translation helpful? Give feedback.
-
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>
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 [WyzeBridge] 🎉 Connecting to WyzeCam Doorbell - Front door on 10.40.40.120 |
Beta Was this translation helpful? Give feedback.
-
I did only two of these suggestions and it has made a huge difference. My guess is the second item made the most impact.
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.
|
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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>
|
Beta Was this translation helpful? Give feedback.
-
FYI there is a separate issue ongoing then theres the deeper discussion here and someone's solution here Im sure there are fixes on the way but some of these options may help you guys |
Beta Was this translation helpful? Give feedback.
-
Regarding the recent issues: 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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/
Beta Was this translation helpful? Give feedback.
All reactions