OK, so I spent some time on incorporating your volume control changes into the App and Driver. The changes to the App I really didn't change, other than moving some things around. However, I made extensive changes to the Child Alexa TTS driver. I wanted it to use the standard "Audio Volume" capability, instead of custom attributes and commands.
I also changed the logic for how the user preference for volume is used. If defined, it will always send a setVolume command to the Echo device before it sends the TTS command. If it is not defined, then everything behaves exactly the same as it does today. I basically simplified things in a way that I believe most users would want.
With the AudioVolume capability comes some commands that really aren't useful with this Alexa integration...specifcally, volumeUp(), volumeDown(), mute(), and unmute(). I have stubbed these commands out and added a log.debug message to inform the user to use the setVolume() command instead. It's not perfect, but I feel it is the best compromise for now.
New versions are already in my GutHub if you want to take a look.
on question or a couple the reason i did not do it similar is that set volume is also considered a command so doing it at the same time or immediately before a text stream was causing a too many calls too quickly error. have you looked into that..
also is there an option to set it back the way it was, it would seem you may only want to set the volume once not on every command and/or if you do it on every command you may want it to go back to the volume it was previously?
Good points, especially the “too many calls” issue. Will have to think about that one.
However, there is no way to know what the current volume is on the Echo device (and I am not willing to start polling Amazon’s servers to find out.) Users adjust the volume on their Echos all the time by voice command. Thus, there really is no way to know what to set it back to.
I have just updated my GitHub repo with a new version of the Alexa TTS App and Driver. This latest version adds a timeout parameter to all http calls to help reduce the possibility of long-running threads on the hub, which eventually result in an error.
In addition, this latest version allows one to set the volume of the Echo device. Be forewarned that setting the volume does mean that another call to the amazon server occurs, and amazon does impose throttling on these requests. Thanks @kahn-hubitat for the volume functionality!
@ogiewon Any chance you can add an optional field to enter the owner ID? This is needed to use "All Echo" if there are multiple Echo devices on the account that have different owners.
I added the optional field previously and forgot and just overwrote the code to the most recent version. Would be great if I could have it in the app already so I can easily move on to the latest version.
@ogiewon Any chance you can add an optional field to enter the owner ID? This is needed to use "All Echo" if there are multiple Echo devices on the account that have different owners.
I added the optional field previously and forgot and just overwrote the code to the most recent version. Would be great if I could have it in the app already so I can easily move on to the latest version.
Did you enable the new preference for default volume by any chance? Disable that feature, and maybe issue a single setVolume() command in RM, before sending the TTS command(s). You can also make sure you add delays between successive TTS commands.
The error message is pretty descriptive. It means you’ve tried to send too many back to back commands in rapid succession, which Amazon blocks.
ya that is why i mplmmented the set volume the way i did and not assume you want it on every call.. i figured you could do it in rm if you did want it on every call.
Yep, and I recognized that as a possible issue earlier when you pointed it out. I am considering a simple method to deal with the potential for this issue. Will report back once I have something to test.
I’d still like to hear back from @toy4rick to see whether or not he enabled the new feature.
I have just pushed a new version of both the Alexa TTS App and the Child Driver to my repo. Give it a try if you'd like. This version will properly send error notifications, including the throttling error, to make it easier to troubleshoot (if one has selected a notification device, of course.) In the Child Driver, I have also implemented the standard 30 minute automatic debug logging disable feature found in most Hubitat drivers. Finally, this version of the Child Driver prevents the automatic volume setting before each TTS message from occurring more frequently than once every 10 seconds. The idea being that if someone is ending multiple TTS requests in a row to a specific device, that device will only request a set volume command on the first one.
The throttling issue that is still possible, though, is if one enables the automatic volume setting on multiple echo child devices and tries to send a TTS to multiple echos at the same time... This is why I like keeping Alexa TTS simple. Such seemingly small additions always grow into larger issues. I may simply remove the automatic volume setting feature if others experience difficulties.
For those who want a robust, full featured Echo integration, there is always Echo Speaks as a viable option.
ive even had issues with the throttling trying to send a message to say 3 alexa devices. i have had to use the all alexas to get around it or put my own delays in the rules.. so not suprised say one voice setting and a message to a couple of alexas could cause issues. i'm thinking maybe a new option to set a user configurable delay with a reasoneable defualt that kicks in when you send a message to more than one alexa (with an option to disable obviously)
even unrelated stuff has issues.. for instance i've notice when im playing an audible audio book and the wife asks a different alexa to do something or a message from hubitat comes in the audiobook always pauses till the other interaction is complete. So obviously alexa doesnt have enough headroom...
Yes I did enable the feature however turned it off within a matter of seconds. I was interested in seeing if there were any other options to consider when the feature was enabled
Just checked, no errors since I disabled the feature
I used this app for a long time back in the day, hated dealing with expiring cookies since I don't have any options to handle it automatically, recently moved from Alexa Speaks back here as my hubstats were showing 1-2 seconds and I was troubleshooting slow hub performance...
This morning I received another "too many request" error, didn't do anything special at all, normal automation stuff around here, wasn't playing with HE...
I assume you have cleared out the "Default Volume" user preference for this Echo device, since you're explicitly setting the volume in the rule?
Also, did you upgrade both the Alexa TTS App and Child Driver with my latest code changes from this weekend? These changes were specifically added to help alleviate this issue.
you need a delay between the set volume and the message.. even two back to back calls can cause the error message. put a 5 or 10 sec delay after the set volume in the rule. I wish amazon would fix this it is kind of unfortunate.. but currently that is the nature of the beast. my last driver was a little different.. that is why i had the attribute tracking the volume and if you never manually change it you could check the attribute in the rule, and only issue the set volume if it was not to your liking.. A little different approach.
this page says alexa limits the rate to 25 tps per second whatever tps is?
i am experiementing with adding code with exponential backoff with retry on error 429 seems to work but regardless if you send mutliple voice clips to the same device in a row.. it disregards the first if the second comes in before the first is completed.. I dont thing there is anything we can do about that.. but i think this code would help in some cases..
catch (groovyx.net.http.HttpResponseException hre) {
//Noticed an error in parsing the http response. For now, catch it to prevent errors from being logged
// lgk add retry after delay on error 429 rate limited
def statusCode = hre.getResponse().getStatus()
if (statusCode == 429)
{
def newDelay
if (currentDelay == 0)
newDelay = 5
else newDelay = currentDelay * 2
if (newDelay >= 20)
{
log.debug "Already tried repeated command 3 times ... Giving Up!"
}
else
{
log.debug "Got Alexa rate limiting error (429) delaying for $newDelay and Retrying!"
runIn(newDelay,"speakMessage",[data: [message, device,newDelay]])
}
}
else if (statusCode != 200) {
This is why I like keeping Alexa TTS simple. Such seemingly small additions always grow into larger issues. I may simply remove the automatic volume setting feature if others experience difficulties.
