no i didnt. thx have been waiting for it.
your link didnt show me anything but this one shows that its real!! yeah
im gonna play with it. 
https://newsbeezer.com/germanyeng/alexa-can-now-also-voice-recognition-my-voice-starts-in-germany/
do you think this control will ever be part of hass.io as “standard” function? would be great to control every echo-device without getting this to work. also haaska could be a standard.
i hope not from hassio but from home assistant.
but i think not for a while, because the only person who tried it untill now (with the mediaplayer component) seems to have little time to develope at the moment.
and somehow i got the feeling that he is trying it on a “none HA way” preventing it from implementing.
1 Like
How long is the cookie lasting for you all? For me its only lasting from 6 to 10 days. This is in spite of setting a very high scan interval. I only update when its needed, roughly 3 times per day.
Any suggestions for changes to my setup to increase cookie life?
Getting much the same here Have setup a sensor which checks for the cookie disappearing 10 days so far previous renews were 15 days and 22 days.
Is your script still working since the most recent update?
I’m in the process of trying to get this to work and have had no luck. Here’s my configuration:
shell_command:
upstairs_ecobee: 'python3 /config/alexa/alexa_wrapper.py "{{ params }}"'
I consistently receive the following error (which is what I was getting when following the original directions using the direct call to alexa_wrapper.sh) when I try to make a call to the service:
2019-01-11 13:32:46 ERROR (MainThread) [homeassistant.components.shell_command] Error running command: `python3 /config/alexa/alexa_wrapper.py "{{ params }}"`, return code: 1
NoneType: None
I should note that alexa_remote_control works fine from the command line. As you, I’m running Hass.io as well.
@lonebaggie The @ keatontaylor custom componentt does not take the place of your component. The sensor.last_alexa works great with your component. It does not work well with the other component.
see
This is not my component, mealy the ability to run the python script in hass.io. I’m not smart enough to write any of this 
I have removed the setup I described above and I am now using the keatontaylor custom component . It has never stopped working , never needed a cookie refresh . It has been very solid. The above is a “fudge” I put up with it for the last alexa options and the ability to run routines.
I use Keaton’s component to send tts. However I am unable to use last_alexa with his component because it doesn’t update quick enough to be used to ask Alexa something that is passed to HA and be able to respond back to the correct echo.
When by my voice, alexa triggers an HA booleon, I can do an entity update on your sensor.last_alexa and immediately get back which echo I asked the question. I cannot do that with Keaton’s component.
I know the sh script isn’t yours but the method you put together with the python script is the only thing I know that works with HA unless you use AppDaemon or something like that. People still need to know how to do this using your method until if and when the other component can provide a quick responding sensor.last_alexa.
Good point . I extended the scan rate on the last alexa script, to preserve the cookie timeout to about a minute so I have not noticed how quickly the new sensor updates
I will play with the scan rate
and report back
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?
1 Like
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.
1 Like
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.
EDIT: Issue is already opened see last_called is too slow? · Issue #83 · alandtse/alexa_media_player · GitHub
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.
1 Like
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
1 Like
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.
1 Like
Seems like all of this works now with the newest version of alexa mediaplayer.
Last_called is fast now.