cookie time out will always be at 2 weeks, unless you try to do stuff to much and to fast.
amazon doesnt seem to like it if you try to do several things at several devices within seconds.
for example i got 13 echo’s and when i dont put in a short delay between tts to all, the cookie will expire much sooner.
it has a disadvantage though.
the tts to 13 devices is now takung 26 seconds for the last device.
there are other advantages from the sh script.
you can just ask for the last alexa when you like it without polling at all, which makes way more sense
ask alexa to trigger something in HA
HA looks what the last alexa was, then send TTS to that device.
i can set volume when i like it, i can start media when i like it, but i dont need a mediaplayer entity.
why would i ever want 13 mediaplayer entities, to be able to send TTS to 13 devices?
Yes, this is the main reason why the sh script (and for me, this method that @lonebaggie cobbled together) is still needed. Waiting 26 seconds using the Keaton component is just not feasible to determine last_alexa.
I have @keatontaylor alexa tts component working great. But would like alexa to report device states when asked. Will this script do that by itself and if so what is the best way to go about setting it up. Or do i need both?
Do you really have to wait 26 sec for a response?
Also I noticed that most on this thread are having issues with amazon cookies and dont know if this is relevant or not but the only time that i ever have to reenter the captcha for @keatontaylor tts is if i change something major in ha like restore a vm checkpoint or really mess something up, the captcha entry has lasted i know at least 2 months before i have restored something or messed something up and had to reenter. i am sure someone has thought of this but thought i would mention anyway.
Maybe you should open an issue on that in keatons component? But be interested what he says about making the last- alexa sensor faster.
I don’t see another reason for that sensor if not using it like you do (Boolean and answer). And this way you need it fast, if it’s slow it’s useless in that case.
But probably there are other reasons for that sensor I don’t see.
i need to wait 26 secs for response from the 13th echo, because i CHOOSE to add a 2 sec delay between each.
the original sh script on its own does nothing unless yo activate it. (i dont know what @lonebaggie added besides an easy option to connect to the SH and a polling to the last alexa)
if you have the mediaplayer working like you want, then i dont think there is a need for you to use the script at all.
for me its about a choice between 2 options that both have advantages and disadvantages, for almost everyone chosing both is not advisable.
@h4nc the last alexa from the mediaplayer is connected to the mediaplayer (although i believe they want to make it a seperate sensor, or already did) but it should be a service and not a sensor or an attribute.
as a sensor it is actally in most cases useless, you dont want to update a sensor and then retrieve the value from the sensor, because thats only delaying things.
Wow, thanks for the quick responce @ReneTode.
I see what you mean about the delay, didnt think about it before. I have 12 echos and dots total myself.
And right after i posted the request for help i found this https://github.com/keatontaylor/custom_components/wiki/Automation-examples
so i think i get the jist of things now. I’ll give it a shot with @keatontaylor examples.
Thanks so much for clarifying, sometimes a person just needs to here it a different way for it to sink in. lol
I never thought the delay would cause so many issues. I only have 4 Alexa devices. @ ReneTode 13 alexas that is some palace you live in
My testing with the template sensor I knocked up is sub 10 seconds to update the last alexa name.
I don’t know if that’s due to the number of alexa’s I have or the sensor delay I set (10 seconds). This time is more than enough for me to ensure the TTS response goes back to the correct alexa.
The bottom line is the @keatontaylor alexa media component is much more reliable . The TTS has never failed me , the cookie has never timed out, it is only getting better, hopefully it will become a standard component of HA.
This script has always been problematical, spent ages making it work in Hass.io and cookie time out makes it impracticable. I just wanted to point out to new users looking for a solution especially in Hass.io, there are simpler ways.
your right. i always pointed out that for hassio users that dont like tinkering, that they should use the mediaplayer.
for me the only trouble with the sh script is the cookie. i can find a way to automate renewal, so i end up renewing it every 2 weeks.
i got 2 ways to make sure i do it on time a pic on dashboard shows its time, and when there is an unexpected loss of the cookie, my lights start to blink, so we know that TTS isnt working.
its actually 2 houses (there are 4 at my fathers house at the moment) but when i am finished i will have around 30 devices in both houses together.
and yeah its not a small house
but i also want to have TTS on my outside areas, so the total space to cover is around 450 m2 inside and 150 m2 outside, in my house and then the much smaller house from my father.
by the way, at this point it is @alandtse who is doing most of the heavy lifting on the mediaplayer
so credit where credit belongs
Agreed. It’s on the todo list to expose a service. The polling mechanism was never the ideal way to do it, but it was the only mechanism that was easy to add in at the time it was contributed and fit with the HA design. Given that many people who need the faster response already do the script (as shown in this thread), it’s been a lower priority to add the service while we triage some of the other bugs and features.
