LBS19000809 - Alexa Control

[jonofe]

Alexa Control LBS - Update v1.6

Diese Version ist notwendig, wenn der Alexa Smarthome LBS zukünftig das auslösende Echo Device signalisieren soll. Damit sind dann grundsätzlich alle Smarthome Kommandos so konfigurierbar, dass der gleiche Befehl bei unterschiedlichen Echo-Devices unterschiedliche Reaktionen auslöst,

Bsp:

Gibt man den Sprachbefehl "Alexa, schalte das Licht ein" an den Echo im Wohnzimmer, dann wird das Wohnzimmerlicht eingeschaltet. Gibt man denselben Befehl an den Echo in der Küche, wird das Küchenlicht eingeschaltet.

Wie gesagt, das Update des Alexa Control LBS (19000809) auf v1.6 ist nur die notwendige Bedingung, damit dies bald funktioniert. Die hinreichende Bedingung liefert das nächste Update des Smarthome Skill LBS (19001200), welches bald folgt.

Die Funktion des Updates kann man prüfen, in dem man nach dem Start des LBS auf dem EDOMI Server prüft, ob es ein neues File /tmp/.echos.inc.php gibt und ob der Inhalt die verschiedenen Echo Device IDs, Echo Namen und einige Config-Daten des LBS enthält (cookiefile, amazon und alexa Adressen, sowie den UserAgent String). Wenn dies der Fall ist, dann ist alles okay.

Außerdem wurden die Curl-Aufrufe angepasst und die SSL certificate checks aktiviert und das Timing der Abfragen optimiert. Bislang konnte es sein, dass der Start einen TuneIn Senders nicht funktionierte, weil die Statusabfrage zu schnell auf den TuneIn Call folgt. Dies war insbesondere beim Echo 2. Generation der Fall.
Ggf. müssen die SSL Stammzertifikate geupdated werden (siehe Hilfstext des LBS).

[jonofe]

Du könntest einfach Links auf das .alexa.cookie anlegen:

cd /tmp
ln -s .alexa.cookie .alexa-[B][COLOR=#FF0000]<ID>[/COLOR][/B].cookie

<ID> einfach durch die ID des Alexa-Control-LBS ersetzen. Das musst du dann nur einmalig machen und danach nur noch das Skript starten, welches dann die .alexa.cookie erneuert.

[eXec]

wget https://loetzimmer.de/patches/alexa_remote_control_plain.sh
chmod 755 alexa_remote_control_plain.sh

cd /tmp
cp .alexa.cookie .alexa-{LBS-ID}.cookie

Hi jonofe


bestimmt gibt es eine Möglichkeit die beiden Befehle als eine Art CRON-Job oder so etwas ablaufen zu lassen, oder?
Bei mir hat sich nun auch wieder der Cookie verabschiedet, aber durch Ausführen vom alexa_control_plain.sh und anschließendem Kopieren/Ersetzen der Cookies konnte dies behoben werden.

Deswegen die Frage, kann man das scripten und sei es nur manuell startbar, damit ich nicht jedes Copy/Paste für alle Geräte einzel machen muss? Dafür bin ich nicht Linux fir genug, aber für dich bestimmt kein Ding.

Grüße Andre

[sepplo815]

Ja, leider sicher.
Hatte an einem Tag 4 verschiedene...

[jonofe]

Bist du sicher? Ich war der Meinung die ID ändert sich nur bei neuem pairing. Werde das aber bei mir noch mal testen

[sepplo815]

Sooo....

Hab es jetzt mit einer RasPi zum Laufen bekommen.
Die ID bekomm ich raus und wenn ich die statt der Mac Adresse Eintrage funktioniert alles wunderbar.
Das Problem ist aber, dass sich diese ID immer wieder ändert...
Auch ohne Neustart des Echo oder so, die ist immer wieder eine andere...

Hmmm...
Seppl

[sepplo815]

jetzt bekomme ich das

bluetooth devices for dev:Lounge type:A7WXQPH584YP serial:G2A0RF03745604D0:
error: Invalid character
.bluetoothStates[] | select(.deviceSerialNumber == $serial) | "\(.pairedDeviceList[]?.address) \(.pairedDeviceList[]?.friendlyName)"
                                                                                    ^
error: Invalid character
.bluetoothStates[] | select(.deviceSerialNumber == $serial) | "\(.pairedDeviceList[]?.address) \(.pairedDeviceList[]?.friendlyName)"

[jonofe]

dann mach mal

yum install epel-release -y
yum install jq -y

und ein

chmod 755 alexa_remote_control*.sh

Danach sollte es so funktionieren: (statt sh verwende ./ am Anfang des Befehls)

./alexa_remote_control.sh -d Lounge -b list

[sepplo815]

leider nein

[root@edomi tmp]# sh alexa_remote_control.sh -d Lounge -b list
alexa_remote_control.sh: Zeile 452: jq: Kommando nicht gefunden.
alexa_remote_control.sh: Zeile 453: jq: Kommando nicht gefunden.
alexa_remote_control.sh: Zeile 454: jq: Kommando nicht gefunden.
ERROR: unkown device dev:Lounge

[jonofe]

Die curl Version von CentOS 6.5 ist zu alt. MAcht aber nichts. Du kannst im Skript einfach das --http1.1 löschen. Danach sollte es hoffentlich funktionieren.

[sepplo815]

OK - hab ich mal gemacht.
Bekomme die Meldungen:

curl: option --http1.1: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
grep: /tmp/.alexa.header: Datei oder Verzeichnis nicht gefunden
curl: option --http1.1: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
awk: Kommandozeile:1: Fatal: Kann Datei '/tmp/.alexa.cookie' nicht zum Lesen öffnen (Datei oder Verzeichnis nicht gefunden).
curl: option --http1.1: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
grep: /tmp/.alexa.header2: Datei oder Verzeichnis nicht gefunden
ERROR: Amazon Login was unsuccessful. Possibly you get a captcha login screen.
 Try logging in to https://alexa.amazon.de with your browser. In your browser
 make sure to have all Amazon related cookies deleted and Javascript disabled!

Ich glaune die Refferenzierung auf die cURL binary ist falsch.
Ist die schon standardmäßig auf dem EDOMI Server oder muss ich die noch installieren?
Wenn ja, wie? 8-)

[jonofe]

Aber wie soll ich das Skript ausführen?
Am Edomi Server?

Auf dem EDOMI Server.
Du musst im Skript aber vorher deine Amazon Kennung eintragen (genau wie beim LBS).

[sepplo815]

Hi,
habe mir die von dir verlinkte Seite schon durchgelesen…
(trau mich fast nicht fragen)
Aber wie soll ich das Skript ausführen?
Am Edomi Server?
Am Windows (oder Mac) Rechner wird das wohl nicht funktionieren.
Meine Linux Kenntnisse sind leider recht dürftig.

und DANKE für deine schnellen Bemühungen!!!

LG
Seppl

[jonofe]

Ich hatte wohl irgendwie die Generationen von Echo Dot und Echo durcheinandergebracht.
Habe selbst auch einen Echo 2. Generation mit Stoff und konnte das Verhalten nachvollziehen und das Problem auch lösen.
Wenn du auf die Seite mit dem weiter oben verlinkten Skript gehst und dort die Anleitung zu den Bluetooth Befehlen durchliest, dann steht dort, dass es auch sein kann, dass nicht die BT MAC Adresse verwendet wird, sondern eine andere scheinbar zufällig generierte ID. Genau das scheint beim Echo 2. Generation der Fall zu sein. Mit dem Skript, welches du auf dieser Seite downloaden kannst, kann man aber die Liste der verbundenen BT Devices auslesen und damit auch die IDs.

alexa_remote_control.sh -d <Echo-Name> -b list

Bei mir sieht das dann für Dot und Echo so aus (Dot hat den Namen "Andre" und der Echo den Namen "Kueche")

andre@goliath:~$ ./alexa_remote_control.sh -d Andre -b list
bluetooth devices for [B]dev:Andre [/B]type:A3S5BH2HU6V### serial:G090L91072040###:
[COLOR=#00FF00][B]18:D2:76:39:##:##[/B][/COLOR] Mate9
andre@goliath:~$ ./alexa_remote_control.sh -d Kueche -b list
bluetooth devices for [B]dev:Kueche [/B]type:A7WXQPH58### serial:G2A0P30774140###:
[COLOR=#FF0000][B]975997198670 [/B][/COLOR]Mate9

Wenn ich nun den roten Code an E31 meines LBS verwende, dann funktioniert es auch mit dem Echo 2. Generation.
Bei Gelegenheit schaue ich mir das Skript noch mal an und versuche den LBS um die Liste der verbundenen BT Devices zu ergänzen.

[jonofe]

Nein, im Moment leider nicht, allerdings wird an einer Stelle im Code nach "deviceType" gefiltert, welcher bisher ECHO (Echo, Echo Dot), WHA (Echo Group), ROOK (Echo Show) oder KNIGHT (Echo Spot) sein konnte. Evtl. wurde ein neuer deviceType für den Echo mit Stoff eingeführt?
Du könntest die Zeil 1329

// logging($id,'Devices JSON: '.$content); 

mal wieder einkommentieren und dann noch mal testen. Dann müssten die RAW Datein eigentlich im Log stehen, inkl. eines möglichen neuen DeviceTypes.