alternative Steuerung von FHEM mit Hilfe Scripten

[Beta-User]

Irgendwie kam mir dieser Einleitungstext bekannt vor...

Wer die diesbezügliche Diskussion von vor 1,5 Jahren sucht: https://forum.fhem.de/index.php/topic,79095.0.html.

Meine persönliche Meinung dazu hat Benni damals gut zusammengefaßt:

Na ja, wer schon Probleme mit DOIF hat, wird damit wahrscheinlich auch nicht glücklich.

Aber wenn schon was neues lernen, warum nicht gleich Perl lernen, das ist doch die Skriptsprache von/für FHEM

Der Punkt, welchen Vorteil das ganze gegenüber vorhandenen anderen Alternativen zu direktem Perl-scripting (DOIF/MSwitch) ist für mich völlig ungeklärt. Vielleicht wäre es gut, wenn der TE hierzu etwas mehr erläutern würde, wo die Unterschiede liegen und v.a. der Vorteil.

Ich muß dazu aber vorab anmerken, dass ich selbst mich damit nicht weiter befassen werde (wie auch nicht mit DOIF oder MSwitch), für mich selbst habe ich irgendwann entschieden, dass es besser ist, direkt mit Perl zu arbeiten und daher das zu "lernen".

Aber ansonsten habe ich auch gegen weitere funktionierende Optionen einzuwenden, es gibt ja weiter den alten Grundsatz: There's more than one way to do it...

Ich hätte dazu nur den Wunsch, dass wir Usern, die generell an "sowas" Interesse haben, an irgendeiner Stelle eine Übersicht bieten, was so die spezifischen Stärken jeder der Lösungen sind. Denn wer sich nicht so richtig für eine Lösung entscheidet und dann nicht strukturiert arbeitet, wird am Ende genau vor dem Problem stehen, für das dieter56 hier seine Lösung präsentiert hat (ohne allerdings das Problem selbst in einer für mich verständlichen Form darzustellen).

Just my2ct.

[Damian]

Ich würde erstmal die Sprachbeschreibung fertigstellen und dann veröffentlichen. Sonst wird sich kaum jemand mit einem Modul auseinandersetzen, dessen vollständige Syntax noch nicht mal beschrieben ist. Einchecken würde ich etwas erst dann, wenn User es ausgiebig getestet haben und es tatsächlich auch nutzen wollen. Ich habe mit meinem ersten Modul (THRESHOLD) nach Veröffentlichung drei Monate gewartet und es erst auf Wunsch der User eingecheckt als das Modul schon mehrfach im erprobten Einsatz nicht nur bei mir, sondern auch bei anderen war.

[Maui]

Das mit fhem und FHEM geht bei dir aber nur, weil du auf Windows bist.
Linux ist case-sensitive und damit muss es dort FHEM heissen.

Stimmt so nicht. Er kann problemlos in fhem einen Unterordner fhem haben. Auch in Linux
Da sein Modul-Ordner allerdings fhem heißt und unser aller FHEM, Muss man bei den 98-Dateien je eine Anpassung machen.

Aus

Code Auswählen Erweitern


use lib ("fhem/lambda/");

muss

Code Auswählen Erweitern


use lib ("FHEM/lambda/");


EDIT:
Was mir halt neben fhem/FHEM zu denken gibt, ist der von Beta-User ausgekramte Thread. Da gab es User, die getestet haben und beide sind in Probleme gelaufen aber Antworten kamen dazu nie. Jetzt nach 1,5 Jahren: Der König ist tot, lang lebe der König.
Also ich finde die Bemühungen bemerkenswert aber ich glaube und hoffe nicht, dass das so jemals eingecheckt wird. Da bleibe ich dann lieber bei DOIF, MSwitch etc.
Da mache ich mir keine Sorgen, dass Damian etc. da nicht Supporten und das hat Hand und Fuß.

[dieter56]

Hallo Damian,

Selbstverständlich wird an einer kompletten Sprachbeschreibung gearbeitet. Die wird systematisch und ausfühlich sein. Allerdings ist so etwas eher zum Nachschlagen und Vertiefen gemacht.
Ich denke, der Einsteiger ist mit den praktischen kleinen Beispielen auf der Website http://lambda-script.org/schnelleinstieg.php fürs erste gut beraten. Ich denke, auch du hast, bevor du dir dein erstes PERL-Buch gekauft und durchgelesen hast, mit kleine Scripten und Beispielen das Programmieren gelernt haben.

Gruß
Dieter

[dieter56]

Hallo Maui,

Danke für den Hinweis.

Da es wahscheinlich so ist, dass üblicherweise der Ordner mit den Modulen FHEM und nicht fhem heißt, werde ich den Download entsprechen anpassen.
Ich bin leider kein großer PERL-Experte. Kann man es nicht so einrichten, das man ein Modul "use modulx" nicht auch aus einem Unterverzeichnis laden kann? Z.B. mit "use lambda/modulx".

Nochmal Danke
Dieter

[Beta-User]

Da es wahscheinlich so ist, dass üblicherweise der Ordner mit den Modulen FHEM und nicht fhem heißt, werde ich den Download entsprechen anpassen.
Ich bin leider kein großer PERL-Experte. Kann man es nicht so einrichten, das man ein Modul "use modulx" nicht auch aus einem Unterverzeichnis laden kann? Z.B. mit "use lambda/modulx".

Ganz allgemein gesprochen, sollten solche Dinge in jedem Fall vor dem Einchecken in einer Weise funktionieren, die auf allen möglichen Plattformen läuft und auch gegen solche Nutzereingriffe wie eine andere Ordnerstruktur oder -benennung halbwegs immun ist.

Vermutlich wäre es besser, die zusätzlichen labda-Dinge nach "lib" zu packen, was aber m.E. voraussetzt, dass sie Perl-mäßig sauber gekapselt sind, damit Konflikte mit anderen Dingen ausgeschlossen sind.

MaW: Ganz ohne Perl-Kenntnisse wird es eher schwierig, und ohne Berücksichtigung der in FHEM üblichen Standards ist es ein no-go.

[dieter56]

Hallo,

Ich habe jetzt eine Version zum Download bereitgestellt, die unbhängig von der Schreibweise der Modulverzeichnisses ist. Meine Module greifen jetzt ohne eine neue "lib" zu definieren direkt auf die Submodule zu.
Dank an alle die mitgeholfen haben.

Gruß
Dieter

[Beta-User]

Hm,

wollte das auf meiner Testmaschine mal versuchen, aber da kommt ein "Cannot load module lamda", wenn ich versuche, das Testdevice wie auf der Webseite angegeben zu definieren.
Das ist ein strawberry-Perl-System unter Windows auf einem USB-Stick. Kann sein, dass da sonst noch was verbogen ist (ich bekomm leider kein logfile), aber alles andere schien sich bisher immer darauf testen zu lassen. Ein Rechteproblem ist es wg. Windows also nicht.

Mit -d bekomme ich immerhin die Meldung, dass es ein Problem in Zeile 30 gäbe. Daher mal testweise ein " qw(:all)" ergänzt, dann komme ich immerhin zu der erweiterten Fehlermeldung, dass data in @INC nicht vorhanden wäre. Das bezieht sich vermutlich auf deine lib, nicht eine allg. Perl-lib?

Tatsächlich erhalte ich jetzt auch dieselbe Fehlermeldung unabhängig davon, ob das labda-Verzeichnis in FHEM direkt liegt oder im Unterverzeichnis FHEM/lib. (Wenn schon, sollte man m.E. solche Dinge da unterbringen...).

[Benni]

Irgendwie kam mir dieser Einleitungstext bekannt vor...

Wer die diesbezügliche Diskussion von vor 1,5 Jahren sucht: https://forum.fhem.de/index.php/topic,79095.0.html.

Ah. wusst ich's doch!
Ich hatte auch irgendwie das Gefühl, dass wir darüber schon mal disktiert haben 

Gruß Benni.

[Damian]

Das Ding braucht auf jeden Fall auch eine Perl-Schnittstelle, sonst wird das Modul es schwer haben, sich gegenüber bestehenden Modulen durchzusetzen. FHEM besteht bekanntlich nicht nur aus FHEM-Befehlen.

[dieter56]

Hallo Beta-User,

Ganz vielen Dank, dass du versucht hast das Modul zum Laufen zu bringen. Ich denke ich habe den Fehler gefunden. In dem Modul lambda.pm wird das Modul data geladen. Dort war noch die Existens eines separaten lib-Eintrages vorausgesetzt. Ich habe das Laden durch den expliziten Verweis ersetzt use lambda::data;. Ich hoffe, das es das jetzt war. Eine neue Datei lambda.pm füge ich an. Die  Installationsdatei auf der Webseite habe ich ebenfalls aktualisiert. Wenn Du bitte noch die Datei ../lambda/lambda.pm mit der neuen austauschen könntest? Ich wäre dir wirklich sehr dankbar, wenn wir das gemeinsam zum Laufen bringen könnten. - Unabhängig davon was du am Ende von dem Modul hältst. Trotz alle Mühe die ich mir gegeben habe muss ich sagen: Der Anfang ist doch schwerer und mühsamer als gedacht. Wenn du mir noch ein klein wenig helfen könntest.

Beste Grüße
Dieter

[Byte09]

Hi Dieter,

ohne das ich mir das Modul jetzt angeschaut hätte oder auch nur installiert habe denke ich ( und das sage ich aus Erfahrung ) , das dieses Modul es vermutlich sehr schwer haben wird sich zu etablieren - und das kann schon fast Frust auslösen.
Im Grunde sehe ich nicht wirklich , wer dein 'Zielpublikum' ist. Für Anfänger, die zum Teil mit Notify etc. schon überfordert sind .. und auch nicht wirklich die Bereitschaft zu lernen an den Tag legen - ist es mit Sicherheit nicht Interessant sich in eine Scriptsprache einzuarbeiten, halbwegs Fortgeschrittene werden sich wohl mit bestehenden Modulen auseinandersetzen und der Rest, der sich wirklich mit Fhem beschäftigen will kommt so oder so nicht an Perl vorbei.

Ich persönlich sehe auch nicht wirklich den Mehrwert zu bestehenden Möglichkeiten.

Drücke dir aber trotzdem die Daumen , das es angenommen wird und werde es mir selber am WE mal anschauen.

gruss Byte09

edit : aber Respekt vor der investierten arbeit !!

[dieter56]

Hallo Damian,

warum braucht man zwingend eine Perl-Schnittstelle? Sowohl Perl als auch als auch lambda-script sind Turing-Vollständig. Das heißt, alles was ich mit der einen Sprache berechnen kann, geht auch mit der anderen. Da ich mit lambda-script über die FHEM-API den vollen Zugriff auf die FHEM-Devices (sowohl lesend über die Readings als auch steuernd über die set-Befehle) habe, kann nichts fehlen.

Gruß
Dieter

[Beta-User]

Also:
Das test-Device läßt sich nach Tausch der lambda.pm definieren, und zwar unabhängig davon, ob das lambda-Verzeichnis direkt in fhem/FHEM liegt oder in fhem/FHEM/lib (das qw(:all)) hatte ich bei den beiden Hauptmodulen noch drin.

Mehr habe ich einstweilen nicht getestet.
(Es wird mich schon jemand korrigieren, wenn das falsch ist: m.E. gehört das "Hintergrundgedöns" nach lib, die Verzeichnisstruktur an sich in FHEM sollte nicht noch unübersichtlicher werden, als sie schon ist...).

Man sieht deiner Seite an, dass du dir Mühe gegeben hast, und auch wenn sich mir nicht recht erschließt, warum der Code insgesamt so sehr verteilt ist, sieht das an sich auf den ersten Blick sauber aus (ohne damit in Anspruch nehmen zu wollen, das wirktlich beurteilen zu können). Daher hast du eine Chance verdient. Die auf den ersten blick eher ablauforientierte Herangehensweise ist jedenfalls was, was mich mehr anspricht, als das Konfigurieren einer Art Zustandsmaschine durch eine unübersichtliche Vielzahl von Attributen, über deren Anwendung und Wirkweise sich selbst fortgeschrittene User gelegentlich nicht einig sind...

Allerdings interessiert mich immer noch, welches Problem du eigentlich damit löst . Vielleicht erklärst du uns das ja noch etwas ausführlicher?

[Damian]

Hallo Damian,

warum braucht man zwingend eine Perl-Schnittstelle? Sowohl Perl als auch als auch lambda-script sind Turing-Vollständig. Das heißt, alles was ich mit der einen Sprache berechnen kann, geht auch mit der anderen. Da ich mit lambda-script über die FHEM-API den vollen Zugriff auf die FHEM-Devices (sowohl lesend über die Readings als auch steuernd über die set-Befehle) habe, kann nichts fehlen.

Gruß
Dieter

Ganz einfach, es sollte zumindest das können, was ein notify und at kann. z. B. einen Aufruf von {myfunction()}.