Strange feedback, seems ok, but no result

[Ezeta31]

Everything was working well, but since some times, the script was not working.
I had a look and sens it fail because cookie expired and a captcha was required. So I made an update of the cookie and the error has gone... but commands seems to have no effect: my device have no reaction.

I have the following feedback in the console:

sending cmd:speak:test test test to dev:Echo Salon type:*************
serial:********************** customerid:*********************
Sequence command: Alexa.Speak
HTTP/1.1 0 x-amzn-RequestId: f6ddf25f-2d68-11e9-bfd6-a39ce45b897c
Access-Control-Allow-Origin: https://alexa.amazon.fr
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, 10 Feb 2019 19:20:45 GMT
Connection: close

Do you see something I don't ?

[adn77]

@Ezeta31 regarding the Captcha Login; try setting the LANGUAGE to the exact same string as your browser sends in the Accept-Language header.

Are you using the plain version? I just updated both versions. The strange thing is that I don't get any HTTP response output.
What does your SET_OPTS look like? Or do you have an environment variable $OPTS?

[Ezeta31]

The language is matching.

I use the following options:

SET_EMAIL=''
SET_PASSWORD=''

#SET_LANGUAGE="de,en-US;q=0.7,en;q=0.3"
#SET_LANGUAGE="en-US"
SET_LANGUAGE="fr-FR"

#SET_AMAZON='amazon.de'
#SET_AMAZON='amazon.com'
SET_AMAZON='amazon.fr'

#SET_ALEXA='alexa.amazon.de'
#SET_ALEXA='pitangui.amazon.com'
SET_ALEXA='alexa.amazon.fr'

cURL binary

SET_CURL='/usr/bin/curl'

cURL options

-k : if your cURL cannot verify CA certificates, you'll have to trust any

--compressed : if your cURL was compiled with libz you may use compression

--http1.1 : cURL defaults to HTTP/2 on HTTPS connections if available

SET_OPTS='--compressed --http1.1'
#SET_OPTS='-k --compressed --http1.1'

browser identity

SET_BROWSER='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:1.0) bash-script/1.0'
#SET_BROWSER='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0'

tmp path

SET_TMP="/home/pi/alexa/tmp"

[adn77]

@Ezeta31 try setting the Language to the exact same String as your browser sends in the "Accept-Language:" header - then you might not have to copy the cookie from your browser every time ;)
(Note: this requires your email and password in the script or in the env vars EMAIL/PASSWORD!)

Can you please down load the latest version and try something like
alexa_remote-control.sh -r "bbc 6 music"

And if that works:
alexa_remote-control.sh -e speak:"hello"

[Ezeta31]

I think my first message was confusing: the problem is not the captcha (after refreshing the cookie, it is no more requesting it to me). So this point is ok.
Anyway I checked the language and it is coherent with my browser header accepted language value.

The problem is that the request has no effect (and displays the above text).

I took your last version of the script, and executed your commands, but the result is the exact same one...

Note that the script is able to find my device, but not able to control it.

[adn77]

Can you send any command that works?
What is the output of
curl --version

[Ezeta31]

The commands to list devices (-a) or to see the last used device (-lastalexa) are working well.
But all others are returning the above result.

curl --version is returning 7.52.1

[rudybroersma]

I have the exact same issue as Ezeta31:

• Login works (copied cookies.txt)
• I can get last active device, it sees my device list, etc. Everything seems to work
• Any actual command does nothing

# curl --version
curl 7.52.1 (arm-unknown-linux-gnueabihf) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

# ./alexa_remote_control.sh -e speak:"Hello"
setting default device to:
Living room
sending cmd:speak:Hello to dev:Living room type:A3S5BH2HU6VAYF serial:G090LF1000752ETC customerid:A12D196SG9F9V
HTTP/1.1 0 x-amzn-RequestId: 23ef8f07-32cc-11e9-ac70-856117b76cbc
Access-Control-Allow-Origin: https://alexa.amazon.co.uk
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, 17 Feb 2019 15:53:16 GMT
Connection: close

[adn77]

@rudybroersma @Ezeta31 very good that somebody else can reproduce this 👍

I guess this is some rather obvious thing that I overlooked. Your debugging help is highly appreciated!

The intended behavior is an output like this (note the missing cURL response headers) :

# export EMAIL='me@example.org'
#  export PASSWORD='very_secret'
# ./alexa_remote_control.sh -e speak:"Hello"
setting default device to:
Living room
sending cmd:speak:Hello to dev:Living room type:A3Sxxxxxxxxx serial:G090xxxxxxxxxx customerid:A12xxxxxxxxx 

#

(please anonymize your posts if you didn't already)

Two possible scenarios:

1. the -aand -lastalexacommands grab the stdout of the curl command that's why you don't see anything
2. those commands do something different than the others

Regarding 1.) please have a look at the /tmp./alexa.devicelist.json if you can find any HTTP output besides the JSON {"devices"...}.

One thing that comes to mind about 2.) is that those commands use -X GET while most of the others use a -X POST (HTTP method) for querying the API. There might be an issue with how your cURL handles things.
What is your OS and can you please see if the OPTS variable is empty: echo $OPTS
I assume you didn't change the TMP path.

Please bear with me ... :)

[rudybroersma]

Hi.

• The device list looks alright to me:
  cat /tmp/.alexa.devicelist.json | python -m json.tool
  Prints out a lovely perfectly marked-up array of all the bits and pieces. I see no HTML code anywhere.

• $OPTS is empty

• OS is Raspbian:

# lsb_release  -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.6 (stretch)
Release:        9.6
Codename:       stretch

I can't do any additional debugging now (I'm not with my Alexa devices, so I can't verify that they play anything). But I understand I should not see the HTTP response headers. I'll see if I can do some debugging myself some time this week.

[adn77]

@rudybroersma thank you for the detailed response.
I actually took a Pi and tried there on RasbianLite and it works.
In order to have the same pre-conditions, could you please re-download the script and configure it only through env vars (like I did in the example above).
Please post your vars (except email+password).

[rudybroersma]

Hmm, I found some time to debug this. Tried running the script, but it failed due to missing cookie file. Auto login failed, so I had to do the cookie export from Chrome.

For some strange reason the script now suddenly works. I didn't change anything (did not re-download yet, as you advised)

[bru73f0rc3]

Same exact issue as @Ezeta31
-a and -lastalexa work fine, the rest simply prints out the request and doesn't perform any action.
Running on home assistant docker on QNAP.
script version: v0.11
#curl --version
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2q zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

Examples below are using an Echo Show v2, but it's the same for any device.
#./alexa_remote_control.sh -d 'Office Echo Show' -r "bbc 6 music"
playing stationID:s44491 on dev:Office Echo Show type:AWZXXX serial:XXX mediaownerid:XXX
HTTP/1.1 0 x-amzn-RequestId: cfadfcaa-4781-11e9-8236-XXX
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: Sat, 16 Mar 2019 00:24:07 GMT
Connection: close

#./alexa_remote_control.sh -e speak:"test"
setting default device to:
Office Echo Show
sending cmd:speak:test to dev:Office Echo Show type:AWZXXX serial:XXX customerid:XXX
Sequence command: Alexa.Speak
HTTP/1.1 0 x-amzn-RequestId: b57b548b-4782-11e9-b245-XXX
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: Sat, 16 Mar 2019 00:30:32 GMT
Connection: close

Any ideas?

[adn77]

I know it's been a while... today this happened to me as well.
Looks like Amazon changed the way of where we get the CSRF cookie - please try the again with the latest version.

Alex

[Ezeta31]

Hi, I also had it working again suddenly these last days, without any change on my side... I don't understand why but... great :-)

…

Le 18 juin 2019 à 21:04, Alex ***@***.***> a écrit : I know it's been a while... today this happened to me as well. Looks like Amazon changed the way of where we get the CSRF cookie - please try the again with the latest version. Alex — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Dizzy1985]

Join me .... Have the same problems. Even the version from 18.06 in use. No routines, or radio station, etc. are executed. Devices are recognized by the script and the commands sent. But probably Amazon does not accept them (registration?)

root @ loxberry: / opt / loxberry / data / plugins / alexaremote # ./alexa_remote_control.sh -d Kitchen -e automation: 'Window'
sending cmd: automation: window to dev: kitchen type: xxxxxxxxxx serial: xxxxxxxxcc customerid: xxxxxxcccccc
HTTP / 1.1 0x-amzn-RequestId: d07d0dcd-00a4-4701-acf9-b01601c9fb8e
Access-Control-Allow-Origin: https://alexa.amazon.de
Content encoding: deflate
Vary: Origin
Access-Control-Expose-Headers: x-amzn-dat-gui-client-upgrade, X-Amzn-Error, loginUrl, X-Amzn-RequestId, x-amzn-old-domain, Date, Location
Access-Control-Allow-Credentials: true
Date: Thu, 20 Jun 2019 08:20:34 GMT
Connection: close

[adn77]

I implemented three different ways to download the CSRF now.
Please try latest version (2019-06-28)!

[ghost]

For me i doesnt work too. But i never worked before. I have the newest version.

[mrussell-betbright]

I'm also having the same issue - i did it on my sisters Raspberry PI and it worked great , i copied it exactly to mine from hers when i got home and it didnt work and then without change a few days later her one stopped working as well.

The listing -a works fine and it says its sending rhe info , but nothing happens - any ideas ? has anyone resolved this ?

root@Pi-Nas:/pi-nas-info# curl --version
curl 7.64.0 (arm-unknown-linux-gnueabihf) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

root@Pi-Nas:/pi-nas-info#
root@Pi-Nas:/pi-nas-info#
root@Pi-Nas:/pi-nas-info#
root@Pi-Nas:/pi-nas-info#
root@Pi-Nas:/pi-nas-info# ./alexa_remote_control.sh -a
the following devices exist in your account:
Living room
Everywhere
Kitchen echo
Hall
Kitchen dot
Taz Echo Show
Harsh
Kitchen
This Device
Mark's Alexa Apps

root@Pi-Nas:/pi-nas-info# ./alexa_remote_control.sh -e speak:"Hello"
setting default device to:
Living room
sending cmd:speak:Hello to dev:Living room type:A2M35JJXXXXXXXX serial:G090LA09XXXXXXXX customerid:A1QXXXXXXXXX

root@Pi-Nas:/pi-nas-info#

[Ezeta31]

Still having the same issue here since several years. I abandoned, and it it rarely working (randomly). I hope something more official (And stable) will come out some day... Guillaume PS: Envie de vous détendre et de vous amuser ? Jouez à mon tout nouveau jeu vocal pour Alexa: Miniventura. https://www.amazon.fr/Nutyzeta-Miniventura/dp/B089FLKZCR/ref=sr_1_2?dchild=1&device=mobile&qid=1591775234&rd=1&s=digital-skills&sr=1-2

…

Le 9 sept. 2020 à 15:45, mrussell-betbright ***@***.***> a écrit :  I'm also having the same issue - i did it on my sisters Raspberry PI and it worked great , i copied it exactly to mine from hers when i got home and it didnt work and then without change a few days later her one stopped working as well. The listing -a works fine and it says its sending rhe info , but nothing happens - any ideas ? has anyone resolved this ? ***@***.***:/pi-nas-info# curl --version curl 7.64.0 (arm-unknown-linux-gnueabihf) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3 Release-Date: 2019-02-06 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL ***@***.***:/pi-nas-info# ***@***.***:/pi-nas-info# ***@***.***:/pi-nas-info# ***@***.***:/pi-nas-info# ***@***.***:/pi-nas-info# ./alexa_remote_control.sh -a the following devices exist in your account: Living room Everywhere Kitchen echo Hall Kitchen dot Taz Echo Show Harsh Kitchen This Device Mark's Alexa Apps ***@***.***:/pi-nas-info# ./alexa_remote_control.sh -e speak:"Hello" setting default device to: Living room sending cmd:speak:Hello to dev:Living room type:A2M35JJXXXXXXXX serial:G090LA09XXXXXXXX customerid:A1QXXXXXXXXX ***@***.***:/pi-nas-info# — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[ungerland]

I have this same issue now after a few months of the script working fine using the chrome extension to get the cookies from an incognito window.

-a works but -e speak “hello” does not. It prints sending cmd with the correct ids, but that’s it. I added -v to the curl command and could see that -a returns http 200 back but -e returns 401 Unauthorized with the same cookies. I am in the US and running Mac BigSur. The alexa mobile app works fine.

The browser page at http://alexa.amazon.com in a browser enables viewing but not controlling devices. It seems to me there is a permission you need to control devices that is only returned to the alexa mobile app and is not in the cookie set obtained by the chrome extension.

[xg6968]

I have this same issue :
-a works but -e speak "hello" does not...
Please help me.

[dbochicchio]

It stopped for me and a bunch of users on Vera as well. It seems to be related to Simon Says skills crashing, so announcements are not working, but plain audio is. Other things seems to be unaffected.

[dbochicchio]

So, I've found that while

-e speak:"something" is OK,
-e speak:'something' is not.

there's probably some parsing problem, but I've managed to fix it by replacing double quotes with single quotes in the voice markup, and by using double quote as the container for the message.

[adn77]

@dbochicchio did you test the speak command from a command-line without Vera interfering?

If you're getting a complaint about the SimonSays skill not working, there is very likely something wrong in the SSML.

[dbochicchio]

@adn77 as I've said, I've just swapped double quotes with single quotes, and it started working again. I changed the SSML markup as well, changing the markup as well.

[noureddin212]

Do you have any news ?
I have the same problem with quote or double quote