WebSocket via DevIO?

Begonnen von KernSani, 06 April 2020, 07:43:45

Vorheriges Thema - Nächstes Thema

KernSani

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, ...

rudolfkoenig

ZitatWäre das ein Fall für DevIO?
Ich meine ja. Wenn Du einen Patch hast...

ZitatGibt 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.

RichardCZ

Zitat von: rudolfkoenig am 06 April 2020, 08:56:05
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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

herrmannj

@KernSani

ich würde Unterstützung anbieten.

KernSani

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, ...

KölnSolar

ZitatIm 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.

ZitatKann 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-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

mahowi

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

herrmannj

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.

mahowi

Zitat von: herrmannj am 07 April 2020, 09:03:40
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

herrmannj

dies Beispiel zeigt imho warum es doch schön ist, wenn fhem das ootb mitbringt

mahowi

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

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

herrmannj

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

ZitatFrage: 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).

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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.