Huge bandwidth hog

[rpelletierrefocus]

As soon I I start up this container I start having issues access the internet and other IP cameras (non-wyze) start to intermittently go up and down. I stop the container and everything goes back to normal. I do not see other people complaining of this issue, but thing is completely consuming the bandwidth on my LAN and out through the WAN on my network. This is despite the fact I have the cameras set to SD30.

Any ideas?

[maxfield-allison]

Strange, this is running on docker-ce on a Linux host. Glad to have made some progress with you on this in any case. hopefully this turns into a much more stable and resource efficient bridge!

[maxfield-allison]

Well I swapped out the kitchen AP-AC-LR for a slightly better AC-Pro and saw the same utilization on the dev build. I'm gonna dig around some more and see what, if anything I can find out.

[maxfield-allison]

For what it's worth, I rebuilt my firewall configuration from scratch a few days ago and reconfigured my IGMP and multicast settings on top of adding another wireless AP and Now the bridge seems to be doing its thing without much issue. The Kitchen AP is still the AP-AC-LR and channel utilization, while high, is only maxing about 70%. I think what we may be seeing here (assuming you didn't make any stealthy updates that i totally missed) is more related to router/firewall/network misconfiguration. Normally doesn't cause issues but with tons of streams going it begins showing up or something, idk.

[mrlt8]

Sorry, been busy with another side project, so I haven't been able to work on this one for the past few weeks.

I'll try to debug the threaded version to see what's causing it to crash.

[maxfield-allison]

no worries and no rush!

[maxfield-allison]

I ended up having to stop the container again because the channel started getting flooded. I removed one of the v3 cam's that normally connects to the kitchen AP and restarted the container. Everything is running smoothly now. im wondering if there are just some weird API issues with the V3 cams. The kitchen AP now serves a pan cam v2, a v2 cam and a v3. still some heavy utilization but nowhere near clogging up the works

[mrlt8]

Are the the two v3s on the same firmware?

[maxfield-allison]

Since I posted that I've seen some different behavior. The v3's are all on the latest stock firmware but i just checked and it looks like all but 2 cams are now attached to my living room AP which was recently upgraded to a U6 Pro. so I have 6 cams (v2's, v3's and pan v2's) connected to that single access point at about 60% utilization. The kitchen AP now has a single v2 cam and the deck v3 cam (deck cam is excluded in compose with env var) connected.

[justinj57]

Also having the same issue with an ER-X paired with an Unifi AP-HD. Watching multiple streams through the app produces no issues, but as soon as the container is fired up the 2.4GHz utilization goes to 98%. I have tried every combination of multicast/IGMP snooping, host/bridge, dev/latest, etc with no luck. If I can collect any data to help resolve, I'm happy to help.

[justinj57]

I have isolated this problem, in my case, to only being an issue when more than one camera is whitelisted. Whenever I add more than 1 camera, the network utilization goes nuts again.

[parthmodi]

When you say whitelisted, do you mean on your network? Or in the docker config?

[justinj57]

Docker config

On Mon, Jun 27, 2022, 2:38 PM parthmodi @.***> wrote:

When you say whitelisted, do you mean on your network? Or in the docker config?

— Reply to this email directly, view it on GitHub https://github.com/mrlt8/docker-wyze-bridge/issues/241#issuecomment-1167735659, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQZDGIEOLHR52UZBKFADPJTVRHYJDANCNFSM5IRKAUYA . You are receiving this because you commented.Message ID: @.***>

[justinj57]

Interesting data point - I installed external antennas on my 2 cams, and now the utilization has dropped from 98% to 60-70%. Every once in a while, it will jump into the 90s which seems to correspond to a WARNING: frame not available yet and waiting on keyframe error.

[maxfield-allison]

@mrlt8 any hope of reviving the threaded build? still having the same issues. saw another couple bug reports of the same problem

[mrlt8]

I did have a look at the threaded build while working on the on-demand stuff, but was still getting blocking issue where a single camera failing to connect would block the all the connections.

Not sure if it's an issue in the tutk library version that we're using or I'm missing some config.

[maxfield-allison]

ok, I'm finally digging into the tutk documentation. I'll let you know if I get any harebrained ideas and pull request if they work for me.

[maxfield-allison]

@mrlt8 fyi This could be of use: https://github.com/gtxaspec/wz_mini_hacks

[mrlt8]

wz_mini_hacks is great, and I do pop in there from time to time.

We're currently using v4.2.1.1 of the TUTK SDK which is about a year old and the newest version I have access to. Would be interesting to see if another version may work better.

[maxfield-allison]

I ended up swapping my setup recently and came across some behavior that might help narrow down the issue here. My original setup was wyze bridge into motion eye. I've since swapped to wz mini hacks and frigate, replacing all v2 cameras with either v3's or v2 pan cams. While troubleshooting ffmpeg and hardware acceleration settings on frigate, I discovered that as soon as I start encoding the rtsp streams from the cameras, my unifi console shows the same incredibly high channel utilization with about 7mbps upload on each access point with wyze cams connected. when i remove the encoding options, utilization drops again.

below, you can see the args used with no issue and the added args that cause the problem after the comment #

ffmpeg: global_args: -hide_banner -loglevel warning hwaccel_args: -c:v h264_cuvid -hwaccel cuda input_args:

• -avoid_negative_ts
• make_zero
• -fflags
• nobuffer
• -flags
• low_delay
• -strict
• experimental
• -fflags
• +genpts+discardcorrupt
• -use_wallclock_as_timestamps
• "1"

Output Args record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy #:v h264_nvenc -c:a aac -ar 16000 rtmp: -f flv -c copy #:v h264_nvenc -c:a aac -ar 16000 detect: -f rawvideo -pix_fmt yuv420p

This makes 0 sense to me. it only occurs on the older gen of my access points too. the ap-ac-lr shows massive channel utilization but the new ap-6-pro with the same number of cams connected is at half the value.

I have no idea how ffmpeg encoding on the server could cause high channel utilization since presumably the exact same data is being sent and requested.

[mrlt8]

Interesting datapoint - do you get the same result with x264? Have you tried playing around with -threads?

[maxfield-allison]

Haven't messed with -threads but it happened with lib264 and cpu encoding as well. I'll look into more tests tomorrow and post if I find anything new

On Thu, Sep 29, 2022, 7:52 PM mrlt8 @.***> wrote:

Interesting datapoint - do you get the same result with x264? Have you tried playing around with -threads?

— Reply to this email directly, view it on GitHub https://github.com/mrlt8/docker-wyze-bridge/issues/241#issuecomment-1262981049, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDOF4ZKDR5SL2YK2BH2Y4LWAY2TRANCNFSM5IRKAUYA . You are receiving this because you were mentioned.Message ID: @.***>

[adamaze]

it took me a few days to realize that installing this to use with my 3 cameras is what totally decimated my 2.4 Ghz network. it was frustrating having a smart home where almost all of my sensors/switches/lights were broken for a few days, but more frustrating that it took me so long to realize it was docker-wyze-bridge.

I have 3 v2 cams at firmware 4.28.4.41 let me know if there is anything i can do to help test out a fix, or troubleshoot

[mrlt8]

@adamaze I'd check the router setting - specifically IGMP/multicast and beam forming and other non-standard wifi options like airtime fairness.

[adamaze]

I'm on two mostly stock unifi UAP AC Pros ( I don't think I have messed with WiFi settings much at all. Think that will still make a difference?

[mrlt8]

I believe unifi's seem to have lots of issues with wyze products for some reason, but probably still worth a look. I don't have a unifi, so can't confirm, but some potential setting to look into: IGMP Snooping, IGMPv3, block LAN to WLAN multicast, Spanning-Tree Protocol, auto-optimize network.

[McAllstar]

Hi, So I installed and setup the docker-wyze-bridge ion HA and as soon as I enable the plugin/integration it literally kills me internet connection. random devices start disconnecting. Netflix, Disney+ etc etc will start to buffer. I'm NOT running unifi AP's. I'm running a TP-Link Deco M4 WIFI mesh system with one device as my internet gateway.

[mrlt8]

@McAllstar How many cameras? You could try to enable on-demand streaming which will only pull the stream on demand, though that probably won't fix the underlying issue.

Try going through your router settings - seems like fast roaming and beam forming could be an issue with tp-link and wyze (might want to google tp-link + wyze or tp-link + sonos for additional options to play around with).

Please keep us updated if you find anything useful!

[compeek]

I wish I had something more useful, but just to add another data point, I'm having the same issues with my Unifi APs. I have 9 V3s now, but I had the same issues with the V2s. I also had the same issues when I was using the RTSP firmware before I found this bridge. I even tried wz_mini_hacks on a couple of the V2s so I could use RTSP with the stock firmware, but that didn't really help either.

For me, it's pretty much the same as what has been described. With multiple cameras streaming, my channel utilization skyrockets quickly. I currently have an AC Lite and an AC LR. The AC Lite only seems to be able to handle 2 cameras reliably, and I get away with 3 on the AC LR. Any more than that and they start going nuts with the channel utilization maxing out and the cameras dropping the streams over and over.

What's interesting though is the cameras work significantly better when connected to my old Netgear WNDR4500v2 router set up as an AP. I previously had 6 V2s, and I eventually resigned to just having them all connected exclusively to that, and it hummed along without much trouble. When I upgraded to the V3s, I moved all my cameras to the exterior of the house (previously they were looking out the windows) and added a few more, so all of the signal strengths got worse, and obviously I now had 9 instead of 6. I was no longer able to connect all of them to the Netgear router at the same time reliably, but I think that was more because I couldn't find a spot in the house to put the router where all 9 cameras had a good enough signal. Regardless for whatever reason the Wyze cameras are much happier with that router than with my Unifi APs. It was the same way when I was using the official RTSP firmware, too

With 2 cameras on the AC Lite, 3 on the AC LR, and the other 4 on my old Netgear router, currently things are pretty stable, but I still get glitches here and there where one of the cameras will drop out for a bit. Utilization (Rx) is around 27% on the AC Lite with 2 cameras and 55% on the AC LR with 3 cameras. But like I said, if I add one more camera to each, the utilization starts spiking and things go haywire.

I started to suspect the problem was just not having strong enough signals from the cameras to the AP, but I optimized the location of all of my cameras best I can, and while really bad signals of course do make a difference, even when the signals are all acceptable, it doesn't fix the problem. All of my cameras are currently showing a signal at around -60 dBm or better in Unifi (the signal received by the camera at the access point, which I assume is what matters here), which seems to be enough to keep the transfer rates high. Sometimes the transfer rate from the camera to the AP will drop way low (as reported by Unifi as Rx Rate for the client), and it seems like that's usually when the cameras start dropping out again. I'm not sure what is the cause and what is the effect though between signal strength, data rate, channel utilization, etc.

I've spent hours and hours over the last few years trying every configuration possible in Unifi, really to no avail.

[McAllstar]

Hi

Thanks for getting back to me.

I have 6 cams in total (4 x V3, 1 x V2 and 1 x cam pan 2) I’ll mess around with the router settings bit more and see how far I get and will let you know if I find something useful.

From: mrlt8 @.> Date: Monday, 31 October 2022 at 16:03 To: mrlt8/docker-wyze-bridge @.> Cc: McAlister, B. (Brett) @.>, Mention @.> Subject: Re: [mrlt8/docker-wyze-bridge] Huge bandwidth hog (Issue #241) CAUTION - EXTERNAL SENDER - Please be careful when opening links and attachments. Nedbank - IT Information Security Department (ISD)

@McAllstarhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMcAllstar&data=05%7C01%7CBrettM%40Nedbank.co.za%7C398f2f192b5241f94d9708dabb489de0%7C0b1d23d810d140938cb7fd0bb32f81e1%7C0%7C0%7C638028217869720523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2b3K9Qph9LLKbdefIOQe2V%2BDbCRi78%2FQ2aGxuBSeLVs%3D&reserved=0 How many cameras? You could try to enable on-demand streaming which will only pull the stream on demand, though that probably won't fix the underlying issue.

Try going through your router settings - seems like fast roaming and beam forming could be an issue with tp-link and wyze (might want to google tp-link + wyze or tp-link + sonos for additional options to play around with).

Please keep us updated if you find anything useful!

— Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrlt8%2Fdocker-wyze-bridge%2Fissues%2F241%23issuecomment-1297139613&data=05%7C01%7CBrettM%40Nedbank.co.za%7C398f2f192b5241f94d9708dabb489de0%7C0b1d23d810d140938cb7fd0bb32f81e1%7C0%7C0%7C638028217869720523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6nKKAlg9UfZSG1NJiagimxodqkVSLiagdu9QrSNsg4A%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJHBIBFFQTAWRJ3LOCDYJ5DWF7GPJANCNFSM5IRKAUYA&data=05%7C01%7CBrettM%40Nedbank.co.za%7C398f2f192b5241f94d9708dabb489de0%7C0b1d23d810d140938cb7fd0bb32f81e1%7C0%7C0%7C638028217869720523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kcG7%2Bab%2FhfIp3%2BYPTijWsVjOlXVwO4TchQ5N4IcogWM%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

---

Nedbank Limited group of companies (Nedbank) disclaimer and confidentiality notice:

This email, including any attachments (email), contains information that is confidential and is meant only for intended recipients. You may not share or copy the email or any part of it, unless the sender has specifically allowed you to do so. If you are not an intended recipient, please delete the email permanently and let Nedbank know that you have deleted it by replying to the sender or calling the Nedbank Contact Centre on 0860 555 111.

This email is not confirmation of a transaction or a Nedbank statement and is not offering or inviting anyone to take up any financial products or services, unless the content specifically indicates that it does so. Nedbank will not be liable for any errors or omissions in this email. The views and opinions are those of the author and not necessarily those of Nedbank.

The names of the Nedbank Board of Directors and Company Secretary are available here: www.nedbank.co.za/terms/DirectorsNedbank.htm. Nedbank Ltd Reg No 1951/000009/06.

---

[Matchlighter]

Another voice to this... I've been thinking I was crazy. I'm on Unifi too and have 2 Wyze Doorbells (I want to link up more, but any more and this problem gets unbearable) and see this problem. It's generally good when I force them to separate APs, but even then there's an occasional problem. Killing the bridge and waiting a couple of hours before restarting seems to help for a day or so, but it inevitably starts eating the channel again.

I've tried setting minimum RX/TX rates, DTIM, fast roaming, and several other settings in Unifi. I thought each helped at first, but everything I've tried so far has eventually not helped.

Has anybody not on Unifi seen this issue? - glancing through the thread, Unifi seems to be a common factor.

[maxfield-allison]

Has anybody not on Unifi seen this issue? - glancing through the thread, Unifi seems to be a common factor.

I saw a few people pop up with tp link deco and a few other situations. so its not necessarily limited to unifi.

[parthmodi]

Have tp link deco with Wi-Fi 6e and can confirm that I have the same issue. I’ve played with beamforming and fast roaming as well. But no success.

[mrlt8]

Has anyone tried some of these settings for unifi?

[compeek]

Has anyone tried some of these settings for unifi?

Some of those settings are no longer available (unless you switch to the old UI but it's unclear if they actually do anything at this point). Nonetheless yes, I'm pretty sure I've tried just about everything imaginable at this point. I even found a way to disable ATF manually in a config file somewhat recently.

I've never found a combination of settings that seemed to make any real difference. I can watch the channel utilization go up with every camera I add, and at best I get 2-3 per AP before they all just stop working right.

I keep holding out hope that somebody will uncover the magic formula, though.

[mrlt8]

Could someone try running the bridge on a remote network or VPS and see if p2p or relay mode also flood the network?

Another potential solution could be to run the bridge on something like a Pi in AP mode so that the cameras could be on their own separate network with the bridge like the way wyze does with their outdoor cams and hub.

[Matchlighter]

Don't have a VPS or fully remote network, but I've setup a firewall rule on the Wyze Bridge that prevents any direct communication with the cameras. I've verified that with this the cameras now use relay mode. I'll enable it with all my cameras and see how the network does.

EDIT: That was fast with all 5 cameras! Still murders my network.

I like the idea of using a Pi - makes everything nice and self-contained as long as it can be located well enough to communicate with all devices properly. I've got a travel router w/ OpenWRT and an old Netgear w/ DDWRT that I think I'm going to try using as dedicated APs and see how that works out this week as well, though I may not be able to see the problem as well.

[mrlt8]

Thanks for testing that!

It's most likely an issue with the wifi on the camera - will be interesting to see how wyze attempts to handle the problem with their own mesh routers.

[Matchlighter]

Set up my old Netgear as a dedicated AP with a dedicated channel for Wyze cameras. So far so good, but I haven't tried it with either of the two channels the rest of my networks use, so I can't make any statements about interference/congestion.

[maxfield-allison]

891