[37_echodevice] Amazon Echo Modul (nicht Alexa)

[doman75]

Hallo,

ich habe heute ein update von fhem gemacht, da hat es wohl auch die eingecheckte Version von echodevice mit eingespielt, seit dem kommt da ein error, will ich den npm login neu machen steht folgendes im log:

Code Auswählen Erweitern


  at Object.Module._extensions..js (module.js:416:10)
    at Module._compile (module.js:409:26)
    at Object.<anonymous> (/opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/lib/proxy.js:10:15)
    at require (internal/module.js:12:17)
    at Module.require (module.js:353:17)
    at Function.Module._load (module.js:300:12)
    at Module.load (module.js:343:32)
    at Object.Module._extensions..js (module.js:416:10)
    at Module._compile (module.js:373:25)
    at exports.runInThisContext (vm.js:53:16)
SyntaxError: Unexpected token {

          ^
    const { middleware } = new http_proxy_middleware_1.HttpProxyMiddleware(context, opts);
/opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/node_modules/http-proxy-middleware/dist/index.js:4
2020.01.06 19:39:31.838 2: MAXCUBECUN_2: CUL_TCM97001 Unknown device CUL_TCM97001_89 model:NC_WS msg:s5938003510EB, please define it
2020.01.06 19:39:31.596 1: [Freezemon] myFreezemon: possible freeze starting at 19:39:24, delay is 7.595 possibly caused by: no bad guy found :-(
npm WARN engine to-regex-range@5.0.1: wanted: {"node":">=8.0"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine fill-range@7.0.1: wanted: {"node":">=8"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine picomatch@2.2.1: wanted: {"node":">=8.6"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine braces@3.0.2: wanted: {"node":">=8"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine http-proxy@1.18.0: wanted: {"node":">=6.0.0"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine micromatch@4.0.2: wanted: {"node":">=8"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine http-proxy-middleware@0.20.0: wanted: {"node":">=8.0.0"} (current: {"node":"4.9.1","npm":"2.15.11"})


Was kann ich da jetzt machen?
Grüße
Swen

[balli1187]

Ich bekomme als Ausgabe:

tcp        0      0 10.1.14.0:3002          0.0.0.0:*               LISTEN      13564/node

Hast du da den richtigen Port? Ich hab's jetzt nicht im Kopf aber dir wurde geraten den Port 3003 zu prüfen aber bei dir taucht jetzt zum zweiten Mal 3002 auf....
Tippfehler oder Absicht?


Gesendet von iPhone mit Tapatalk

[balli1187]

Hallo,

ich habe heute ein update von fhem gemacht, da hat es wohl auch die eingecheckte Version von echodevice mit eingespielt, seit dem kommt da ein error, will ich den npm login neu machen steht folgendes im log:

Code Auswählen Erweitern


  at Object.Module._extensions..js (module.js:416:10)
    at Module._compile (module.js:409:26)
    at Object.<anonymous> (/opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/lib/proxy.js:10:15)
    at require (internal/module.js:12:17)
    at Module.require (module.js:353:17)
    at Function.Module._load (module.js:300:12)
    at Module.load (module.js:343:32)
    at Object.Module._extensions..js (module.js:416:10)
    at Module._compile (module.js:373:25)
    at exports.runInThisContext (vm.js:53:16)
SyntaxError: Unexpected token {

          ^
    const { middleware } = new http_proxy_middleware_1.HttpProxyMiddleware(context, opts);
/opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/node_modules/http-proxy-middleware/dist/index.js:4
2020.01.06 19:39:31.838 2: MAXCUBECUN_2: CUL_TCM97001 Unknown device CUL_TCM97001_89 model:NC_WS msg:s5938003510EB, please define it
2020.01.06 19:39:31.596 1: [Freezemon] myFreezemon: possible freeze starting at 19:39:24, delay is 7.595 possibly caused by: no bad guy found :-(
npm WARN engine to-regex-range@5.0.1: wanted: {"node":">=8.0"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine fill-range@7.0.1: wanted: {"node":">=8"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine picomatch@2.2.1: wanted: {"node":">=8.6"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine braces@3.0.2: wanted: {"node":">=8"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine http-proxy@1.18.0: wanted: {"node":">=6.0.0"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine micromatch@4.0.2: wanted: {"node":">=8"} (current: {"node":"4.9.1","npm":"2.15.11"})
npm WARN engine http-proxy-middleware@0.20.0: wanted: {"node":">=8.0.0"} (current: {"node":"4.9.1","npm":"2.15.11"})


Was kann ich da jetzt machen?
Grüße
Swen

Ich würde den Eintrag

Code Auswählen Erweitern

wanted: {"node":">=8.0.0"} (current: {"node":"4.9.1","npm":"2.15.11"}
So interpretieren, dass dein Node.js nicht aktuell genug ist.


Gesendet von iPhone mit Tapatalk

[arminius]

Hallo zusammen,

wird der Echo Show 8 schon unterstützt?
Hintergrund der Frage ist, dass ich nur bei diesem Device kein Set und get Button in FHEM sehe.
Laut der verlinkten Doku wird auf den Vorgänger Show verwiesen und dieser funktioniert auch bei mir.

Wenn ich den set Befehl direkt eintrage, dann funktioniert es auch nicht.

Gruß
Arminius

[Tommy82]

Hallo,
ich habe im Log releative viele Meldungen von freezmon mit den Echomodul Devices.
EIner eine idee was ich dagegen machen kann.

Code Auswählen Erweitern

2020.01.06 00:52:24.487 1: [Freezemon] myFreezemon: possible freeze starting at 00:52:20, delay is 4.484 possibly caused by: tmr-echodevice_GetSettings(ECHO_90F00718642405VR) tmr-echodevice_GetSettings(ECHO_70900309449702SN) tmr-HttpUtils_Err(N/A)
2020.01.06 03:31:35.313 1: [Freezemon] myFreezemon: possible freeze starting at 03:31:31, delay is 4.309 possibly caused by: tmr-echodevice_GetSettings(ECHO_G090U50784160HFP)
2020.01.06 10:48:51.894 1: [Freezemon] myFreezemon: possible freeze starting at 10:48:49, delay is 2.891 possibly caused by: tmr-echodevice_GetSettings(ECHO_G000MW04742305HS)
2020.01.06 11:36:10.121 1: [Freezemon] myFreezemon: possible freeze starting at 11:36:08, delay is 2.119 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 11:40:10.860 1: [Freezemon] myFreezemon: possible freeze starting at 11:40:09, delay is 1.858 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 12:11:11.103 1: [Freezemon] myFreezemon: possible freeze starting at 12:11:10, delay is 1.1 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 12:42:12.296 1: [Freezemon] myFreezemon: possible freeze starting at 12:42:11, delay is 1.293 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 15:46:54.106 1: [Freezemon] myFreezemon: possible freeze starting at 15:46:53, delay is 1.104 possibly caused by: tmr-echodevice_GetSettings(ECHO_G000MW0773410SEV)
2020.01.06 16:29:58.470 1: [Freezemon] myFreezemon: possible freeze starting at 16:29:56, delay is 2.467 possibly caused by: tmr-echodevice_GetSettings(ECHO_G000MW04742305HS)





[MadMax-FHEM]

Hallo,
ich habe im Log releative viele Meldungen von freezmon mit den Echomodul Devices.
EIner eine idee was ich dagegen machen kann.

Code Auswählen Erweitern

2020.01.06 00:52:24.487 1: [Freezemon] myFreezemon: possible freeze starting at 00:52:20, delay is 4.484 possibly caused by: tmr-echodevice_GetSettings(ECHO_90F00718642405VR) tmr-echodevice_GetSettings(ECHO_70900309449702SN) tmr-HttpUtils_Err(N/A)
2020.01.06 03:31:35.313 1: [Freezemon] myFreezemon: possible freeze starting at 03:31:31, delay is 4.309 possibly caused by: tmr-echodevice_GetSettings(ECHO_G090U50784160HFP)
2020.01.06 10:48:51.894 1: [Freezemon] myFreezemon: possible freeze starting at 10:48:49, delay is 2.891 possibly caused by: tmr-echodevice_GetSettings(ECHO_G000MW04742305HS)
2020.01.06 11:36:10.121 1: [Freezemon] myFreezemon: possible freeze starting at 11:36:08, delay is 2.119 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 11:40:10.860 1: [Freezemon] myFreezemon: possible freeze starting at 11:40:09, delay is 1.858 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 12:11:11.103 1: [Freezemon] myFreezemon: possible freeze starting at 12:11:10, delay is 1.1 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 12:42:12.296 1: [Freezemon] myFreezemon: possible freeze starting at 12:42:11, delay is 1.293 possibly caused by: tmr-echodevice_GetSettings(Echos)
2020.01.06 15:46:54.106 1: [Freezemon] myFreezemon: possible freeze starting at 15:46:53, delay is 1.104 possibly caused by: tmr-echodevice_GetSettings(ECHO_G000MW0773410SEV)
2020.01.06 16:29:58.470 1: [Freezemon] myFreezemon: possible freeze starting at 16:29:56, delay is 2.467 possibly caused by: tmr-echodevice_GetSettings(ECHO_G000MW04742305HS)





Du bist nicht alleine: https://forum.fhem.de/index.php/topic,82631.msg1009029.html#msg1009029

Bei mir ist es auf einem meiner Testsysteme ähnlich...
...auf meinem Hauptsystem habe ich kaum welche...

Gruß, Joachim

[Tommy82]

Dann fehlt ja nur noch eine Erklärung und eine Lösung dafür

[MadMax-FHEM]

Dann fehlt ja nur noch eine Erklärung und eine Lösung dafür

Schwierig.

Weil wenn tatsächlich nur HTTP_Nonblocking verwendet wird (müsste man im Code schauen, allerdings klingt die Aussage von Michael so) und dnsServer gesetzt ist, sollte eigentlich nichts blockieren...

Ich bin auch nicht sicher, ob dabei FreezeMon zuverlässig anzeigt oder das halt als false-positive erkennt...
...da müsste der Entwickler von FreezeMon was sagen (ich hab nur im Kopf, dass es sowas geben kann bei FreezeMon)...

Interessant ist, dass ich bei meinem Hauptsystem praktisch gar keine Freezes habe (was gut ist   )...
...und auf dem Testsystem ebefalls so viele (auch vom echodevice-Modul), obwohl es die selben Echos sind (selber Account), ich auf dem Hauptsystem das echodevice nutze (auf dem Testsystem läuft das nur mit) und die Systeme eigentlich relativ ähnlich sind (OS und fhem)...

Gruß, Joachim

[KölnSolar]

eine Lösung dafür

ich hatte eine vorgeschlagen.

tatsächlich nur HTTP_Nonblocking verwendet wird (müsste man im Code schauen, allerdings klingt die Aussage von Michael so) und dnsServer gesetzt ist, sollte eigentlich nichts blockieren...

Wird verwendet. Mit global dnsserver ist es "anders" geworden. freezes lassen sich zumindest nicht mehr eindeutig zuordnen. Irgendwie ist es die event-/notify-queue.... oder zu viele geforkte Prozesse ? 

[Thyraz]

ich hatte eine vorgeschlagen. ::

Meinst du https://wiki.fhem.de/wiki/Blocking_Call?

Ich wäre mir nicht sicher, ob es eine gute Idee ist das für jeden HTTP Aufruf innerhalb FHEM zu verwenden.
Das ist ja jedesmal ein Fork, der den FHEM Hauptprozess duplizuiert und somit auch die Speichernutzung.

Ich hab unzählige Module laufen die per Web-API auf irgendwas (Gateway, Hardware direkt, ...) zugreifen.
HttpUtils_NonblockingGet wird doch von vielen Modulen verwendet und scheint für einfache asynchrone Aufrufe eher der Standard zu sein.

In den Threads in denen ich bisher zu Problemen in dieser Funktion gelesen habe, wurde das an sich immer durch DNS Anfragen ausgelöst (Service unzuverlässig, oder hängendes FHEM bei fehlender Internetverbindung).
Die Lösung war da eigentlich immer das dnsserver Attribut zu setzen.

Habe seit ich das vor Ewigkeiten gemacht habe auch nie wieder Probleme mit FHEM Hängern aufgrund Netzwerkabfragen gehabt (Sofern die Module einen ansychronen Aufruf verwenden).

[KölnSolar]

Meinst du https://wiki.fhem.de/wiki/Blocking_Call?

Ja.

Ich wäre mir nicht sicher, ob es eine gute Idee ist das für jeden HTTP Aufruf innerhalb FHEM zu verwenden.

Ich mir ja auch nicht. Aber einen Versuch wäre es wert. echodevice macht(so wie ich das interpretiere) eine Masse an Zugriffen und events.
In meinen Modulen nutze ich BlockingCall und das hat bis dato zu keinen Problemen geführt bzw. die sind in freezemon unauffällig.

Bei mir war es sicherlich auch das DNS-Problem. Und im Augenblick suche ich weiter nach Gründen von "possible" freezes, die in freezemon auftauchen. Einen Bösewicht(anderes Modul) hab ich gerade "enttarnt". 

[michael.winkler]

Ja.Ich mir ja auch nicht. Aber einen Versuch wäre es wert. echodevice macht(so wie ich das interpretiere) eine Masse an Zugriffen und events.
In meinen Modulen nutze ich BlockingCall und das hat bis dato zu keinen Problemen geführt bzw. die sind in freezemon unauffällig.

Bei mir war es sicherlich auch das DNS-Problem. Und im Augenblick suche ich weiter nach Gründen von "possible" freezes, die in freezemon auftauchen. Einen Bösewicht(anderes Modul) hab ich gerade "enttarnt". 

Habe mir gerade mal die Anleitung zum BlockingCall durchgelesen. Muss gesehen dass ich es mit dem HTTP_blocking.. verwechselt habe.

Wenn die freezes am DNS liegen, dann wäre es allerdings Sinnvoller den entsprechenden Eintrag im globale Device zu machen. Ein generelles Umbauen auf BlockingCall halte ich für weniger Sinnvoll, da jedes Echo Device dann im 60 Sekundentakt 2x BlockingCalls erzeugen. Das Account Device ruft alle 60 Sekunden ca. 10 HTTP aufrufe ab. Da es auf vielen FHEM Installation sowieso schon Speicherprobleme (Perl Problem) gibt, wäre das diese Modul gleich wieder ein weiterer der das Problem eventuell verschlimmert.

Gruß
Michael

[rudolfkoenig]

(Da man mich per PM gebeten hat, meine Meinung hinzuschreiben)

Die Ausfuehrungen von Thyraz sind zutreffend.

BlockingCall hat zwei Nutzungszenarien:
- wenn die Verarbeitung der Daten CPU-intensiv ist (ich meine das ist im Calendar Modul der Fall).
- wenn der Modulautor eine blockierende Bibliothek oder Programm verwenden muss (oder es aus Bequemlichkeit tut )

BlockingCall forkt den Haupt-FHEM Prozess, was den aktuellen Speicherzustand kopiert (bzw. die Seiten Copy-On-Write markiert, und den potentiell benoetigten zusaetlichen Speicher reserviert). Der neue Prozess eroeffnet danach eine TCP/IP Verbindung zum Alten, um die Ergebnisse darueber mitzuteilen, und fuehrt die bestellte Funktion aus. Das ist teurer als HttpUtils_NonblockingGet, was sich nur (wie alle anderen FHEM-Geraete mit IO) in die globale select Liste eintraegt, und benachrichtigt wird, falls laut Kernel die Netzwerkverbindung bereit ist, um Daten zu schreiben oder zu lesen.

HttpUtils_NonblockingGet kann eine schlechte Wahl sein, wenn man fuer die Verarbeitung der Daten (und damit meine ich nicht die ausgeloesten Events oder userReadings) viel CPU benoetigt, s.o.

Zu "attr global dnsServer": die "normalen" perl / libc Routinen, um Namen nach IP zu wandeln (getaddrinfo, gethostbyname) sind alle blockierend. Falls der DNS-Server normal funktioniert, dann faellt das nicht auf (<0.1sec pro Anfrage) , wenn nicht, dann gibt es stoerend lange Timeouts. Mit "attr global dnsServer" wird die HttpUtils eigene, nicht blockierende Implementierung genutzt. Eine weitere Alternative ist direkt IP-Adressen zu verwenden statt Hostnamen.

Zu fork/Copy-on-Write: frueher(TM) hat Linux nicht den kompletten Speicher fuer den Worst-Case reserviert, und ohne diese waere das BlockingCall/Not Enough memory bei weitem nicht so tragisch. Weiss jemand, wann sich das geaendert hat, und ob/wie man das Verhalten beeinflussen kann?

[rudolfkoenig]

Weiss jemand, wann sich das geaendert hat, und ob/wie man das Verhalten beeinflussen kann?

Ist wohl hier erklaert: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

D.h. bei BlockingCall Speicherproblemen kann einer der beiden Zeilen (oder beide zusammen) helfen:

Code Auswählen Erweitern

sysctl -w vm.overcommit_memory=1
sysctl -w vm.overcommit_ratio=100
Nebeneffekt: Falls nicht mehr genug Speicher da ist, dann wird irgendein Prozess terminiert, das kann verwirrend sein und zu Datenverlust fuehren.
Wer die Implikationen nicht ganz versteht, soll es bitte _NICHT_ aendern.
 

[justme1968]

nur der vollständigkeit halber: es gibt noch zwei weitere möglichkeiten um etwas non blocking und parallel zum haupt fhem auszuführen: SubProcess und CoProcess.

beides ist um gegensatz zu BlockingCall  eher gefacht um etwas ein mal zu starten und dann lange zeit parallel zu fhem laufen zu haben. ersteren eher um in perl/fhem weiter zu machen, letzteres um einen komplett anderen prozess laufen zu lassen.