Mine is still working fine… what happens when you Run ./alexa_remote_control.sh -d “My Dot Name” -e speak:This_is_a_test! From the command line
Those log were what I got from ssh command line 
Today not working at all. o.O’ cookie expire even I sign-in and download new cookie.txt and replace.
This looks like a great tool but I’m having problems. Seems that the cookie is always expired. Downloaded and copied from both Chrome and Firefox, and can’t get past the first check ./alexa_remote_control.sh -a.
This would have been great for my new Ring Doorbell and being able to have a chime or a message to notify that someone is here. A much-needed feature that Ring left out of their Alexa skill. 
Hopefully a fix can be found soon.
Noob here. How do I make the .sh file become executable on hassio?
It’s ok now… Managed to solved it!
Have you managed to solve the problem?
I just got everything setup today and encountered the same problem as you.
Access-Control-Allow-Origin: https://alexa.amazon.com
Content-Encoding: deflate
Vary: Origin
Access-Control-Expose-Headers: x-amzn-dat-gui-client-upgrade,X-Amzn-Error,loginUrl,X-Amzn -RequestId,x-amzn-alt-domain,Date,Location
Access-Control-Allow-Credentials: true
Date: Sun, 19 Aug 2018 09:30:01 GMT
Connection: closeThank you, it’s solved after couple of days re-doing the steps. Not sure what caused that.
Not quite sure myself. I think it has to do with file permissions(?).
This is the way I’m doing it on my hassbian on RPi3, not necessary the only way or perfect, I still need to re-do this every couple days:
On my windows PC, login to alexa.amazon.com (log out first if needed, don’t check the Keep me signed in box)
Copy the cookie.txt to RPi3, /www folder, I reuse the .alexa.cookie below.
ls -al .alexa*
-rwxrwxr-x 1 root root 2898 Aug 19 16:41 .alexa.cookie
I run this set of commands when HA starts:
- service: shell_command.run_sudo
data_template:
cmdline: “cp /home/homeassistant/.homeassistant/www/.alexa.cookie /tmp”
I can test at the ssh shell with
sudo cp //www/.alexa.cookie /tmp && sh //www/alexa_remote_control.sh -a
device list does not exist. downloading ...
the following devices exist in your account:
Living room Echo
Ground floor
ls -al /tmp/.alexa*
-rwxr-xr-x 1 root root 2898 Aug 19 16:42 /tmp/.alexa.cookie
-rw-r–r-- 1 pi pi 6546 Aug 19 16:42 /tmp/.alexa.devicelist.json
In HA, I use a simple script to tts:
tts_alexa_say:
sequence:
- service: shell_command.run_sudo
data_template:
cmdline: “/usr/bin/aplay -Dhw:0,0 /home/homeassistant/.homeassistant/www/sound/Text-tone.wav”
- service: mqtt.publish
data_template:
topic: “tts/tone”
payload_template: “Play”
retain: true
- service: shell_command.run_sudo
data_template:
cmdline: sh /home/homeassistant/.homeassistant/www/alexa_remote_control.sh -d “{{alexa}}” {{alexa_cmd}}"{{tts_say}}"
Hope this helps
Thanks!
I will give it a try.
I gave this a try tonight. I was able to get the cookies copied over and had the script pulled back the device list. When I tried a sample speak command from the command line it shows the following:
root@homeassistant-76-1:/config# ./alexa_remote_control.sh -d "Bedroom Echo Dot" -e speak:test
sending cmd:speak:test to dev:Bedroom Echo Dot type:REDACTED serial:type:REDACTED customerid:type:REDACTED
Sequence command: Alexa.Speak
Nothing is spoken from the device. I logged into the Alexa portal and the History is empty, too. I tried the alexa_remote_control_plain.sh as well with the same results. Any idea what I’m doing wrong?
I’ve tried the cookies.txt thing from both Chrome and Firefox. They seem to be working since I was able to pull the device list.
try a longer test and different devices.
when it doesnt work try pulling the devicelist again.
remember that the device is capital sensitive.
sometimes a text just dissapears in my case.
i send most of my texts to 6 devices. (from the 7 i own)
and sometimes it reaches only 4 or 5
Yeah, I’ve tried all of this. If the device name is incorrect, you get a message saying device not found. I’ve tried long and short messges. I’ve tried sending with 3 different Echo devices with no success. I’ve deleted all the /tmp/ files and tried this 3 times now.
I managed to figure out my problem, and I believe this is a bug in the script. I turned on a trace of the curl command that the script was sending and found that it was returning a HTTP 400 Bad Request response from Amazon. Further investigation showed that the customerId on the payload was not correct. After inspecting the .alexa.devicelist.json file, I was able find my correct customerId associated to a one of my devices. I went into the script and hardcoded the payload to use my customer Id, and now all is working.
So, I believe this is a bug in the script. I suspect what is happening is that Amazon is returning the customerId of whoever’s account is associated with the device at the time you run this script’s setup. My wife and I switch accounts on Echo devices all the time, so her customerId is on a lot my devices. This script tries to use that customerId in the request and it fails. I believe the script needs to always use the customerId of whoever did the signin/cookie stuff.
2 Likes
thats obvious.
but there is no easy way to retrieve the id from the cookie i think.
so i dont think its a bug, more a complication.
but you found a good workaround.
I’m not sure why you are defending the script as-is. There is always room for improvements. You can call it what you want - bug, complication, defect - regardless - it’s a problem with the script and won’t work with all users out there. You are incorrect about it not being easy to get the customer id. The script is already calling the REST API /api/bootstrap which returns the customerId of the logged in user. It shouldn’t be hard to fix the script to add this change. It doesn’t look like the original author put this on github, so the hardest part to get this fixed might be to communicate this change to the author.
im not defending the script.
but i dont call things like this a bug or a defect, i dont see it as a problem either. in my eyes its nothing more then obvious that you cant communicate with a device that is in use by another person.
i think its buggy that you find it possible that you can communicate with that device.
so what you call a fix is in my eyes adding the use of a bug.
there is always room to add new options off course.
ithe api return the logged on user first after you have send a command. so the first command will always fail for a device that is in use for another user in my eyes. unless you add the userid to the script like you did.
its not hard to communicate with the author. go to his page and you can leave comments there.
I also have the issue where I sometimes need to log back in and save the cookie again… not really consistent sometimes 2 weeks sometimes a few days… but when looking at it tonight I found that line 755 of the alexa_remote_control.sh has 3 rm lines removing the cookies and device lists as part of the log off sequence… I commented out those 3 lines… so we will see what happens.