[OH 2.4.0 M7] Sonos online and immediately offline again

I use my Sonos speakers with smart plugs and switch the power off overnight / when not at home, to save energy. When switching the plug on, the speaker comes online again after about 25 sec (I check this with a network ping). and I can play musing using the Sonos app right after. However, in openhab (latest snapshot release) the status is OFFLINE (COMMUNICATION_ERROR) even though I’m already playing. After about 8-10 minutes the openhab status changes to ONLINE and I can control the loudspeaker also again via openhab.

Does this have to do with the timing of the UPnP discovery and if positive is there a way to set a timer for more frequent execution?

Per the doc’s latest version

Attention: You might run into trouble if your control system (the binding) is in another subnet than your Sonos device. Sonos devices make use of multicast which in most cases needs additional router configuration outside of a single subnet.
If you observe communication errors (COMMUNICATION_ERROR/not registered), you might need to configure your router to increase the TTL of the packets send by your Sonos device. This happens because of a TTL=1 for ALIVE packets send by Sonos devices, resulting in dropped packets after one hop.

Thanks, I’m happy to have a look into this, but all speakers are on the same subnet as openhab, so the subnet should(?) not be the root cause

Also, I should mention that I had the same network config on 2.3 and did see the OFFLINE errors disappear very fast and turn again into ONLINE

I didn’t find an issue on git for this so I’m not sure what the root cause may be.

here’s what the log contains

2018-12-11 08:23:43.733 [vent.ItemStateChangedEvent] - SteckdoseSonosSchlafzimmer_Switch changed from OFF to ON
2018-12-11 08:23:54.216 [vent.ItemStateChangedEvent] - SonosSchlafzimmer_Online changed from OFF to ON
2018-12-11 08:23:57.015 [me.event.ThingUpdatedEvent] - Thing ‘network:pingdevice:sonos_schlafzimmer_ping’ has been updated.
2018-12-11 08:24:01.553 [hingStatusInfoChangedEvent] - ‘sonos:One:RINCON_7828CA0092F401400’ changed from OFFLINE (COMMUNICATION_ERROR): The Sonos player RINCON_7828CA0092F401400 is not available in local network. to OFFLINE (COMMUNICATION_ERROR)
2018-12-11 08:24:06.357 [hingStatusInfoChangedEvent] - ‘sonos:One:RINCON_7828CA0092F401400’ changed from OFFLINE (COMMUNICATION_ERROR) to ONLINE
2018-12-11 08:24:06.386 [hingStatusInfoChangedEvent] - ‘sonos:One:RINCON_7828CA0092F401400’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): The Sonos player RINCON is not available in local network. to OFFLINE (COMMUNICATION_ERROR)

As you can see, the speaker goes online and then immediately offline again. However, a ping (SonosSchlafzimmer_Online) returns success (=ON) and I can play music on it using the Sonos app. But given that in OH the speaker is marked as offline I cannot control it via OH. Note that the speaker is on the same subnet as the OH server.

Same problem here. We have a sonos connect and a sonos AMP, both used to work flawless for a long time. I’m on stable release 2.3. Now I can’t seem to get them online again. Maybe a Sonos update which broke the link with OH? Haven’t really digged in the logs though… but haven’t updated or changed much on OH side for the last couple months…

I have found this thread after I have reported the same issue here

I have exactly the same behaviour - has someone found a solution yet?

I’m running OH 2.4 and I’ve been slowing upgrading my bindings to 2.5 and here’s my findings. I have 12 Sonos; combination of Sonos Ones and Amps. I do have a Sonos Boost and the Sonos are a combination of wireless and hardwired. I have 3 stereo pairs setup with the Sonos Ones.

I spent a week trying to figure out a pattern with this issue. I’ve read across posts that you need to increase the TTL (did it at the Sonos and Router level - didn’t work). I have a DHCP server that has all the Sonos devices set to Reserved so I can push settings such as TTL to them.

Enabled jupnp and set hops from 5 to 10

Sonos TTL:
TTL set to 10 hops
Keep Alive Internal set to 500

I tried different versions of org.jupnp . I’ve ran 2.5.1 and 2.5.2 and both at the same time. Didn’t work with Sonos Binding 2.5m1 or 2.5 (Aug 2019 build)

The ONLY version I got to work successfully long term is the one that comes with OH 2.4. Even with this one; once and a while one Sonos device will go into Communication Error but it recovers itself after a bit.

0.10.0.oh240 │ org.eclipse.smarthome.binding.sonos

I hope this saves some folks time in going down this path with the latest Sonos binding and OH 2.4.

Best, Jay

1 Like

I don’t have much time to extract (debug) logs or go into much detail. But I have the same setup as OP :

  • All SONOS devices in the same subnet as the OpenHAB instance
  • Some SONOS devices connected via ethernet and some wireless
  • Power plug to switch off devices during off-hours to save energy
  • Running OpenHAB 2.5.0M2 (but I remember these issues from previous installations including 2.4.0M6)

I also notice the Sonos devices going from OFFLINE to ONLINE and vice versa quite a lot in my logs…

Possible Solution for Sonos Things going into OFFLINE - Communication_Error

I have been having lots of troubling keeping my 13 Sonos devices “ONLINE” within OH 2.4 consistently for over 11 months. I’ve tried Sonos binding versions 2.4m1 - 7 and 2.5m1 and I keep seeing the same results of them going into “OFFLINE - Communication_Error” states. Sometimes they go back online but mostly what happens is one goes offline then the rest will slowly follow so all of them are in “OFFLINE - Communication_Error” state. Only way I found to get them back online with OH is to restart OH.

Lots of talk about JUPNP being the problem. I’m running these UPNP versions:

openhab> list -s | grep upnp
212 │ Active │ 80 │ 2.5.2 │ org.jupnp
218 │ Active │ 80 │ 0.11.0.oh250M1 │ org.eclipse.smarthome.config.discovery.upnp
296 │ Active │ 80 │ 0.11.0.oh250M1 │ org.eclipse.smarthome.io.transport.upnp

Current Sonos Binding:

openhab> list -s | grep sonos
300 │ Active │ 80 │ 0.10.0.oh240M6 │ org.eclipse.smarthome.binding.sonos

This is from someone on a Sonos support community board which got me thinking:

"So I have been having same issues for months after over a year of zero issues. Same network nothing changed except SONOS began to not work. Tried almost all the answers here - reboot reboot —sounds like my IT here at work. Usually, the issues arise whenever we involve ALEXA. Even if you dont use it. I was in my Amazon account and ended up finding my way to Alexa settings and noticed my registered sonos devices. I just deregistered all of them . . . "

I have numerous Sonos devices connected via Alexa via OH HUE Emulation tied to Switches. I’m not using the Sonos Skill with Alexa so the actual Sonos devices are not listed as a device for me BUT

I ended up going into the Alexa Mobile App into devices and disabled ALL Sonos related devices that Alexa had linked up as a device from an OH perspective. It’s been 24 hours and NONE of my Sonos devices have fallen off OH since I did this. I have pushed rule policies at least 3 times and started/stopped OH also during this time period which sometimes starts to cause the issue with Sonos.

It’s my belief that Alexa/Amazon is scanning all devices for states and it causing the Sonos devices to fall off of OH. I’m not sure if this has anything to do with Sonos natively OR its tied to the HUE Emulation piece of it?

Can someone else having this Sonos issue please try what I did to help validate it?

Best, Jay

1 Like

I’ve been hyper focused in getting Sonos THINGs to stay online within OH for more than 24 hours. I’ve had some good results following this article.


Like his setup in his article I also have lots of Sonos devices; I had 1 Boost and lots of RED in my graph. I just got 2 Boost’s now setup and half of my RED is gone and OH Sonos THINGs is recovering when they go into OFFLINE_COMMUNICATION errors.

I have a third Boost ordered to see if I can remove all the RED from the graph and stop Sonos THINGs from going into error states.

Best, Jay

Bounty Created:

Best, Jay

1 Like

Did this solution suddenly stop working?

Not suddenly, nothing I tried last longer than 24 hours. If I dont play sonos at all, then the Things seem to stay online longer.

I’d be glad to submit debug logs consistently if someone wants to tackle this.

Best, Jay

I’ve updated the bug to include the following:

I decided to turn on jupnp debugging for a few minutes while my Sonos PlayBar was in a bad state. Every second I get this message set:

2020-02-02 13:40:34.657 [DEBUG] [org.jupnp.transport.Router ] - Sending via TCP unicast stream: (OutgoingActionRequestMessage) POST http://REDACTED:1400/DeviceProperties/Control
2020-02-02 13:40:34.657 [DEBUG] [org.jupnp.transport.spi.StreamClient] - Will not attempt request because it failed in the last 600 seconds: (OutgoingActionRequestMessage) POST http://REDACTED:1400/DeviceProperties/Control

Then, every 600 seconds I get:

2020-02-02 13:44:11.804 [DEBUG] [org.jupnp.transport.Router ] - Sending via TCP unicast stream: (OutgoingActionRequestMessage) POST http://REDACTED:1400/DeviceProperties/Control
2020-02-02 13:44:21.804 [INFO ] [org.jupnp.transport.spi.StreamClient] - Timeout of 10 seconds while waiting for HTTP request to complete, aborting: (OutgoingActionRequestMessage) POST http://REDACTED:1400/DeviceProperties/Control

2020-02-02 13:54:22.222 [DEBUG] [org.jupnp.transport.Router ] - Sending via TCP unicast stream: (OutgoingActionRequestMessage) POST http://REDACTED:1400/DeviceProperties/Control
2020-02-02 13:54:32.222 [INFO ] [org.jupnp.transport.spi.StreamClient] - Timeout of 10 seconds while waiting for HTTP request to complete, aborting: (OutgoingActionRequestMessage) POST http://REDACTED:1400/DeviceProperties/Control

A CURL (with POST) to the URL gives me:
<s:Envelope xmlns:s=“http://schemas.xmlsoap.org/soap/envelope/” s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault>s:ClientUPnPError401</s:Fault></s:Body></s:Envelope>
NOTE: I get this from ALL Sonos speakers I have. I’m not sure if I’m missing something on the query to get a bad authentication.

I have verified that I have <1ms ping times to the bar (no packet loss) and they are on the same network so the Sonos TTL=1 is not an issue here.

I let this go for about an hour with the same result. Then I restarted OH2. All of my speakers immediately came online and are stable. Given this, I do NOT believe the issue to be the Sonos itself as a “random” restart of OH2 should not clear out the issue on the Sonos.

Going through the debug of the OH2 restart it looks like OH2 effectively registers as an endpoint with the Sonos speaker. My assumption (since I can’t just make one fail at will) is that this registration becomes invalid at some point. Assuming that this theory is correct, at this point I would suggest that the Sonos binding be modified to detect this issue and “self heal” by restarting the registration process with that specific speaker when the HTTP request to the control URL fails to reply.