1.1.5 TTS: Sonos

I have found with the sonos that if they are in a group and you send tts to anything other than the group leader it will split the group

E.g I made a sonos group by adding ā€˜landing speakerā€™ to ā€˜hall speakerā€™

If I send tts to the hall speaker group ... all ok
But if I send tts to the ā€˜landing speakerā€™ or select the group and the landing speaker it will play but split the group

This I have seen on both HE and ST

Andy

I just tried it again with both zones playing, and this time the Kitchen zone was not dropped. Both zones started the next song. So I guess you could say it worked perfectly. Hopefully this will be consistent.

Since I discovered this, I only send tts to the groups now.
Hasnā€™t split the group since.

Andy

So far TTS is much improved with this update! Your work is much appreciated @mike.maxwell !

1 Like

this use case was never tested, by me at least.

is the TV audio fed in via optical?, and the input on the play bar isn't set back?, although we have no interface for inputs in the driver...

@mike.maxwell
Mike, is there any plan to extend the 128 character limit for tts?

Andy

TV audio is via optical on my playbar. Music via wired lan

sure, what do you want it to be?
I know I asked this before, but really didn't get a solid answer LOL

1 Like

Will it cause any issues to be really quite high like 600?

Edit: if this is a negotiation can we pretend I asked for 1000? :slight_smile:

Andy

3 Likes

If there is a cost to Hubitat for this, how about a ā€˜Premiumā€™ service :wink:

Not sure if anyone else would, but I would be happy to pay for,this if it costs you guys.

Andy

EBITDAR is always good!

well, lets do a little maths shall we?, what's the average size of a 600 character tts message?
even with out knowing that, it will be almost 5 times larger than a 128, which means that your hub will store 5 times few of them than before...

@Cobra its not a cost issue, they don't really charge that way at the rate that we use it, it was simply an arbitrary setting, we talked about this internally, no one really made a case one way or the other about the size limit.

So the actual calls to the tts engine would be more frequent as the storage gets full up?
A lot of mine are dynamic anyway so necessitate a call to the engine each time.

I can give you a use case for anyone using the random variables with my Message Central app.
Some of the variable groups could contain quite long messages before the actual message is added

For example..

Random: ā€œIā€™m sorry to disturb you, but I thought you might like to knowā€
+
Actual message: ā€œitā€™s raining and the following windows or doors are open:ā€
+
List of open contact sensors: ā€œthe conservatory window, the master ensuite windowā€
The list could be quite long which would obviously massively exceed the current limit.

Silly question:
What would be the implications of NOT caching larger messages?
Over a certain size limit just donā€™t cache them

Andy

we take the text, plus the selected actor, md5 hash that, we then look in the file system for that file, if its there we use that, other wise we fetch it from Poly then write it to disk.

Another use case:
I recently released another app that surprised me with the amount of people using it.
ā€œCheck Open Windows & Doorsā€
This uses a configurable trigger to initiate a ā€˜checkā€™ of a list of contact sensors and confirm that they are closed or open.
Any open contacts are added to a list for them to be sent to tts and ā€˜spokenā€™

This again could easily generate more than 128 characters

Andy

we're going to extend it, we're discussing the length, and what seems reasonable, we can't have it unlimited, this isn't a book reading service LOL

1 Like

So not 50, 000 then? :smile:

I think I understand the implications, and using tts as I do (with random dynamic messages) it would probably need to be fetched from ā€˜Pollyā€™ almost every time.

Andy

correct, and so long as folks understand that, the world is a happy place eh?

1 Like

To be honest Mike, I think most people would.
The additional delay of a second or two makes no difference if you just want a weather report or a report on open windows.
Itā€™s only things like ā€œthere is someone at the front doorā€ where any delay or loss (due to internet loss) would make any difference.
(And small, repetative messages would be cached anyway)

Another silly question...
Would it be possible to allow the use of some kind of flag as a prefix to the message to tell then hub not to try and cache it?
That could easily be added to any app that uses tts when the character limit is to be exceeded.

Andy

Btw.. do you know if blank spaces are counted as a character?
Just a side question.

Andy