Sonos in Docker

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.

@Scriptwriter
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: /172.33.0.1:0
2023-10-25 22:00:50.193 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /239.255.255.250:1900
2023-10-25 22:00:50.193 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.33.0.1:0
2023-10-25 22:00:50.194 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.32.0.1:0
2023-10-25 22:00:50.195 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /239.255.255.250:1900
2023-10-25 22:00:50.196 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.32.0.1:0
2023-10-25 22:00:50.196 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.35.0.1:0
2023-10-25 22:00:50.197 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /239.255.255.250:1900
2023-10-25 22:00:50.197 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.35.0.1:0
2023-10-25 22:00:50.198 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.34.0.1:0
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /239.255.255.250:1900
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /172.34.0.1:0
2023-10-25 22:00:50.199 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending message from address: /192.168.1.11:0
2023-10-25 22:00:50.201 [DEBUG] [.jupnp.transport.impl.DatagramIOImpl] - Sending UDP datagram packet to: /239.255.255.250:1900

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.

Maybe this helps you.

4 Likes

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

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

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

-Dorg.jupnp.network.useInterfaces=ovs_eth0
1 Like

Hey all,

when I set some of my containers (influxdb, loki, grafana, prometheus) to host its working without any additional upnp settings but i want to try this setting

EXTRA_JAVA_OPTS: "-Dorg.jupnp.network.useInterfaces=eth0 -Dorg.jupnp.network.useAddresses=192.168.x.x"

but how do i set it with openhab running with docker?

Try setting it as the EXTRA_JAVA_OPTS container environment variable like in these examples:

Merry christmas,

thanks for the link, really much in there i missed to read. I expected that the parameter has to be set in a service file.

Just works perfect with the 2 parameters

EXTRA_JAVA_OPTS: "-Dorg.jupnp.network.useInterfaces=eth0 -Dorg.jupnp.network.useAddresses=192.168.xxx.xx -Duser.timezone=Europe/Berlin"

Finally i got my sonos online after long time :slight_smile:

1 Like

Fine.
Could you please contribute by an enhancement of the following page in documentation ?

The corresponding page in Github to propose your change :

@Franco

Let me know if you plan to update the readme. Else I could do it as well - as I consider it very valuable information. But it does not make sense if I do something that will conflict with your work.

1 Like

If you can that would be great as im quite busy with my kids these days.

fyi: I’ve updated

removed bug tag and added documentation and enhancement tags - as it is not a bug in the sonos binding or OH code in general.

I think that once the doc is updated that issue can be closed.

3 Likes

I am going to test this evening. I think it will work when jupnp network interface is specified

2 Likes

A preview of the updated documentation is available at Installation - Docker.

At all:
Please feel free to comment on the PR and provide suggestions if changes are required. If you have feedback, please be as precise as possible - so that I know what you would like to change, or even directly use the text.

It would also be appreciated if a user running docker on a windows system could help me out to create the respective tab in the docu on how to find the correct interface name.

1 Like

Thanks a lot! Found a typo, added a comment on the PR.
A few additional points:

  • I actually added a second parameter in my config: -Dorg.jupnp.network.useAddresses=192.168.X.X. I’m not sure if this is necessary, maybe someone can confirm.
  • The [^multicastrouting] is rendered as is, not sure what the intention is here?
  • Since the problem was primarily discussed with the SONOS binding (I think…), maybe it’s worth adding a link to this docker page in the corresponding binding documentation?