-
-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add host_network: true for use in home assistant #1439
base: main
Are you sure you want to change the base?
Conversation
Changing the container network mode to host didn't fix anything for me. Verified container started without any start up errors or port conflicts, and is running normally with host networking. All logs and IOTC errors remain exactly the same. |
I did get them working, so I believe the network_mode: host is def necessary, but I disabled a bunch of somewhat advanced network management stuff in my Unifi setup that had never been a problem with the cams/wyze-bridge before. I kinda changed a bunch of crap all at once because I honestly wasn't expecting any of it to help. But miraculously they did start working after my last round of network adjustments. So now I am going back and trying to test what exact change fixed it. Will post back here when I determine it if this is a good place. And I will also post onto that thread about optimal Unifi network/wifi settings, because I had followed that guide previously and am 99% sure that none of my setup conflicted with that setup guide, so something there might need updated. |
no offense but this PR is a bandaid and not a fix. im running the app outside docker with no virtualization at all and i still cant connect. @bpapa9013 what is your ip range on the two vlans? i have an IoT vlan as well but i moved a raspberry pi onto it and ran wyze-bridge and it still failed to connect. I have that VLAN tagged 100, so im wondering if there's some issue with either subnet range or vlan tagging. ive posted some of my troubleshooting here |
The PR, even if was a fix, will not be implemented it doesn't appear. Without must discussion, it appears this project is dead. |
I had my cams on VLAN 20 in a 10.0.20.0/22 subnet IIRC, but part of what I changed was to move all the cams back onto my main native LAN (192.168.0.0/24), disabled multiple preshared key auth on my main SSID, added the host networking to the wyze-bridge container which is also now on my main native LAN, and disabled some of the more advanced features in the Wifi and network config for my main LAN in the Unifi settings. I suspect that it may have been a combination of getting everything very literally into the same subnet and then disabling the "Multicast and Broadcast Control" in the Unifi Wifi config. I'm running HA/wyze-bridge/frigate in docker/portainer on Debian 12 (no HAOS, all just standard containers). But I'm working today and won't be able to go back and specifically test that in my environment until this evening. I tested just about everything else I changed last night without finding anything, but got tired and gave up at a certain point. |
After ensuring all cams and the docker host are on the same subnet and giving the wyze-bridge container host networking, if you run Unifi networking gear and are using "Multicast and Broadcast Control" on the SSID the cams connect to, then you must add the docker host to the "Multicast and Broadcast Control exceptions list". I presume this would be a similar requirement for an haos set up running the modified add-on, but my environment is strictly separate containers (no haos), so I have no way to test that. |
Excuse. How can I add these command line: Host_Network: true I'm using HAOS but I can't manage docker and YML. Sorry if I'm saying something wrong. I'm such a new in this community. Thanks. Does anyone know when can we get an official update? |
Docker changes something, so this addon must run on the host network for some cameras
Fixes: #1438 #1433 #1434