Sonos in Docker

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.

What else could I try?

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.

Forgot to mention the most important part, sorry. Yes, it’s on --net=host, that’s why I don’t understand.

Double check that your LAN is selected instead of the Docker network under Settings → Network Settings.

Check firewalls would be the next thing to check. Particularly host based firewalls where OH is running.

Beyond that I’ve no other ideas.

Never looked at the Network Settings, but looks correct: (IP of server’s normal address, docker networks are 172.X.X.X), broadcast is set to

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.

I’m reasonably certain that it’s just the number of containers and not the number of different networks, but I could be wrong.

It might be worth checking out the docker boards to see if there’s any better recent info on the issue.

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.

Yeah, I just moved over to Gitea myself a little while ago. I’m quite happy with it.

Tagging you as I see you had the same problem in this thread (now closed). Did you ever find a solution ?

I activated TRACE loglevel for jupnp and started a Scan for Sonos Things:

/opt/openhab/userdata/logs$ cat openhab.jupnp.TRACE.log | grep jupnp | head -n 20
2023-10-25 22:00:49.389 [TRACE] [org.jupnp.registry.Registry         ] - Maintaining registry...
2023-10-25 22:00:49.389 [TRACE] [org.jupnp.registry.Registry         ] - Executing pending operations: 0
2023-10-25 22:00:50.188 [TRACE] [.jupnp.controlpoint.ControlPointImpl] - Sending asynchronous search for: ssdp:all
2023-10-25 22:00:50.190 [TRACE] [g.jupnp.protocol.async.SendingSearch] - Executing search for target: ssdp:all with MX seconds: 3
2023-10-25 22:00:50.191 [TRACE] [org.jupnp.transport.Router          ] - Trying to obtain lock with timeout milliseconds '6000': ReadLock
2023-10-25 22:00:50.191 [TRACE] [org.jupnp.transport.Router          ] - Acquired router lock: ReadLock
2023-10-25 22:00:50.191 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.193 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.193 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.194 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.195 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.196 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.196 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.197 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.197 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.198 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /
2023-10-25 22:00:50.201 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /

It also sends messages on (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
(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.

Maybe this helps you.


Oh, never saw that before! Will try this weekend and report back. Thanks a lot!

:partying_face: :partying_face:
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.

I can finally use my Sonos speakers as intended.

Thanks a lot!

1 Like

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.

Thank you very much!

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
1 Like