Sonos Items work in eclipse, not in production. UPNP problem?

Add-ons Bindings
, ,
1

I’ve been using the Sonos binding for years. I have about 12 amps and I play whole house music from a filesystem of MP3s on my local NAS. My openhab is a 5.1.3 installation on a Debian-based server at my house. I use 3 scripts:

  1. A morning script that sets the volume of 10 different amps, joins them to a single “control” amp, and starts playback on that amp.
  2. A later-in-the-morning script that increases the volume plus-one-at-a-time on a handful of those amps (the ones closer to my bedroom)
  3. An evening script that decreases the volume minus-one-at-a-time on all amps, until they reach 0, then pauses the music, then resets the volumes to sane values for the next day.

I have been annoyed for some time, that the Coordinator value isn’t working right. It doesn’t properly reflect the “control” amp. Most of the amps either show NULL, or their own UDN as the value of the Coordinator. I was motivated recently to look at the code, because when I turn on the family room TV, I want the kitchen amp to change sources to family room TV (rather than the “control” amp playing the whole-house music). Having finished messing around with the Blink Binding, I decided to look at the Sonos Binding code.

I updated the demo distribution “app” xml to include the Sonos binding (alongside the Blink binding I’ve been developing). I struggled with the stupid dependency refresh buttons for an hour or two (translation: I don’t understand what it’s doing), and I got it working. I use a Mac laptop as my desktop / development environment. openhab calls itself a 5.2.0-SNAPSHOT version.

It found the Sonos amps, and I added the Things from the inbox, then created a number of Items.

To my surprise, it all works perfectly on the laptop instance of openhab running within eclipse.
I did a bunch of reading forums and learned that the Sonos binding has not changed in a long while, although the UPNP / JUPNP libraries have had some churn.

I tried to copy the .jar file from the Mac to the server, just like I had done successfully with the Blink binding jar file, but it won’t run, it complains about a upnp package missing:

2026-02-25 00:55:12.669 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.sonos-5.2.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.sonos [311]
  Unresolved requirement: Import-Package: org.openhab.core.config.discovery.upnp

        at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]

Stymied by not being able to run the 5.2.0 SNAPSHOT version of Sonos on my server, I tried a different approach…

Guessing perhaps I had some stale Things in my server-based openhab 5.1.3 instance, I deleted all 66 Sonos Items, all Sonos Things, and uninstalled the Sonos Add-On. I reinstalled the add-on from the marketplace, and proceeded to recreate dozens of Things and Items.

It still doesn’t work. The volume Items are all NULL, and the Coordinator values are generally set to each amp’s own UDN. The controls work but the state updates back to the Items don’t:

  1. If I use the MediaControl for the “control” amp, I can advance to the next song (good)
  2. If I use debian server openhab to modify the volume of one amp, then the Item will show the new volume (good) (and also, the volume does change in the room)
  3. If I use the Sonos app to modify the volume of one amp, then the debian server openhab Item does not change (bad), but the Mac/eclipse openhab Item does change (good)

So it’s probably not the Sonos Binding. But what is it? Server openhab Sonos Binding is not receiving incoming updates from the Sonos hardware, but Mac openhab Sonos Binding is.

Not even sure where to start.

The server is on wired ethernet, in the same IP network range as the MacBook’s wifi. They are both on a 192.168.192./18 network. Both the MacBook and the server are in 192.168.213. range and the Sonos amps are in 192.168.215.* range. Again, based on netmask these are the same network, it is a /18, NOT a /24.

During openhab startup on the server (but not on the MacBook), there is an ominous message:

2026-02-25 00:46:29.974 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 192.168.213.20/18, truncating to /24, some addresses might be lost

But I don’t know who’s responsible for that message, so I don’t know the scope of what it affects. Might be relevant, but then again, the MacBook eclipse openhab works just fine on this same network range (and without the INFO log message).

Any ideas? Thanks in advance!

2

The first thing to make sure is that the build of the add-on actually works for 5.1. Usually add-ons are built for a specific version of OH and do not work on previous versions of OH. So the problem may be a version mismatch between bundles (e.g. the upnp bundle on 5.1 is too old for what 5.2 expects).

It might be that Sonos doesn’t like more than one connection at a time. Which ever of your OH instances that connects first works, and it’s not related to the versioning. Though I think that’s unlikely here based on the error generated.

It is definitely the case that when you install an add-on by dropping the jar file in the addons folder, dependencies are not automatically installed. You may need to get on the karaf console and manually install the upnp bundle. Or install another add-on that depends on that bundle too.

I’m not sure why you don’t see that on the Mac. There is probably something in karaf that is producing this. This comes from the part of OH that does MDNS and other network discovery type stuff. If this were the problem though, OH wouldn’t be able to discover your Sonos speakers in the first place. You wouldn’t see errors in the logs like you are seeing.

3

Ok, Rich, I appreciate this!

I will explore how to modify the build environment to build for 5.1.3 instead of 5.2.0-SNAPSHOT. I don’t remember the dev guide talking about it, but honestly I might have skimmed over it. It’s hard to absorb everything on a page when it’s all new. If you say it’s something easy, like "use git checkout 5.1.3 to switch your branch and rebuild, then I can take it from there.

That said, I was thinking about the Sonos “one connection” theory. As far as I know, there isn’t a single connection limit, but honestly I have no idea. So to test this theory, I decided to:

  1. leave my existing server-based openhab running (it isn’t getting Sonos updates)
  2. leave my existing Mac eclipse-based openhab running (it IS getting Sonos updates)
  3. Install the openhab 5.1.3 distro from apt sources on a third machine, an 8GB raspberry pi, which is on the same 192.168.213.* network as these above machines. I did the initial setup (lat/long, persistence add ons, and I for other add-ons, I only chose Sonos, Astro, javascript, & Basic-UI). I wanted to minimize the complexity.

(Side note, I do not see the aforementioned /18 → /24 subnet size warning. I suspect my legacy server openhab is generating that because of the Network Services add on (I am using it to ping the IP address of a wifi WAP, so I can power cycle it when it crashes (via its zwave smart plug/brick))). Anyway, I don’t think the /18->/24 subnet size message is relevant to the Sonos investigation.

So what did I observe on the PI-based openhab?

  1. The Sonos amps appeared in the Inbox automatically
  2. I created a Thing for the family room amp, and 3 Items: Volume, Coordinator, and LocalCoordinator
  3. I observed that the Volume was Null, the LocalCoordinator (boolean) was Null, and the coordinator was set to itself (which is incorrect).
  4. Using the Sonos app on my phone, I modified the volume. The Eclipse-hosted Sonos Item updated to the new volume. The original server openhab Sonos Item did not change. The PI openhab Sonos Item did not change.
  5. In the Mac Eclipse window, I terminated the openhab JVM.
  6. Using the Sonos app on my phone, I modified the volume. The original server openhab Sonos Item did not change. The PI openhab Sonos Item did not change.
  7. I restarted the PI openhab process via sudo service openhab restart, and waited for it to complete its startup
  8. Using the Sonos app on my phone, I modified the volume. The original server openhab Sonos Item did not change. The PI openhab Sonos Item DID CHANGE.

So I believe you’re correct: only one openhab process running a Sonos Binding will see the updates. From the above, it appears that the first one in wins, but I need to ponder more carefully how the Mac Eclipse one launched and was successful, while my original server openhab instance which has been running for months, was not. And of course the Sonos phone app works regardless of the existence of one or more openhab instances. I can look more closely at the code to see how the Sonos Binding talks to the retail system–perhaps it uses a client id which is supposed to be unique to the client (the Blink Binding did this using a UUID); if it is a hardcoded value then perhaps the retail system is treating the multiple openhab Sonos Binding instances as a single client, as opposed to being multiple clients who all need status updating.

So to test this further:

  1. I shutdown the PI-based openhab, leaving only the original server-based openhab still running.
  2. Using the Sonos app on my phone, I modified the volume. The original server openhab Sonos Item did not change.
  3. I restarted the server based openhab
  4. After it finished its startup, I observed that the Sonos volume and Coordinator values are accurate!
  5. Using the Sonos app on my phone, I modified the volume. The original server openhab Sonos Item DID CHANGE.

So my conclusions:

  1. There isn’t anything wrong with my server hardware/configuration or the network
  2. Only one Sonos Binding can be fully functional on a given network at a time. It might be that only the first one started will work (based on my disciplined testing in this thread), but there is some uncertainty based on how I got to this point (see below)
  3. Because a week ago, the only Sonos Binding running in my network was an openhab v5.1 instance on my server, and the Sonos Items were not updating (and hadn’t for months). Thus, it may or may not be the case that Things or Items created with an older* Sonos Binding were working with v5.1. I deleted them all and reinstalled them this week, and now that I’ve also terminated the debugging instance, it behaves better. (* perhaps as old as openhab v3.3, as my original Sonos setup notes are from late 2022 when I had openhab 3.3)

Thanks again for the insight, Rich!

4

I don’t do development on OH, so I can’t say. But that seems the reasonable way.