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
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.
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
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
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.
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.