[37_echodevice] Amazon Echo Modul (nicht Alexa)

[balli1187]

Moin,
Ich hätte zwei Frage an die jenigen, die nach einem

Code Auswählen Erweitern

get <Account> settings
Auf die Voice-Readings ihrer Echos triggern und das dann weiter auswerten....

1) wie "schnell" ist das im Vergleich zum direkten schalten über einen separaten dummy für jede Aktion/Routine? Gibt es da (merkliche) Latenzen?
2) wie verhindert ihr, dass "zufällig" eine Aktion gestartet wird, weil eines eurer Schlüsselwörter in einem anderen Zusammenhang genannt wird und dann im Voice-Reading steht?


Gesendet von iPhone mit Tapatalk

[charly166]

Hallo Michael,

könntest du bitte noch den Telekom Magenta Speaker in dein Modul einpflegen, sonst müssen wir das nun nach jedem Update nachpflegen. Habe eben das aktuelle Modul um die Zeile 4147 erweitert:

Code Auswählen Erweitern

elsif($ModelNumber eq "A1HNT9YTOBE735"  || $ModelNumber eq "Telekom Smart Speaker") {return "Telekom Smart Speaker";}

Vielen Dank im Voraus.
Viele Grüße

Charly

[KölnSolar]

Hi Michael,
wo ich sah, dass Du in Deinem System auf freeze-Ursachensuche bist: Ich beobachte immer wieder nicht zu vernachlässigende freezes, an denen das echodevice-Modul beteiligt ist

Code Auswählen Erweitern

2020.01.05 04:55:22.154 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.01.05 04:55:22.155 5: HttpUtils url=https://layla.amazon.de/api/notifications
--- log skips     4.229 secs.
2020.01.05 04:55:26.384 4: IP: layla.amazon.de -> 52.222.171.207
2020.01.05 04:55:26.386 4: [echomaster] [echodevice_SendCommand] [alarmvolume] STARTwobei notifications austauschbar ist(zB. auch todos). Da ich bei anderen http-Zugriffen diese Häufung nicht habe und die analysierten freezes zur Nachtzeit entstanden, tippe ich auf mangelnde Verfügbarkeit des amazon-Servers. Du nutzt ja  HttpUtils_NonblockingGet. Mit Umstellung auf BlockingCall ließen sich die freezes vermeiden.
Grüße Markus

[michael.winkler]

Hi Michael,
wo ich sah, dass Du in Deinem System auf freeze-Ursachensuche bist: Ich beobachte immer wieder nicht zu vernachlässigende freezes, an denen das echodevice-Modul beteiligt ist

Code Auswählen Erweitern

2020.01.05 04:55:22.154 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.01.05 04:55:22.155 5: HttpUtils url=https://layla.amazon.de/api/notifications
--- log skips     4.229 secs.
2020.01.05 04:55:26.384 4: IP: layla.amazon.de -> 52.222.171.207
2020.01.05 04:55:26.386 4: [echomaster] [echodevice_SendCommand] [alarmvolume] STARTwobei notifications austauschbar ist(zB. auch todos). Da ich bei anderen http-Zugriffen diese Häufung nicht habe und die analysierten freezes zur Nachtzeit entstanden, tippe ich auf mangelnde Verfügbarkeit des amazon-Servers. Du nutzt ja  HttpUtils_NonblockingGet. Mit Umstellung auf BlockingCall ließen sich die freezes vermeiden.
Grüße Markus

Warum sollen diese freezes mit BlockinCalls weg sein? Es ist doch gerade der Vorteil von Nonblocking! Kannst du das kurz erklären?

[PfennigsR]

Hi moin moin,

ich hab da ein Problem mit der NPM Installation. Ich habe mich bereits durch locker 40 Seiten Forum gekämpft, aber nicht die Lösung für mein Problem gefunden.

Bevor ich auf ein Intel NUC umgezogen bin und die 2FA Authentisierung aktiviert hatte, hatte auch alles funktioniert. Folgendes habe ich versucht:

- Proxy Port auf die die 3003 testweise geändert
- proxy listen ip auf die des Servers gestellt
- im Betrieb mit netstat die Ports überprüft
--> hat alles nicht funktioniert --> Seite wird nicht aufgerufen und ich bekomme einen Timeout

Ich gebe euch auch mal einen Screen von den einzelnen Fenstern in FHEM (Device und Status)

Vielen Dank im Vorraus!

[KölnSolar]

Warum sollen diese freezes mit BlockinCalls weg sein? Es ist doch gerade der Vorteil von Nonblocking! Kannst du das kurz erklären?

Gerne.

Die Funktion HttpUtils_NonblockingGet initiiert den Verbindungsaufbau und übergibt alles weitere an FHEM interne Routinen. Sobald eine Antwort vom HTTP-Server eintrifft, wird eine Callback-Funktion mit verschiedenen Parametern (unter anderem auch das Ergebnis) aufgerufen, um die Antwort entgegenzunehmen und weiter zu verarbeiten.

Die Funktion HttpUtils_NonblockingGet ist nicht komplett durchgehend "non-blocking". DNS-Abfragen sind weiterhin blockierend. Insbesondere wenn der DNS-Name nicht aufgelöst werden kann.

[michael.winkler]

Gerne.

OK, das die DNS Anfragen noch NonBlocking sind war mir bekannt. Trotzdem stellt sich die Frage warum dann ein BlockingCall, wo alles blockiert, besser sein soll. Verstehe ich leider immer noch nicht.

[michael.winkler]

Hi moin moin,

ich hab da ein Problem mit der NPM Installation. Ich habe mich bereits durch locker 40 Seiten Forum gekämpft, aber nicht die Lösung für mein Problem gefunden.

Bevor ich auf ein Intel NUC umgezogen bin und die 2FA Authentisierung aktiviert hatte, hatte auch alles funktioniert. Folgendes habe ich versucht:

- Proxy Port auf die die 3003 testweise geändert
- proxy listen ip auf die des Servers gestellt
- im Betrieb mit netstat die Ports überprüft
--> hat alles nicht funktioniert --> Seite wird nicht aufgerufen und ich bekomme einen Timeout

Ich gebe euch auch mal einen Screen von den einzelnen Fenstern in FHEM (Device und Status)

Vielen Dank im Vorraus!

Welchen Browser verwendest du? Wie ist die IP-Adresse Deines FHEM Server?

Lau Screenshot verwendest Du das falsche Attribut für die IP-Adresse. Hier mal das Attribut "npm_proxy_ip" verwenden.

Eventuell hilft Dir dieser Link weiter:
https://mwinkler.jimdo.com/modul-echodevice-npm/

[MadMax-FHEM]

OK, das die DNS Anfragen noch NonBlocking sind war mir bekannt. Trotzdem stellt sich die Frage warum dann ein BlockingCall, wo alles blockiert, besser sein soll. Verstehe ich leider immer noch nicht.

Bei setzen von "global dnsServer" ist auch die DNS-Abfrage non-blocking...

Ansonsten gehe ich mit Michael (und auch sonst "überall" im Forum) nonblockingGet...

EDIT: und soweit ich das in Erinnerung habe sind die Angaben von FreezeMon "nur" potetielle Kandidaten, irgendwas mit (internal) Timer, also kein "Muss", dass es sich auch 1. um einen "echten" Freeze handelt und 2. dass das genannte Modul auch tatsächlich der "Übeltäter" ist...

EDIT2: ich habe auch grad vor einigen Tagen auf 3 meiner Systeme (Hauptsystem und 2 Testsystemen) FreezeMon mal aktiviert. Auf 2 Systemen habe ich das echodevice-Modul laufen. Auf einem davon (Testsystem) habe ich auch solche Einträge.
Auf meinem Hauptsystem nicht. Wollte die Tage mal schauen warum dem so ist... Aber da mein Hauptsystem gut läuft, hat das niedrige Prio...

Gruß, Joachim

[KölnSolar]

warum dann ein BlockingCall, wo alles blockiert,

Wie alles blockiert ?

Das Modul Blocking.pm wurde von Rudolf König entwickelt, um in FHEM Funktionsaufrufe zu ermöglichen, die relativ viel Zeit in Anspruch nehmen und normalerweise FHEM damit zum Stillstand (für die Dauer der Ausführung der Funktion) bringen würde.
Um so etwas zu verhindern, kann man mit Hilfe von Blocking.pm eine Funktion über einen Fork des Hauptprozesses unabhängig davon abarbeiten und das Ergebnis dieser Funktion optional an den Hauptprozess übergeben.

Verstehe ich leider immer noch nicht.

weil dann halt der gesamte Zugriff geforked ist.(So mein Gedanke)

EDIT: und soweit ich das in Erinnerung habe sind die Angaben von FreezeMon "nur" potetielle Kandidaten, irgendwas mit (internal) Timer, also kein "Muss

Die Aussage ist weniger auf das freeze-log, als die Info der readings zu verstehen. Und im konkreten Fall ist es die Häufung, die den Verdacht nährt.

Bei setzen von "global dnsServer" ist auch die DNS-Abfrage non-blocking...

Bin mir nicht sicher, ob das hilft und auch für alle Plattformen die Lösung ist. Ich prüfe....

[MadMax-FHEM]

Laut Rudolf König führt das Setzen des dnsServer dazu, dass die DNS-Auflösung non-Blocking von fhem statt blocking vom System gemacht wird...

Kann man sicher im Forum finden, wurde öfters erläutert...

Einzige Alternative (aber eigentlich unnötiger Zusatzaufwand) wäre alles per non-Blocking im Modul zu implementieren, also mit Callback usw.

Gruß, Joachim

[michael.winkler]

Laut Rudolf König führt das Setzen des dnsServer dazu, dass die DNS-Auflösung non-Blocking von fhem statt blocking vom System gemacht wird...

Kann man sicher im Forum finden, wurde öfters erläutert...

Einzige Alternative (aber eigentlich unnötiger Zusatzaufwand) wäre alles per non-Blocking im Modul zu implementieren, also mit Callback usw.

Gruß, Joachim

Welche IP habt Ihr hier eingetragen? Ich habe mal den Google DNS 8.8.8.8 eingetragen.

[KölnSolar]

Ich hab mal weiter geguckt....
- die freezes sind definitiv vom echodevice
- vermutlich bei mir so offensichtlich, weil ich devices mit Cloudzugriff weitestgehend meide und das echodevice recht viele requests macht
- vermutlich läuft da irgendwas in meinem Netz, das pi-hole/dnsmasq bremst
- den timeout vom nonblockinget runterzusetzen von 10 auf 1 bringt nichts(könntest Du aber vielleicht trotzdem auf 1 setzen)
- mit global dnsserver auf meinen pi-hole/dnsmasq bleiben die freezes scheinbar aus, also komplett non-blocking(danke Joachim)

[MadMax-FHEM]

Also ich habe meinen Router eingetragen, also nicht mal einen "internen" DNS (ist bei mir auch piHole   ), ist noch aus "Historie" nicht umgestellt.

So wie ich die Beiträge von Rudi in Erinnerung habe ist es quasi "egal" was dort eingetragen ist, es wird dann (sobald "etwas" eingetragen ist) eben von blockierenden Systemaufrufen auf fhem-interne (nicht blockierende) Aufrufe umgestellt.

Wahrscheinlich dauert dann der Zugriff bei "falschem" Eintrag länger...
...allerdings länger non-blocking

aber das ist nur eine (schwere) Vermutung...

@KölnSolar: gerne!

Hmmm, vielleicht schaue ich mal bzgl. Unterschied der beiden Systeme. Sind beide PIs (ich glaube beide mit Stretch), ähnlicher Updatestatus bzgl. OS und fhem (Testsystem dient zum "Üben" und wenn es da gut geht, dann folgt [meist] das Hauptsystem)... Allerdings habe ich (natürlich) auf dem Hauptsystem (deutlich) mehr Dinge laufen u.a. doch auch einige Cloud-Dinge (z.B. Xiaomi-Sauger)...

Weil auf dem Hauptsystem hatte ich selbst mit Einstellung Freezes bei bereits 0,3s zu melden (gefühlt, kann ich aber mal nachschauen) keinen Eintrag bzgl. Echodevice...

Aber einige kleinere Dinge gefunden, die ich selbst "verbockt" hatte (ja wusste ich bei Umsetzung aber wie es halt immer so ist   ) und die habe ich jetzt auch "umgestellt" und seither so gut wie keine Freezes mehr (mit Standardeinstellung 1s)...

Gruß, Joachim

[volschin]

Also ich habe meinen Router eingetragen, also nicht mal einen "internen" DNS (ist bei mir auch piHole   ), ist noch aus "Historie" nicht umgestellt.

Auch der Eintrag des eigenen Routers ist ein interner DNS, meist ein cachender DNS-Proxy.