Hallo liebe fhem-Gemeinde.
Ich hatte in meiner fhem-Installation ca. 60 DOIFs, 30 NOTIFYSs und etliche ATs. Dazu gehörten etliche Dummys um sie zu verknüpfen. Weiterhin sind im laufe der Jahre einige Perl-Scripts dazu gekommen. Das ganze System wurde im Laufe der Jahre immer unübersichtlicher.
Parallel dazu wuchs der Wunsch, die gesamte Steuerung mit einer eigenen Scriptsprache möglich zu machen.
Ich habe vor zwei Jahren damit begonnen eine derartige Scriptsprache zu konzipieren und einen Interpreter dafür zu schreiben. Die so entstandenen Module 98_lambda.pm und 98_lambdaDevices.pm laufen seit vielen Monaten bei mir sehr stabil.
DOIFs, NOTIFYs und ATs konnte ich komplett ersetzen und eigene Perl-Scripte brauche ich nicht mehr. Meine gesamte Steuerung ist wesentlich übersichtlicher und damit einfacher geworden.
Vielleicht hat der eine oder andere Lust damit etwas auszuprobieren und mir mit ein paar Anregungen bei der Weiterentwicklung zu helfen.
Ich habe für das Modul eine Website eingerichtet auf der der aktuelle Download zu finden ist. Die Site ist im Aufbau und Beschreibung ist noch sehr unvollständig. Sie wird aber in den nächsten Tagen und Wochen ergänzt werden.
http://www.lambda-script.org
Gruß
dieter56
Hallo liebe FHEM-Gemeinde
Ich habe beantragt, das Modul in die SVM zu integrieren. Rudolf schrieb mir darauf:
Zitatlaut den Regeln, die wir vor etwa einem Jahr beschlossen haben, muss ein neuer
Modulautor sein Modul im Forum vorstellen, ein erfahrener FHEM-Autor soll es
begutachten, und mindestens zwei Benutzer sollten es ausprobiert, und Feedback
gegeben haben.
Ich meine, dass die Ueberpruefung von einem erfahreneren FHEM-Autor in diesen
Fall nicht noetig ist, aber ich wuerde gerne bei so einem Thema allgemeines
Interesse sehen.
Ich verfolge das Forumsthema, und werde Dich eintragen, wenn Feedback von zwei
Benutzer vorhanden ist.
Gruss,
Rudi
Wenn sich also zwei User finden würden, die es zum Laufen bringen, wäre ich sehr dankbar.
Selbstverständlich leiste ich dabei jede mögliche Unterstützung.
Den Download gibt es hier: http://lambda-script.org
Gruß
Dieter
Ich finde das sehr interessant. Muss mal sehen, wenn ich dazu komme es mal auszuprobieren.
Ich hab zwar selbst noch keine Idee, wo ich es nutzen könnte, aber interessant finde ich es auf jeden Fall. Daher wollte ich es gerade mal installieren um einfach mal ein klein wenig zu spielen und zu testen. Leider scheitere ich schon an der Installation.
Ich hab die tar runtergeladen und auf dem Raspi nach /opt/fhem/FHEM kopiert. Dort mit dem Befehl tar -xvf lambda.tar.gz entpackt.
Anschließend mit sudo chown -R fhem:dialout * entsprechend die Rechte neu gesetzt und FHEM neu gestartet.
Versuche ich nun in FHEM ein define, erhalte ich folgende Fehlermeldungen im Log:
2019.04.11 21:15:10.613 1: reload: Error:Modul 98_lambda deactivated:
Can't locate lambda.pm in @INC (you may need to install the lambda module) (@INC contains: fhem/lambda/ . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM ./FHEM/lib) at ./FHEM/98_lambda.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/98_lambda.pm line 30.
2019.04.11 21:15:10.614 0: Can't locate lambda.pm in @INC (you may need to install the lambda module) (@INC contains: fhem/lambda/ . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl ./FHEM ./FHEM/lib) at ./FHEM/98_lambda.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/98_lambda.pm line 30.
Zitat von: swsmily am 11 April 2019, 21:19:14
Ich hab die tar runtergeladen und auf dem Raspi nach /opt/fhem/FHEM kopiert. Dort mit dem Befehl tar -xvf lambda.tar.gz entpackt.
Hmmm ....
Wenn ich die Installationsanleitung (http://www.lambda-script.org/download.php) richtig verstehe, sollte das Paket in /opt/fhem entpackt werden und nicht in /opt/fhem/FHEM
gb#
Hab es aus /opt/fhem/FHEM nochmal alles entfernt und in /opt/fhem entpackt. Da kommt direkt Unknown module lambda.
Tja! Ich habe derzeit nicht vor das bei mir zu testen.
gb#
Moin,
also ich verstehe das so, dass die beiden Module in den FHEM-Ordner und der lamda-Ordner in den fhem-Ordner gehören.
LG
Andreas
ich glaube hier kann wohl nur dieter56 erstmal weiterhelfen.
zum entpacken: die TAR entpackt zwei 98_lambda......pm Dateien ins das Verzeichnis wo die TAR Datei liegt und erstellt in diesem Verzeichnis auch den Unterordner lambda, in dem weitere *.pm-Dateien liegen.
Sieht auf jeden Fall interessant aus. Allerdings sollten das definitiv einige intensivst testen.
Ich schaue mal ob ich morgen dazu komme, das auf meinem 2. fhem zu kopieren.
Allerdings bin ich mir noch nicht ganz klar über den Benefit.
Ein Anfänger user wird die Sprache trotzdem nicht nutzen und für die Profis gibt es Perl. Lambda wird sicherlich nicht mehr als Perl können und ja es sieht einfacher aus aber trotzdem nicht unbedingt selbst erklärend.
Ich bin also sowas wie neugierig und trotzdem ziemlich skeptisch ;)
Hallo,
zur Installation:
Die beiden Module 98_lambda.pm und 98_lambdaDevices.pm müssen in das Verzeichnis in dem sich alle andern Module (von 00_CM11.pm bis 99_myUtils.pm) befinden. In diesen Order muss ebenfals der Ordner lambda.
Siehe angehänges Bild.
Es tut mir leid, dass meine Anleitung etwas verwirrend war.
Gruß
Dieter
Dein Bild verwirrt allerdings wieder mehr. Der normale Ordner für Module ist fhem/FHEM und nicht wie bei dir fhem
Hallo,
Es kann sein, dass die Ordner in meiner Installation etwas anders benannt sind:
Grundsätzlich ist der Aufbau doch so:
ORDNER: fhem
INHALT: fhem.pl
fhem.cfg
....
ORDNER FHEM (bei mir heist der auch fhem)
INHALT: Module 00_CM11.pm bis 99_myUtils
(hier muss 98_lambda.pm, 98_lambda.Devices und neuer Ordner lambda rein)
Ich hoffe, es ist jetzt deutlicher
Dieter
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.
Hallo micky0867,
mein FHEM läuft auf einer Linux-Maschine auf der Basis Debian - und das seit vielen Jahren. Warum der Ordnername bei mir klein geschrieben ist, weiß ich nicht. Entscheidend ist aber, dass die Datein für die lambda-Installation die die Ordner mit den entspechenden Inhalten kommen.
WINDOWS -- brrr.
Gruß
Dieter
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:
Zitat von: Benni am 06 November 2017, 10:01:03Na 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 (https://forum.fhem.de/There's%20more%20than%20one%20way%20to%20do%20it)...
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.
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.
Zitat von: micky0867 am 12 April 2019, 09:04:28
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
use lib ("fhem/lambda/");
muss
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ß.
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
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
Zitat von: dieter56 am 12 April 2019, 10:09:54
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.
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
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...).
Zitat von: Beta-User am 12 April 2019, 09:25:00
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 ;D
Gruß Benni.
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.
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
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 !!
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
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 ;D . Vielleicht erklärst du uns das ja noch etwas ausführlicher?
Zitat von: dieter56 am 12 April 2019, 14:07:33
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()}.
Hallo Byte09,
Ich gebe dir recht. Der User der lediglich 19:00 seine Außenbeleuchtung einschalten will oder bei Bewegung sein Flurlicht, der kann das mit einem at oder einem notify tun.
Obwohl der Unterschied zwischen einem at
19:00 set Lampe on
und lambda-script
wait 19:00'today; set Lampe on
so riesig nicht ist.
Für komplexere Aufgabe ist lambda-script aber bedeutend einfacher. Die Tatsache, das ich in lambda-script komplexe Strukturen (Räume, Heizungssysteme, Häuser, ...) durch Definition neuer Klassen definieren kann, und über diese in funktionaler Weise Operationen definieren kann, bieten sich auch für den normalen Nutzer völlig neue Möglichkeiten. Einfacher als sich in AT's NOTIFY's DOIF's und dann noch im Zusammenspiel mit eigenen Perl-Scripts hineinzufuchsen, ist die Verwendung von λ-script allemal. Ambitionierten Nutzer haben die Möglichkeit Anderen komplexe vorgefertigte Programme zu übergeben.
Die Möglichkeiten gehen deutlich über das hinaus, was jetzt möglich ist. Ich habe z.B. in λ-script auf der Grundlage eine Devices vom Typ TelegramBot einen Bot geschrieben mit dem ich mein Haus über ein Menü komplett steuern kann. Dieses Script könnte ich einfach an jemanden andern übergeben. Der passt die Parameter an seine Gegebenheiten an und es läuft. Wenn ich das ohne λ-script machen wollte, müsste ich: Ein Modul schreiben, die Community überzeugen, dass sie es braucht, den Administrator bitten ob er es in die SVN übernimmt. Das Modul würde über eine Unzahl von Attributen und dummys gesteuert. Und der User kann es nicht ändern. Mit jeden Update wären die Änderungen futsch. Mit lambda-script definiert er ein Device "define meinBot lambda", kopiert das Script rein und fertig.
Ich bin davon überzeugt, dass es eine tolle Sache ist.
Aber ist eben ganz anders als das vorher. Daher ist viel Überzeugungsarbeit nötig.
Und Startschwierigkeiten gibt es sowieso.
Trotzdem bleibe ich optimistisch.
Dieter
ok , ich denke ich muss es mir anschauen , um es zu verstehen . Wie es letztendlich funktionieren soll , vorgefertigte Scripte an andere User zu übergeben ist mir so völlig unklar. Wenn die Geräte dort anders heissen müssen Sie im Script manuell umbenannt werden ( wie in fast jedem Hilfsmodul auch ) ... oder liege ich falsch ?
Ich kann deine Intension ja auch durchaus verstehen , diese scheine ich im Grunde nämlich zu teilen ( keine 100 doifs, notifys, at etc - die ich ebenso komplett ersetzt habe ) .
.... aber ich glaube es ist halt nichts für den 'einfachen' Anwender.
aber ggf. sehe ich das ja nach einem Test anders ;-)
gruss Byte09
Danke Beta-User;
ZitatDaher hast du eine Chance verdient.
Dieser Satz eines Developers macht mich froh und stolz.
Wenn ich noch jemanden überzeugen kann, sich positiv zu äußern, würde Rudi mein Modul nach FHEM übernehmen. Das wäre ein gewaltiger Fortschritt. Dann würde ich auch die komplette Sprachbeschreibung erstellen.
Allerdings interessiert mich immer noch, welches Problem du eigentlich damit löst ;D . Vielleicht erklärst du uns das ja noch etwas ausführlicher?Das hast du eigentlich schon selbst gut erkannt:
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...Einen weiteren Aspekt findest du in meiner Antwort auf den letzten Beitrag von Byte09.
Nochmals Danke und
viele Grüße
Zitat von: dieter56 am 12 April 2019, 15:18:40
Danke Beta-User;
Dieser Satz eines Developers macht mich froh und stolz.
Ganz im Ernst: Ich bin USER, auch wenn ich wegen diverser historischer Zufälligkeiten hier im Forum diesen völlig unpassenden "Titel" trage. Tatsächlich glaube ich selbst nicht, vor Softwareentwicklung wirklich Ahnung zu haben, also tu' du es bitte auch nicht...
ZitatWenn ich noch jemanden überzeugen kann, sich positiv zu äußern, würde Rudi mein Modul nach FHEM übernehmen. Das wäre ein gewaltiger Fortschritt. Dann würde ich auch die komplette Sprachbeschreibung erstellen.
Das war nicht in dem von Rudi gemeinten Sinne positiv gemeint, wie gesagt, ich kann das letztlich gar nicht ernsthaft als Developer beurteilen. Ich wollte lediglich zum Ausdruck bringen, dass ich dem Aufwand Respekt zolle, der in dem Projekt steckt. Nicht mehr, nicht weniger.
Beachte bitte, dass die komplette Sprachbeschreibung - jedenfalls in Kurzform (!) - vermutlich als commandref abzufassen sein sollte und diese dann auch qua Definition in Englisch verfügbar sein muß; ergänzen: von Trickerseien, die mancher hier praktiziert, halte ich persönlich an der Stelle wenig.
ZitatDas hast du eigentlich schon selbst gut erkannt:
Einen weiteren Aspekt findest du in meiner Antwort auf den letzten Beitrag von Byte09.
Das beantwortet ggf. jedenfalls in Teilen meine vorhin gestellte Frage, ja. Vielleicht gibt's dazu auch bei Gelegenheit ein konkretes Beispiel?
Allerdings sehe ich im Moment noch nicht den großen Vorteil, wenn Code - anders als als Modul oder (wenig praktiziert) als myUtils-Code - geshared werden kann. Das ist ok, wenn er von vornherein fehlerfrei ist (was komplexer Code nach meiner Erfahrung praktisch nie ist, schon gleich nicht auf Dauer), aber ansonsten ist es in der Regel besser, es gibt einen zentralen Verantwortlichen, der dann das Problem bei Auftreten für alle löst.
Und viele Attribute, na ja, man muß das nicht lieben, aber wenn es nur darum geht, Referenzierungen herzustellen usw., ist das schon ok. Irgendwo muß so eine Info halt stehen. Und dass man nicht für jede Kleinigkeit einen Dummy braucht, ist eine andere Diskussion, die wir auch schon hinlänglich hatten.
Den Grundgedanken (?), allen FHEM-Geräten (oder Readings?) Klassen zuzuweisen, und dann auf einer etwas abstrakteren Ebene darauf zuzugreifen, finde ich übrigens interessant. Im Moment gibt es kein übergreifendes Konzept (?), wie FHEM auf einfache Weise ohne Berücksichtigung der konkret dahinterstehenden Hardware für externe Schnittstellen "verfügbar" macht; also z.B. für Sprachsteuerungen. Da mag eventuell Verbesserungsbedarf bestehen, aber wenn, dann m.E. auch eher innerhalb der FHEM-eigenen Systematik. Aber wie gesagt: Eigentlich verstehe ich von sowas nichts...
Vielleicht noch eine ganz andere Sache: Wenn du möchtest, dass Tester deinen Code nutzen und an Verbesserungen mitarbeiten, wäre es besser, statt eines tarballs die Struktur so aufzubereiten, dass sie mit dem normalen update-Mechanismus kompatibel ist, also eine controls-txt-file bereitzustellen.
Zitat von: dieter56 am 12 April 2019, 09:10:19
Hallo micky0867,
mein FHEM läuft auf einer Linux-Maschine auf der Basis Debian - und das seit vielen Jahren. Warum der Ordnername bei mir klein geschrieben ist, weiß ich nicht. Entscheidend ist aber, dass die Datein für die lambda-Installation die die Ordner mit den entspechenden Inhalten kommen.
WINDOWS -- brrr.
Gruß
Dieter
Sorry, da habe ich vorschnell von einem grafischem Dateibrowser auf Windows geschlossen...
Allerdings ist es nach meinem bescheidenen Ermessen nicht so ohne weiteres möglich, das Verzeichnis FHEM anders zu benennen, ausser mit einem Symlink getricksts.
Ansonsten schau mal, wie oft /FHEM in fhem.pl vorkommt.
Zu deinen Bemühungen:
Ich hab's mir kurz angeschaut und finde es nicht sonderlich intuitiv.
Außerdem bevorzuge ich eine Sprache/Syntax, die weit verbreitet ist und für die es viele Beispiele/Snippets gibt (beruflich habe ich es nämlich leider mit einem Exoten zu tun, für den es im Internet kaum Beispiele gibt).
Perl würde ich zwar nicht als schöne Sprache bezeichnen, insbesondere nicht für große Projekte, aber Perl ist weit verbreitet und ausgereift.
Hallo micky0867,
Danke für deine Antwort. Warum bei mir das FHEM-Verzeichnis klein geschrieben wird weiß ich wie gesagt nicht. Der aktuell zum Download bereit gestellten Version ist das aber egal.
zu deiner Bemerkung:
Zitat
Ich hab's mir kurz angeschaut und finde es nicht sonderlich intuitiv.
...
Perl würde ich zwar nicht als schöne Sprache bezeichnen, insbesondere nicht für große Projekte, aber Perl ist weit verbreitet und ausgereift.
Sieht man sich Forum-Threads an bei denen es um eine Vermischung con ATs NOTIFYs DOIFs und Perl geht sind die Ergebnisse alls andere als intuitiv - Das soll nicht heißen, dass es unlogisch ist, aber der Weg zu einer funktionierenden Lösung ist anstrengend und voller Fallstricke.
Mein Weg ist ein anderer: Ein definiertes AT z.B.
+00:01 set Lampe off; set Lampe onoder ein notify z.B.
btn3 set lamp $EVENTsind letztendlich auch Produkte zweier Scriptsprachen (einer für at und einer für notify). Die sind nicht miteinder mischbar. Es auch nicht möglich alles zu tun was man als User tun möchte. Auch nicht, wenn ich noch eine dritte (DOIF) hinzunähme. Deshalb muß man Perl hinzuziehen. Ein Mix von Allem ist die Folge. Wer damit gut zurecht kommt, soll das auch weiter tun.
Ich kann mir gut vorstellen, dass der größte Teil der neuen FHEM-User von Perl noch nie etwas gehört hat. Sie sind, wenn man nichts zulässt wie ich es plane, darauf angewiesen eine Sprache von vorgestern zu lernen und mit den ATs, NOTIFYs zu verbinden.
Wenn man schon neu anfängt, dann doch mit etwas, das eine komplette Steuerung unter einem Dach ermöglicht.
In fast jeden Internet-Browser ist die dafür entwickelte Scripsprache java-script integriert, um die Möglichkeiten für die Darstellung von WebSites zu erweitern. Im Office-Paket von Microsoft gibt es die Scriptsprache "Visual Basic for Applications - VBA" um auf die Objekte in einer Office-Datei zuzugreifen. In AUTOCAD werkelt ein LISP-Dialekt als Scripsprache, ...
Wahrscheinlich sind alle diese Programme in C oder C++ programmiert. Man stelle sich vor, man müßte statt mit java-script, VBA, LISP,... mit C-Schipseln hantieren um über die Standardmöglichkeiten hinaus etwas zu erreichen.
Ich habe lambda-script entwickelt und sehr moderne Programmier-Paradigmen umgesetzt.
Das System ist noch offen und sehr flexibel. Es soll keinem der etwas anderes mag übergestülpt werden. Aber, denke ich, es ist wesentlich einfacher zu erlernen, als das, was ich und viele andere lernen mussten, die mit FHEM begannen.
Gruß
Dieter
Hi Dieter,
kannst du das ganze denn mal über eine 'controls.txt' installierbar machen (GIT) ?
gruss Byte09
Hallo Byte09,
Ich habe keine Ahnung wie ich das machen soll. Muss man dafür nicht als Entwickler von Rudi in der SVN registriert sein?
Gruß
Dieter
Zitat von: dieter56 am 14 April 2019, 14:30:44
Hallo Byte09,
Ich habe keine Ahnung wie ich das machen soll. Muss man dafür nicht als Entwickler von Rudi in der SVN registriert sein?
Gruß
Dieter
ja, das ist richtig. aber du kannst es ja vorerst extern automatisiert installierbar machen und stellst den ganzen kram dazu nach 'github.com'. Es ist eigentlich schon fast die Regel das Vorabmodule, Testversionen etc.pp dort 'abgelegt' sind . Auch meine Module ( insbesondere MSwitch ) waren bald 1 Jahr lang nur über diese Möglichkeit installierbar.
Du musst dich da allerdings auch ein wenig reinarbeiten. Aber wenn du dir mal ein Modul suchst , was dort vertreten ist und auf die ensprechende Seite gehst kannst du im Grunde alles abschauen.
findest du reichlich , wenn du mal nach 'github fhemmodul' suchst.
In jedem Fall mindert das ggf. die manuelle 'Installationsfaulheit' und fördert die Akzeptanz ( zumindest gilt das für mich ) ;)
gruss Byte09
Hallo Byte09,
danke. Ich denke, das hilft mir weiter. Heute werde ich aber nicht mehr dazu kommen.
Bis bald
Dieter
Hallo Dieter,
jetzt muss (nein möchte) ich doch auch nochmal kurz meine Gedanken zu deiner Argumentation anführen:
Zitat von: dieter56 am 14 April 2019, 13:58:30
In fast jeden Internet-Browser ist die dafür entwickelte Scripsprache java-script integriert, um die Möglichkeiten für die Darstellung von WebSites zu erweitern. Im Office-Paket von Microsoft gibt es die Scriptsprache "Visual Basic for Applications - VBA" um auf die Objekte in einer Office-Datei zuzugreifen. In AUTOCAD werkelt ein LISP-Dialekt als Scripsprache, ...
Na ja, die Skriptsprache von FHEM ist eben Perl. Ja, das ist zufällig die Sprache, in der FHEM entwickelt wird. Muss ja deswegen nicht schlecht sein!
Und Perl kann ich in notify, AT, DOIF, ... verwenden , gar kein Problem und damit kann jeder User tun, was immer er möchte. Und das ist keine Vermischung, sondern Anwendung.
Zitat von: dieter56 am 14 April 2019, 13:58:30
Ich kann mir gut vorstellen, dass der größte Teil der neuen FHEM-User von Perl noch nie etwas gehört hat. Sie sind, wenn man nichts zulässt wie ich es plane, darauf angewiesen eine Sprache von vorgestern zu lernen.
Von Lambda aber auch nicht, und außer hier gibt es dazue keine weiteren Wissensquellen, das sieht bei Perl schon anders aus.
Und wieso ist Perl eine Sprache von Vorgestern? Was genau ist die Begründung dafür? Perl wird auch weiterentwickelt und auch mit Perl sind "moderne Programmierparadigmen" umgesetzt und umsetzbar.
Auch hat ein Anfänger, der als FHEM-User Perl lernt immerhin die Chance später an FHEM selbst aktiv mitzuentwickeln.
Das ist bereits mehrfach so passert ;)
Und was ich bisher zu Lambda-Skript gesehen habe, ist die Lernkurve für einen Anfänger, der bisher eher nichts mit Programmierung (im besten Fall vielleicht VBA) zu tun hatte, auch relativ steil.
Zitat von: dieter56 am 14 April 2019, 13:58:30
Sieht man sich Forum-Threads an bei denen es um eine Vermischung con ATs NOTIFYs DOIFs und Perl geht sind die Ergebnisse alls andere als intuitiv - Das soll nicht heißen, dass es unlogisch ist, aber der Weg zu einer funktionierenden Lösung ist anstrengend und voller Fallstricke.
In die (vermeintliche) Vermischung von notify, AT und DOIF, Perl wird sich dann eben auch noch Lambda einreihen.
Versteh mich nicht falsch, ich will deine Arbeit nicht schlecht reden, ganz im Gegenteil!
Aber dennoch sind die Argumente dafür (zumindest für mich) eigentlich keine.
Nichts desto trotz werden sich auch für Lamda Fans finden. Klingt für mich ganz so, als ob das v.a. was für die DOIF-Fraktion (hier gehört noch ein Augenzwinkern hin) ist.
Generell sehe ich das wie Beta-User:
Zitat von: Beta-User am 12 April 2019, 09:25:00
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 (https://forum.fhem.de/There's%20more%20than%20one%20way%20to%20do%20it)...
Aber eine möglichst vollständige Dokumentation sollte bei so einer komplexen Geschichte, wie einer Skriptsprache schon vorhanden sein. Und unterschätze nicht den Supportaufwand, der auf dich zukommt!
gb#
Danke Benni,
für dein ausfühliches Statement. Wenn du mit dem System, so wie es jetzt ist, zurecht kommst und zufrieden bist, ist das doch toll.
Nur noch eine konkrete Richtigstellung zu
ZitatIn die (vermeintliche) Vermischung von notify, AT und DOIF, Perl wird sich dann eben auch noch Lambda einreihen.
Nein, die Verwenduing von lambda-script macht alles andere unnötig. Man braucht nur noch lambda-script.
An der ausfühlichen Dokumention wird kontinuierlich gearbeit. Ab und zu mal reinschauen auf: http://www.lambda-script.org
Gruß
Dieter
Hallo Dieter,
im aktuellen Download ist keine Datei lambda.pm im Unterordner lambda ???
Panik
Sorry,
mein Fehler. Jetzt ist die Downloaddatei komplett.
http://lambda-script.org
Danke für den Hinweis.
Bitte sofort melden wenn du Probleme hast. Kann aber über Ostern etwas dauern bis ich mich melde. Familie und so ..
Nochmals Danke.
Bis bald Dieter
Zitat von: dieter56 am 14 April 2019, 15:07:01
Nein, die Verwenduing von lambda-script macht alles andere unnötig. Man braucht nur noch lambda-script.
Da bin ich noch nicht ganz überzeugt. Aber vielleicht kannst Du mir helfen? Wie könnte ich z.B. folgende DOIFs in lambda-script schreiben?
defmod di_Waschmaschine DOIF ([Waschmaschine_Power:power]<5) (set ameBot msg 'Waschmaschine fertig')
attr di_Waschmaschine wait 300
Wenn power unter 5 kommt, und 300 Sek lang unter 5 bleibt => Nachricht
defmod diBackup DOIF ([02:00|0]) (configdb dump,"tar cfz /net/backup/FHEM-`date +%Y%m%d_%H%M%S`.tar.gz --exclude=backup .")
Hier sind die Fragen: wie definiere ich ein "moment" an einem bestimmten Wochentag, und wie komme ich auf Systembefehle?
defmod nt_di_Boost DOIF (([di_Boost] eq "on") and ([?di_Automatik] eq "auto")) \
(set di_HC disable, set di_HC_zuHause disable, set Heizung_Diele desired-temp 21)\
(set di_HC enable, set di_HC_zuHause enable, {Heating_Control_SetTemp("di_HC")})\
\
DOELSEIF (([di_Boost] eq "on") and ([?di_Automatik] eq "zuhause"))\
(set di_HC disable, set di_HC_zuHause disable, set Heizung_Diele desired-temp 21) \
(set di_HC enable, set di_HC_zuHause enable, {Heating_Control_SetTemp("di_HC")})\
\
DOELSEIF (([di_Boost] eq "off") and ([?di_Automatik] eq "auto")) \
(set di_HC enable, set di_HC_zuHause enable, {Heating_Control_SetTemp("di_HC")})\
\
DOELSEIF (([di_Boost] eq "off") and ([?di_Automatik] eq "zuhause")) \
(set di_HC enable, set di_HC_zuHause enable, {Heating_Control_SetTemp("di_HC_zuHause")})\
attr nt_di_Boost wait 0,7200:0,7200:0:0Da sehe ich schon die mögliche Struktur des lambda-scripts, mit einem wait, mehrere if und case, und wait x'seconds, aber wie rufe ich die Perl-function Heating_Control_SetTemp() auf? Und was passiert, wenn di_Boost während der 7200 wait-Sekunden wieder auf "off" springt?
defmod di_Rolladen_MorgenAbend DOIF ([{sunrise("REAL",0,"06:00","08:00")}|8] and [RolladenAutomatik] eq "on")\
(set wz_Rolladen auf)\
DOELSEIF ([{sunrise("REAL",0,"09:00","09:30")}|7] and [RolladenAutomatik] eq "on")\
(set wz_Rolladen auf)\
DOELSEIF ([{sunset("REAL",1800,"18:00","23:00")}] and [RolladenAutomatik] eq "on")\
(set wz_Rolladen zu, set ez_Rolladen zu, set kz_Rolladen zu )Hier: wie komme ich auf sunrise / sunset, abhängig vom Wochentag?
Mir ist auch nicht ganz klar, wie ich auf Ereignisse reagieren kann, wie z.B.:
defmod UpdateFinished notify global.UPDATE.* set Update.Dummy done
Hallo amenomade und danke für deine Fragen.
Zu deiner Ersten:
ZitatWenn power unter 5 kommt, und 300 Sek lang unter 5 bleibt => Nachricht
Eine Möglichkeit:
WM_msgTime := now;
repeat {
w := wait Waschmaschine_Power WM_msgTime;
case
(w = 2) {set ameBot "msg Waschmaschine fertig"}
([Waschmaschine_Power power]'toNumber < 5 & WM_msgTime < now) {WM_msgTime := now + 5,0}
([Waschmaschine_Power power]'toNumber >= 5) {WM_msgTime := now};
};
Die erste Zeile
WM_msgTime := now; definiert eine Variable die die Zeit der Benachrichtigung enthält. in der Schleife dann der wait Befehl
wait Waschmaschine_Power WM_msgTime;Er wartet darauf, dass sich in dem Device Waschmaschine_Power was tut oder auf das Erreichen der Zeit WM_msgTime. Er wartet so lange, bis eins von Beidem eintrifft. Da WM_msgTime nicht in der Zukunft liegt, wird nur auf Waschmaschine_Power gewartet.
Der Rückgabewert des Wait-Befehls ist die Nr. des Parameters der ausgelöst hat. Ist der Rückgabewert ist 2, also wenn WM_msgTime gesetzt und erreicht wurde - dann die Meldung.
Ansonsten wird das Reading power ausgewertet. Wenn kleiner als 5 und keine Benachrichtigungszeit gesetzt wurde, wird das gemacht (aktuelle Zeit plus 5 Minuten). Ist das Reading power >= 5 wird die Benachrichtigungszeit wieder zurückgesetzt. Man kann zum Zurücksetzen auch einen beliebigen Zeitpunkt in der Vergangenheit nehmen. z.B.: WM_msgTime := today;
Soweit dazu. Es ist vielleicht nicht die eleganteste Lösung, aber die die mir spontan einfiel. Zum Rest melde ich mich später. Ich muss jetzt erst mal ins Bett.
Gruß
Dieter
Hallo Dieter,
jetzt fehlt da die 98_lambda.pm
Panik
Hallo Panik,
Wenn ich das Archiv mit mc (MidnightCommander) ansehe ist alles drin. Wahrscheinlich verstehe ich zu wenig davon. Ich habe die Dateien nochmal jeweils einzeln zum Download hochgeladen.
Gruß
Dieter
Hallo Dieter,
ich nehme immer 7-ZIP und da sind es gesamt nur 2 Dateien ???
Aber was Anderes:
Könnte man mit lambdaDevices eine Liste der Devices anzeigen lassen?
Und ist es auch möglich später mal mit den Alias-Namen eines Gerätes zu arbeiten, sofern einer vergeben wurde?
Ansonsten schönes Osterfest!
Panik
Hallo dieter56,
bin schwer begeistert von Lambda.
Scheint schon so ziemlich alles dabei zu sein: Respekt, eine Skriptsprache auf ~~ 3 Seiten darzustellen, sehr strukturiert und auf das Notwendige eingedampft.
Habe heute nachmittag meine Urlaubsautomation in einem device runtergeschrieben, incl. RTS-Rollos, Tradfri, Sonoff-Tahomas; Netatmo und die Heizung habe ich heute nicht geschafft.
Da ich noch neu 'im Geschäft' bin (und Perl auch nicht kenne) fällt es mir deutlich leichter die Aufgaben in Lambda zu erledigen an Aufgaben und Zeiten orientiert als mit DOIFs, ATs oder ähnlichem.
Genau genommen braucht man mit Lambda nur die devices als Objekte mit Eigenschaften und Aktionen, sehr übersichtlich.
Also auf jeden Fall vielen Dank, ich hoffe dass es weitergeht mit dieser Skriptsprache, sie gefällt mir auch aber auch so schon sehr gut.