Constant "invalid authentication" from Sonos devices in logs

Hi, I’m getting an “invalid authentication” notification in Home Assistant multiple times a day triggered by my various Sonos devices. The log shows as follows:

Logger: homeassistant.components.http.ban
Source: components/http/
Integration: HTTP (documentation, issues)
First occurred: 11:23:05 (2 occurrences)
Last logged: 11:26:13

Login attempt or request with invalid authentication from SonosZP ( (Linux UPnP/1.0 Sonos/69.1-31120 (ZPS14))

Yesterday it appeared over 40 times! I used to get this message very occasionally so I’d ignore it, but recently it’s gotten annoying. The hostname and IP change, but the hosts are always Sonos devices.

Any ideas where I could look to find out what’s causing it?

Running the official HassOS image in a Proxmox VM. Latest update installed as of today.



1 Like

Same thing is happening with me. I’ve even had to ryen off BAN IP beacuse it was stopping me from logging in.

I’ve made a github issue here:

I keep getting this also. Deleting and re-installing the integration changes nothing. Re-setting/rebooting the Sonos also does nothing.
The Sonos isn’t even playing anything, and the error appears. Did notice that it is linked to the Sonos attempting to access media in Home Assistant, which it may have played in the past.

Any fix on this? Just started happening last month. From all my Sonos devices, probably trying to access mp3 on my HA.

See if your Sonos playqueue for the speaker in question still has it in there and remove it if it does.

Yes, the MP3 is in set in the sonos device, not playing. I can’t clear it, but I can put something else in the Sonos app.

Is there a way for the automation to unqueue the media?

You should be able to use the media_player.clear_playlist service.

I may have found a solution to this issue.

All my media sound files that play through my Sonos I renamed to remove spaces, and replaced with an underscore or hyphen. Since having done this, no more login errors I’ve encountered.
Fingers crossed that the spaces was causing the issues.

1 Like

Been happening to me for a few months now as well. Yesterday I tried upgrading to the latest HassOS and 2023.6.3 and still doing it.

I do have some local media, and I tried removing the spaces but two of my speakers got IP banned about 10 minutes after I tried again.

This is quite frustrating. Anyone else made progress with figuring out a solution - or is there an official bug report somewhere I can pile on to?

Also an issue for me, on varying annoyance levels.

I use a bunch of Ikea/Sonos shelf speakers for various notifications like doorbell and phone, and to summon my kids to lunch.

First off, the speakers in question don’t play these notifications once they are in this error state, until I manually select a sound file to play from the media menu.

Second, the error message (both notification and log) always states “SonosZP ([ip-address])” as the culprit instead of a friendly name.
Kinda hard to find out which of my (currently 6, 3 more queued for installation) Sonos is the one acting up.

The blanks-in-file-names approach did not work, neither did clearing the playlists.
In fact I only have them play single sound files.

Found a workaround.

Play a Piper TTS after playing a soundfile.

The TTS URI doesn’t include the (soon to be outdated) API key, hence it won’t trigger the “invalid authentication” error.

Fun fact: Piper doesn’t actually need to say anything. An empty string will do nicely.

Same problem.

Getting this as well, It’s random to me when it happens as i have a bell.mp3 that all 4 of my sonos players play when the door bell goes. Some of them get banned after that some it takes 4-5 weeks of being fine before the get banned.
Rather strange.

having this issue too. any fixes?

Same to me. Having this issue withvonly one speaker of three

+1 same here

Did anyone try the solution/work-around listed in the HA Issue: power-cycle your speaker(s). It worked for me.

I had this issue for months, I spent some time investigating it and it is NOT random at all.

The URI for playing a sound file contains an access token.
The integration seems to keep a copy of the last URI for some reason.

The problem happens if you don’t use the Sonos for a while and/or if you restart HA.

That’s where the integration seems to execute (part of?) the remembered URI which now contains an OUTDATED access token, which leads to the ‘invalid authentication’ error.

So much for the bug.

Now, Piper TTS doesn’t seem to leave an access token in the URI, hence the idea of my workaround:

I always make sure that my Sonos’ play an empty (!) TTS after playing a sound file.

Since I do that, I never saw the error message again.

This is a kludge, of course, but it beats power cycling, reloading the integration and anything else I saw so far.

1 Like

Would using “announce” work for play a notification, as I seem to remember reading that it then play/loads what was on the speaker before the announce.

Tho as I write that it might just be a s2 feature and I’m stuck on s1 due to old speakers

Getting this too pretty randomly and only from a wifi sonos speaker. Fun fact is that I use that speaker once a month maybe.