[Adapter] Sonoff- Tasmota
-
Hi @Bluefox,
erstmal Danke für den schnellen Fix.
Den Streamserver haste ja rausgeschmissen.
Ich hatte selber bei mir eine von mir umgebaute server.js laufen,
die im Grunde dem entsprach,w as Du umgesetzt hast.
Anstatt eines Timeouts auf dem Stream hatte ich aber bei einem pingreq den pingresp
unterdrückt, wenn der Client geschlossen war.
Also sowas in der Art:
client.on('pingreq', (/*packet*/) => { if (clients[client.id]) { adapter.log.debug('Client [' + client.id + '] pingreq'); client.pingresp(); } });Das sollte dafür sorgen, daß bei einem "close" kein ping mehr
für den Stream eines geschlossenen Clients geschrieben werden sollte.
Sorgte im Endeffekt aber dafür, daß der Client nochmals geschlossen wurde,
das erste Mal durch den "socket has closed by other party" (ErrorCode: EPIPE),
um danach gleich nochmal wegen des Pings geschlossen zu werden ..
Bin halt kein Javascript-Experte … sondern nur echtem Java.
Ist wahrscheinlich auch falsch gewesen an der Stelle aber war eben ein Test von mir ...
Hab nun die Installation auf das neueste 2.0.0 geupdatet und lasse das mal so laufen
und schau was passiert.
Daß der Fehler mit WLAN-Qualität zu tun haben soll, kann ich auch nur bedingt bestätigen.
Hab selber eine Fritzbox 7490, sowie einen Fritzbox WLAN-Repeater 1150 im Einsatz (als MESH-Netz).
Nachts schalte ich das Gast-WLAN per TR64-Adapter immer aus; und dann haben sich
die Sonoffs, die am Repeater hingen auch netztechnisch verabschiedet.
Ich denke, daß es hier auch Unterbrechungen geben kann, die auf die Router/Repeater-Hardware
zurückzuführen ist.
Beim Anschalten des Gast-WLANs am Morgen gibt es dagegen keine Probleme.
MfG Markus
-
Danke für die Mühe.
Hab das Skript vom Marcus deaktiviert und den Adapter aktualisiert. Bei der Installation gab es einige fehler
! ````
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1
iobroker 2018-03-17 07:12:38.340 info WARN optional SKIPPING OPTIONAL DEPENDENCY: authenticate-pam@1.0.2 (node_modules/authenticate-pam):npm WARN optional SKIPPING OPTIONAL DEPENDENCY: authenticate-pam@1.0.2 install:node-gyp rebuild
iobroker 2018-03-17 07:12:38.335 info npm
iobroker 2018-03-17 07:12:16.800 info gyp ERR! not ok
iobroker 2018-03-17 07:12:16.800 info gyp ERR! node-gyp -v v3.4.0
iobroker 2018-03-17 07:12:16.800 info gyp ERR! node -v v6.11.5
iobroker 2018-03-17 07:12:16.800 info gyp ERR! cwd /opt/iobroker/node_modules/authenticate-pam
iobroker 2018-03-17 07:12:16.800 info gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
iobroker 2018-03-17 07:12:16.800 info gyp ERR! System Linux 4.9.59-v7+
iobroker 2018-03-17 07:12:16.800 info gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:219:12)
iobroker 2018-03-17 07:12:16.800 info gyp ERR! stack at ChildProcess.emit (events.js:191:7)
iobroker 2018-03-17 07:12:16.800 info gyp ERR! stack at emitTwo (events.js:106:13)
iobroker 2018-03-17 07:12:16.800 info gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
iobroker 2018-03-17 07:12:16.800 info ERR! build error gyp ERR! stack Error:makefailed with exit codeDer Adapter funktioniert aber. Ich halte euch auf dem laufenden. Schönes Wochenende Timm -
So ähnliche Fehler hatte ich auch. Ist bei mir sehr oft der Fall. Ich vermute mal, weil ich einen Orange Pi mit armbian nutze. Wahrscheinlich ist da der Zusammenbau der Pakete komplizierter und es muß meistens etwas compiliert werden.
Aber das sind nur Mutmassungen von mir, keinnen mich in den Tiefen der embedded Linuxwelt nicht aus.
-
Bei mir steigen immer noch einige sonoff aus und sind dann nicht mehr übern Broker zu erreichen.
! ````
2018-03-17 09:47:13.424 warn Client error [Terrasse_mitte]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 09:47:13.423 warn Client error [Terrasse_mitte]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 09:47:13.423 warn Client error [Terrasse_mitte]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 09:47:13.423 warn Client error [Terrasse_mitte]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 09:47:13.423 warn Client error [Terrasse_mitte]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 09:47:13.423 warn Client error [Terrasse_mitte]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 09:47:13.422 info Client [Terrasse_mitte] closed
sonoff.0 2018-03-17 09:47:06.033 info Client [Terrasse_mitte] connected
sonoff.0 2018-03-17 09:34:47.010 warn Client "Toaster" not connected
host.raspberrypi 2018-03-17 09:30:05.668 info instance system.adapter.dwd.0 terminated with code 0 (OK)
host.raspberrypi 2018-03-17 09:30:00.105 info instance system.adapter.dwd.0 started with pid 26881
host.raspberrypi 2018-03-17 09:12:09.552 info instance system.adapter.weatherunderground.0 terminated with code 0 (OK)
host.raspberrypi 2018-03-17 09:12:00.117 info instance system.adapter.weatherunderground.0 started with pid 25978
host.raspberrypi 2018-03-17 09:00:05.608 info instance system.adapter.dwd.0 terminated with code 0 (OK)
host.raspberrypi 2018-03-17 09:00:00.117 info instance system.adapter.dwd.0 started with pid 25383
sonoff.0 2018-03-17 08:52:23.475 warn Client "Toaster" not connected
sonoff.0 2018-03-17 08:52:20.802 warn Client "Toaster" not connected
sonoff.0 2018-03-17 08:47:55.441 warn Client error [Toaster]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:47:55.440 warn Client error [Toaster]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:47:55.440 warn Client error [Toaster]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:47:55.439 warn Client error [Toaster]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:47:55.439 warn Client error [Toaster]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:47:55.438 warn Client error [Toaster]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:47:55.437 info Client [Toaster] closed
sonoff.0 2018-03-17 08:46:33.307 info Client [Toaster] connected
host.raspberrypi 2018-03-17 08:30:05.824 info instance system.adapter.dwd.0 terminated with code 0 (OK)
host.raspberrypi 2018-03-17 08:30:00.100 info instance system.adapter.dwd.0 started with pid 23910
sonoff.0 2018-03-17 08:15:26.426 info Client [Terrasse_rechts] connected
sonoff.0 2018-03-17 08:15:25.318 warn Client error [Terrasse_rechts]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:15:25.318 warn Client error [Terrasse_rechts]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:15:25.313 warn Client error [Terrasse_rechts]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:15:25.313 warn Client error [Terrasse_rechts]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:15:25.312 warn Client error [Terrasse_rechts]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:15:25.311 warn Client error [Terrasse_rechts]: Error: This socket has been ended by the other party
sonoff.0 2018-03-17 08:15:25.303 info Client [Terrasse_rechts] closed
host -
Läuft bei Dir die 2.0.0?
Der party-Fehler kam bei mir gar nicht mehr.
Bei mir kam "sonoff.0 Client [SonoffS20-01] timeout"
oder "sonoff.0 Client [SonoffS20-01] closed"
Stelle das Adapter-Log mal auf debug. Dann sieht man auch die Pings alle 15 sec.
-
Ja es läuft die 2.0.0
Hatte den Party fehler zum teil über 24h gar nicht mit der 1.0.0.
Kann also gut sein das du noch etwas warten musst.
Mfg Timm
-
Du nutzt ja die Tasmota-Firmware.
Welche Version nutzt Du da? Die 5.12.0?
Mit der 5.12.0 haben einige User WLAN-Probleme gemeldet … vielleicht ist das bei Dir ja der Fall.
Dann entweder die 5.11.1 nehmen oder eine 5.12.0c oder höher per Atom.io und Platform.io
selber kompilieren und hochladen.
-
Habe auf allen 5.12.0e geflasht.
Bis jetzt keine neuen Ausfälle. Habe den Adapter nur 1x neu gestartet.
-
Auch daran gedacht nach Installation von GitHub nochmal ein Upload zu machen?
Also über erweiterte Einstellungen und dann bei der sonoff Instanz den Upload Button drücken.
Bin darüber auch schon mehr als einmal gestolpert … Da das Upload bei installationen von einer Urlaub nicht Automtisch geht ...des sei denn daß es inzwischen behoben wurde ....
-
Danke das war mir nicht bewusst. Hab ich jetzt mal nachgeholt.
Warum muss man das machen?
-
Ob es inzwischen behoben wurde weiss ich nicht …
Aber bei installationen von GitHub oder per Urlaub musste man sonstvei. Upload machen ...
Wohl um die Adminseiten upzudaten und auf die aktuellste Version zu bringen.
Irgendwie sowas ....
Hab mir daher angewöhnt bei Installation von GitHub direkt auch immer das Upload zu machen.
Ob es noch nötig ist weiss ich aber nicht wirklich ...
Ist eben nur ne Idee gewesen ...
-
Auch daran gedacht nach Installation von GitHub nochmal ein Upload zu machen?
Also über erweiterte Einstellungen und dann bei der sonoff Instanz den Upload Button drücken.
Bin darüber auch schon mehr als einmal gestolpert … Da das Upload bei installationen von einer Urlaub nicht Automtisch geht ...des sei denn daß es inzwischen behoben wurde ....
`Hallo zusammen.
Was genau meinst du mit Upload nach der Installation machen?
Danke im voraus für die Info.
Gruß Markus
-
Wenn man von GitHub installiert hat ….. Dann bei den Instanzen die erweiterten Enstellungen aktivieren .... Man sieht dann auf der rechten Seite in der Liste bei den Adaptern 2 Buttons mehr ..... Ei erdavon ist der Upload-Button ...
Jedenfalls bei Admin Adapter 2 .... In der 3er Version sieht das wohl anders aus ....
-
Wenn man von GitHub installiert hat ….. Dann bei den Instanzen die erweiterten Enstellungen aktivieren .... Man sieht dann auf der rechten Seite in der Liste bei den Adaptern 2 Buttons mehr ..... Ei erdavon ist der Upload-Button ...
Jedenfalls bei Admin Adapter 2 .... In der 3er Version sieht das wohl anders aus .... `
OK. Und das sollte man für jeden Adapter machen den man von
GitHub installiert hat?
Was genau wird denn dann auf den Pi hoch geladen?
Gruß Markus
-
Ich glaube die Admin-Seiten nur ….
-
Hier stand mal eine Erkenntnis über das EnergySaving, die sich aber als falsch herausstellte.
Aus diesem Grund habe ich das entfernt, um keine Verwirrung zu stiften!
-
Hi @Bluefox,
erstmal Danke für den schnellen Fix.
Den Streamserver haste ja rausgeschmissen.
Ich hatte selber bei mir eine von mir umgebaute server.js laufen,
die im Grunde dem entsprach,w as Du umgesetzt hast.
Anstatt eines Timeouts auf dem Stream hatte ich aber bei einem pingreq den pingresp
unterdrückt, wenn der Client geschlossen war.
Also sowas in der Art:
client.on('pingreq', (/*packet*/) => { if (clients[client.id]) { adapter.log.debug('Client [' + client.id + '] pingreq'); client.pingresp(); } });Das sollte dafür sorgen, daß bei einem "close" kein ping mehr
für den Stream eines geschlossenen Clients geschrieben werden sollte.
Sorgte im Endeffekt aber dafür, daß der Client nochmals geschlossen wurde,
das erste Mal durch den "socket has closed by other party" (ErrorCode: EPIPE),
um danach gleich nochmal wegen des Pings geschlossen zu werden ..
Bin halt kein Javascript-Experte … sondern nur echtem Java.
Ist wahrscheinlich auch falsch gewesen an der Stelle aber war eben ein Test von mir ...
Hab nun die Installation auf das neueste 2.0.0 geupdatet und lasse das mal so laufen
und schau was passiert.
Daß der Fehler mit WLAN-Qualität zu tun haben soll, kann ich auch nur bedingt bestätigen.
Hab selber eine Fritzbox 7490, sowie einen Fritzbox WLAN-Repeater 1150 im Einsatz (als MESH-Netz).
Nachts schalte ich das Gast-WLAN per TR64-Adapter immer aus; und dann haben sich
die Sonoffs, die am Repeater hingen auch netztechnisch verabschiedet.
Ich denke, daß es hier auch Unterbrechungen geben kann, die auf die Router/Repeater-Hardware
zurückzuführen ist.
Beim Anschalten des Gast-WLANs am Morgen gibt es dagegen keine Probleme.
MfG Markus `
Habe jetzt das übernommen und 2.0.1 auf npm gepublished. -
Ah! Das Update scheint gelungen.
Ich habe bisher keine Abbrüche.
Das ist deutlich zu merken und das Log ist leer.
-
Danke für die schnelle Umsetzung.
Aber inzwischen kam mir eine ganz andere Idee bzw. Erkenntnis
(jaaaaaaa .. ich bin voller Erkenntnisse, wenn es ums Finden einer Lösung geht … :-))
Und zwar:
Was passiert, wenn sich ein Client zweimal connected, ohne daß vorher ein close,error oder dergleichen kam?
Passiert nämlich beim Neustart eines Sonoffs immer ...
Szenario:
Sonoff wird das erste mal gestartet und im Adapter wird ein Client-Objekt angelegt, bezeichnen wir den mal als Pointer_A, samt Stream.
Nun wird der Sonoff nochmals gestartet und es erfolgt wieder ein Connect.
Hier wird dann, soweit ich das übersehen kann, ein neuer Client angelegt, sagen wir Pointer_B.
Es wird dabei nicht überprüft, ob der Client schon da ist oder dergleichen.
Somit ergeben sich dann für denselben Sonoff für den gleichen Client 2 Pointer-Objekte: A und B.
A und B haben immer noch einen eigenen Stream, da Pointer_A nie geschlossen wurde.
Im Endeffekt sieht man aber einen Timeout, der dann aber von Pointer_A zu kommen scheint und nicht Pointer_B.
Testen kann man das folgendermaßen:
1.) Sonoff-Adapter neu starten.
2.) sonoff verbindet sich und im Log steht "Client [sonoff] connected".
3.) Sonoff über WebUI neu starten.
4.) Es erscheint wieder die Meldung ""Client [sonoff] connected".
Diese dürfte dann der Punkt sein, an dem der Adapter 2 Streams für denselben Client im Speicher hält;
nämlich den "vergessenen Stream" vom ersten Connect und dann den aktuellen Stream für
das aktuelle Connect.
5.) Problem hierbei ist, daß für den vergessenen Stream dann der Timeout kommt
und der Adapter dann den Client aus der "connections"-Liste löscht, weswegen
dann kein Schalten mehr möglich ist.
Im Log erscheint nämlich folgendes:
2018-03-17 22:35:43.220 - info: sonoff.0 terminating 2018-03-17 22:35:43.228 - info: host.iobroker instance system.adapter.sonoff.0 terminated with code 0 (OK) 2018-03-17 22:35:45.223 - info: host.iobroker instance system.adapter.sonoff.0 started with pid 27509 2018-03-17 22:35:45.585 - info: sonoff.0 starting. Version 2.0.0 in /work/iobroker/node_modules/iobroker.sonoff, node: v8.9.4 2018-03-17 22:35:45.612 - info: sonoff.0 Starting MQTT authenticated server on port 1885 2018-03-17 22:36:01.754 - info: sonoff.0 Client [kinderzimmer-stehlampe] connected 2018-03-17 22:38:04.450 - info: sonoff.0 Client [kinderzimmer-stehlampe] connected 2018-03-17 22:41:02.164 - info: sonoff.0 Client [kinderzimmer-stehlampe] timeoutErgebnis ist: Sonoff funktioniert; nur er ist nicht mehr über ioBroker steuerbar.
Das erklärt dann auch, wieso noch immer Pings und Telemetrie-Infos ankommen,
aber man über iobroker nicht mehr schalten kann.
Müßte bei einem "connect" eines neuen CLients mit gleicher ID nicht geschaut werden, ob schon ein Client da ist und den terminieren?
Oder wenigstens den Stream eines bereits bestehenden Clients mit gleicher client.id löschen oder schließen?
Hatte das mal testweise so geändert:
client.on('connect' ... let oldClient = clients[client.id]; if (oldClient) { adapter.log.info('Client [' + client.id + '] reconnected'); oldClient.stream.end(); oldClient = undefined; } else { adapter.log.info('Client [' + options.clientId + '] connected'); } client.connack({returnCode: 0});Da nun aber der Stream feherhaft ist, wird der "neue" Client nun geschlossen und über dessen
Stream das LWT gesendet und der Client geschlossen, so daß sich der Sonoff nun wieder neu connected;
was eigentlich überflüssig ist. Die Änderung im PingReq wäre damit auch obsolet.
Im Log sieht das dann nämlich so aus:
2018-03-18 00:49:05.705 - info: sonoff.0 Client [kinderzimmer-stehlampe] connected 2018-03-18 00:51:43.537 - info: sonoff.0 Client [kinderzimmer-stehlampe] reconnected 2018-03-18 00:51:43.552 - info: sonoff.0 Client [kinderzimmer-stehlampe] Error: read ECONNRESET 2018-03-18 00:52:14.791 - info: sonoff.0 Client [kinderzimmer-stehlampe] connectedMan müßte also den "vergessenen Client/Stream" so termieren, daß kein Trigger mehr ausgeführt wird;
oder die Timepout-Methode ändern … oder ... oder .... oder ...
Wie gesagt; bin kein JavaScript-Experte, sondern eher Java und etwas C,
deswegen fiel mir das beim Testen auf. Nur Debuggen kann ich
das JavaScript nicht um zu sehen, welche Objekte in der VM/Speicher
denn nun wirklich bestehen.
Zum Schluß noch ein Kleiner Bug in Zeile 430,
bei dem "adapter.warn" durch "adapter.log.warn" ersetzt werden muß.
MfG Markus
-
Sodele ..
Ich hoffe ich habe nun die Lösung des Problems gefunden.
Jeder Client bekommt nun beim "connect" einen timestamp mit.
Sollte beim connect noch ein "vergessener" Client (was wohl nur ein Duplex-Stream ist) für die gleiche
Client-ID existieren, dann wird dieser "vergessene" Client geschlossen.
Dies passiert, weil die Sonoffs beim Neustart kein close/end mehr in den Stream zum Server schicken
und dieser Stream dann auf dem Server noch weiter rumidlet; aber für den Server dann noch immer aktiv;
hängt wohl mit der Implementierung der "mqtt-connection" zusammen …
Der timestamp eines Clients wird zudem beim Schließen eines Clients überprüft.
Passen die timestamps des Clients, der ein event bekommt, nicht mit dem
Timestamp des gespeicherten Clients überein, dann wird lediglich dieser "vergessene" Client geschlossen.
Sollte sich der Stream aus irgendwelchen Netzgründen verabschieden und weder Server noch Client (also der Sonoff)
kriegen was davon mit, dann greif der von Bluefox eingebaute Timeout und der Client wird geschlossen.
Letzter Sicherheitscheck ist dann der PingResponse, der nur dann bei einem PingRequest gesendet wird,
wenn der Timestamp des Clients, für den der Ping ist, mit dem gespeicherten Client-Timestamp übereinstimmt.
Ich habe dafür nun einen PullRequest beim ioBroker.sonoff auf GitHub erstellt.
Wäre schön wenn Bluefox nochmal drüber schaut und den commiten würde;
in der Hoffnung, daß ich mal richtiges Javascript geschrieben habe ...
Lösung wäre auch für den mqtt-Adapter evtl. interessant, da dort ähnliche Probleme auftauchen.
MfG Markus
