Autor Thema: WebSocket via DevIO?  (Gelesen 2160 mal)

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
WebSocket via DevIO?
« am: 06 April 2020, 07:43:45 »
Hallo zusammen,

Ich bastle gerade ein Modul, um die Daten meines Grünbeck-Wasserenthärters aus der Cloud zu lesen. Nun habe ich festgestellt, dass ein Teil der Daten (aktuelle Verbrauchdaten etc...) via Websocket kommt. Das ist „Neuland“ für mich. Bevor ich mich da im Detail einlese: Wäre das ein Fall für DevIO? Gibt es ein Modul, wo ich mir das mal ansehen kann?

Danke,

Grüße,

Oli


Gesendet von iPhone mit Tapatalk
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #1 am: 06 April 2020, 08:56:05 »
Zitat
Wäre das ein Fall für DevIO?
Ich meine ja. Wenn Du einen Patch hast...

Zitat
Gibt es ein Modul, wo ich mir das mal ansehen kann?
FHEMWEB.pm implementiert eine unvollstaendige Version eines Websocket Servers.
Im Wesentlichen: HTTP-Aufruf, was per HTTP-Upgrade-Headerzeile zu websocket wird. Die gesendeten Daten werden jeweils mit einer Laengenangabe geprefixt.
Problematisch bei DevIO: Control-Pakete wie ping, wo keine Daten fliesen.
Ich wuerde es erst mal im Modul implementieren, und wenn es funktioniert, dann nach DevIO portieren.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:WebSocket via DevIO?
« Antwort #2 am: 06 April 2020, 09:15:32 »
Ich meine ja. Wenn Du einen Patch hast...
FHEMWEB.pm implementiert eine unvollstaendige Version eines Websocket Servers.
Im Wesentlichen: HTTP-Aufruf, was per HTTP-Upgrade-Headerzeile zu websocket wird. Die gesendeten Daten werden jeweils mit einer Laengenangabe geprefixt.
Problematisch bei DevIO: Control-Pakete wie ping, wo keine Daten fliesen.
Ich wuerde es erst mal im Modul implementieren, und wenn es funktioniert, dann nach DevIO portieren.

Kann man in solchen Fällen heutzutage echt nicht "einfach mal" fertige Implementierungen nehmen?

https://metacpan.org/pod/release/VTI/Protocol-WebSocket-0.26/lib/Protocol/WebSocket.pm

Wenn einige Voraussetzungen erfüllt sind:

* Perl-Only (damit man das tatsächlich mit dem Source ausliefern kann)
* keine weiteren Abhängigkeiten, oder nur CORE, oder ebenfalls kleinere Perl-only
* stabil/funktional/gewartet

sehe ich keinen Grund warum man sich da nicht bedienen sollte.

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:WebSocket via DevIO?
« Antwort #3 am: 06 April 2020, 09:18:04 »
@KernSani

ich würde Unterstützung anbieten.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #4 am: 07 April 2020, 08:31:59 »
Danke erstmal. Ich werde mal modulspezifisch was basteln und mich melden, wenn ich nicht weiter komme.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #5 am: 07 April 2020, 08:52:21 »
Zitat
Im Wesentlichen: HTTP-Aufruf, was per HTTP-Upgrade-Headerzeile zu websocket wird. Die gesendeten Daten werden jeweils mit einer Laengenangabe geprefixt.
So ist es im SamsungAV realisiert.

Zitat
Kann man in solchen Fällen heutzutage echt nicht "einfach mal" fertige Implementierungen nehmen?
Wie heißt die Lib, die mit apt-get installiert werden kann ? Google brachte nicht die Erleuchtung.  :'(

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:WebSocket via DevIO?
« Antwort #6 am: 07 April 2020, 08:59:43 »
Als Debian Paket gibt's das Modul zur Zeit nur für Bullseye: https://packages.debian.org/bullseye/libprotocol-websocket-perl

Dazu muß man also die Bullseye Repositories apt hinzufügen und über "Pin-Priority" festlegen, daß nur libprotocol-websocket-perl daraus installiert wird. Ähnlich habe ich das auf einem anderen Pi für PiVPN mit Wireguard.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:WebSocket via DevIO?
« Antwort #7 am: 07 April 2020, 09:03:40 »
Moin,

die lib (CPAN) Protocol::WebSocket / und apt-get libprotocol-websocket-perl

Fertig oder cleanroom, wird ja hier immer mal wieder diskutiert. fhem bringt bereits eine Implementierung mit. (CPAN) Protocol::WebSocket ist, soweit ich auf die schnelle sehe, pure perl. Kann man also auch fix adaptieren.

edit: überschnitten. @mahowi, ich glaube debian (sid+) hat die auch so in den sources.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:WebSocket via DevIO?
« Antwort #8 am: 07 April 2020, 09:10:15 »
edit: überschnitten. @mahowi, ich glaube debian (sid+) hat die auch so in den sources.
Ja, in sid ist sie auch drin. Aber das ist ja auch testing. In allen (stabilen) Versionen davor bis inklusive Buster ist sie leider nicht dabei.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee
Informativ Informativ x 1 Liste anzeigen

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:WebSocket via DevIO?
« Antwort #9 am: 07 April 2020, 09:22:52 »
dies Beispiel zeigt imho warum es doch schön ist, wenn fhem das ootb mitbringt
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:WebSocket via DevIO?
« Antwort #10 am: 07 April 2020, 09:42:15 »
Prinzipiell ist es schön, wenn FHEM alles mitbringt. Andererseits halte ich es für unnötig, das Rad ständig neu zu erfinden, wenn es bereits praktikable Lösungen gibt.

Und wenn bereits existierende Bibliotheken z.B. in FHEM/lib kopiert werden, führt das dazu, daß dort im Laufe der Zeit wahrscheinlich veraltete Versionen liegen, die keiner mit der ursprünglichen Version synchronisiert. Das ist dann wie bei vielen Windows-Programmen, die Standard-Bibliotheken mitbringen und im eigenen Verzeichnis ablegen. Man hat hinterher dieselben Dateien in unterschiedlichen Versionen überall im System verteilt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10466
  • eigentlich eher "user" wie "developer"
Antw:WebSocket via DevIO?
« Antwort #11 am: 07 April 2020, 10:05:41 »
Vielleicht verstehe ich von diesen ganzen Dingen zu wenig, will aber mal als Stichwort "perlbrew" in den Raum werfen, nachdem das jüngst in anderen Zusammenhängen hier in den Raum geworfen wurde...

Kurz zum Hintergrund:
Was die Perl-Basis angeht, hatte ich bisher immer versucht, nur das zu installieren, was das OS kannte (via apt-get), vor allem, damit alles auf einem zueinander passenden Stand ist. Mit cpan war ich immer sehr vorsichtig, und wenn, dann habe ich dh-make verwendet, um Debian-Pakete zu bauen, die man auch wieder deinstallieren kann.

Von perlbrew habe ich jetzt verstanden, dass man das nutzen kann, um
- neuere (oder ältere) Versionen von Perl-Paketen zu erhalten, und zwar alle auf demselben "Perl-Stand"
- darüber ggf. auch zusätzliche Pakete "in der richtigen Version" zu installieren.
Tendenziell würde ich jetzt dazu neigen, mir perlbrew etwas näher anzusehen, weil das ggf. Perl "aktueller" halten kann und dabei manche Probleme gar nicht entstehen würden, die ich seither über den dh-make Weg lösen wollte, ohne genau zu wissen, ob das wirklich klappt...

Frage: Wäre das nicht ein genereller Ansatzpunkt, um auf "Doppelungen" verzichten zu können, oder fürchten wir dadurch das Oberchaos, weil dann eben plötzlich "Fremdpakete" eine viel größere Rolle spielen könnten?

Es ist mir durchaus bewußt, dass der eine oder andere User dann möglicherweise völlig "verloren" bei der Frage ist, wo was zu finden und zu aktualisieren ist, wenn er jetzt noch eine "Ebene" zwischen dem OS und FHEM präsentiert bekommt. Aber evtl. ist das das kleinere Übel?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:WebSocket via DevIO?
« Antwort #12 am: 07 April 2020, 10:35:55 »
perlbrew https://perlbrew.pl/ hilft eigentlich erstmal unterschiedliche perl Versionen parallel zu betreiben (und /auch welche die es vom OS garnicht gibt)

CPAN braucht man trotzdem

Zitat
Frage: Wäre das nicht ein genereller Ansatzpunkt, um auf "Doppelungen" verzichten zu können, oder fürchten wir dadurch das Oberchaos, weil dann eben plötzlich "Fremdpakete" eine viel größere Rolle spielen könnten?
Ich mag die Diskussion gar nicht nicht führen. Fakt ist, fhem bringt mqtt. json, websocket, web mit, Abhängigkeiten im grossen und ganzen keine ausser core. Bedeutet, man kann sich das Paket vom fhem Server runterladen, starten  - läuft ohne "gefrickel" (CPAN, apt-get)

Auf der anderen Seite gibt's einige Module die setzen externe Bibliotheken vorraus. Guter Stil ist es das in deutlich in die Doku zu schreiben und dafür zu sorgen dass keine Abstürze durch nichtvorhandene Abhängigkeiten entsehen (bspw eval). Zusätzlich muss man als Autor dann sehr genau darauf achten dass keine blocking calls stattfinden (LWP zb, das muss einfach nicht sein -> httputils nonblocking get).
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10466
  • eigentlich eher "user" wie "developer"
Antw:WebSocket via DevIO?
« Antwort #13 am: 07 April 2020, 10:52:44 »
Dass man cpan braucht, war gar nicht die Frage, vermutlich ist das "Problem" auch, dass ich mich mit der Funktionsweise von cpan schlicht bisher nie beschäftigt habe bzw. was da ganau passiert, wenn man was darüber installiert (insbesondere: Welche Version bekommt man darüber eigentlich...?). War immer eher ein "großes dunkles Loch", das ich tunlichst gemieden hatte...

Wenn ich das hier https://opensource.com/article/18/7/perlbrew (ziemlich unten) richtig verstanden habe, gibts via Perlbrew jedenfalls Möglichkeiten, das so zu machen, dass man ggf. mehrere Versionen parallel hat. Wenn cpan das im Standard auch so gut macht, soll es mir recht sein ;D .

Ansonsten fand ich den bisherigen Angang auch sympatisch, für eine "normale Installation" möglichst auf "externes Gedöns" verzichten zu können und sich mit solchen Fragen gar nicht erst auseinandersetzen zu müssen. Aber meistens kommt eben irgendwann der Punkt, an dem man doch über irgendwas stolpert (und sei es nur, um es anzutesten), für das man eben weitere Pakete irgendwoher nehmen muß...

(Wollte euch also mit meiner Anmerkung keinesfalls davon abhalten, sinnvolle Erweiterungen vorzunehmen!)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #14 am: 07 April 2020, 10:53:53 »
Bei perlbrew ist das Einbinden von Perl-Modulen nicht immer trivial, wenn sie von Fremdbibliotheken wie OpenSSL abhaengen. Jenachdem, ob man erfahrener und/oder ausdauernder ist als der Maintainer der Distribution (dem perl mit seinen Modulen nicht die oberste Prio darstellt), kann man damit eine bessere Loesung haben oder nur Zeit verlieren. Fuer Support kann es auch ein Problem bedeuten, weil mit perlbrew so ziemlich sicher jeder eine einmalige Kombination von Modulversionen hat. Ich bin nicht prinzipiell gegen perlbrew (ich verwende es auch), das wird aber fuer Anfaenger nicht die Loesung sein.

Ob man fuer Websocket eine externe Bibliothek verwendet, oder ob man es selbst impementiert, sollte dem Entwickler ueberlassen werden: ich kann fuer beide Loesungen gute Argumente aufzaehlen. Mir ist nur wichtig, dass man Nonblocking beachtet.
Informativ Informativ x 1 Hilfreich Hilfreich x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:WebSocket via DevIO?
« Antwort #15 am: 07 April 2020, 11:10:59 »
perlbrew https://perlbrew.pl/ hilft eigentlich erstmal unterschiedliche perl Versionen parallel zu betreiben (und /auch welche die es vom OS garnicht gibt)

CPAN braucht man trotzdem
Ich mag die Diskussion gar nicht nicht führen.

Ja, aber vielleicht mag sie jemand anders führen.

@Beta-User

Perlbrew ermöglicht all das was Hermann gesagt hat aber vor allem entkoppelt es OS Updates von "Perl Infrastruktur Updates". D.h. wenn man mal sein Stretch auf Jessie Buster oder sonstwas updated, bedeutet das, dass Deine Perlbrew-Perl Installation erstmal unangetastet bleibt. Allerdings bedeutet perlbrew auch: Man hat eine Compile-Infrastruktur auf der Maschine. Von daher sehe ich perlbrew derezit nur für Entwickler (da würde ich das schon in "Pflicht" Regionen sehen), bzw. für den ambitionierten User, der ggf. bei der Installation mehr Aufwand treiben will, dafür bei den Updates weniger.

Allgemein würde ich perlbrew dem Feld-Wald-Wiesen User nicht empfehlen.

Zitat
Fakt ist, fhem bringt mqtt. json, websocket, web mit, Abhängigkeiten im grossen und ganzen keine ausser core. Bedeutet, man kann sich das Paket vom fhem Server runterladen, starten  - läuft ohne "gefrickel" (CPAN, apt-get)

Naja ... das ist nicht komplett korrekt, FHEM bringt natürlich je nach Modul noch andere Abhängigkeiten mit sich, teilweise OS abhängig und nicht abgefangen im Code. So verlangen einige Module - 42_SMARTMON fällt mir da spontan ein - externe (Linux) Binaries, die man eh via apt-get oder irgendwie anzukarren hat.

Zitat
Auf der anderen Seite gibt's einige Module die setzen externe Bibliotheken vorraus. Guter Stil ist es das in deutlich in die Doku zu schreiben und dafür zu sorgen dass keine Abstürze durch nichtvorhandene Abhängigkeiten entsehen (bspw eval). Zusätzlich muss man als Autor dann sehr genau darauf achten dass keine blocking calls stattfinden (LWP zb, das muss einfach nicht sein -> httputils nonblocking get).

Nuja. LWP sind schon schwere Kanonen, aber die Doku https://metacpan.org/pod/LWP#The-User-Agent spricht relativ deutlich einen timeout Parameter an.

Ich befürworte den Ansatz "möglichst wenig Gefrickel" bei der Installation und "noch weniger Gefrickel" beim Update. Da geht aber IMHO mehr, als man bei FHEM derzeit zu tun bereit ist. Und irgendwie passt es nicht für mich zusammen auf der einen Seite zu sagen "wir haben so wenig Entwicklerkapazität/Zeit/Lust was neu zu machen" und dann "wir machen lieber unsere eigene Implementierung".

Würde ich das jetzt malevolent interpretieren wollen, würde ich sagen "Not Invented Here"-Syndrom Terminalstadium.
Aber ich interpretiere ja stets benevolent.

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:WebSocket via DevIO?
« Antwort #16 am: 07 April 2020, 11:17:19 »
Dass man cpan braucht, war gar nicht die Frage, vermutlich ist das "Problem" auch, dass ich mich mit der Funktionsweise von cpan schlicht bisher nie beschäftigt habe bzw. was da ganau passiert, wenn man was darüber installiert (insbesondere: Welche Version bekommt man darüber eigentlich...?). War immer eher ein "großes dunkles Loch", das ich tunlichst gemieden hatte...
Über CPAN bekommst Du die jeweils aktuellste Version. Die Module werden unter /usr/local installiert, so daß keine unter /usr installierten Dateien überschrieben werden. Auch deinstallieren geht mit cpanm --uninstall.

Die einzigen Module, dich ich bisher nur über CPAN und nicht als Debian-Paket gefunden habe, waren Net::MQTT::... Die werden (zumindest laut Wiki) für MQTT benötigt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee
Informativ Informativ x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10466
  • eigentlich eher "user" wie "developer"
Antw:WebSocket via DevIO?
« Antwort #17 am: 07 April 2020, 11:28:33 »
Allgemein würde ich perlbrew dem Feld-Wald-Wiesen User nicht empfehlen.
Diese Schlußfolgerung lag nach Rudi's Anmerkung schon nahe.

Und ja: perlbrew wird seinen Weg auf mein Laptop finden... Viele Dinge waren halt bisher nicht notwendig, und bitte entschuldigt, wenn meine Anmerkung hier kurz vom eigentlichen Thema des Threads abgelenkt haben sollten ::) .

@mahowi: Thx für die näheren Hintergründe. MQTT (alt bzw. Generic Bridge) war auch der Anwendungsfall, bei dem ich über dh-make gegangen war (die betreffenden Hinweise im Wiki zu dem Tool stammen von mir...). Ansonsten hast du recht, das ist selten, dass man cpan überhaupt bemühen muss.
Btw: Mit dh-make kann man afaik auch rausfinden, ob es ein verfügbares Debian-Paket gibt: " dh-make-perl locate xyz"
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Informativ Informativ x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:WebSocket via DevIO?
« Antwort #18 am: 07 April 2020, 11:47:45 »
Diese Schlußfolgerung lag nach Rudi's Anmerkung schon nahe.

Es ist auch distributionsabhängig. Ok, wenn jemand Gentoo verwendet ist er vermutlich eh kein FWW-User, k.A. ob sich "Arch Linux" User auch in dieser Kategorie sehen. Prinzipiell gilt: Man spart sich viel Leid wenn man bei einer "Versionless Linux Distri" perlbrew benutzt.

Oder auch eine Distri wie Ubuntu, die automatisch Updates fährt (wobei wer sowas bei seiner Haussteuerung macht, der hat auch in jedem Zimmer ein Damoklesschwert hängen)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10466
  • eigentlich eher "user" wie "developer"
Antw:WebSocket via DevIO?
« Antwort #19 am: 07 April 2020, 12:12:02 »
Es ist auch distributionsabhängig. Ok, wenn jemand Gentoo verwendet ist er vermutlich eh kein FWW-User, k.A. ob sich "Arch Linux" User auch in dieser Kategorie sehen. Prinzipiell gilt: Man spart sich viel Leid wenn man bei einer "Versionless Linux Distri" perlbrew benutzt.

Oder auch eine Distri wie Ubuntu, die automatisch Updates fährt (wobei wer sowas bei seiner Haussteuerung macht, der hat auch in jedem Zimmer ein Damoklesschwert hängen)
Klar ist die Welt ziemlich bunt, aber vielleicht dazu noch ein paar OT-Anmerkungen (bewußt plakativ, ist nicht böse gemeint): "gefühlte" 98% der Linux-"User" hier nutzen eine Himbeere und sind dabei ganz überwiegend schon froh, wenn sie "sudo" fehlerfrei getippt bekommen und sich nicht damit auseinandersetzen müssen, was der Unterschied zwischen einem Befehl mit und ohne diese 4 letters ist.

Schon die Empfehlung, doch bitte keine GUI zu installieren, sondern "headless" zu fahren, finden die als unangemessene Gängelung (teils auch, weil ein beliebter Videoblogger, dessen "Kenntnisse" teils als das Maß der Dinge angesehen werden, das mal mit GUI vorgemacht hat...).

Ergo:
Bitte im Hinterkopf behalten, dass das "Damoklesschwert" in Form von raspbian über den meisten der Köpfe hier hängt, und zwar zu allem Überfluß noch zu 100% über genau all denen, die keinen Plan haben, wie sie sich notfalls selbst helfen können...
Dann gibt es noch einige Minderheiten, wobei Debian und Ubuntu auch da weit dominierend sein dürften.

(Btw.: ich bin ca. Mitte 2014 von der Fritte (AVM Fritzbox) auf debian-basierte Serversysteme (neben der Himbeere im Lauf der Zeit alles mögliche) umgestiegen, kann mich aber an kein (FHEM betreffendes) Problem erinnern, das auf ein OS-update zurückzuführen gewesen wäre - und ich mache regelmäßig updates. Von daher: Ja, das ist ein Thema, aber man sollte es nicht überbewerten! Besser ein aktuelles OS und Restrisiken beim updaten als nicht geschlossene, aber bekannte Sicherheitslücken...
Aber auch das legt nahe: möglichst wenig externes "Zeug" (Abhängigkeiten, Zusatzpakete usw.), denn da kommt zumindest bei mir schnell das Gefühl auf, dass es "schwammig" wird, wenn es mal Probleme gibt.)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:WebSocket via DevIO?
« Antwort #20 am: 07 April 2020, 12:32:38 »
Schon die Empfehlung, doch bitte keine GUI zu installieren, sondern "headless" zu fahren, finden die als unangemessene Gängelung (teils auch, weil ein beliebter Videoblogger, dessen "Kenntnisse" teils als das Maß der Dinge angesehen werden, das mal mit GUI vorgemacht hat...).

Ja aber Gängelung der User ist doch die einzige Entlohnung die man bekommt wenn man die Software schon kostenlos abgibt! Oder nicht?  ;)

Will sagen: Ich stimme ja prinzipiell zu.

* kein perlbrew für Normalsterbliche
* Code muss robust geschrieben sein, dass er bei fehlenden Abhängigkeiten nicht alles in den Abgrund reisst

Ich stimme nicht zu:

* Wir liefern unter keinen Umständen CPAN code mit

Ich mache das in Hobo, z.B. für Export::Attrs. Das sind 12KB reiner distri- & architekturunabhängiger Perl Code, der wohl auch die nächsten 10 Jahre ohne Updates tun wird.
Kein Gefrickel für den User, extreme Erleichterung für den modulbewussten Entwickler. Und solche non-CORE Module gibt es einige. Die würde ich nicht dogmatisch ausschliessen.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16260
  • s/fhem\.cfg/configDB/g
Antw:WebSocket via DevIO?
« Antwort #21 am: 07 April 2020, 13:48:37 »
In allen (stabilen) Versionen davor bis inklusive Buster ist sie leider nicht dabei.

wget http://ftp.de.debian.org/debian/pool/main/libp/libprotocol-websocket-perl/libprotocol-websocket-perl_0.26-2_all.deb
dpkg -i libprotocol-websocket-perl_0.26-2_all.deb

Geht auch mit Buster.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25321
Antw:WebSocket via DevIO?
« Antwort #22 am: 07 April 2020, 13:56:03 »
Debian ist die einzige Distribution welche ich kenne die eine Unmenge an zusätzlicher Perlmodule mitliefert. Versuch mal bei OpenSuse was zu finden. Kannste knicken.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:WebSocket via DevIO?
« Antwort #23 am: 07 April 2020, 13:56:57 »
wget http://ftp.de.debian.org/debian/pool/main/libp/libprotocol-websocket-perl/libprotocol-websocket-perl_0.26-2_all.deb
dpkg -i libprotocol-websocket-perl_0.26-2_all.deb

Geht auch mit Buster.

Natürlich kann ich mir jedes Debian Package auch irgendwo runterladen und mit dpkg installieren. Sauberer finde ich aber den Weg, die Sourcen einzubinden.

/etc/apt/sources.list.d/bullseye.list:
deb https://mirror.netcologne.de/raspbian/raspbian/ bullseye main
/etc/apt/preferences.d/limit-bullseye:
Package: *
Pin: release n=bullseye
Pin-Priority: -1

Package: libprotocol-websocket-perl
Pin: release n=bullseye
Pin-Priority: 100

So bekomme ich auch Updates, falls es welche gibt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25321
Antw:WebSocket via DevIO?
« Antwort #24 am: 07 April 2020, 13:59:27 »
Natürlich kann ich mir jedes Debian Package auch irgendwo runterladen und mit dpkg installieren. Sauberer finde ich aber den Weg, die Sourcen einzubinden.

/etc/apt/sources.list.d/bullseye.list:
deb https://mirror.netcologne.de/raspbian/raspbian/ bullseye main
/etc/apt/preferences.d/limit-bullseye:
Package: *
Pin: release n=bullseye
Pin-Priority: -1

Package: libprotocol-websocket-perl
Pin: release n=bullseye
Pin-Priority: 100

So bekomme ich auch Updates, falls es welche gibt.

Na hoffentlich nimmt das jetzt kein User zum testen. Sonst ist seine buster Installation gleich im Eimer  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:WebSocket via DevIO?
« Antwort #25 am: 07 April 2020, 14:26:04 »
Na hoffentlich nimmt das jetzt kein User zum testen. Sonst ist seine buster Installation gleich im Eimer  ;D
Eigentlich sollte man sich damit nichts zerschiessen können.

Zitat von: man apt_preferences
       100 <= P < 500
           veranlasst, dass eine Version installiert wird, außer wenn eine Version verfügbar ist, die zu einer
           anderen Distribution gehört oder die installierte Version neuer ist

       0 < P < 100
           veranlasst, dass eine Version nur dann installiert wird, wenn es keine installierte Version des Pakets
           gibt

       P < 0
           verhindert das Installieren der Version

Da ich für alle Pakete (*) Pin-Priority: -1 gesetzt habe, wird auch außer den explizit aufgeführten nichts aus Bullseye installiert.

Mutwillig kaputt machen geht natürlich immer noch.  ;D

Im Übrigen installiert PiVPN auf die Art auch wireguard inkl. Kernel-Modulen auf einem Debian Buster.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16260
  • s/fhem\.cfg/configDB/g
Antw:WebSocket via DevIO?
« Antwort #26 am: 07 April 2020, 14:39:45 »
Natürlich kann ich mir jedes Debian Package auch irgendwo runterladen und mit dpkg installieren.

Den von mir genannten FTP Server von Debian würde ich jetzt nicht zwingend als "irgendwo" einstufen. Und man muss das auch nicht für jedes Paket so machen, sondern nur für die Pakete, die im Standard nicht in den Quellen vorhanden sind - wofür es meistens gute Gründe gibt.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #27 am: 01 Mai 2020, 00:48:30 »
Zurück zum Ursprungsthema. Ich habe das jetzt mal hier umgesetzt: https://forum.fhem.de/index.php/topic,110323.0.html
Nutzt DevIO und Protocol::WebSocket::Client. Kann man sicher schöner machen, aber funktioniert erstmal. Im BOTVAC Modul gibt es übrigens eine WebSocket-Implementierung mit DevIo, die ohne Protocol::WebSocket::Client auskommt. Vielleicht kann man sich auch daran orientieren.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:WebSocket via DevIO?
« Antwort #28 am: 01 Mai 2020, 19:10:36 »
die lib (CPAN) Protocol::WebSocket / und apt-get libprotocol-websocket-perl

Fertig oder cleanroom, wird ja hier immer mal wieder diskutiert. fhem bringt bereits eine Implementierung mit. (CPAN) Protocol::WebSocket ist, soweit ich auf die schnelle sehe, pure perl. Kann man also auch fix adaptieren.

Ist pure-Perl, gerade gründlich getestet.
Und gleich assimiliert: https://gl.petatech.eu/root/HomeBot/-/commit/1d37880dbca37f4f92079548842acde1b492288c

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #29 am: 23 Mai 2020, 17:45:18 »
Hi Oli,
ich hab mir Dein Kunstwerk mal angesehen, weil ich gerade auch für ein neues Modul mit websocket arbeiten muss u. gerne die SelectLoop nutzen möchte.

Du hast ja noch ne Menge httputils-Zugriffe im Modul, aber ich interpretiere das mal als zusätzliche Zugriffe bei get-/set-Befehlen ?(Machen es nicht gerade übersichtlich für mich  :()

Will heißen, Deine Logik bildet tatsächlich websocket-Zugriff für/mit DevIO und den Vorteilen von ...Read u. ...Ready sowie disconnect ab ?
Möchte halt sichergehen bevor ich den Aufwand betreibe u. Dein Konstrukt noch nicht vollständig verstanden habe.

Und TLS hast Du ja auch problemlos genutzt, richtig ?

Schönes We
Markus
PS: Wär ja schon schön es in DevIO zu haben. ;)
Ich meine ja. Wenn Du einen Patch hast...
.
.
Ich wuerde es erst mal im Modul implementieren, und wenn es funktioniert, dann nach DevIO portieren.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #30 am: 23 Mai 2020, 18:34:41 »
Hi Markus,

mein Werk ist sicher nichts was man so nach DevIO portieren könnte :-D Korrekt, ich habe eine Menge "normale" Abfragen. Über Websocket kommen beim Entkalker nur so Daten wie aktuelle Durchflussmenge etc...

Was du brauchst (und gerne schöner lösen kannst) sind die Sub wsConnect und ales was danach kommt.

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #31 am: 23 Mai 2020, 18:42:23 »
Danke Dir
Zitat
Sub wsConnect und ales was danach kommt.
So sah ich das und meine verstanden zu haben, dass du "vorher"(negotiate) nur einen "Schlüssel" holst.
Zitat
und gerne schöner lösen kannst
Wohl kaum.  ;) Bin froh, wenn ich das per cut&paste hinbekomme. Vielleicht erbarmt sich Rudi mal. ;) Kommen ja immer mehr devices hinzu.

Grüße Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #32 am: 24 Mai 2020, 11:18:39 »
Hi Oli,
ich glaub Du hast mich ganz schön durch Deine Namensgebung aufs Glatteis geführt. wsfail hab ich gelesen u. nicht weiter über DevIo nachgedacht. Und      Log3 $name, LOG_ERROR, qq ([$name] - error while connecting to Websocket: $error);hat mich noch im Gedanken bestätigt. Ich hab mir das Hirn zermartert, was da bei mir schief läuft. Aber bei DevIo ist es ja gar keine fail-Funktion(wie bei blockingcall), sondern der callback für die non-blocking-variante. Danach erfolgt dann erst die init-func. Will heißen, Namensgebung verwirrend u. es fehlt noch ein if auf $error.

Ich hab aber noch 2 andere Probleme, dazu per edit später mehr.....

Grüße Markus

Edit: so, jetzt sehe ich klarer
1. Warum $client->read($recv_data);in while von wsHandshake ? Das ist doch die http-connect-message ?
2. $hash->{helper}{wsClient} wird für mich noch nicht nachvollziehbar nicht befüllt. Sicherlich ein indiv. Problem. >:(
3. Ich denke der Server macht nach einer Zeit einen close, weil ich keine Authentication(wg. 2.) mache.
    Aber wieso kommen (vermeintliche) frame-Header-Fragmente an ?  :o
    Ich dachte das löst nun Protocol::Websocket für mich(im Gegensatz zur "manuellen" Variante, wo ich mich selber drum kümmern muss)?
Zitat
2020.05.24 11:40:21 5: [EET] solmate Received from socket: 52fd080b
2020.05.24 11:40:41 5: [EET] solmate Received from socket: 03fd
2020.05.24 11:41:04 5: [EET] solmate Received from socket: fd27fdfd
2020.05.24 11:41:24 5: [EET] solmate Received from socket: 03fd
2020.05.24 11:41:47 5: [EET] solmate Received from socket: 33e3fd
Und wenn nicht, wo hast Du das abgefangen ? ??? :-\ :-[
« Letzte Änderung: 24 Mai 2020, 12:12:54 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #33 am: 24 Mai 2020, 11:56:21 »
Zitat
Vielleicht erbarmt sich Rudi mal. ;) Kommen ja immer mehr devices hinzu.
Wie kann man sowas einfach testen, ausser mit FHEMEB?

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #34 am: 24 Mai 2020, 12:00:17 »
Hi Oli,
ich glaub Du hast mich ganz schön durch Deine Namensgebung aufs Glatteis geführt. wsfail hab ich gelesen u. nicht weiter über DevIo nachgedacht. Und      Log3 $name, LOG_ERROR, qq ([$name] - error while connecting to Websocket: $error);hat mich noch im Gedanken bestätigt. Ich hab mir das Hirn zermartert, was da bei mir schief läuft. Aber bei DevIo ist es ja gar keine fail-Funktion(wie bei blockingcall), sondern der callback für die non-blocking-variante. Danach erfolgt dann erst die init-func. Will heißen, Namensgebung verwirrend u. es fehlt noch ein if auf $error.

Ich hab aber noch 2 andere Probleme, dazu per edit später mehr.....

Grüße Markus
Das erklärt dann vielleicht auch das komische Verhalten, das ich gelegentlich beobachte :-D Schaue ich mir nochmal an...


Kurz, weil mobil....
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #35 am: 24 Mai 2020, 12:21:43 »
dann bitte auch ein Blick auf das edit meines Posts...

Zitat
Wie kann man sowas einfach testen, ausser mit FHEMEB?
Bin mir nicht sicher, ob ich Dich richtig verstanden hab: Man kann es meines Erachtens nur über die Modulentwicklung wie bei Oli u. mir(inet-Server !)
Wenn ich so weit wäre, würd ich SamsungAV(derzeit mit http, upgrade ws, frame-handling) umbauen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:WebSocket via DevIO?
« Antwort #36 am: 24 Mai 2020, 12:34:34 »
Zum Test reicht ein Echo Server
https://www.websocket.org/echo.html
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #37 am: 24 Mai 2020, 12:43:09 »
Oh Mann. Der ist ja klasse.  :-* Hätte mir Stunden, Nächte, wscat... gespart.... >:(
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #38 am: 24 Mai 2020, 19:51:09 »
Hi Oli,
ich kann mir mittlerweile nicht mehr vorstellen, dass bei Dir das write funktioniert. Ein read nur deshalb, weil Du die framing bytes irgendwie eliminierst.

 Nach diversen Abstürzen, Zusatzlogging ....habe ich mal write mit simple_write gemacht. Kein Absturz. Beim anschließenden read bekomme ich nur framing bytes. Letzteres kenne ich aber schon, da ich das bei der "manuellen" Variante(also http, upgrade websocket...). auch hatte. Es ist einfach ein finales frame ohne payload mit opcode 0x08(close) vom Server, weil ihm der payload nicht gefiel.

Ich schätze neben dem o.g. die Situation nun so ein:
- websocketaufbau (mit TLS) funktioniert bestens(das Modul macht nichts anderes als das bekannte http-get, upgrade)
- Nutzung von DevIo funktioniert mit seinen Funktionen open, read, write, is_open. Read_Fn u. Ready_Fn auch.
- für read muss das frame um die framing bytes gestripped werden; vor dem write um die framing bytes ergänzt; und schließlich brauchen wir die Inhalte der framing bytes, da z.B. manchmal der Server ohne payload antwortet, aber z.B. der opcode(z.B. close) für die Weiterverarbeitung nötig ist.

@Rudi: prüft DevIo eigentlich in irgendeiner Form(z.B. ping)zyklisch , ob die Verbindung noch steht ?
Wenn ja, würde das zu einem close der Verbindung führen.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #39 am: 24 Mai 2020, 20:23:06 »
Zitat
@Rudi: prüft DevIo eigentlich in irgendeiner Form(z.B. ping)zyklisch , ob die Verbindung noch steht ?
Natuerlich nicht.

Websocket koennte so in DevIo eingebaut werden:
- DevIo_OpenDev uebernimmt HTTP connect und upgrade
- DevIo_SimpleRead packt die Daten aus, und beantwortet Ping & co. ReadFn (wo SimpleRead aufgerufen wird) muss mit "" als Rueckgabewert klarkommen, und dabei nichts tun. undef bedeutet Ende der Verbindung.
- DevIo_SimpleWrite packt die Daten vorm Schreiben ein. Ist noch unklar, ob dabei direkt geschrieben wird, oder die Daten ins WriteBuffer gesteckt werden.

Online herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:WebSocket via DevIO?
« Antwort #40 am: 24 Mai 2020, 20:32:08 »
Für die frames würde es cpan Module geben. Die machen auch gleich binary, verschiedene Standards usw. Vielleicht doch Überlegenswert ? siehe KernSanis Beitrag unten  ;)
« Letzte Änderung: 24 Mai 2020, 23:19:30 von herrmannj »
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #41 am: 24 Mai 2020, 22:43:56 »
@Markus:

Hi Oli,
ich glaub Du hast mich ganz schön durch Deine Namensgebung aufs Glatteis geführt. wsfail hab ich gelesen u. nicht weiter über DevIo nachgedacht. Und      Log3 $name, LOG_ERROR, qq ([$name] - error while connecting to Websocket: $error);hat mich noch im Gedanken bestätigt. Ich hab mir das Hirn zermartert, was da bei mir schief läuft. Aber bei DevIo ist es ja gar keine fail-Funktion(wie bei blockingcall), sondern der callback für die non-blocking-variante. Danach erfolgt dann erst die init-func. Will heißen, Namensgebung verwirrend u. es fehlt noch ein if auf $error.
Ich habe jetzt extra nochmal nachgelesen. Die initFn (in meinem Fall wsHandshake) wird bei erfolgreichem Verbindungsaufbau aufgerufen, die callBackFn (in meinem Fall wsFail) wird aufgerufen, wenn die Verbindung nicht hergestellt werden kann. Die CallbackFn führt zusätzlich dazu, dass die Verbindung nonBlocking aufgebaut wird.

In wsHandshake wird dann eine Instanz von Protocol::WebSocket::Client erzeugt. Diese kümmert sich um das Ganze framing Gedöns.
Write brauche ich in meinem Szenario nicht und habe ich nicht getestet, aber bei read passiert folgendes:
Über die ReadFn (wsReadDevIo) bzw. darin Simple_Read kommen Daten. Diese übergebe ich an den zuvor definierten client (Protocol::WebSocket::Client) der sich um das framing kümmert und ich kann in parseWebsocketRead die Inhalte auswerten. Kurz tcpsocket-Aufbau und "Raw"-Kommunikation erfolgt über DevIo, Protocol::WebSocket::Client kümmert sich um die Websocket-Spezifika.

Was mir noch unklar ist: Ich habe gelegentlich Einträge im Log:
Strange call for nonexistent : ReadFnDiese stehen in keinem zeitlichem Zusammenhang zu den Websocket-Verbindungen, ich habe aber den Verdacht, dass da noch irgendwo DevIo-Leichen herumschwirren, die ich noch nicht näher aufspüren konnte.



RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #42 am: 25 Mai 2020, 08:54:32 »
Hi Oli,
Zitat
die callBackFn (in meinem Fall wsFail) wird aufgerufen, wenn die Verbindung nicht hergestellt werden kann.
Das stimmt so nicht.
Zitat
Der Rückgabewert enthält im Fehlerfall eine entsprechende Fehlermeldung. Im Erfolgsfall wird undef zurückgegeben.
Sie wird immer aufgerufen und in Deinem Fall fehlt im Erfolgsfall dann eben ein kleines if auf undef, um die Logmeldung dann nicht abzusetzen.

Zitat
Diese kümmert sich um das Ganze framing Gedöns.
Das glaube ich auch nicht. Sonst bekäme ich ja nicht die framing bytes. Und beim write setzt Du ja nirgends opcode, FIN-bit....
Ich bin aber leider auch mal wieder zu blöd OOP-Perl so richtig zu verstehen.  :-[ Und kriege es deshalb auch nicht besser hin.
Beispiel: Du machst die Zuweisung des Objekts/Socket
    $hash->{helper}{wsClient} = $client; um es Dir zwischenzuspeichern. Das wird aber gar nicht befüllt(zumindest bei mir nicht, steht da bei Dir etwa was drin ?). Und weil das(zumindest bei mir) nicht klappt, habe ich ja im nächsten Aufruf überhaupt keinen Bezug mehr zum Objekt ?!?!? Deshalb meine Abstürze. Mache ich es mit simple_write, dann klappt es im Prinzip, weil devIo ja den fileDesriptor hat.

@Rudi: das klingt gut.
@Jörg: Das wäre ja dann z.B. Protocol::Websocket:Frame
Daran habe ich mich auch schon versucht. Aber ich bin zu doof für OOP.

Das
Protocol::WebSocket::Frame->new('data');   verstehe ich ja noch. Und dass die framing bits default FIN=0x01, opcode=0x01.... sind auch. Aber wie bekomme ich nun das zu sendende frame ?
Bei my $frame = Protocol::WebSocket::Frame->new('data');klappt DevIo($hash, $frame->to_bytes,2);irgendwie nicht.
Und was ich auch nicht verstehe: Ist das Objekt dann nach dem Modulaufruf noch im Nirwana des Speichers und muss ich es vorher irgendwie "löschen" oder mir irgendwie eine Referenz in einem helper "mitschleppen", um es beim nächsten Modulaufruf zu nutzen ?

Grüße Markus
« Letzte Änderung: 25 Mai 2020, 09:30:03 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #43 am: 25 Mai 2020, 10:21:23 »
Hi Oli,Das stimmt so nicht.Sie wird immer aufgerufen und in Deinem Fall fehlt im Erfolgsfall dann eben ein kleines if auf undef, um die Logmeldung dann nicht abzusetzen.
Da hast du recht. Bei mir lokal läuft schon länger eine Version, die das berücksichtigt... Hatte ich nur noch nicht hochgeladen...

Zitat
Beispiel: Du machst die Zuweisung des Objekts/Socket
    $hash->{helper}{wsClient} = $client; um es Dir zwischenzuspeichern. Das wird aber gar nicht befüllt(zumindest bei mir nicht, steht da bei Dir etwa was drin ?). Und weil das(zumindest bei mir) nicht klappt, habe ich ja im nächsten Aufruf überhaupt keinen Bezug mehr zum Objekt ?!?!?
Bei mir klappt das... Auch wenn die Lösung äußerst unschön ist. Eigentlich sollte das eine globale Variable o.ä. sein.

Zitat
Und was ich auch nicht verstehe: Ist das Objekt dann nach dem Modulaufruf noch im Nirwana des Speichers und muss ich es vorher irgendwie "löschen" oder mir irgendwie eine Referenz in einem helper "mitschleppen", um es beim nächsten Modulaufruf zu nutzen ?
Das ist genau die obige hässliche Zuweisung.

Ich hatte das Ganze ursprünglich ohne DevIo umgesetzt (auf Basis des in den Kommentaren verlinkten Artikels) und nachträglich DevIo mit rein gefummelt. Der Artikel erklärt ganz gut, wie das funktioniert.

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #44 am: 25 Mai 2020, 11:15:36 »
Habe in DevIo.pm websocket Unterstuetzung eingebaut und kurz getestet mit echo.websocket.org und FHEMWEB.

Beispielmodul:
use strict;
use warnings;
use DevIo;

sub
wstest_Initialize($)
{
  my ($hash) = @_;
  $hash->{DefFn}     = "wstest_Define";
  $hash->{ReadFn}    = "wstest_ReadFn";
}

sub
wstest_Define($$)
{
  my ($hash, $def) = @_;
  $hash->{DeviceName} = "ws:echo.websocket.org:443";
  $hash->{SSL} = 1;
  DevIo_OpenDev($hash, 0, undef, sub(){
    DevIo_SimpleWrite($hash, "list", 2);
  });
}

sub
wstest_ReadFn($)
{
  my ($hash) = @_;

  my $buf = DevIo_SimpleRead($hash);
  if(!defined($buf)) {
    DevIo_CloseDev($hash);
    return;
  }
  Log 1, "GOT via websocket: >$buf<";
}

1;

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #45 am: 25 Mai 2020, 11:42:48 »
Danke Rudi. Ich probier es mal aus.

Trotzdem würde ich gerne verstehen(zu meiner Weiterbildung  ;D), warum das bei mir nicht klappte.
Zitat
auf Basis des in den Kommentaren verlinkten Artikels
Genau den suche ich immer wieder vergebens. Ich weiß, dass ich einen Link irgendwo gesehen hatte....Weißt Du noch wo bzw. wie der lautet ?

Zitat
Bei mir klappt das... Auch wenn die Lösung äußerst unschön ist. Eigentlich sollte das eine globale Variable o.ä. sein.
Wenn ich aber ein list device mache, gibt es bei mir keine helper-Variable. Bei Dir ?!?!?!?! Oder "versteckt" list den Eintrag u. führt mich in die Irre ?

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:WebSocket via DevIO?
« Antwort #46 am: 25 Mai 2020, 18:00:42 »
Perltidy krächzt.

419: return $doCb("websocket is only supported with callback") if(!$c ...
            -----^
found ( where operator expected (previous token underlined)

Do you mean '$doCb->(' ?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #47 am: 25 Mai 2020, 18:47:14 »
Danke fuer den Hinweis, habs gefixt.

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:WebSocket via DevIO?
« Antwort #48 am: 31 Mai 2020, 23:48:38 »
Hallo Rudi,

danke für den Einbau. Leider scheitere ich in meinem Anwendungsfall schon beim Verbindungsaufbau. Der Websocket-Server ist in meinem Fall erreichbar unter einer URL der Form wss://host:port/irgendwas?undmehr=1&bla. Devio reduziert leider erstmal auf host:port (das passt ja auch für den tcpsocket) und hängt dann ein http/https für den nonBlocking-Connect vorne dran, dadurch ergibt sich https://host:port und die Websocketverbindung kommt natürlich nicht zu Stande.
Meine aktuelle Implementierung (auch vor Anpassung von DevIo) läuft vereinfacht gesagt wie folgt:
* DevIo baut tscpsocket auf (host:port)
* Basierend auf tcpsocket ($hash->{TCPDev}) wird Protocol::WebSocket::Client instantiiert (mit kompletter URL)
* Protocol::WebSocket::Client macht Handshake (upgrade etc...)
* ReadFn leitet $buf an Protocol::WebSocket::Client weiter, um Rückgabe zu bearbeiten.

Welchen Input benötigst du um das auf DevIO-Seite zu optimieren?

Danke,

Oli

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #49 am: 01 Juni 2020, 00:58:35 »
Meines Wissens sollte das Beschriebene ohne "Optimierung" funktionieren.
wss:XX ist als ws:XX + $hash->{SSL}=1 zu spezifizieren, analog zu TCP, siehe mein Beispiel.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #50 am: 01 Juni 2020, 06:19:02 »
Hi Rudi,
auch ich habe mich mühevoll versucht. Die Definition ist ja eigentlich einfach. Ich dachte, dass es an TLS liegt, aber scheinbar ist es etwas anderes beim handshake, das die Verbindung nicht zustande kommen lässt. Mit wscat u. der Test-Website, die Jörg genannt hatte, funktioniert alles bestens.

Ich hab nun die Möglichkeit das Ganze ohne TLS auszuprobieren. Ich guck mir das im Laufe des Tages mit tcpdump/Wireshark mal an.

Wunsch: Den opcode des frames zurückliefern. Insbesondere beim Test fänd ich es hilfreich, wenn die Info ankommt, dass der Server die Verbindung "geclosed" hat. Ich guck aber selber mal, ob man das einfach in DevIo unterbringen kann.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #51 am: 01 Juni 2020, 09:55:05 »
Lt. Wireshark antwortet der Server auf den upgrade websocket request
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: t4n9guUpD/ZNPtfze+r3aUVqTo0=
Date: Mon, 01 Jun 2020 07:32:51 GMT
Server: Python/3.5 websockets/7.0

dann noch ein TCP-Ack des FHEM-Servers an den websocket-Server, aber dann wartet FHEM den timeout(3s) ab.... :'(

Und so sieht das im FHEM-Log aus
2020.06.01 09:32:51 3: [EE2] sol_local EE2_Ready(connection seems to be lost) retrying wsconnect for DeviceName: ws:xxxip.de:9124
2020.06.01 09:32:51 5: HttpUtils url=http://xxxip.de:9124/
2020.06.01 09:32:51 4: IP: xxxip.de -> Ipdeshosts
2020.06.01 09:32:51 5: HttpUtils request header:
GET / HTTP/1.1
Host: xxxip.de:9124
User-Agent: fhem
Accept-Encoding: gzip,deflate
Sec-WebSocket-Key: sXh1fxWrbbVHEyfLPyO77Q==
Connection: Upgrade
Sec-WebSocket-Version: 13
Upgrade: websocket

2020.06.01 09:32:54 4: [EE2] sol_local - error while connecting to Websocket: read from http://xxxip.de:9124 timed out from DevIO
2020.06.01 09:32:54 4: [EE2] sol_local - callback called

Auf was wartet httputils bzw. DevIo da noch ?!?!?!?

Wenn Du mehr brauchst, melde Dich gerne
Grüße Markus

Correction: additional new line added
« Letzte Änderung: 01 Juni 2020, 20:32:10 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #52 am: 01 Juni 2020, 11:07:50 »
Zitat
Auf was wartet httputils bzw. DevIo da noch ?!?!?!?
Falls Du die Daten vollstaendig kopiert hast: auf einem zweiten NL nach dem Header.
Ich fuerchte mit dieser Methode kommen wir nur muehsam weiter: gibt es eine Moeglichkeit, dass ich mich direkt mit deinem Server verbinde?

Ich habe DevIo.pm erweitert: mit verbose 5 wird jedes websocket Frame geloggt, und wss: ist equivalent zu ws: + $hash->{SSL}=1;

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #53 am: 01 Juni 2020, 11:36:08 »
Mit TLS kannst Du es auf sol.eet.energy:9124 testen.

Was ist ein NL ?  :-[

Danke fürs logging. Ich hol mir mal die aktuelle Version...

Allerdings genügt das Logging vermutlich nicht  :'( Ich konnte verfolgen, dass der Server alle 20s einen ping sendet, womit dann mit einem pong geantwortet wird(ansonsten schließt der Server die websocket-Verbindung). Ein websocket-frame ohne Daten kommt aber nicht im Modul über die ReadFn an, oder ? Oder ist das etwas, was in DevIo rein müsste ?
Ich glaube im konkreten Fall kommt kein Ping mehr, wenn man die ersten Daten(Logindaten)) geschickt hat...

Für ein anderes Modul überlege ich mir, ob ich auch auf DevIo umbaue. Allerdings ist das ein device, das nicht regelmäßig verfügbar ist. Du schreibst ja hier u. da, dass DevIo dann eher keinen Sinn macht. Was hältst Du von einer Lösung, wo die Verfügbarkeit des devices mit einem anderen Mechanismus überwacht wird und nur für die Dauer der Verfügbarkeit eine websocket-Verbindung aufgebaut bleibt, also Aufbau, wenn verfügbar und ein close(und damit auch kein ReadyFn/ReadFn ), wenn nicht mehr verfügbar.

Grüße Markus
« Letzte Änderung: 01 Juni 2020, 11:39:39 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #54 am: 01 Juni 2020, 12:30:18 »
Zitat
Mit TLS kannst Du es auf sol.eet.energy:9124 testen.
Habs gemacht.
Eine websocket Verbindung wird zwar hergestellt, aber von der anderen Seite sofort geschlossen (mit OP:8 == Close), vermutlich weil das von mir gesendete "list" ohne Weiteres dem Server nicht passt.

NL steht fuer NewLine: ein HTTP Header wird mit zwei Newlines abgeschlossen, und in deinem Beitrag sieht man nur eins.
Ein Websocket Frame wird mit DevIO nie beim Modul ankommen, da das Prinzip von DevIo ist, vom Transportschicht-Eigenheiten zu abstrahieren.
Abgesehen davon wuesste ich nicht, warum Ping/etc das Modul interessieren sollte.

Zitat
Du schreibst ja hier u. da, dass DevIo dann eher keinen Sinn macht.
Das ist vermutlich falsch interpretiert, kannst Du mir diesen Zitat zeigen?
Websocket ist (im Gegensatz zu HTTP) fuer eine laenger geoeffnete Verbindung ausgelegt.
Man kann es (wie alles) missbrauchen, und ob man das mit DevIo oder ohne macht, ist mir egal.

Zitat
Was hältst Du von einer Lösung, wo die Verfügbarkeit des devices mit einem anderen Mechanismus überwacht wird und nur für die Dauer der Verfügbarkeit eine websocket-Verbindung aufgebaut bleibt,
Wenig, wenn beide Verfahren das gleiche Medium (Netzwerk) nutzen.
Wenn die andere Seite nicht da ist, dann kriegt man das auch per websocket mit: ob jetzt ping oder der TCP Connect-Versuch keine Antwort kriegt, ist  egal. Es kommt dazu, dass man fuer ping entweder spezielle Rechte (root), oder unangemessen viel Ressourcen (fork+exec) braucht.
Heisst nicht, dass ich die, die sowas programmieren, aktiv verfolge, ich aussere nur meine Meinung, wenn ich danach gefragt werde :)
Zustimmung Zustimmung x 1 Liste anzeigen

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #55 am: 01 Juni 2020, 12:53:31 »
Hi Rudi,
Zitat
Eine websocket Verbindung wird zwar hergestellt, aber von der anderen Seite sofort geschlossen (mit OP:8 == Close), vermutlich weil das von mir gesendete "list" ohne Weiteres dem Server nicht passt.
Ja, das macht er, wenn ihm was nicht passt.  ;) Wie hast Du das denn jetzt mit dem "fehlenden" 2. NL gelöst ? Geänderte  DevIo sehe ich nicht.  :-[

Zitat
Abgesehen davon wuesste ich nicht, warum Ping/etc das Modul interessieren sollte.
Das sehe ich dann, wenn es mal mit dem Modul klappt.... ;)
Zitat
Das ist vermutlich falsch interpretiert, kannst Du mir diesen Zitat zeigen?
Finde ich bestimmt nicht mehr, aber Du hast ja jetzt ausführlich aufgeklärt.

Danke&Grüße Markus
« Letzte Änderung: 01 Juni 2020, 20:33:02 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #56 am: 01 Juni 2020, 13:58:54 »
Hm,
mein lokales device gibt auch nur ein NL zurück.  Das war wohl Quatsch. Du meintest ja die response. :( Trotzdem selbes Problem mit meinem lokalen device.

2020.06.01 13:50:57 5: HttpUtils url=https://localIP:8002/
2020.06.01 13:50:57 4: IP: localIP -> localIP
2020.06.01 13:50:57 5: HttpUtils request header:
GET / HTTP/1.1
Host: localIP:8002
User-Agent: fhem
Accept-Encoding: gzip,deflate
Sec-WebSocket-Key: 9nXYHmyxKMPCKREAHTn2Ng==
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13

2020.06.01 13:51:00 5: [SamsungAV] Fernseher - callback after connecting to Websocket by DevIO
2020.06.01 13:51:00 2: [SamsungAV] Fernseher - error while connecting to Websocket: read from https://localIP:8002 timed out from DevIO

Edit: Das mit dem NL ist es wohl nicht. Hab nochmal in Wireshark geguckt. Die response endet mit \r\n\r\n. Ich passdie obigen Posts mal an.
« Letzte Änderung: 01 Juni 2020, 20:29:50 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #57 am: 01 Juni 2020, 20:20:33 »
Zitat
mein lokales device gibt auch nur ein NL zurück.
Du verwirrst mich.
Im Code-Stueck sind zwei zu sehen: einmal nach "Sec-WebSocket-Version: 13" und danach die leere Zeile.
Der Zugriff auf "sol.eet.energy:9124" klappte ohne Aenderung, der schickt schon 2 NLs.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #58 am: 01 Juni 2020, 20:44:54 »
Ich mich auch. Hab jetzt erst gemerkt, dass Du ja die response meintest. Ja, da kommt die 2. NL. Hatte ich nur nicht mitkopiert. :o

Aber dann sind wir so weit wie heute Morgen: Was führt zu dem timeout ? Und viel schlimmer: wieso klappt das bei Dir ? ??? Da kann man doch eigentlich nichts falsch machen.  :-[

    $hash->{DeviceName} = "ws:".$hash->{Host} . ":" . $hash->{Port}; 
#    $hash->{SSL}         = 1;  # TLS only used for remote access; set by attribute   
#    $hash->{WEBSOCKET}   = 1;  set by Dev
    DevIo_OpenDev( $hash, 0, "wsHandshake", "wsCb" );
sub wsCb ($){
    my ($hash, $error)  = @_;

    my $name  = $hash->{NAME};

    if (defined($error)) {Log3 $name, 4, "[EE2] $name - error while connecting to Websocket: $error from DevIO" };
    Log3 $name, 4, "[EE2] $name - callback called";
    return $error;
}
« Letzte Änderung: 01 Juni 2020, 20:58:57 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #59 am: Gestern um 09:03:31 »
Hi Rudi,
nachdem es also nicht am NL liegt, wird für mich die Sache immer ominöser. Was mich in meinem Log so blind gemacht hatte ist, dass es überflutet wurde. Das liegt daran, dass permanent die ReadyFN aufgerufen und ein Neuaufbau versucht wird. Es ist doch richtig, dass die ReadyFn eigentlich gar nicht aufgerufen werden dürfte oder zumindest der STATE auf connected stehen müsste, oder ?

Außerdem hadere ich mit dem reopen-Flag. Ich hab jetzt noch einmal ein wenig umgebaut und bekomme folgendes Logging
2020.06.01 23:17:38 3: [EE2] sol_local defined with host: localDomain port: 9124
...Versatz von 20s ist korrekt, weil der Aufbau über einen internaltimmer 20s nach dem define gestartet wird
2020.06.01 23:17:58 4: [EE2] sol_local  Attempting to open websocket by DevIo
2020.06.01 23:17:58 3: Opening sol_local device ws:localDomain:9124
2020.06.01 23:17:58 5: HttpUtils url=http://localDomain:9124/
2020.06.01 23:17:58 4: IP: localDomain -> localIP
2020.06.01 23:17:58 5: HttpUtils request header:
GET / HTTP/1.1
Host: localDomain:9124
User-Agent: fhem
Accept-Encoding: gzip,deflate
Upgrade: websocket
Sec-WebSocket-Version: 13
Connection: Upgrade
Sec-WebSocket-Key: 7i8DGRzM9v3nc2QrBABKIw==

2020.06.01 23:18:01 1: sol_local: Can't connect to localDomain:9124: No such file or directory
2020.06.01 23:18:01 1: sol_local: Can't connect to localDomain:9124: read from http://localDomain:9124 timed out
2020.06.01 23:18:01 4: [EE2] sol_local - error while connecting to Websocket: read from http://localDomain:9124 timed out from DevIO
2020.06.01 23:18:01 3: [EE2] sol_local EE2_Ready(connection seems to be lost) retrying wsconnect for DeviceName: ws:localDomain:9124
2020.06.01 23:18:01 3: Opening sol_local device ws:localDomain:9124
2020.06.01 23:18:01 4: [EE2] sol_local - connecting to Websocket successful
2020.06.01 23:18:01 3: [EE2] sol_local EE2_Ready(connection seems to be lost) retrying wsconnect for DeviceName: ws:localDomain:9124
2020.06.01 23:18:01 4: [EE2] sol_local - connecting to Websocket successful
2020.06.01 23:18:02 3: [EE2] sol_local EE2_Ready(connection seems to be lost) retrying wsconnect for DeviceName: ws:localDomain:9124
2020.06.01 23:18:02 4: [EE2] sol_local - connecting to Websocket successful
.
.
.
bei diesem coding.
.
Initial-websocket-connect
    $hash->{helper}{wsconnect} = 0;
    Log3 $name, 4, "[EE2] $name  Attempting to open websocket by DevIo";
    $hash->{DeviceName} = "ws:".$hash->{Host} . ":" . $hash->{Port}; 
    DevIo_OpenDev( $hash, 0, "wsHandshake", "wsCb" );
.
.
ReadyFN
   Log3 $hash->{NAME}, 3, "[EE2] $hash->{NAME} EE2_Ready(connection seems to be lost) retrying wsconnect for DeviceName: $hash->{DeviceName}";
  return DevIo_OpenDev( $hash, $hash->{helper}{wsconnect}, "wsHandshake", "wsCb" )
                if($hash->{STATE} eq "disconnected");     

wsCb
    if (defined($error)) {Log3 $name, 4, "[EE2] $name - error while connecting to Websocket: $error from DevIO" }
    else {
       Log3 $name, 4, "[EE2] $name - connecting to Websocket successful";
       $hash->{helper}{wsconnect} = 1;
    }
Auf ein write habe ich komplett verzichtet, da ggfs. der Server mit einem disconnect reagiert.

Aber wieso gibt es erst diese "Can't connect" Meldung mit 3s timeout, dann der identische Aufruf von DevIo(reopen=1), der nun scheinbar erfolgreich ist, aber nicht zu einem "connected" führt bzw. die ReadyFn aufgerufen wird, wo dann erneut ein erfolgreicher ws-connect(reopen=1) erfolgt, der aber wieder in die ReadyFN läuft. Und das dann permanent.

Soll ich das nochmal genau mit Wireshark analysieren ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #60 am: Gestern um 11:44:02 »
Oh Mann, Rudi.

Und wenn man nicht mehr weiter weiß, macht man ein update u. shutdown/restart.

Und dann klappts auch. Ich spekuliere: die httputils wurde auch erneuert. Ich hatte aber immer nur DevIo aus dem SVN manuell geladen.  :-\

Ich kann Dir aber schon einmal
Zitat
Zitat
Zitat

Abgesehen davon wuesste ich nicht, warum Ping/etc das Modul interessieren sollte.

Das sehe ich dann, wenn es mal mit dem Modul klappt.... ;)
beantworten: nach 20s sendet der Server einen ping. Ohne ein pong des FHEM-client schließt er die Verbindung. FHEM schickt zwar den Pong, die Verbindung wird aber trotzdem vom Server geschlossen. (möglicherweise, weil es nicht "masked" gesendet wurde ?

Trotz richtiger Daten, löst das simple_write auch ein disconnect aus. Mit Wireshark konnte ich feststellen, dass der Unterschied darin liegt, dass wir "unmasked" senden. Hier hab ich was gefunden, dass es zwingend erforderlich wäre.

Grüße Markus
« Letzte Änderung: Gestern um 13:29:19 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #61 am: Gestern um 11:48:48 »
Zitat
Ich spekuliere: die httputils wurde auch erneuert.
Ja, die Aenderung ist fuer websocket relevant.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4346
Antw:WebSocket via DevIO?
« Antwort #62 am: Gestern um 21:03:50 »
Während Du geantwortet hast, hatte ich getestet, den Post editiert... Ich wiederhol dann mal meine unschöne Feststellung als trigger für einen change im Thread,

Trotz richtiger Daten, löst das simple_write auch ein disconnect aus. Mit Wireshark konnte ich feststellen, dass der Unterschied darin liegt, dass wir "unmasked" senden. Hier hab ich was gefunden, dass es zwingend erforderlich wäre. Gar nicht gut . >:(

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22327
Antw:WebSocket via DevIO?
« Antwort #63 am: Heute um 14:28:59 »
Danke fuer die Recherche. Ich habe die Begruendung gelesen: entweder waren das Anfaenger, oder sie haben was in der Begruendung nicht erwaehnt.

Wie auch immer, ich habe jetzt die DevIo Routinen so umgestellt, dass alles maskiert gesendet wird.
FHEM und echows kommt damit zurecht, sol.eet.energy ist immerhin nicht sofort beleidigt, und wartet auf mehr Daten.

 

decade-submarginal