Oh, that makes sense. I’ll give it a try when I’m back home. It would be handy to have a way of not having to say “Alexa, Turn On, Whats the house temperature” but guess thats for a next time?
Thanks for the help. I’ll give it a test later today.
create a routine where you say “Alexa, Whats the house temperature” and let it turn on the switch.
This worked perfectly 
Is there any way to auto detect which Echo I’m talking to? At the moment I broadcast the info to all of them, but its a bit annoying 
Thanks
just read a bit back in this topic and you see examples for last_alexa.
but dont forget that it needs quite a delay.
1 Like
Alternatively, if the delay from last_alexa of this component is too long for your needs, consider creating a last_alexa sensor per the instructions below. There is practically no delay with it. The con with it is you have take a minute to create a cookie every couple of weeks or so.
2 Likes
While this is a workaround, please note what this is effectively doing is increasing API calls to the unofficial Alexa API using the script. I haven’t heard of anyone hitting a rate cap yet, but it’s worth considering.
For those who care to know we currently rate limit hitting the AlexaAPI for this data to every 1 second. However, based off what people are saying I don’t think that’s the cause. I think the delay issue is tied to the default poll rate in HA per media_player device (which I don’t actually know but will assume is 5 seconds). In other words, all the media_players are probably doing a burst of requests on some 5 second refresh which we rate limit on the burst.
On another note, I’m looking for brave people to try the dev build of 1.0.0 with breaking config changes. Basically, we’re preparing this for HA submission. It has some bug fixes and multi-account support so far, but it may break at any time as I work on features. 
Whenever I need the the state of sensor.last_alexa (from alexa_remote_control.sh) I always first use the update_entity service on that sensor because my scan_interval for that sensor is set very high in configuration.yaml in an attempt to extend its cookie life.
So in other words, if I ask Alexa, “Are the garage doors open”? This triggers my HA script that first updates sensor.last_alexa before HA responds back to the media player identified in sensor.last_alexa.
This may be a dumb question, but is it conceivable that the last_called attribute on the amazon media_players of this component would be updated more quickly if the update_entity service was used on the group of alexa media players such as group.amazon_echo (which is what my group is called)?
this is insane. if you read this topic back youll see there are a lot of reports that have constant warnings in the log, saying that the mediaplayer took over 10 secs.
i think something like this should be configurable with an advise to keep it as low as needed.
i am not a big fan of this, because i am afraid that at some point amazon will see this as a problem and take care of it, with the result that noone can use this anymore. (including me)
please realise that you are doing something that is not supported, dont make it unwanted.
I’d be actually surprised if the cookie life is impacted by the number of calls directly. Last I checked the cookie was set to some ridiculously long time frame on the client side which normally governs expiration. However, it’s Amazon’s call on when to force expire the cookie, but I suspect it’s more likely tied to Amazon’s API changes or if they detect something funky with your account (like excessive logins, etc.).
I don’t think updating the group matters. Right now, whenever a media_player refreshes, it hits the main AlexaAPI that reports the activity history to identify the last serial number called and checks if it is that serial number. I just realized that this call is actually ungated by the rate limiter and we probably need to get it behind the rate limiter or someone with 15 devices will probably clobber the API.
The ‘update is taking longer than 10 secs’ error is probably not related to the rate limiter. There’s probably some code cleanup needed to fix the 10 secs error. However, as I mentioned earlier, it’s probably not being hit because it’s designed as an additional limit on the homeassistant media_player poll interval. The setting can be changed though by changing
self.update_devices(no_throttle=True)
to
self.update_devices(no_throttle=False)
This will set it to 15 seconds. I actually did that in the dev build I’m working on because I agree with you that it should probably be dialed back.
I have to regenerate a cookie roughly every 2 weeks when using alexa_remote_control.sh. …but yeah I set a scan_interval so high it never updates until I call the update_entity service in an attempt to stop the cookie from expiring every 2 weeks. It didn’t increase cookie life, but it works well for me to just update it when I need it with no delay to speak of.
the problem is that noone else does that.
from the start i did point people to the mediaplayer because it did create an easy way to for them to setup TTS. but the mediaplayer function is a high risk for all that use the TTS functions (and all other functions) because of the high scanning rate.
i think it would be very much more usefull if the component would go to a direction, where that what is available is usable without excessive contact with the amazon servers.
i got input sliders to set the volume, i got switches to start some radio, i got a last alexa sensor, thats almost always accurate but at least when i need it (because of the way i use it)
but everything based on a single call to the amazon servers.
hundreds or even thousands of people calling the servers every second for each device they own, is just asking for a reaktion from amazon.
even a default from every 15 secs is already questionable if the amount of people that use it starts rising.
please consider to go with this component into a direction to give commands to alexa instead of such a high rate of polling to keep HA up to date with the state alexa devices are into.
As I mentioned, I’m working on helping address the rate issues with the code and typically my changes are being accepted so it’d become the new default. Also, this is a limiter on top of HA. We are also working with the HA ecosystem so update_interval options are already there from HA.
However, what you’re proposing is essentially that we just delete the media player component and refer people to the script version so they can run a command when they want info or commands. It also suggests I should just stop trying to help port this for official HA inclusion since when it’s an official component, the use will further increase. Frankly, since I’m just trying to help, that would be easier for me overall as I’m happy keeping my own internal build that fixes the issues I run into. But unfortunately the code is public and nothing would stop someone else from doing it.
Also, I think you realize that HA is basically using unofficial APIs left and right. If you’re not comfortable with that trend, then you have a much bigger target there.
no, thats not what i propose at all.
and i am sorry if it seems like i am saying that.
what i propose is to change the component so that it has more easy accesible services, and that its communicated to the users that the mediaplayer component is there but that it has big disadvantages.
that if they use it they should use it for say max 1 device or so.
instead of adding the last used alexa as attribute to the mediaplayers, give a service that calls for the last alexa at the moment that its needed.
that would be a) more relaiable, and b) would have less impact.
dont add all alexa devices by default and give people the option to exclude and include, but only add those devices that are added in the config.
make people aware of what they are using and the risks ( i think i said already over 100 times to people that they need to realise its a hack, place that in capitals at the top from every place where people get it)
do everything that can be done to keep the traffic to amazon at a minimum.
and yeah i know that HA uses a lot of unofficial APIs, but almost all of them are not targeting a server from the component. and a few that did so in the past already are deleted, because the other party created restrictions.
there is no problem with using unofficial APIs, but for sure those who develope should be aware that they themselve can be the cause that those APIs can stop being available at some point, when they cause an overload to third party servers.
Just to add my thoughts having been using this and the script for a while now…
I think this component is fantastic, it greatly reduces the entry barrier for people who want to do this because it simplifies the whole messy authentication process compared to other methods, and integrates with HA in a way thats immediately recognisable and consumable for users with less development/integration experience.
I’ve got both this and the script running currently, and both are using ‘unofficial APIs’ (I don’t think it’s right to describe it as a hack), as are many other integrated devices.
Sure there are some downsides to the media player, and perhaps a little more user configurable options wouldn’t go amiss - but this is a ‘beta’ component thats developed very quickly, and these things will come with maturity.
What was started by keatontaylor, moving from node to python, and continued by the community with considerable effort from alandtse has opened up real avenues of home automation in many ways that wasn’t possible for other people.
The team working on this should be applauded and I really do hope they continue the great work, and result in this being an official component in HA. Sure there might need to be a few design alterations along the way, what software component doesn’t…
Lets all continue to work together to polish up the loose ends to ensure all the hard work on this results in a thoroughly deserved official component.
5 Likes
thats why i applauded from the start
and thats what we dont need to forget.
when 1000 people use it (because it is made easy) and it stays like this with 1 sec calls
and those people have on average 3 devices
we are talking about 260.000.000 calls to the amazon servers every day.
and only changing 1 sec to 2 secs reduces the load from the unofficial API use with 130.000.000 calls a day.
with an amount of calls that high, its only waiting for a response. (dont forget that there are others out there using the script too, so the actual amount would be even higher)
for most people the TTS part is the most valuable part from this component.
maybe together with some other possible services.
disconnect that from the mediaplayer and it could save millions of calls daily.
at this point everyone who want easy access to the tts service needs to add all their devices to the mediaplayer list to be able to use it. and that adds a shitload of calls that are unneccesary.
1 Like
First, the hard cap was likely never hit in practice because the default for media_player refresh is 15 seconds so stating its every second is disingenuous.
Second, I filed an issue to resolve this because I understand your concern given the default state of a media player is idle. I put together a dev version last night which ceases polling on non-playing media_players and am working on an update today that also allows a newly detect last_called media_player to begin polling for a short interval or until idle. Unfortunately, while I hook into everything we have in this system to resume the polling, there will be gaps in our ability to figure out when an Alexa is back in use.
Third, if this gets accepted as the next version, there will be a lot of complaints about how media players stop updating after some period of time. I hope you’ll be helping to explain why it changed when that happens.
then i need to make an excuse, i did misunderstand your reaction a bit back and thought it was default set to 1.
i am glad that you take it serious, because i am sure that it will make the time that we can enjoy it longer.
i know that making a working mediaplayer will be hard without polling.
and i know its hard to create services in HA without creating entities.
allthough, the google TTS can be created also without a mediaplayer, so maybe explore that path.
off course i will still help answering questions here, and i am absolutely willing to make people aware that if we want to keep the TTS from alexa as long as possible, that the mediaplayer is risking that.
and finally i want to say that i really appreciate your efford. i dont use it but i still am glad that you are working on it!
I have to regenerate a cookie roughly every 2 weeks when using alexa_remote_control.sh. …
I’m not sure if you tried it but there are a few RM lines in alexa_remote_control.sh that were deleting the cookies and devicelist files… I removed those and get much more life out of the cookie.
I’m currently using both methods for some of my TTS routines just to help keep both alive and to determine which one lasts longer… as someone mentioned above the cookies expiration may be coming from amazon directly as the last two times I had to redo them they both expired at the the same time.
1 Like
I have no idea what is going in … installed the py component …. create the configuration.yaml changes as per the guide … rebooted the Hass.IO device and nothing appears in the overview. I don’t get the captcha request either.
Below is what appears in my logs …
2019-02-04 15:17:11 WARNING (MainThread) [homeassistant.loader] You are using a custom component for media_player.alexa which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-02-04 15:17:47 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/urllib3/connection.py”, line 159, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw)
File “/usr/local/lib/python3.6/site-packages/urllib3/util/connection.py”, line 80, in create_connection
raise err
File “/usr/local/lib/python3.6/site-packages/urllib3/util/connection.py”, line 70, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 600, in urlopen
chunked=chunked)
File “/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 354, in _make_request
conn.request(method, url, **httplib_request_kw)
File “/usr/local/lib/python3.6/http/client.py”, line 1239, in request
self._send_request(method, url, body, headers, encode_chunked)
File “/usr/local/lib/python3.6/http/client.py”, line 1285, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File “/usr/local/lib/python3.6/http/client.py”, line 1234, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File “/usr/local/lib/python3.6/http/client.py”, line 1026, in _send_output
self.send(msg)
File “/usr/local/lib/python3.6/http/client.py”, line 964, in send
self.connect()
File “/usr/local/lib/python3.6/site-packages/urllib3/connection.py”, line 181, in connect
conn = self._new_conn()
File “/usr/local/lib/python3.6/site-packages/urllib3/connection.py”, line 168, in _new_conn
self, “Failed to establish a new connection: %s” % e)
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x6f4c56d0>: Failed to establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/requests/adapters.py”, line 449, in send
timeout=timeout
File “/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 638, in urlopen
_stacktrace=sys.exc_info()[2])
File “/usr/local/lib/python3.6/site-packages/urllib3/util/retry.py”, line 398, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host=‘192.168.1.161’, port=8060): Max retries exceeded with url: /query/device-info (Caused by NewConnectionError(’<urllib3.connection.HTTPConnection object at 0x6f4c56d0>: Failed to establish a new connection: [Errno 111] Connection refused’,))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/roku.py”, line 56, in roku_discovered
CONF_HOST: info[‘host’]
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/roku.py”, line 105, in _setup_roku
r_info = roku.device_info
File “/usr/local/lib/python3.6/site-packages/roku/core.py”, line 213, in device_info
resp = self._get(’/query/device-info’)
File “/usr/local/lib/python3.6/site-packages/roku/core.py”, line 172, in _get
return self._call(‘GET’, path, *args, **kwargs)
File “/usr/local/lib/python3.6/site-packages/roku/core.py”, line 189, in _call
resp = func(url, *args, **kwargs)
File “/usr/local/lib/python3.6/site-packages/requests/sessions.py”, line 546, in get
return self.request(‘GET’, url, **kwargs)
File “/usr/local/lib/python3.6/site-packages/requests/sessions.py”, line 533, in request
resp = self.send(prep, **send_kwargs)
File “/usr/local/lib/python3.6/site-packages/requests/sessions.py”, line 646, in send
r = adapter.send(request, **kwargs)
File “/usr/local/lib/python3.6/site-packages/requests/adapters.py”, line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host=‘192.168.1.161’, port=8060): Max retries exceeded with url: /query/device-info (Caused by NewConnectionError(’<urllib3.connection.HTTPConnection object at 0x6f4c56d0>: Failed to establish a new connection: [Errno 111] Connection refused’,))