Sonos introduced a power saving feature recently which reduces their power to a couple of watts when not being used. In HA devices in this state are shown as unavailable and services such as TTS stop working (they work fine when the Sonos is awake & playing a tune.)
It works fine for a few minutes after the official Sonos app has spoken to it, but then becomes unavailable again soon after.
Is this in the latest firmware revision (14.0)? How can you tell they’re in an idle state? Is this a controllable preference? Does it affect all models?
It came with the S2 app last November/December apparantly. I’m only assuming they’re idle because HA shows them as offline a short while after they stop playing. I can’t find a preference to control it and it effects my play:1 & play:3’s that I have.
I’m on the latest firmware and I’m not seeing the issues you’re describing. If speakers are being marked as unavailable then something seems wrong. Any warnings or errors related to Sonos in your logs?
I’d be really interested in seeing a link to any documentation about this newly introduced power saving feature. Thanks.
@Stubbs I’ve also seen similar issues when the integration has fallen back into polling mode. Do you have any Sonos warnings in your log which say “falling back to polling, functionality may be limited”?
According to the Sonos Release Notes, version 13.4 (released 11/16/2021) introduced:
A new Battery Saver mode is available for portable Sonos products.
In all subsequent releases to date (13.4.1 and 14.0) I don’t see anything mentioning a “power saving feature” for any of their other products.
Interesting @jjlawren …
Here’s what I can see. The device history shows a lot of flip-flopping between “Paused” & unavailable:
There are a few errors in the log from a few days ago, but they relate to not being able to find the device:
Office rebooted or lost network connectivity, reconnecting with <SoCo object at ip 192.168.20.17>
25 January 2022, 21:35:23 – (WARNING) Sonos - message first occurred at 18 January 2022, 16:45:50 and shows up 4 times
Error requesting favorites from <SoCo object at ip 192.168.20.17>: HTTPConnectionPool(host='192.168.20.17', port=1400): Max retries exceeded with url: /MediaServer/ContentDirectory/Control (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f283ec5f970>: Failed to establish a new connection: [Errno 111] Connection refused'))
25 January 2022, 21:35:15 – (WARNING) Sonos - message first occurred at 25 January 2022, 17:21:52 and shows up 12 times
Matt's room cannot reach None, falling back to polling, functionality may be limited
25 January 2022, 17:21:49 – (WARNING) Sonos
Exception in async_seen when dispatching 'sonos_seen-RINCON_B8E937E1B05801400': () Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/sonos/speaker.py", line 491, in async_seen done = await self.async_subscribe() File "/usr/src/homeassistant/homeassistant/components/sonos/speaker.py", line 320, in async_subscribe raise RuntimeError( RuntimeError: Attempted to attach subscriptions to player: <SoCo object at ip 192.168.20.15> when existing subscriptions exist: [<soco.events_asyncio.Subscription object at 0x7f283ec5f160>, <soco.events_asyncio.Subscription object at 0x7f283ec5f760>, <soco.events_asyncio.Subscription object at 0x7f283ec5f790>, <soco.events_asyncio.Subscription object at 0x7f283ec5f940>, <soco.events_asyncio.Subscription object at 0x7f283ec5f070>, <soco.events_asyncio.Subscription object at 0x7f283ec5f730>]
25 January 2022, 17:21:42 – (ERROR) util/logging.py - message first occurred at 23 January 2022, 18:09:49 and shows up 5 times
Failed to connect to rebooted player '192.168.1.107': HTTPConnectionPool(host='192.168.1.107', port=1400): Max retries exceeded with url: /MediaRenderer/RenderingControl/Control (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f283ecb6f40>: Failed to establish a new connection: [Errno 113] Host is unreachable'))
25 January 2022, 17:17:15 – (WARNING) Sonos
If I play something on one of the players, they all almost immediately come back to life in HA, showing correctly as paused. They stay available for a couple of minutes and then become unavailable, with nothing in the logs at that time.
Looks like I saw that announcement & saw the behaviour of my devices and put 2 & 2 together, but got 5. I just assumed they’d rolled it out to all devices now as what I saw fit that.
First problem to solve is that your speakers can’t seem to connect back to the HA host on port 1400. This allows subscription events to arrive. If they can’t it falls back to periodic polling which is less reliable and less efficient.
Any reason that connection back might be restricted or blocked? What’s your HA install method?
HA is running via a Docker container but it runs in host mode so it should be able to access 1400 no problem.
If I try and connect to the port though, it works:
> nc -v 192.168.1.80 1400
Connection to 192.168.1.80 port 1400 [tcp/cadkey-tablet] succeeded!
Is this a new feature or changed behaviour because I never used to have this issue, I did upgrade HA a couple of months ago & started my config from fresh to take advantage of the new UI based config for most stuff.
This has always been the case, but it wasn’t explicitly documented. I added this section to the documentation page a couple days ago to make this more clear.
It seems like you have Sonos devices on multiple subnets (192.168.1.X & 192.168.20.X). Is this correct? Are you running multiple subnets, have internal firewalls in place, etc?
I also don’t believe this is the complete picture. For example, your subscriptions have been completely cancelled by the time it falls back into polling mode–normally we’ll wait to cancel them until after this warning is logged. Perhaps there is more information if you grab the complete log from the backend (/config/home-assistant.log).
Finally, I’ve added the ability to request a diagnostic report from the integration in 2022.2 which will be out in a couple days. If you can upgrade and provide diagnostics when you’re experiencing the issues perhaps we’ll see something new.
They are on a couple of different subnets, yes. From a bodged attempt to put HA stuff that required no external access on one subnet, stuff that needed access on another and laptops, phones etc on a third. It never worked properly so I reverted to just 1, but it appears one of my devices didn’t get the memo 
I’ve removed the 2nd network from the Sonos app and this appears to have fixed the issue. I don’t really understand why the devices on the same subnet as HA were also effected though, but now they’re all on the same subnet they seem to be happy.