Autor Thema: js oder py für externe Funktionen für neues Modul  (Gelesen 331 mal)

Online KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3485
js oder py für externe Funktionen für neues Modul
« am: 29 April 2019, 07:59:41 »
Hi,
ich beabsichtige ein neues Modul zu erstellen. Basis wäre ein vorhandenes Python3-Skript, welches die eigentliche Steuerung/Kommunikation(mit der cloud  >:() übernimmt. Nun möchte ich den User nicht "zwingen" extra Python zu installieren.
Jetzt hab ich festgestellt, dass jemand das Skript auch nach js übersetzt hat. Ist es sinnvoller das zu nutzen, um Overhead-Installationen zu vermeiden ? Wenn ja, gibt es ein Modul wo Ähnliches gemacht wurde, welches ich mir als Muster angucken könnte ?

Danke&Grüße Markus
RPi3/2 Stretch-STV_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)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21617
Antw:js oder py für externe Funktionen für neues Modul
« Antwort #1 am: 29 April 2019, 08:24:06 »
Wäre es nicht am aller besten das Script nach Perl zu schreiben?
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
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer
Zustimmung Zustimmung x 1 Liste anzeigen

Online KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3485
Antw:js oder py für externe Funktionen für neues Modul
« Antwort #2 am: 29 April 2019, 09:55:54 »
Zitat
Wäre es nicht am aller besten das Script nach Perl zu schreiben?
Das war natürlich mein erster Gedanke.  ;) Ist aber sehr umfangreich.  :'( Und wenn man dann kein Python "kann".  :'( Langfristig würd ich mich da schrittweise ran wagen. Aber erst einmal den FHEM-Modulrahmen erstellen und vorhandene "fremde" Skripte nutzen. Mit dem SamsungAV hatten wir das so ähnlich, wobei da von Python einerseits wenig zu übersetzen war und andererseits ich eine sehr ähnliche Python-Perl-Übersetzung als Vorlage hatte. 8)
RPi3/2 Stretch-STV_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)

Online Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3633
  • ~ Challenging Innovation ~
Antw:js oder py für externe Funktionen für neues Modul
« Antwort #3 am: 29 April 2019, 10:32:00 »
also aus Systemintegration Sicht kann ich aus den Erfahrungen beim Docker Image sprechen: Node.js scheint mir robuster und konsistenter zu sein, während das Paket- und Versionsmanagement bei Python sehr viel schwieriger scheint (nicht zuletzt auch, weil Python2 und Python3 koexistieren). Auch gibt es meines Wissens nach aktuell nur ein einziges (offizielles) FHEM Modul, was Python beinhaltet (98_GOOGLECAST.pm, nutzt dafür das Perl Modul Inline::Python), während es durch die Sprachassistenten eine ganze Reihe davon gibt, die im Backend auf Node.js setzen. Nicht zuletzt gibt es für Node.js schon ein FHEM Paketmanagement Modul (42_npmjs.pm), während Python PIP zwar auf der Agenda steht, aber eben keine sonderlich große Priorität genießt, weil es eben nur ein einziges Modul betrifft. Auch die programmatische Integration in FHEM ist Dank André sehr viel besser. Ich bin nicht sicher, ob Python so schnell dieses Niveau erreicht oder ob das aus aktueller Sicht überhaupt lohnenswert wäre.
« Letzte Änderung: 29 April 2019, 13:11:11 von Loredo »
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Online KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3485
Antw:js oder py für externe Funktionen für neues Modul
« Antwort #4 am: 29 April 2019, 17:36:36 »
Danke Dir.
In FHEM würde ich es keinesfalls einbauen wollen. FHEM wäre "nur" integrative Oberfläche, also set/get, readings/events. Die tatsächliche Verarbeitung, Kommunikation mit den Endgeräten verbliebe(zumindest vorerst) in den vorhandenen Paketen.

Dann guck ich mir mal npmjs.pm an.
RPi3/2 Stretch-STV_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)

 

decade-submarginal