Chromecast uriQ (message queue stalled)

Sorry for the spam guys, but this one is driving me nuts (and I'm driving the wife nuts testing it :smiley:).

I turned on the "Stop after TTS is complete" setting in the preferences section of the GH Mini device. It looks like it forces a disconnect after every announcement, which I believe lack of disconnect was leading to the errors. I've disabled my refresh() for now and will continue for the next several hours/days testing in this mode.

Two drawbacks I've noticed:

  1. Logging seems to be clipped when I do this. I don't get consistent logging of "speaker is playing", "speaker is idle", and "media source is Hubitat" events. But 100% consistency on "media source is None" within a couple seconds of the event.

  2. You get the new device connecting sound with EVERY event, regardless of how close together they are. Not a drawback for me, but I know others have said this drive them crazy. Guess it's good that I'm already crazy. :stuck_out_tongue_winking_eye:

1 Like

Got it thanks VERY much

"Stop after TTS complete" setting seems to have worked. I'm over 24 hours and everything is working fine without refreshes.

I'm still seeing inconsistent/incomplete logging. :-\

1 Like

Ok, while the GH mini hasn't gone offline since I turned on the "Stop after TTS complete" setting, it appears to truncate long messages (like notifications from @aaron's NOAA Weather Alerts). Hmmm.....

Does anyone know if there is a character limit for TTS? If there is I can do something similar to my PushOver character limitation. I have not personally run into any issues with TTS announcements with my NOAA application.

I believe it is 1024 characters. It used to be 128 but Mike increased it recently. See this discussion: 1.1.5 TTS: Sonos - #15 by Cobra

currently there isn't a limit

1 Like

So there should be no reason for a long weather alert to be truncated correct?

as long as what's being passed in is standard ascii characters...

1 Like

I believe it was related to the "Stop after TTS complete" setting I was using on the GH mini to keep Hubitat from forgetting about the speaker.

I've bumped that timeout setting in 2.0.7 by 50%, hopefully that will help with this.

I've just run some tests and can confirm that "Stop after TTS complete" is absolutely what is cutting off long messages.

@mike.maxwell, the only reason I'm using that setting is because the GH mini gets forgotten by Hubitat sometime during the course of a 24 hour day unless you refresh the device. While I appreciate the extended timeout, I'd rather have the integration fixed.

The library were using is not that great which is why this integration is in beta.
At some point in the future we will likely revisit this it's not a huge priority right now.

Understood and I appreciate the prioritization efforts. Hubitat was good when I bought it and only getting better. There are work around in place, I can live with that for now.

1 Like

With the release of Rule 4.0 I was able to create this rule that has completely solved this issue for me. Hopefully this helps someone.

Why does the triggers have 2 with status and 1 with mediaSource? Just curious.

Great catch. Thanks for pointing that out. My mistake they should all be status for the triggers. You probably just save me a bunch of time trying to figure out what went wrong with that speaker :wink:

Also the two second delay seems to stop the end of the message being cut off. Not sure why it happens with no delay as the status shouldn’t change to idle until after it’s finished playing.

I put together this rule. Do you see anything wrong with it?

I just gave this a try and did some speech through one of the speakers and the mediaSource never changed to None from Hubitat. Does yours return to None?

@tsviper This rule works!

1 Like