Warum will jeder DOIF verwenden?

Begonnen von Thorsten Pferdekaemper, 10 Februar 2017, 14:37:15

Vorheriges Thema - Nächstes Thema

Damian

#45
Zitat von: Thorsten Pferdekaemper am 11 Februar 2017, 14:32:07
Vielen Dank, Damian, für Deine differenzierten Antworten. Ich hoffe sehr, Du fühlst Dich durch mich nicht angegriffen. Falls doch, dann tut mir das leid und wir sollten das irgendwie aus dem Weg räumen.

Ehrlich gesagt, habe ich nichts anderes erwartet. Es ist ja nicht die erste Diskussion zu diesem Thema. Ich bin schon länger im Forum unterwegs und kenne inzwischen die meisten  "Power"-User und deren Sichtweisen, daher überraschen mich deren Antworten nicht.

Genauso wie ich mir im aller ersten Post zum Modul https://forum.fhem.de/index.php/topic,23833.msg170608.html#msg170608 sicher über eine rege Diskussion war, bin ich mir jetzt sicher, dass wir uns noch öfters über dieses Modul "austauschen" werden, denn das Modul entwickelt sich weiter und nachdem ats und notifys mit dem Modul überflüssig wurden, werden mit den neuen Möglichkeiten der Websteuerung im DOIF auch zahlreiche Dummys wegfallen.

Naja, vielleicht brauchen wir tatsächlich bald eine Anfänger-Doku zu diesem Modul, denn die Grundidee des Moduls wird durch die vielen Features und die immer länger werdende Dokumentation immer mehr verschleiert.

Auch wenn die User einen komplexen endlichen Automaten mit dem Modul bauen wollen - ich werde sie daran nicht hindern - die ursprüngliche Intention war am Anfang zumindest eine andere.


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Ich nutze diesen Thread um DOIF-Fans und die es werden wollen über die gerade eingecheckte neue DOIF-Version zu informieren.

Auszug aus der neuen Commandref:

Anwendungsbeispiel: Schaltbare Lampe über Fernbedienung und Webinterface

define di_lamp DOIF ([FB:"on"]) (set lamp on) DOELSEIF ([FB:"off"]) (set lamp off)
attr di_lamp cmdState on|off
attr di_lamp devStateIcon on:on:cmd_2 initialized|off:off:cmd_1


Mit der Definition des Standart-FHEM-Attributs devStateIcon führt das Anklicken des on/off-Lampen-Icons zum Ausführen des set-Kommandos cmd_1 bzw. cmd_2 und damit zum Schalten der Lampe.

Selbstverständlich lässt sich der einfacher Anwendungsfall lediglich über ein notify, eine Perl-if-Abfrage und einen Dummy realisieren. Zusätzlich würde ich die Perl-if-Abfrage in myUtils auslagern, weil man dort direkt auf Syntaxfehler hingewiesen wird und nicht vergessen die set-Kommandos zum Schalten der Lampe in den Funktionsaufruf fhem("...") zu verpacken, naja so lernt man wenigsten Nebenbei bisschen Perl

oder man benutzt DOIF, allerdings weiß man dann nicht genau, was intern passiert, tja damit muss man dann wohl leben ;)

In diesem Sinne, viel Spaß beim Ausprobieren der neuen Version, ab morgen per Update verfügbar :)

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

vbs


kumue


Damian

Zitat von: vbs am 11 Februar 2017, 19:13:40
8)

Einen habe ich noch:

Leider wird sich die Anzahl der blöden Klammern durch die Verwendung des Perl-if-Befehls nicht verringern, sondern erhöhen, denn die ReadingVal-Abfrage, der if-Befehl und der fhem-Befehl brauchen ja auch welche - Mist. Ok beim fhem-Befehl könnte man sie ja weglassen, aber wir wollen den Anfängern keinen schlechten Programmierstil beibringen. Immerhin sieht man die Klammern in der fhem.cfg nicht, weil sie dann ja ausgelagert sind. Puh, noch mal alles gut gegangen ;)

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

satprofi

Doif ist einfacher als if,else. Die ganzen geschweiften Klammern machen einen wuggi. Und nichts ist einfacher als tu wenn zu denken

Gesendet von meinem ONEPLUS A3003

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

sentinel1

Hallo,

hätte es DOIF zu meine FHEM anfangszeit nicht gegeben wäre ich jetzt nicht mehr dabei.

War leicht und schnell zu lernen, dazu eine super Doku mit viele Beispiele.Es gibt nichts was ich, für mich ,nicht mit DOIF bauen kann und das reicht mir.
Im DOIF-Unterforum wird auch schnell geholfen und nicht immer auf die SuFu hingewiesen.

Ich verstehe die Diskussion hier auch nicht,mir scheint als währen hier einige neidisch auf das was Damian geschafft hat.

Danke an Damian für dieses tolle Modul.

Claudiu

rudolfkoenig

Zitatmir scheint als währen hier einige neidisch auf das was Damian geschafft hat.

Nicht immer :) Ich muss wg. DOIF mehr Support leisten, weil DOIF seine eigene Syntax schafft, und Leute bei den ueberall verfuegbaren Perl evals mit DOIF Syntax auf die Nase fallen. Statt lange Doku zu lesen experimentiert man halt mit copy&paste herum, und wenn es nicht tut, dann fragt man im Forum, und wenn es einen meiner Module trifft, dann bin ich halt dran. Eigentlich duerfte man IF und DOIF erst dann verwenden, wenn man verstanden hat, dass das jeweils Module mit eigener Syntax sind, und nicht perl.

(da wir jetzt komplett Off-Topic geworden sind, sorry Thorsten)
Irgendwie muesste man Damian dazu bringen, dass er fuer DOIF ein grafisches Frontend baut, wo man DOIF per Drag & Drop konfiguriert, und den eigentlichen DOIF Syntax nicht sieht. Damit waere dem Anfaenger / Ungeduldigen / Lernunwilligen :) geholfen, und die, die eine Programmiersprache verwenden wollen, wuerden nicht mit komischen Fragen genervt.

jkriegl

Habe Aufklappmenues auf einfache DOIFs umgestellt.
Zuvor war ein dummy plus ein notify erforderlich.
Rpi 3, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

marvin78

Andere Meinungen zu etwas zu haben, heißt nicht, dass man jemanden angreift oder gar die Arbeit von bspw. Damian nicht zu schätzen weiß bzw. sich bewusst ist, dass da viele gute Arbeit drin steckt. Wenn man aber über Dinge, wie DOIF diskutiert, kann es nicht immer nur heißen: "alles toll, es sollte nur noch DOIF geben". Man muss auch einfach mal andere Meinungen akzeptieren ohne dahinter gleich einen persönlichen Angriff zu vermuten (@Damian, damit bist du nicht persönlich gemeint). FHEM lebt genau davon, dass viele Wege nach Rom führen.

Ich vergleiche das ganze mal (auch wenn der Vergleich leicht hinkt) mit Einführung der Ribbons bei MS Office: Leute, die vorher sehr lange Office eingesetzt haben, fanden sich plötzlich nicht mehr zurecht und mussten alles lange suchen. Leute, die erst mit der neuen Office Version eingestiegen sind, taten sich oft leichter, als diejenigen, die vor Jahren mit der alten Menüform eingestiegen sind.

Solche unterschiedliche Meinungen können aus persönlichen Vorlieben, Gewöhnung und auch Erfahrungen entstehen. Solchen Meinungen darf man auch Ausdruck verleihen, ohne dass gleich irgendein seltsamer Hintergrund oder gar Neid vermutet wird.

Ich glaube kaum, dass Damian hinten rum gehoben werden muss, um weiter an DOIF dran zu bleiben.

Damian

Zitat von: rudolfkoenig am 11 Februar 2017, 20:37:24
Nicht immer :) Ich muss wg. DOIF mehr Support leisten, weil DOIF seine eigene Syntax schafft, und Leute bei den ueberall verfuegbaren Perl evals mit DOIF Syntax auf die Nase fallen. Statt lange Doku zu lesen experimentiert man halt mit copy&paste herum, und wenn es nicht tut, dann fragt man im Forum, und wenn es einen meiner Module trifft, dann bin ich halt dran. Eigentlich duerfte man IF und DOIF erst dann verwenden, wenn man verstanden hat, dass das jeweils Module mit eigener Syntax sind, und nicht perl.
ja, das Problem wirst du oder wir alle immer stärker haben. Denn in fünf Jahren wirst du noch viel mehr Module haben und jedes Modul wird seine eigene Syntax verwenden, da es keine Syntaxvorgaben gibt. Damit werden User noch mehr durcheinander werfen.

Mehr als:

Zitat aus der Commandref zu DOIF:

ZitatAn dieser Stelle setzt das Modul DOIF an. Es stellt eine eigene Benutzer-Schnittstelle zur Verfügung ohne Programmierkenntnisse in Perl unmittelbar vorauszusetzen.

kann ich auch nicht schreiben.

Zitat
(da wir jetzt komplett Off-Topic geworden sind, sorry Thorsten)
Irgendwie muesste man Damian dazu bringen, dass er fuer DOIF ein grafisches Frontend baut, wo man DOIF per Drag & Drop konfiguriert, und den eigentlichen DOIF Syntax nicht sieht. Damit waere dem Anfaenger / Ungeduldigen / Lernunwilligen :) geholfen, und die, die eine Programmiersprache verwenden wollen, wuerden nicht mit komischen Fragen genervt.

ja, allerdings zweifle ich an der Umsetzung, denn es kommt der Anforderung nahe, baue eine Drap & Drop Oberfläche um Perl zu programmieren. Denn die Bedingungen beim DOIF ist erweitertes Perl. Das dürfte schon an der Umsetzung der Klammern-Hierarchie scheitern. Eine Klammer auf oder zu irgendwo hinzuschieben macht wohl wenig Sinn. Tabellarische Konzepte wie bei Access für SQL-Abfragen zwingen User logische Abfragen durch Umformung in eine bestimmte Struktur zu pressen - gefällt mir auch nicht.

Jeder, der programmieren kann, kann allerdings einen Oberflächenaufsatz für DOIF bauen, um vielleicht 90 % der Standardfälle abzudecken. Das so etwas möglich ist, zeigt eindrucksvoll das DOIFtool-Modul von Ellert, dafür ist FHEM offen genug  (oder nicht ausreichend abgeschottet) um auf alle Definitionen zuzugreifen. Das hätte auch den Vorteil, dass das Modul nicht noch weiter aufgebläht würde - es muss ja schließlich jedesmal erst in den Speicher geladen werden.






Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Deckoffizier

Hallo,

da ja nach der Anfängersicht gefragt, gebe ich auch mal meinen Senf dazu, auch wenn ich schon 2 bis 3 Jahre mit FHEM zugange bin, bin ich mir noch sicher überhaupt den Anfängerstatus schon erreicht zu haben.
Schlicht und ergreifend kommt einem das DOIF bekannt vor,und  wenn man aus der Zeit des KC87, C64, Archimedes RISC-PC  und mit nie wider gefundenen intuitiven Software wie SBase stammt.
Bin nach wie vor der Meinung eine Programmiersprache lernen ist ähnlich einer Fremdsprache lernen und da ist Perl für mich nicht so  intuitiv und DOIF eher das Schweizer Taschenmesser.
Dazu habe ich das "Gefühl" Probleme mit ein zwei DOIF gelöst zu bekommen anstatt 10 notify die Programmierer mögen mir dies nachsehen und bin froh über über die vielen Beispiele die zentral an einer Stelle liegen zum Modul DOIF, wogegen ich bei andern Modulen schon ganz schön kreuz und quer in der Weltgeschichte suchen muss.
Aber um Himmels Willen jetzt keinen Glaubenskrieg und möchte auch keinen auf den Schlips treten, ist doch schön wenn man viele Möglichkeiten zur Problemlösung hat
Wenn man Programmierung Informatik von der Picke auf gelernt hat bzw. Zeit zum Selbststudium hatte sieht die Welt vielleicht anders aus aber dies war wohl nicht die Frage ?

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Damian

Zitat von: Deckoffizier am 12 Februar 2017, 17:31:48
Dazu habe ich das "Gefühl" Probleme mit ein zwei DOIF gelöst zu bekommen anstatt 10 notify die Programmierer mögen mir dies nachsehen und bin froh über über die vielen Beispiele die zentral an einer Stelle liegen zum Modul DOIF, wogegen ich bei andern Modulen schon ganz schön kreuz und quer in der Weltgeschichte suchen muss.

Genau das ist die Intention, die hinter diesem Modul steckt, nicht mehr und nicht weniger.

Zitat
Wenn man Programmierung Informatik von der Picke auf gelernt hat bzw. Zeit zum Selbststudium hatte sieht die Welt vielleicht anders aus aber dies war wohl nicht die Frage ?

Ich habe Informatik studiert und kann mittlerweile auch Perl programmieren und benutze es trotzdem ;)

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

kroemmel

Zitat von: Mitch am 10 Februar 2017, 17:20:17
[...]
ich benutze alle drei (DOIF, notiy, at) in folgender Reihenfolge:
1. ein Device zu einer bestimmten Zeit schalten: at
2. auf ein Event reagieren und ein Device schalten: notify
3. mehrere Events und Bedingungen, auf die verschieden reagiert werden soll: DOIF
[...]

Das kann ich so unterschreiben. Natürlich lassen sich mehrere Events und Bedingungen auch über eine Kombi von notify und at lösen, aber dann habe ich ggf. mehrere Orte, an denen ich Stellschrauben drehen müsste. Im DOIF nur einen.

Viele Wege führen zur Lösung (allgemeingültig für die Informatik, gerade in FHEM besonders gültig) und Eleganz oder Effizienz liegen manchmal halt im Auge des Betrachters.

Ob DOIF jetzt besonders Einsteigerfreundlich oder -feindlich ist, kann ich nicht beurteilen (als ich anfing, gab es noch kein DOIF soweit ich mich erinnere), aber ich bin immer ein Freund in der Lernphase möglichst viel "zu Fuß" zu erledigen, als über Hilfsmodule. Die machen einem später das Leben leichter, sofern man die Konzepte verinnerlicht hat. Sonst führen sie eher zu wilden Fragestunden.

cheers,
kroemmel
() FHEM als Ubuntu-VM
() VCCU mit 1 HMLAN, 2 UARTs und div. Sensoren/Aktoren (primär HM), HUE,
() Integration Fritz!Box, Googlekalender, Unifi, Viessmann Heizung, Umweltbedingungen, Sonnenstand, PWM, Jalousiesteuerung, Anwesenheitserkennung, Raumklimaüberwachung, Telegram

Damian

Zitat von: kroemmel am 12 Februar 2017, 18:51:47
Das kann ich so unterschreiben. Natürlich lassen sich mehrere Events und Bedingungen auch über eine Kombi von notify und at lösen, aber dann habe ich ggf. mehrere Orte, an denen ich Stellschrauben drehen müsste. Im DOIF nur einen.

Viele Wege führen zur Lösung (allgemeingültig für die Informatik, gerade in FHEM besonders gültig) und Eleganz oder Effizienz liegen manchmal halt im Auge des Betrachters.

Ob DOIF jetzt besonders Einsteigerfreundlich oder -feindlich ist, kann ich nicht beurteilen (als ich anfing, gab es noch kein DOIF soweit ich mich erinnere), aber ich bin immer ein Freund in der Lernphase möglichst viel "zu Fuß" zu erledigen, als über Hilfsmodule. Die machen einem später das Leben leichter, sofern man die Konzepte verinnerlicht hat. Sonst führen sie eher zu wilden Fragestunden.

cheers,
kroemmel

Wenn man zuerst at und notify kennengelernt hat, dann ist diese Vorgehensweise sicherlich ok.

Auf der anderen Seite könnte man sagen, wenn ich im Falle 3. DOIF verwende und mir seine Syntax angeeignet habe, warum sollte ich dann drei verschiedene Module mit jeweils unterschiedlicher Syntax lernen bzw. benutzen. Die Performanceunterschiede zwischen den Modulen werden nicht messbar sein, weil DOIF die gleichen Routinen benutzt wie at oder notify. Und wenn ich eine Lampe einschalte, dann will ich sie meistens auch wieder ausschalten, warum sollte man das nicht in einem Modul tun. Den Fall, dass man eine Lampe einschaltet und nicht wieder ausschaltet wird es wohl kaum geben.





Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF