I experience the same issue. Sonos binding has been working flawless for years. Running 2.5.5 on Raspberry PI 3 (Openhabian Jessie)
Recently I shutdown my pi to make a backup image. When I started to see the issues with Sonos, I discovered that v2.5.12 of the binding was installed, no idea how come. As I was worried that there might be a conflict with a older OpenHAB core, I ran an update to 2.5.12 via openhabian-config.
Sonos binding was ok right after the update, but now suddenly the devices are offline. I stopped and started the bundle via karaf and see this in the log. Not certain of this was always the case befor
2021-03-07 19:19:58.172 [ERROR] [org.openhab.binding.sonos ] - bundle org.openhab.binding.sonos:2.5.12 (252)[org.openhab.binding.sonos.internal.SonosHandlerFactory] : Cannot register component
java.lang.IllegalStateException: BundleContext is no longer valid
at org.eclipse.osgi.internal.framework.BundleContextImpl.checkValid(BundleContextImpl.java:989) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.getBundle(BundleContextImpl.java:129) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:226) ~[bundleFile:?]
at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:442) [bundleFile:?]
at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:314) [bundleFile:?]
at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:269) [bundleFile:?]
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:380) [bundleFile:?]
etc etc etc
Will do some more troubleshooting this week and try to isolate the issue.
Still not solved. I’m actually considering setting up a small virtual machine running OH3 with only the Sonos binding for the sole purpose of updating my main OH3 instance through the new remote binding.
I tested it quickly: on other machines in docker or in a new VM using OH3 as system service, Sonos is working without any issues. I still don’t see where the difference on my server is.
Very ugly solution, but I don’t see any other solution right now…
Ah yes, I did. Sorry, didn’t want to confuse. Wanted to make it a bit clearer as I’m pretty sure it is related to Docker in my case. Reading your answers again, you do seem to have to same problem but not related to Docker.
I was able to get it working again by shutting down the Unifi Docker container running on the same host although I still don’t see a clear connection. It even worked some time after restarting that, but the Things started flapping from ON to OFF and back again a few times.
I’m curious if the JUPNP bugfix mentioned here will solve my problem. Might give the 3.1 milestone a try for that. Unfortunately, I don’t think there’s going to be a backport for 2.X. I’ll report back if it works, then you’ll have a reason to upgrade to OH3
No problem @pgruetter . From what I read over the past weeks, I also had started thinking in the direction of upnp. Since my setup is stable now, I will keep it like that for now. Good to know that 3.1 might have a bugfix. I will keep an eye on the release notes and then decide when/if I make the jump. Thanks for mentioning.
Unfortunately, upgrading to 3.1.0M2 did not solve it for me.
Turned on some more logs for JUPNP and see the following messages:
2021-03-16 13:14:33.323 [INFO ] [org.jupnp.transport.spi.StreamClient] - Timeout of 10 seconds while waiting for HTTP request to complete, aborting: (StreamRequestMessage) GET http://192.168.1.203:1400/xml/device_description.xml
2021-03-16 13:14:33.324 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response: http://192.168.1.203:1400/xml/device_description.xml
So it looks like OH3 is requesting details about the Sonos speaker, but doesn’t get a response.
Calling the URL with wget on the same machine returns the XML in a few milliseconds.
That’s very strange, I’m running OH3 with net=host.
Found a few related messages, especially concerning the Unifi Controller but they didn’t solve it for me
Are there any updates?
I faced the same issues with OH 3.1.
I‘ve set the network mode to host.
Scan does not return any item.
Adding manually does not work too.
The UPNP Browser on my phone Show the devices properly.
so now I’m a bit lost to be honest overall i guess I have the same issue as @pgruetter.
It seems I can detect the devices but when then StreamClient tries to get the description it fails. (As shown below).
2021-11-17 13:34:27.331 [DEBUG] [org.jupnp.transport.Router ] - Sending via TCP unicast stream: (StreamRequestMessage) GET http://192.168.3.31:80/description.xml
2021-11-17 13:34:27.332 [TRACE] [org.jupnp.transport.spi.StreamClient] - Preparing HTTP request: (StreamRequestMessage) GET http://192.168.3.31:80/description.xml
2021-11-17 13:34:27.334 [TRACE] [org.jupnp.transport.spi.StreamClient] - Creating HTTP request. URI: 'http://192.168.3.31:80/description.xml' method: 'GET'
2021-11-17 13:34:27.336 [TRACE] [org.jupnp.transport.spi.StreamClient] - Waiting 10 seconds for HTTP request to complete: (StreamRequestMessage) GET http://192.168.3.31:80/description.xml
2021-11-17 13:34:27.372 [DEBUG] [org.jupnp.transport.Router ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
2021-11-17 13:34:27.422 [DEBUG] [org.jupnp.transport.Router ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
2021-11-17 13:34:27.472 [DEBUG] [org.jupnp.transport.Router ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
2021-11-17 13:34:27.521 [DEBUG] [org.jupnp.transport.Router ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
2021-11-17 13:34:27.571 [DEBUG] [org.jupnp.transport.Router ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
2021-11-17 13:34:37.338 [INFO ] [org.jupnp.transport.spi.StreamClient] - Timeout of 10 seconds while waiting for HTTP request to complete, aborting: (StreamRequestMessage) GET http://192.168.3.31:80/description.xml
@Kai : is there a way to Specifiy the interface that should be used to resolve this description.xml?
Unfortunately, no update from my side. I ended up installing a very small virtual machine (VirtualBox) with a second OH3 installation only for the Sonos things
I then use the remote binding to connect the two OH3 instances. Works perfectly, but obviously a huge overkill.
Since I’m trying to get rid of the VM, I’ll probably install the same thing on a raspberry pi.
Strangely enough, on my main OH3 installation, the Sonos speakers did turn up in the inbox. So at least at some point in time, they were detected by OH3.
OK, thought maybe you have used another port but that’s the default and I still can’t see how that interferes with UPNP.
Anyway, to get rid of my virtual machine, I now installed the second openhab instance on a raspberry pi. I have one running pihole and I just installed openhab on that one. I only have the Sonos things / items and connect to the main openhab installation via the remote binding. Solves it for me.