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
Wäre es nicht am aller besten das Script nach Perl zu schreiben?
ZitatWä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)
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.
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.