-
-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sonos: Read timed out. (read timeout=9.5) #114936
Comments
Hey there @jjlawren, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) sonos documentation |
Thanks for the report. Couple of questions. What is the source type that you are activating? Please provide the full text from home-assistant.log |
I'm running 2024.4.2 and have also noticed the timeout error.
FWIW, no new hardware has been added to the network. Let me know if there's anything else needed to help narrow down the cause. EDITThis might be a red herring but someone reported an excessive amount of mDNS traffic produced by Home Assistant. Given that it uses UDP and so does the Sonos integration then maybe the flood of traffic is affecting timing. Apologies if I have misinterpreted how all of this actually operates under the hood. |
I am able to reproduce the issue reported by @TheNightmanX, that radio station always seems to take ~15 seconds to play. So I believe that raising the timeout when using select_source may be a good solution. I am testing a change for this. @tdejneka - while the error message you are seeing is the same, it is from the call to set the volume which should occur very fast. When it doesn't that usually indicates some type of network problem. |
I am sorry for not providing logs so far, but I was not able to do it due to time constraints. I apologize for that.
|
What's perplexing is it happened at 7 in the morning when there's ostensibly the least amount of network traffic because there's no activity yet (no audio/video streaming, internet browsing, etc). Anyways, I'll keep a record of when the timeouts occur (they're very infrequent) and try to find anything they have in common (and possibly correlate them with other network activity). Think I need some kind of network monitoring software to give me visibility into UDP traffic. The only thing I use now is pihole (and the router's log) and that's not the right tool for this job. |
I've had some sluggishness on one of my Sonos S2 networks when using the Sonos appI looked at this article https://support.sonos.com/en-gb/article/reduce-wireless-interference I checked my router and I had channel 9 selected - not sure why - and there's not a lot of other WiFi in this area. So I changed it to 1, rebooted the router. 3 out of 5 Sonos devices joined, the other 2 (which are the newer models Sonos 1) did not despite power cycling several times. I used the Sonos App to repair them and now they are back. Anyways,.... I was surprised that changing the channel causes an issue. This should be transparent as client should be looking for the SSID and connecting with the password. But apparently the Sonos 1 were tied to the channel assignment. You may want to look at the WIFI channel assignment in the router. |
In my case, it's fixed at channel 11, chosen for least interference with neighboring (weaker) WiFi channels and local Zigbee channel. All Sonos speakers are S2 and connect to WiFi promptly after they, or the router, are rebooted. |
@jjlawren - working on a fix for this, there are a couple of options. The timeout is 100% reproducible using the station in this issue. The select_source call ends up in this function and calls play_uri. play_uri is using the default timeout of 9.5 seconds and does not allow the timeout to be specified.
One choice is to open a pull request on Soco to add the timeout. I have this protoyped - and then we change the call to use the LONG_SERVICE_TIMEOUT
The other alternative is to temporarily override it:
Both work. |
Overriding & resetting a module state attribute around every call seems a little gross. The first option to add the argument to the call feels better. Alternatively we could just increase the global "short" timeout, but that seems like it would hide more problems. |
Agreed - opened a pull request on Soco |
Fix is working. Thank you all so much for your help 👍🏻 |
The problem
Getting the following error multiple times a day when setting the source for playback on a Sonos system. The source is played despite the error (so it works). But the error is still noted in the error log.
Error while executing automation automation.sonos_wz_antenne_duesseldorf: Error calling SonosMediaPlayerEntity.select_source on media_player.sonos_wohnzimmer: HTTPConnectionPool(host='192.168.1.30', port=1400): Read timed out. (read timeout=9.5)
What version of Home Assistant Core has the issue?
core-2024.4.0
What was the last working version of Home Assistant Core?
never
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Sonos
Link to integration documentation on our website
https://www.home-assistant.io/integrations/sonos
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: