I’ve set up some TTS messages to my HomePods using Node Red. They only work some of the time. I just triggered a message to a HomePod and it worked. I waited a few seconds and did it again and got this error:
"Call-service error. no response to ANNOUNCE rtsp://10.0.0.185/3102234273 (RTSP/1.0)"
I’ve had this error on several different HomePods. I have a good morning message that I’ve been using for a few years now. Sometimes, it stops working for a day or two and then works for months.
Given that it works some of the time, it seems like it’s a problem with Apple side of the interface. Does anyone else have this problem?
@postlund is your interface automatically updated with Home Assistant or do I have to do it manually? It’s been quite awhile since I installed it. I’m on version 2023.3.1 of Home Assistant
Yep, same here since iOS update to 16.4 on my HomePod mini.
Before that, it happened from time to time and I just had to restart the HomePod. but now it’s permanent and no restart fixes it.
My good morning message has gone out on previous software upgrades. It usually comes back after a couple of days without me doing anything. I haven’t tried to restart the HomePod. I didn’t know you could.
Update
After three days of no tts, it came back this morning on one of my HomePods. I did nothing to my HomePods although I’m pretty sure I have auto-update turned on. When I tested it on my HomePod Mini in another room, I still get the the no response error.
Update 2
It didn’t last long. After a couple of days, it stopped working again. I noticed that, if I retried the process, it would usually work the third time. How charming My guess is that the HomePod is in state that can’t receive messages and that sending it one or two ‘wakes’ it up so that it then can process a message.
Work Around
I changed my Node-Red flow that generates the message, adding a catch node for the tts error and a retry counter to keep it from an infinite loop if the device is down. The catch flow increments the retry count and, if it’s below the max, calls the tts node again. I have no idea how to do this in a Home Assistant automation.
Apparently, since iOS 16.4, the HomePods can take up to 7s to wake up, but unfortunately the integration timeout is 5s.
But when the HomePod is awake (in stby mode instead of idle), it responds immediately.
So when you send a tts again just after the error, it works.
Unfortunately, it’s impossible to repeat in an HA automation after an error because the “continue on error” directive doesn’t work. There are many complaints about that but this bug has never been addressed.
The only solution I know of has been mentioned in another thread: the “Retry” integration from HACS.
I tried it and it works, but because you have to wait for at least one failure (and sometimes more), that means that your tts could come out after a 10-15s delay which is huge for certain applications.
@iDevice That’s great to hear. I have a half dozen other tts flows and refactoring for error handling takes work. As for getting the latest version of pyatv when the fix is included, is it part of a Home Assistant update? I don’t remember doing a pip install, especially given I’m using a Docker VM for Home Assistant.
With the error handler installed, the tts has been working on the second attempt the last two days.
Ultimately, it will be part of a release, I hope.
The pip install from the mentioned thread is just a temporary hack by changing the integration timeout.
This is not standard procedure and I would avoid it, unless you’re desperate.
That said, if something goes wrong while doing it, I guess the fix would just be a backup away, but I prefer to be patient.
Since adding the retry logic, I’ve had varying retry attempts. Usually, it works without a retry or with one retry. Occasionally, it takes two retries. I’ve also had it not work at all after five retries. In those cases, I re-executed the command and it worked without a retry. I’ll report back once the update is installed.
I don’t think the timeout bump has been merged in a prod release yet as I still see warnings from the Retry integration as well.
Otoh, I have the impression of seeing less retries than a week ago or so.
So it could have been merged after all but not bumped enough ?
I think we’ll see with Wednesday milestone.
The patch is not out there as of yet, I am still modifying the /usr/local/lib/python3.10/site-packages/pyatv/support/http.py file around line 389 to change from 4 seconds to 10. This works until you upgrade HA.
Still having issues on my end. I use my HomePods for TTS notifications and they are only working in my notifications around 5% of the time or so. Anyone have any ideas on when this will be implemented in the Core release? Or have a temporary workaround?
If you had read this thread, you would have found at least two workarounds, but the fix is already merged in the next core release, so I guess you might just wait a few days more.
My Homepod Mini has been playing TTS announcements daily with 100% accuracy for a year now. However, since a week or so, it started to fail and not make a sound while the automations trigger appropriately.
I have an easy fix for it, just reload the integration and it starts working again. However it only works for a day or so and stops playing out the messages again. Until I manually reload again.
Something clearly broke somewhere after mid March 2024.
@terppatyyppi yeah, I have noticed this lately too. I don’t know when the issues started happening. Had been working fine for a long time. Any idea what update might have caused it?
I have a theory which I’m now testing. Maybe this behaviour has something to do with one of the recent updates to Homepods…around power saving / long(er) idle times etc.
I’ve now added a “wakeup” command to be sent to the Homepod, 2 seconds before each TTS call…so far it’s working, then again there’s not been enough time in between yet to see if it’s a permanent solution.
Maybe I’m totally off with this, but at least that’s my theory currently…soon we’ll know…
My guess is that the HomePod is in state that can’t receive messages and that sending it one or two ‘wakes’ it up so that it then can process a message.