LBS19000809 - Alexa Control

[jonofe]

Muss denn an A43 der User-Agent-String mit vorangestelltem Attributnamen "User-Agent" angegeben werden oder nur der eigentliche User-Agent-String?

Das ist in der Tat ein valider Punkt. Der Attributname sollte nicht enthalten sein.
Vielleicht ist das ja schon das Problem.
Haben alle, die mit dem Speak Probleme hatten den Defaultwert verwendet, bzw. User-Agent: vorangestellt?

Ich habe das jetzt im LBS mal angepasst.

[jonofe]

Ich habe bislang gute Erfahrung damit gemacht, den User-Agent String meines Chrome Browsers zu verwenden, mit dem ich mich auch auf alexa.amazon.de einlogge. Das ein User-Agent allerdings bei den Grundfunktionen funktioniert und beim Speak nicht, habe ich bislang auch noch nicht erlebt.

[Glotzkowski]

Muss denn an A43 der User-Agent-String mit vorangestelltem Attributnamen "User-Agent" angegeben werden oder nur der eigentliche User-Agent-String?
Als Init-Wert im LBS ist

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0

definiert.

In der Hilfe des LBS ist die Rede davon, dass das Ändern des Strings eine möglich Lösung bei Problemen mit den Cookies sein könnte.
Führt dies jemand regelmäßig durch?
Ich hatte bisher immer mit dem Init-Wert an A43 gearbeitet, also kein iKO dran gebunden oder den Init-Wert verändert, dies werde ich nun ändern.

[Glotzkowski]

Frohe Weihnachten!

Ich hatte bis jetzt nichts hierzu beigetragen aber das Problem auch bei mir festgestellt und kann das Verhalten nachvollziehen bzw. bestätigen.
Danke!

[Lapheus]

Hallo zusammen,

Frohe Weihnachten!

Ich habe es gefunden!
Es hängt (vermutlich) mit dem User Agenten zusammen. Wenn ich den User Agenten am E43 fest auf den Wert "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:1.0) bash-script/1.0" (wie im Lötzimmer Scipt) setze, funktioniert es nach einem Neustart oder einer Projetaktivierung nicht! Setze ich E43 jetzt im Livemonitor noch einmal, und benutze E42 oder E44 funktioniert es.

Kann das mal jemand der anderen Betroffenen nachvollziehen?

[Lapheus]

Hab es jetzt mal wie folgt zusammengebaut:

Aus dem Lötzimmer Script den CURL Aufruf raus genommen und alle Variablen ersetzt.

/usr/bin/curl --compressed -s -b /tmp/.alexa.cookie -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:1.0) bash-script/1.0" -H "DNT: 1" -H "Connection: keep-alive" -L -H "Content-Type: application/json; charset=UTF-8" -H "Referer: https://alexa.amazon.de/spa/index.html" -H "Origin: https://alexa.amazon.de" -H "csrf: CSRF_WERTAUS/tmp/.alexa.cookie" -X POST -d @"/tmp/.alexatest.cmd" "https://alexa.amazon.de/api/behaviors/preview"

Im /tmp/.alexatest.cmd Datei habe ich aus dem Baustein Log alles hinter Speak POST Data-1: eingetragen.

Jetzt spricht Alexa
Wenn ich den entsprechenden Wert im alexatest.cmd ändere spricht sie auch dementsprechend.

[jonofe]

Dann liefert der CURL Call einen HTTP-Code != 200 zurück. Warum kann ich leider nicht sagen.

Ich habe mir nochmal den Unterschied des JSONs angeschaut.
Beim Lötzimmer Skript kann man eine separate Speak Lautstärke einstellen, d.h. das 'längere' JSON macht

1. Setzen Speak-Lautstärke (SPEAKVOL)
2. Sprachausgabe
3. Setzen der (NORMALVOL)

Der LBS macht nur Schritt 2 (Sprachausgabe).

[Lapheus]

Bis einschließlich Volume geht es, dann kommt beim Speak befehl sofort ERROR auf A1.

[jonofe]

wie müsste ein direkter CURL Aufruf lauten mit dem "Speak POST Data-1:" Teil aus dem Log
(Sorry, aus dem ganzen Parametern im Sciptblog bekomme ich das auf die schnelle nicht rausgelesen)

Das geht mir genauso. Ich bin froh, dass ich das ganze in PHP-CURL übersetzt bekommen habe.

das hier hast du gelesen: Code:

# Due to some weird shell-escape-behavior the command has to be written to a file before POSTing it echo $ALEXACMD > "${TMP}/.alexa.cmd"

Das ist hier nicht relevant, da curl ja nicht in der Shell ausgeführt wird, sondern php-curl verwendet wird.

Was du mal versuchen könntest:

• Zuerst einen Radiosender abspielen,
• dann Volume auf 40 stellen
• und dann einen Speak Befehl absetzen.

[Lapheus]

Hmm, einige Fragen

• im Lötzimmer Scipt wird auf die Lautstärke verwiesen:
  

  # the speak command is treated differently in that the wolume gets set to $SPEAKVOL

  Das machst Du nicht oder?
• wie müsste ein direkter CURL Aufruf lauten mit dem "Speak POST Data-1:" Teil aus dem Log
  (Sorry, aus dem ganzen Parametern im Sciptblog bekomme ich das auf die schnelle nicht rausgelesen)

Ergänzung:

das hier hast du gelesen:

# Due to some weird shell-escape-behavior the command has to be written to a file before POSTing it
  echo $ALEXACMD > "${TMP}/.alexa.cmd"

Ergänzung die 2te:

Aus dem Logfile des Bausteins:

{
    "behaviorId": "PREVIEW",
    "sequenceJson": "{\"@type\":\"com.amazon.alexa.behaviors.model.Sequence\",\"startNode\":{\"@type\":\"com.amazon.alexa.behaviors.model.OpaquePayloadOperationNode\",\"type\":\"Alexa.Speak\",\"operationPayload\":{\"deviceType\":\"Typenbezeichnugn",\"deviceSerialNumber\":\"SerienNR\",\"locale\":\"de,en-US;q=0.7,en;q=0.3\",\"customerId\":\"BenutzerID\",\"textToSpeak\":\"Es_hat_geklingelt\"}}}",
    "status": "ENABLED"
}

Aus dem /tmp//.alexa.cmd File:

{
    "behaviorId": "PREVIEW",
    "sequenceJson": "{\"@type\":\"com.amazon.alexa.behaviors.model.Sequence\",\"startNode\":{\"@type\":\"com.amazon.alexa.behaviors.model.SerialNode\",\"nodesToExecute\":[{\"@type\":\"com.amazon.alexa.behaviors.model.OpaquePayloadOperationNode\",\"type\":\"Alexa.DeviceControls.Volume\",\"operationPayload\":{\"deviceType\":\"Typenbezeichnugn",\"deviceSerialNumber\":\"SerienNR\",\"customerId\":\"BenutzerID\",\"locale\":\"de-DE\",\"value\":\"40\"}},{\"@type\":\"com.amazon.alexa.behaviors.model.OpaquePayloadOperationNode\",\"type\":\"Alexa.Speak\",\"operationPayload\":{\"deviceType\":\"Typenbezeichnugn",\"deviceSerialNumber\":\"SerienNR\",\"customerId\":\"BenutzerID\",\"locale\":\"de-DE\",\"textToSpeak\":\"Es hat geklingelt\"}},{\"@type\":\"com.amazon.alexa.behaviors.model.OpaquePayloadOperationNode\",\"type\":\"Alexa.DeviceControls.Volume\",\"operationPayload\":{\"deviceType\":\"Typenbezeichnugn",\"deviceSerialNumber\":\"SerienNR\",\"customerId\":\"BenutzerID\",\"locale\":\"de-DE\",\"value\":\"13\"}}]}}",
    "status": "ENABLED"
}

Da wird also einiges mehr geschickt...

[jonofe]

Wenn das Lötzimmerskript, welches ja auch curl verwendet, auf dem EDOMI-Server funktioniert, dann hab ich jetzt keine Idee mehr.

[jonofe]

CentOS release 6.5 (Final)

Wenn Du CentOS 6.5 hast, dann ist doch kalr, dass alles anders ist, als bei mir.
Ich habe das aktuelle CentOS7 und darauf EDOMI 2.0 installiert.

[Lapheus]

Du könntest noch mal die Version von CentOS, PHP, Curl posten. Und die Einstellung der cacerts für curl.

Bei mir sieht es so aus:

[root@edomi ~]# cat /etc/redhat-release
[COLOR=#FF0000][B]CentOS Linux release 7.6.1810 (Core)[/B][/COLOR]
[root@edomi ~]# php -v
[COLOR=#FF0000][B]PHP 7.2.25 (cli) (built: Nov 20 2019 17:44:37) ( NTS )[/B][/COLOR]
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
[root@edomi ~]# curl -V
[COLOR=#FF0000][B]curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3 [/B][/COLOR]
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets

[ThorstenGehrig]

Hm,
bei mir siehts so aus:
CentOS release 6.5 (Final)

Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

curl 7.66.0 (x86_64-redhat-linux-gnu) libcurl/7.66.0 OpenSSL/1.0.1e-fips zlib/1.2.3 c-ares/1.15.0 libssh2/1.8.2 nghttp2/1.6.0
Release-Date: 2019-09-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB SPNEGO SSL UnixSockets

Dabei habe ich doch ein offizielles Edomi upgrade.
Hast du dein EDOMI auf einer eigeninstallation von CentOS?

Gruß
Thorsten

[jonofe]

Du könntest noch mal die Version von CentOS, PHP, Curl posten. Und die Einstellung der cacerts für curl.

Bei mir sieht das so aus:

[root@edomi ~]# [I][B][COLOR=#0000CD]cat /etc/redhat-release[/COLOR][/B][/I]
[COLOR=#FF0000][B]CentOS Linux release 7.7.1908 (Core)[/B][/COLOR]
[root@edomi ~]# [I][COLOR=#0000CD][B]php -v[/B][/COLOR][/I]
[COLOR=#FF0000][B]PHP 7.2.24 (cli) (built: Oct 22 2019 11:15:01) ( NTS )[/B][/COLOR]
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
[root@edomi ~]# [COLOR=#0000CD][I][B]curl -V[/B][/I][/COLOR]
[COLOR=#FF0000][B]curl 7.67.0 (x86_64-redhat-linux-gnu) libcurl/7.67.0 NSS/3.44 zlib/1.2.7 libpsl/0.7.0 (+libicu/50.1.2) libssh2/1.9.0 nghttp2/1.31.1
Release-Date: 2019-11-06[/B][/COLOR]
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL UnixSockets