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
So not 50, 000 then? 
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?
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
ok, 1KB it is, also we do have some protection built in, the sum total of tts files is limited to 5MB, after that it will remove the least accessed files first.
Brilliant!
I’m sure that would be enough for most things
Thanks very much for doing this.
Now... when did you say the next firmware release would be with this included?? 
LOL!
Andy
yes, they are counted, however the string is lower cased for the hash, so Hello == hello as far as the cache is concerned.
This was a bug that was reported after the initial integration, and subsequently fixed if memory serves, then inadvertently broken in this one...
So I'll collect data points on this release, then see about fixing the lack of input restoration as well.
.. that’s exactly what’s happening
.. in the previous firmware this was never an issue. I used to prefer the sound bar because I didn’t really like the music track restarting, obviously not an issue if the sound bar is not being used or just playing tv audio.
I'm not sure this is a firmware issue because its working properly with my Sonos sound bar. When playing movie audio to the sonos via optical, when it receives a TTS it pauses audio, plays tts, then switches back to optical audio. Not trying to discount your issue, just giving another data point.
@mike.maxwell I am seeing another issue with TTS. Its not respecting the volume setting.
I have a few TTS triggers that have a volume setting of 15. When these TTS messages play, it seems that they start at the correct volume, but ramp up to a higher volume very quickly (less than a second) to maybe around 55% while the message is playing. Because of location of the soundbar in my office, 50% is screaming at me.
I setup a test trigger to test. You can probably replicate this.
My volume issue is turning out to be intermittent. Doing it maybe 50% of the time now.
Good news is still no double repeats!!
I have the opposite problem. It started loud then, within a second, the TTS speech ramp down to ~20%. This started happening after my son kept toggling the physical volume buttons on the Sonos while music was playing.
Download the Hubitat app
