I’m starting another attempt to get my Sonos speaker working in OH4 running in Docker.
Currently, OH4 can not detect my Sonos speaker on the same network.
I use the remote binding to connect to a OH3 instance running on a Raspberry PI, which only runs for Sonos integration. Obviously I would like to get rid of this OH3 instance and integrate the Sonos speaker directly.
Using OH4 Docker on another PC (in the same network), it works correctly. So I’m sure it has to be some other service or Docker container or OH4 binding on the server that is interfering.
Tried to disable avahi-daemon or pass on /var/run/avahi-daemon/socket to the Docker container.
Only process listening on port 1900 and 5353 is the openhab process on the server.
How is the networking set on the container? Are you using --net=host? If not then OH is running on a separate network from the Sonos and the broadcast discovery packets are likely not making it to them.
Never looked at the Network Settings, but looks correct: 192.168.1.11/24 (IP of server’s normal address, docker networks are 172.X.X.X), broadcast is set to 192.168.1.255.
I’ll double check the firewall, ufw is inactive. But iptables -L has a lot of docker specific rules. Maybe I’ll find something in there.
This is a well know issue with docker and upnp. The typical solution recommended even on the docker boards is to make sure all of your containers (not just OH) run on host network instead of bridge. In practice, I find that 1 container running in bridge mode is fine, but all the others need to be running in host. As soon as you have more than one bridged container, upnp wigs out. This is occasionally a headache as some containers make it difficult to modify the internal network ports (gogs was a PITA to change the ssh port). My system has been running fine like this for a while now so I haven’t looked into what the latest on the issue is.
Do you know if this is true for “one container” or “one bridge network”? I could imagine moving all containers to one bridge network and leaving OH4 on host. I’ve got ~30 containers running and most of them created a new network. Reducing that is maybe a good idea anyway. But I don’t necessarily want to change all of them to host.
But many start a service on port 8080 or 80, so using host network makes it complicated.
Gitea makes this much easier now. I originally ran Gogs and gave up on it because it was so hard to keep up and configure. But recently was running low on RAM and dropped GitLab and decided to move to Gitea instead of back to Gogs. Apparently it’s a fork of Gogs but appears to be receiving more new development and features. And it takes up less than half the RAM and resources than GitLab does.
It also sends messages on 192.168.1.11 (my server IP), but I think it’s strange that it sends requests on all Docker interfaces too… Not sure what to make of that.
Hi @pgruetter,
i added to my opts these 2 parameters EXTRA_JAVA_OPTS: "-Dorg.jupnp.network.useInterfaces=eth0 -Dorg.jupnp.network.useAddresses=192.168.x.x"
(your main ip in there, and the correct eth-interface name which could be another on your site)
since then it was able to see my upnp devices. It was not possible with network host only.
IT WORKS !!
You can’t imagine how excited I am.
Don’t you just love IT: You can search for forever and not find a solution. And then you just need the right hint and it’s solved in 1 minute.
Interestingly, this did not seem to work for me. I don’t know what the difference is, but since my system runs just find on the host network without this, I’m not going to spend too much time trouble shooting it.
Still a good option to have since it appears to work in some cases.
This works for me as well on a Synology NAS with different Containernetworks and Openhab itself on host network so I’m finally able to decom my Raspberry Pi.
I use
