The UPnP device is not yet registered

I’ve got some problem with my Sonos speakers. They all have the status “OFFLINE (COMMUNICATION_ERROR): The UPnP device RINCON_xxxxxxxxxxxxxxxx is not yet registered”. Tried restarting the binding. Also activated debug logging for the binding, but that gives me nothing at all.

If I check the properties on the Thing everything (macAddress, serialNumber, ipAddress) looks correct.

I’m on 2.2 stable and the binding is version 0.10.0.b1, installed from repository on Debian. Unfortunately I don’t really know when the binding last worked, I think it’s months since I last used it.

Ok, I realized I’d activated debug logging wrongly. I thought it should be org.openhab.binding.sonos whereas it should really be org.eclipse.smarthome.binding.sonos. So now I’ve got debug on. Now the following lines keep repeating over and over:

20:28:40.416 [DEBUG] [os.internal.handler.ZonePlayerHandler] - Polling job
20:28:40.474 [DEBUG] [os.internal.handler.ZonePlayerHandler] - UPnP device RINCON_B8E937BECD0001400 not yet registered
20:28:40.558 [DEBUG] [os.internal.handler.ZonePlayerHandler] - Polling job
20:28:40.621 [DEBUG] [os.internal.handler.ZonePlayerHandler] - UPnP device RINCON_5CAAFD458C9201400 not yet registered

Anyone can tell what’s happening?

Also I forgot to say, the Sonos system works at it should otherwise.

It looks like the UPnP bundle is not seeing your Sonos devices in the network of your OH server.
Please also check that the UPnP bundle.is started.
bundle:list | grep UPnP

Any of those?

openhab> bundle:list | grep UPnP
181 │ Active   │  80 │ 2.3.0                  │ JUPnP Library
204 │ Active   │  80 │ 0.10.0.b1              │ Eclipse SmartHome Configuration UPnP Discovery
205 │ Active   │  80 │ 0.10.0.b1              │ Eclipse SmartHome UPnP Transport Bundle

Ok, some more findings. I enabled debug logging on org.eclipse.smarthome.config.discovery.upnp and org.jupnp and now I get more useful info in my logs. I get things like this:

09:26:24.138 [DEBUG] [jupnp.transport.spi.MulticastReceiver] - UDP datagram received from: 192.168.168.40:57917 on local interface: eth0 and address: 192.168.168.3
09:26:24.313 [DEBUG] [org.jupnp.transport.Router           ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
09:26:24.410 [DEBUG] [jupnp.transport.spi.MulticastReceiver] - UDP datagram received from: 192.168.168.40:57917 on local interface: eth0 and address: 192.168.168.3
09:26:24.414 [DEBUG] [np.protocol.RetrieveRemoteDescriptors] - Sending device descriptor retrieval message: (StreamRequestMessage) GET http://192.168.168.40:1400/xml/device_description.xml
09:26:24.529 [DEBUG] [org.jupnp.transport.Router           ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
09:26:24.656 [DEBUG] [org.jupnp.transport.Router           ] - Sending via TCP unicast stream: (StreamRequestMessage) GET http://192.168.168.40:1400/xml/device_description.xml
09:26:24.763 [DEBUG] [jupnp.transport.spi.MulticastReceiver] - UDP datagram received from: 192.168.168.40:57917 on local interface: eth0 and address: 192.168.168.3
09:26:25.085 [DEBUG] [org.jupnp.transport.Router           ] - Received asynchronous message: (IncomingDatagramMessage) NOTIFY
09:26:34.905 [INFO ] [org.jupnp.transport.spi.StreamClient ] - Timeout of 10 seconds while waiting for HTTP request to complete, aborting: (StreamRequestMessage) GET http://192.168.168.40:1400/xml/device_description.xml
09:26:35.121 [WARN ] [np.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response: http://192.168.168.40:1400/xml/device_description.xml

From what I understand it fails fetching the device_description.xml, right? Strange thing is I tried fetching the exact same URL from the server (using wget) and that works fine and I get an ok looking xml file. So why doesn’t the binding succeed in getting the same xml?

Looks good.

Have you something standard for your local network ? Same network for OH server and Sonos devices ?

Nothing strange there. The OH server is on wired and Sonos devices on wireless, but no VLANs or anything like that.

I might notice though that I upgraded DD-WRT on my router a couple of weeks ago (from a version from 2016 to latest, r34311). I’ve tried finding out if DD-WRT does anything that should be relevant to this, but not that I can find…

I don’t know if this is relevant, but others also seem to have problems with upnp since the last Sonos update, see here and here. If that would be the problem I guess I wouldn’t be the only OH user with the problem though, would I? Anyone else having problems?

Also if I understand my logs correctly the problem isn’t about discovery but about simply fetching an xml file, really don’t understand how that could be a problem…

Ah ok so it would be a bug in the Sonos firmware.

The XML file to be read is the XML description of all UPnP services delivered by your Sonos device.
You can try to enter this URL in a browser. Normally you should have an immediate answer.

Yep, opening the url in my browser returns an xml that looks alright. Guess we’ll simply have to wait and see. If it would be something general to everyone running the latest Sonos version I’m sure we’d heard a lot more about it though…

I’m facing exactly the the same problem.

I’m not alone! :smile: Do you know if the problem started with the Sonos 8.2.2 update?

Also, I tried installing an UPnP test program on my laptop and from that I can see all my Sonos speakers just fine. Both when the laptop is on wifi and when it’s connected by cable.

Not sure. I don‘t use it that often. But it worked flawlessly before upgrading the Sonos firmware and to the latest OH stable.

Ok, this is weird. Since an upgrade to 8.3 didn’t solve this problem, I grew tired of it, so a few days ago I contacted Sonos support. Got answer the next day, saying that “this has been disabled in latest 8.3” (my translation). I interpret this as Sonos not wanting third party stuff connecting at all any more. Sent a follow up question, but haven’t got any answer yet.

However (and here comes the strange bit) tonight I hade a power outage here, too long for my ups to keep things alive. So now everything (including of course openhab server and all Sonos speakers) have been restarted and suddenly things seem to work fine! All speakers are online and openhab seems to communicate perfectly well with them. So it seems in 8.3 things work again after a restart (though I don’t know if it’s restart of openhab or speakers). Can anyone else confirm?

And why the heck would Sonos support say it’s been disabled when in fact it has been fixed???

1 Like

I upgraded to 8.3 today and can it worked again.

1 Like

…and now Sonos support tells me that only the systems listed on this page will work with Sonos and nothing else. And that the developers should visit https://developer.sonos.com/ if they want us to be supported.

So first it didn’t work and nobody knew why. Now it DOES work but Sonos themselves says that it shouldn’t… What do you think about that? @Lolodomo, any comments?

They probably propose an official SDK/API to selected partners while we are relying only on reverse engineering findings on their way to use the UPnP protocol.
I doubt they will change all their API and break lots of software but they could probably technically do it. It would be so stupid and deceiving that I can’t imagine it.

1 Like

I did have a quick look at the registration form. Someone should register ESH, it seems to be enough to point out how Sonos users benefit from us.

1 Like

Hi,

i am having the same issue after upgarding my Openhab from 2.1 to 2.3 Is there any temorary workaround/solution available?

For me it takes around 24h until all sonos devices are seen as offline. Throughout these 24h i see them sometimes toggeling to offline for a minute and than comming back up. Until the fully disapear

Saludos M0j0

Please provide logs and details about your setup.