Setting it at 0 caused the queue test to fail (test two, three, and four didn't play). 1 second seems to work fine, but I may leave it at 2 seconds just in case.
Edit: the TTS Queue app itself is still pretty chatty, any chance you could add the option to disable the debug logging there too?
I will look into it.
I do not own a Sonos Speaker. I only reported what their interface has.
@halfrican.ak - Does the SONOS speaker resume playing when a tts notification is received using this app?
I haven't tried this, my Sonos are dedicated announcement speakers. Will try and report back.
Edit: No, it just interrupts stream and announces then stops, at least when casting from my phone to the speaker.
I just re-installed this app/driver after playing around with another idea that didn't work out, but now I'm not able to play a message, I'm just getting "null" announced regardless of what I input.
Also, I notice the "test queue" is no longer showing in the options? Did something change on your github version and not get updated properly?
Ouch.
Fixed driver and it should correct problem. Link:
I iwill look at it some more tomorrow, but initial testing says OK.
Seems to have fixed the "null" announcement, but I still don't have any of the driver settings like the "delay" and "test queue". At least the announcements are back online, when you get time take a look at the other stuff, thanks!
I had to remove the delay and the test queue was not (in my opinion) necessary. Is that OK?????
The default delay was a little long IMHO for my Sonos, but it's not that big of a deal. So if you needed to remove the option for other reasons it understandable, just caught me off guard. The test queue was only needed if you were tweaking the delay so obviously it would have to go too.
Thanks for the update.
I will look at putting back in the default delay. I just thought it was not necessary. I used a 5 second delay.
Dave
Oh, I thought the default was 10s, 5s is what I ended up using anyway so if that's how you have the default set now, that's perfect.
Dave,
Is there any way the "playingTTS" state could be added to the "current states" so that I can test against the attribute in RM 4? I am using the sonos API to control grouping and it would be nice to be able to use a wait for condition based on that state to know when it's OK to change grouping. I've tried using the "real speakers" state but it doesn't work unless I play the TTS on it directly.
Thank you! This fit my needs perfectly!
If you have @djgutheinz Samsung app/driver he incorporated all of this natively. I believe echo speaks v3 does this too.
I have just found this. This looks very interesting. I didn't see this on HPM. I have a bose soundtouch. I'm starting to play with this a bit. I couldn't tell if this support Text/speak and resume. I have Echo devices too. However, I'm assuming write a rule to Virtual device driver it will "queue" it if needed. Only question I have does this support Speak/resume functions?
Thank you for this.
look at the below thread:
I have the that and so far I like it! I have been testing that. The big issue I'm see in most cases if there is a rapide fire of notifications the notifications are lost. TTS Queuing would address this. I'm trying to come up with complete solution that covers every situation.
I have an old app for TTS Audio Buffer. May help. I integrated this into my Samsung Multiroom Drivers. Not perfect - but works pretty well.
Thanks I'll give this a try.
Thanks! This is the one I have been testing with. There isn't a resume audio function so if a track is being played it will interrupt it. If I just the Bose that function works but Queuing doesn't. Thank you for your help.
Download the Hubitat app
