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

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • 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: 1205
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: 12011
  • 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, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}
Informativ Informativ x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • 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: 12011
  • 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, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • 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: 16627
  • 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: 26007
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: 1205
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: 26007
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
Zustimmung Zustimmung x 1 Liste anzeigen

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1205
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: 16627
  • 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: 3389
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: 597
  • 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: 4617
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-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

 

decade-submarginal