[37_echodevice] Amazon Echo Modul (nicht Alexa)

Begonnen von michael.winkler, 12 Januar 2018, 18:20:12

Vorheriges Thema - Nächstes Thema

michael.winkler

Zitat von: Abercrombie1892 am 12 März 2018, 14:34:24
danke michael für die hilfe. mit neuem cookie läuft es super.

kann man die readings in dem modul beschleunigen? braucht doch recht lange bis die readings aktuallisiert werden.

mfg.
ja, kann man. Steht alles in der Doku:
https://mwinkler.jimdo.com/smarthome/eigene-module/echodevice

Ich würde den aktuellen Interval von 60 sekunden nicht zu weit absenken.

michael.winkler

Zitat von: adn77 am 12 März 2018, 12:13:58
Hallo Michael,

ich habe als Feedback auf mein Shell Script, dass Amazon "gelegentlich" HTTP/2 einschaltet, was zumindest bei meiner cURL basierten Version zu Problemen führt.
Je nach verwendeter Version der libcurl sollte daher das Protokoll auf HTTP/1.1 festgesetzt werden.

Alex
Laut httputil Doku ist unter Fhem HTTP/1.0 Standard. Werde es aber mal auf 1.1 setzen und testen. Danke für die Info.

michael.winkler

Auf Seite 1 gibt es wieder eine neue Version, mit einigen neuen Features

Viel Spaß beim testen.

Doku wie immer hier:
https://mwinkler.jimdo.com/smarthome/eigene-module/echodevice/


##############################################
#
# 2018-03-13 v0.0.28
#
# v0.0.28
# - CHANGE:  get "Conversations" auf nonBlocking
#            get "tunein" auf nonBlocking & move to Echo Device & play link
#            get "tracks" auf nonBlocking
#            get "devices" auf nonBlocking
#            set "autocreat_devices" auf nonBlocking
#            httpversion = "1.1"
# - FEATURE: get "actions"
#            get "primeplayeigene_albums"
#            get "primeplayeigene_tracks"
#            get "primeplayeigene_artists"
#            get "primeplayeigeneplaylist"
#            get "help"
#            Multiroom add get settings & tunein
# - BUGFIX:  primeplayeigene
#


Gruß
Michael

JoWiemann

Hallo,

ich habe jetzt mal, basierend auf hier: https://forum.iobroker.net/viewtopic.php?f=37&t=9237, 2FA eingebaut.

Unter set gibt es jetzt twofacode. Hier wird der Code eingetragen, der nach dem ersten Anmelden per SMS usw. zugesendet wird. Durch klicken auf set wird dann ein neuer Login mit 2FA Code durchgeführt.

Grüße Jörg

PS: Die Erweiterung habe ich in der aktuellen Version von Seite 1 gemacht. Die geänderten Stellen findet man durch suchen nach twoFA

PS2: Es kann sein, das nach dem set autocreate_devices ein weiterer Login notwendig wird.
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

michael.winkler

Zitat von: JoWiemann am 13 März 2018, 17:41:36
Hallo,

ich habe jetzt mal, basierend auf hier: https://forum.iobroker.net/viewtopic.php?f=37&t=9237, 2FA eingebaut.

Unter set gibt es jetzt twofacode. Hier wird der Code eingetragen, der nach dem ersten Anmelden per SMS usw. zugesendet wird. Durch klicken auf set wird dann ein neuer Login mit 2FA Code durchgeführt.

Grüße Jörg

PS: Die Erweiterung habe ich in der aktuellen Version von Seite 1 gemacht. Die geänderten Stellen findet man durch suchen nach twoFA

PS2: Es kann sein, das nach dem set autocreate_devices ein weiterer Login notwendig wird.
Wäre es nicht sinnvoller dies über ein Attribut zu machen?

Ich würde es kurz Umbauen, und dann auf Seite 1 gleich zur Verfügung stellen.

Wäre super wenn Du das File erstmal wieder rausnimmst. Support und Fehlersuche mit undefinierten Versionsständen ist sehr schwer.

Gruß
Michael

michael.winkler

Auf Seite 1 gibt es wieder eine neue Version, mit einigen neuen Features.

Inkl. 2FA von JoWiedmann
Zitat von: JoWiemann am 13 März 2018, 17:41:36
Hallo,

ich habe jetzt mal, basierend auf hier: https://forum.iobroker.net/viewtopic.php?f=37&t=9237, 2FA eingebaut.

Unter set gibt es jetzt twofacode. Hier wird der Code eingetragen, der nach dem ersten Anmelden per SMS usw. zugesendet wird. Durch klicken auf set wird dann ein neuer Login mit 2FA Code durchgeführt.

Grüße Jörg


PS2: Es kann sein, das nach dem set autocreate_devices ein weiterer Login notwendig wird.
PS: Wäre super wenn mir jemand eine genaue Anleitung zukommen lassen könnte. Dann würde ich diese in die Doku mit aufnehmen.

@JoWiedmann
Muss der Code bei jedem Cookie erzeugen erneut generiert und eingetragen werden, oder muss diese Prozedur nur einmalig ausgeführt werden. Vielleicht kannst Du das Ganze noch etwas beschreiben. Würde jetzt ungerne meinen Account auf 2FA umstellen.

Viel Spaß beim testen.

Doku wie immer hier:
https://mwinkler.jimdo.com/smarthome/eigene-module/echodevice/


##############################################
#
# 2018-03-13 v0.0.29
#
# v0.0.29
# - FEATURE: Zwei Faktor Authentifizierung (set login2FACode) Danke Benutzer JoWiedmann https://forum.fhem.de/index.php/topic,82631.msg780848.html#msg780848
#
# v0.0.28
# - CHANGE:  get "Conversations" auf nonBlocking
#            get "tunein" auf nonBlocking & move to Echo Device & play link
#            get "tracks" auf nonBlocking
#            get "devices" auf nonBlocking
#            set "autocreat_devices" auf nonBlocking
#            httpversion = "1.1"
# - FEATURE: get "actions"
#            get "primeplayeigene_albums"
#            get "primeplayeigene_tracks"
#            get "primeplayeigene_artists"
#            get "primeplayeigeneplaylist"
#            get "help"
#            Multiroom add get settings & tunein
# - BUGFIX:  primeplayeigene
#

Gruß
Michael

JoWiemann

#426
Zitat@JoWiedmann
Muss der Code bei jedem Cookie erzeugen erneut generiert und eingetragen werden, oder muss diese Prozedur nur einmalig ausgeführt werden. Vielleicht kannst Du das Ganze noch etwas beschreiben. Würde jetzt ungerne meinen Account auf 2FA umstellen.

Hm, das habe ich nicht ausprobiert, weil ich heute die Anzahl der Logins nicht übertreiben wollte. Habe keine Lust gehabt, dass mein Account gesperrt wird  ;)

Beschreibung:

Beim jungfreulichen Login nach dem define ... wird ja von Amazon bei 2FA ein Code über den hinterlegten Kommunikationsweg gesendet. Dieser Code ist dann nur eine begrenzte Zeit gültig. Bei "set <device_name> login2FACode <code>" wird der erhaltene Code hinterlegt und dann wird das Logon wiederholt. Hierbei wird der Code einfach an das Passwort angehangen. Danach lösche ich den internen helper wieder.

Beim ersten Test musste ich das Ganze wiederholen, nachdem ich "set <device_name> autocreate_devices" aufgerufen habe. Wie gesagt, ich habe dann nicht weiter getestet, da ich schon 15 Logins in einer Stunde provoziert hatte.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Hallo Michael,

fünf Dinge sind mir noch aufgefallen:

1. Du setzt STATE im Programm und benutzt es auch intern. STATE gehört allerdings dem User und kann such das Attribut stateFormat verändert werden. In diesem Fall funktioniert dann einiges nicht mehr. Ist kein stateFormat definiert wird STATE automatisch auf den Wert des internen Readings state gesetzt.

2. Es wäre schön, wenn die Liste der Set in Abhängigkeit von connected verändert wird. Also bei nicht connected nur Login und login2FACode angezeigt wird.

3. Für das Passwort würde ich auf die Logik von anderen Modulen wie 72_FB_CALLMONITOR umstellen. Damit würde dann eine gewisse Einheitlichkeit innerhalb der Modulwelten existieren.

4. Für Fehlersuche wäre es schön, wenn Du mehr Log3 Einträge, sinnvoll nach Loglevel 1...5, spendieren würdest.

5. Ich persönlich finde es hilfreich, wenn die vom Modul benutzten Attribute auch als solche erkennbar sind. Also für alle im Modul definierten Attribute z.B. ein echo_ voranstellen.

Die Punkte 3 - 5 sind eher persönliche Wünsche. Punkt 1 ist essentiell und Punkt 2 irgendwo dazwischen.

Und zum Schluss: Vielen Dank für das Modul.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

sw

Hallo Michael,

ersteinmal vielen Dank für das schöne Modul.

Ich habe eine Frage bzgl einer möglichen Erweiterung:
Auf http://blog.loetzimmer.de/2017/10/amazon-alexa-hort-auf-die-shell-echo.html ist eine Scriptlösung zur Abfrage und Steuerung der Echo Devices vorgestellt. Nach meinem Verständniss entspricht das ungefähr Deinem Modul.

Es gibt u.a. das Kommando "-lastalexa". Hier wird abgefragt, welches Echo Device (wenn man denn mehrere hat ...) als letztes ein Sprachkommando empfangen hat. Auf https://wennez.wordpress.com/light-on-with-alexa-for-each-room/ wird beschrieben, wie man mit diesem Kommando (bzw. dem Script)  zusammen mit HA-Bridge endlich ein Kommando "Licht"  (als Beispiel) definieren kann (und nicht "Licht Wohnzimmer", "Licht Esszimmer" usw.)

Gibt es eine Chance, eine solche "lastalexa" Abfrage in Deinem Modul zu haben?
Die Abfrage müsste natürlich "live" sein, soll also kein "altes" Reading aus einem Polling Vorgang zurückliefern ...

michael.winkler

Zitat von: sw am 13 März 2018, 20:16:09
Hallo Michael,

ersteinmal vielen Dank für das schöne Modul.

Ich habe eine Frage bzgl einer möglichen Erweiterung:
Auf http://blog.loetzimmer.de/2017/10/amazon-alexa-hort-auf-die-shell-echo.html ist eine Scriptlösung zur Abfrage und Steuerung der Echo Devices vorgestellt. Nach meinem Verständniss entspricht das ungefähr Deinem Modul.

Es gibt u.a. das Kommando "-lastalexa". Hier wird abgefragt, welches Echo Device (wenn man denn mehrere hat ...) als letztes ein Sprachkommando empfangen hat. Auf https://wennez.wordpress.com/light-on-with-alexa-for-each-room/ wird beschrieben, wie man mit diesem Kommando (bzw. dem Script)  zusammen mit HA-Bridge endlich ein Kommando "Licht"  (als Beispiel) definieren kann (und nicht "Licht Wohnzimmer", "Licht Esszimmer" usw.)

Gibt es eine Chance, eine solche "lastalexa" Abfrage in Deinem Modul zu haben?
Die Abfrage müsste natürlich "live" sein, soll also kein "altes" Reading aus einem Polling Vorgang zurückliefern ...
Du kannst einfach an deinem Account Device ein get settings machen, und bei allen Echo Devices wird das Reading "voice" aktualisiert.

sw

#430
Danke, probiere ich am Wochenende gleich aus  :)

michael.winkler

Zitat von: JoWiemann am 13 März 2018, 19:52:18
1. Du setzt STATE im Programm und benutzt es auch intern. STATE gehört allerdings dem User und kann such das Attribut stateFormat verändert werden. In diesem Fall funktioniert dann einiges nicht mehr. Ist kein stateFormat definiert wird STATE automatisch auf den Wert des internen Readings state gesetzt.
Ja da gebe ich Dir recht, da muss ich nicht etwas anpassen.

Zitat von: JoWiemann am 13 März 2018, 19:52:18
2. Es wäre schön, wenn die Liste der Set in Abhängigkeit von connected verändert wird. Also bei nicht connected nur Login und login2FACode angezeigt wird.
Aktuell ist es so dass die get und set Befehle nur funktionieren wenn das Device connected ist. Ausnahmen sind die beiden set befehle "login" und "login2FACode". An diesem Verhalten werde ich erstmal nichts verändern, denn der Benutzer wird dann direkt informiert warum der set Befehl nicht funktioniert. Wenn die Befehle nicht mehr angezeigt werden, würde der ein oder andere Benutzer bestimmt nicht wissen warum das so ist.

Zitat von: JoWiemann am 13 März 2018, 19:52:18
3. Für das Passwort würde ich auf die Logik von anderen Modulen wie 72_FB_CALLMONITOR umstellen. Damit würde dann eine gewisse Einheitlichkeit innerhalb der Modulwelten existieren.
Was ist schon Einheitlich. Mir ist hier kein Standard bekannt. Zum Anderen habe ich das Modul von Markus M. übernommen. Gerade diesen Teil habe ich noch nicht angefasst und verändert. Hier sehe ich erstmal keinen Handlungsbedarf. Wobei das Modul 72_FB_CALLMONITOR ja letzt endlich auch mit den gleichen Infos die Daten verschlüsselt. Nur dass das Modul 72_FB_CALLMONITOR hier einen MD5 Hash daraus macht. Aber im Grunde kann auch hier das Kennwort wieder angezeigt werden, wenn das System gehackt wurde.

Zitat von: JoWiemann am 13 März 2018, 19:52:18
4. Für Fehlersuche wäre es schön, wenn Du mehr Log3 Einträge, sinnvoll nach Loglevel 1...5, spendieren würdest.
Hier habe ich sehr viele Loglevel 3 Infos auf Loglevel 4 gesetzt, da die ersten Modulversion sehr oft Meldung produziert haben. Viele dieser Meldung wurden dann erstellt wenn das COOKIE ungültig war, und ein erneuter ReLogin versucht wurden Wenn dann noch ein erneutes Login nicht funktioniert, wurde das LOG mit sehr vielen gleichen Meldung vollgemüllt. Daher jetzt alles auf Loglevel 4.

Zitat von: JoWiemann am 13 März 2018, 19:52:18
5. Ich persönlich finde es hilfreich, wenn die vom Modul benutzten Attribute auch als solche erkennbar sind. Also für alle im Modul definierten Attribute z.B. ein echo_ voranstellen.
Auch hier gibt es leider nichts Einheitliches. Ich habe im Entwicklerbereich schon Ansätze gesehen zum sortieren bzw. Anzeigen der Attribute in Gruppen usw. Soweit ich das aber sehe wurde hier auch nichts mehr weiterverfolgt. In der Doku sind die Attribute alle sauber beschrieben. Von daher sollte der Benutzer wissen welches Attribut zum Modul gehört. Ein Umbenennen möchte ich erstmal nicht angehen.

Gruß
Michael

sinus61

Zitat von: michael.winkler am 13 März 2018, 22:10:02
Du kannst einfach an deinem Account Device ein get settings machen, und bei allen Echo Devices wird das Reading "voice" aktualisiert.

Die Idee hinter dem Skript ist aber so wie ich das verstanden habe, dass nur genau der Name des Echos geliefert wird der als letztes ein Kommando empfangen hat um dann damit die ha-bridge zu "füttern".

Ich hab es aber mal so probiert: In der ha-bridge einen "Licht" Befehl angelegt, der ein get <Account Device> settings auslöst. Jetzt in einem Echo ein notify auf das voice Reading das wiederum den Text auswertet und bei "licht an" bzw. "licht aus" jeweils eine passende Aktion auslöst.
Das funktioniert eigentlich, manchmal wird das voice Reading aber trotzdem nicht aktualisiert. Und da Alexa Zahlen als Worte liefert ist es für Dimmer auch nicht so geeignet ( "fünfzig prozent" ), an und aus geht aber.


Abercrombie1892

Zitat von: sinus61 am 14 März 2018, 17:21:36
Die Idee hinter dem Skript ist aber so wie ich das verstanden habe, dass nur genau der Name des Echos geliefert wird der als letztes ein Kommando empfangen hat um dann damit die ha-bridge zu "füttern".

Ich hab es aber mal so probiert: In der ha-bridge einen "Licht" Befehl angelegt, der ein get <Account Device> settings auslöst. Jetzt in einem Echo ein notify auf das voice Reading das wiederum den Text auswertet und bei "licht an" bzw. "licht aus" jeweils eine passende Aktion auslöst.
Das funktioniert eigentlich, manchmal wird das voice Reading aber trotzdem nicht aktualisiert. Und da Alexa Zahlen als Worte liefert ist es für Dimmer auch nicht so geeignet ( "fünfzig prozent" ), an und aus geht aber.

wozu soll das denn gut sein? das kann man doch über die alexa app wesentlich besser aufteilen. ha bridge is doch nur dazu da, dinge in die alexa app einzubringen.

sw

#434
Zitat von: michael.winkler am 13 März 2018, 22:10:02
Du kannst einfach an deinem Account Device ein get settings machen, und bei allen Echo Devices wird das Reading "voice" aktualisiert.

Hallo Michaael,
ich habe den Weg jetzt ausprobiert.
Nur "proof of concept": Neues Device in habridge angelegt, das in Fhem dann "get settings" auslöst.
Funktioniert wie erwartet.

Aber: Wenn habbridge Fhem triggert dauert es (bei meinen Tests) noch 3..5 Sekunden, bis das "voice" Reading aktuell ist. Das ist zum Schalten von Licht leider nicht praktikabel.

Im Script von http://blog.loetzimmer.de/2017/10/amazon-alexa-hort-auf-die-shell-echo.html wird auch nicht auf den erkannten Text gewartet, sondern der
ZitatActivity-Feed hinsichtlich der letzten Aktion befragt
Das geht rasend schnell!

Natürlich kann ich meine Konfiguration mit dem Script aufbauen
(Datenfluss: Echo -> habridge -> Script, welches "lastalexa" benutzt und die tatsächlich zu schaltende Lampe bestimmt -> Fhem).

Schöner wäre natürliche eine Lösung ohne Script nur mit Fhem
(Datenfluss: Echo -> habridge -> Fhem 37_echodevice).

Deshalb noch einmal meine Frage bzw. Bitte: könntest Du Dir mal das Script ansehen? Die last_alexa() Funktion ist nur 8 Zeilen lang. Es wäre genial, wenn Du eine solche Funktion in Dein Modul einbauen könntest!