LBS19000809 - Alexa Control

[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

[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.

[jonofe]

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

[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]

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]

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

[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]

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.

[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?

[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!

[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.

[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.

[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.

[Lapheus]

Im Lötzimmer Script werden auch die FireTV Sticks mit ausgegeben. Über den SPEAK Befehl kann man da auch Durchsagen generieren.
Über A14 werden die im Baustein nicht ausgegeben. werden die herausgefiltert?

[jonofe]

Eigentlich werden so wie im Lötzimmer Skript alle Devices der Devicefamily ECHO, WHA, ROOK, KNIGHT berücksichtigt.
Im Lötzimmer Skript sehe ich auch keine weitere Devicefamily.
Daher ist die Antwort, nein sie werden nicht explizit ausgefiltert, aber ich weiß auch nicht, wie sie in der Device List auftauchen, da ich selbst kein FireTV besitze.
Fehlen die denn nur an A14? Kannst du sie denn per LBS ansteuern?