alternative Steuerung von FHEM mit Hilfe Scripten

[dieter56]

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

Code Auswählen Erweitern

19:00 set Lampe on
und lambda-script

Code Auswählen Erweitern

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

[Byte09]

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

[dieter56]

Danke Beta-User;

Daher 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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[Beta-User]

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...

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.

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.

Das 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.

[micky0867]

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.

[dieter56]

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:

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.

Code Auswählen Erweitern

+00:01 set Lampe off; set Lampe on
oder ein notify z.B.

Code Auswählen Erweitern

btn3 set lamp $EVENT
sind 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

[Byte09]

Hi Dieter,

kannst du das ganze denn mal über eine 'controls.txt' installierbar machen (GIT) ?

gruss Byte09

[dieter56]

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

[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

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

[dieter56]

Hallo Byte09,

danke. Ich denke, das hilft mir weiter. Heute werde ich aber nicht mehr dazu kommen.

Bis bald
Dieter

[Benni]

Hallo Dieter,

jetzt muss (nein möchte) ich doch auch nochmal kurz meine Gedanken zu deiner Argumentation anführen:

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.

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.

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:

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...

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#

[dieter56]

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

In 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

[Panik]

Hallo Dieter,

im aktuellen Download ist keine Datei lambda.pm im Unterordner lambda 

Panik

[dieter56]

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

[amenomade]

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?

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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?

Code Auswählen Erweitern

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?

Code Auswählen Erweitern

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.:

Code Auswählen Erweitern

defmod UpdateFinished notify global.UPDATE.* set Update.Dummy done