Add host_network: true for use in home assistant #1439
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? |
|
Do we have any news... on the development of a fix or is it good to hope that a new project will be created? |
Did you learn where to add the " Host_Network: true" line. I to on HAOS. Thank You, Anthony |
|
Since mrlt8 has been busy of late, I created a fork and merged the PR changes that have been pending for a while. Not trying to steal thunder, but I needed a stable source for updates. The repo does all the Docker Hub publishing and everything, so feel free to click the ADD ADD-ON REPOSITORY button in the repo or grab the new docker image from here |
|
watching this and looking for fix for those running inside HAOS |
|
I forked it and merged all the fixes at https://github.com/IDisposable/docker-wyze-bridge |
I posted a forked version for home assistant weeks ago in this thread. |
|
Thanks @jdeath! I used your fork to start up mine... and merged the pending PRs that made sense, then setup all the changes to ensure it hits the docker repository and HAOS install works. Not trying to grab folks, just trying to ensure that builds are kept up to date and are easily installed. |
|
Thank you.
On Monday, April 21, 2025 at 05:37:57 PM EDT, Marc Brooks ***@***.***> wrote:
Thanks @jdeath!
I used your fork to start up mine... and merged the pending PRs that made sense, then setup all the changes to ensure it hits the docker repository and HAOS install works.
Not trying to grab folks, just trying to ensure that builds are kept up to date and are easily installed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
IDisposable left a comment (mrlt8/docker-wyze-bridge#1439)
Thanks @jdeath!
I used your fork to start up mine... and merged the pending PRs that made sense, then setup all the changes to ensure it hits the docker repository and HAOS install works.
Not trying to grab folks, just trying to ensure that builds are kept up to date and are easily installed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Added repo, and now I can get an updated snapshot but still no stream (IOTC_ER_TIMEOUT). Same Subnet. Running DWB as HAOS add-on in a UTM VM on MacOS Silicon. Edit: If using Unifi APs, this worked for me: cameras and server on same subnet, disable Multicast and Broadcast Control on the SSID for the cameras, use this fork. |
Thank you! I think this has saved my weekend. |
I'm happy to report that the fork fixed my issue. |
Thank you for this! Was having issues with the IOTC_ER_timeout error #628 & #1459 on my Wyze Cam v3. From previous discussions and issues that the best solution was to downgrade to 4.36.11.5859. Fortunately, using this fork in Home Assistant made the firmware downgrade unnecessary. |
Docker changes something, so this addon must run on the host network for some cameras
Fixes: #1438 #1433 #1434