Oft braucht man eine Variable um sich Dinge zu merken. Auf der FHEM-Ebene nutzt man dazu häufig Readings. Mit dem Attribut myReadings soll ähnlich userReadings die Möglichkeit geboten werden, eigene Readings mit Hilfe der DOIF-Syntax zu definieren, auf die man zugreifen kann.
Syntax
attr <DOIF-Modul> myReadings <readingname1>:<definiton>, <readingname2>:<definition>,...
<definition>: Beliebige Perldefinitionen ergänzt um DOIF-Syntax in eckigen Klammern. Angaben in eckigen Klammern wirken triggernd und aktualisieren das definierte Reading.
Beispiel:
define di_temp DOIF ([$SELF:temperature]>20) (push "Die Durchschnittstemperatur ist höher als 20 Grad, sie beträgt [$SELF:temperature]")
DOELSE
attr di_temp myReadings temperature:[#average:d2:"":temperature]
Hierbei wird der Durchschnittswert nur einmal berechnet, statt zwei mal, wenn man die Aggregationsfunktion direkt angeben würde.
Mit myreadings kann man ebenso mehrer Readings innerhalb eines DOIFs definieren, die Informationen sammeln sollen, auf die man überall zugreifen kann.
weitere Beispiele:
attr di_window myReadings open_window:"Offene Fenster ".[@"^window":state:"open"], closed_windows:"Geschlossene Fenster ".[@"^window":state:"closed"]
Korrigierter Wert um ein Grad:
attr di_temp_corr myReadings temperature:[aussen:temperature]-1
Temperaturdifferenz:
attr di_temp_diff myReadings diff:[aussen:temperature:d2]-[innen:temperature:d2]
Anregungen hier posten.
Edit: Beispiele wurden angepasst.
Das Attribut heißt jetzt DOIF_Readings.
Die Funktionalität ist hier eingeflossen https://forum.fhem.de/index.php/topic,77690.0.html
Attributnamen beginnen im Allgemeinen mit einem kleinen Buchstaben und weitere Worte im Namen mit einem Großbuchstaben(userReadings, readingList, setList, webCmd, usw.)
Daher würde ich "myReadings" als Attributnamen vorschlagen.
Zitat von: Ellert am 23 April 2017, 19:15:32
Attributnamen beginnen im Allgemeinen mit einem kleinen Buchstaben und weitere Worte im Namen mit einem Großbuchstaben(userReadings, readingList, setList, webCmd, usw.)
Daher würde ich "myReadings" als Attributnamen vorschlagen.
kein Problem, ist noch nichts programmiert :)
Was passiert, wenn (was man wahrscheinlich nicht machen sollte) ich den Wert mit set überschreibe?
Zitat von: Per am 25 April 2017, 13:47:30
Was passiert, wenn (was man wahrscheinlich nicht machen sollte) ich den Wert mit set überschreibe?
dann würde das Reading bis zum nächsten Trigger der zu der angegebenen Rexex passt überschrieben bleiben.
OK, dass passt.
Fehlt eigentlich nur noch die eigene Oberfläche und DOIF braucht das FHEM-Anhängsel nicht mehr ;D ;D ;D
Zitat von: Per am 25 April 2017, 14:44:25
OK, dass passt.
Fehlt eigentlich nur noch die eigene Oberfläche und DOIF braucht das FHEM-Anhängsel nicht mehr ;D ;D ;D
--> https://developers.google.com/blockly/
das währe dann idiotensicher *g*
Zitat von: the ratman am 25 April 2017, 16:00:49
--> https://developers.google.com/blockly/
das währe dann idiotensicher *g*
muss nur einer programmieren, der Zugriff auf alle Informationen im System ist ja da :)
ich kauf schon mal bücher ... seit ich weiß, das kombjuda anders geschrieben wird, find ich auch infos dazu *g*
ich sollte mit der implementation von blockly in ca. 10 - 15 jahren fertig sein. kannst du bis dahin nix mehr am doif ändern bitte? sonst bin ich wieder verwirrt *bg*
Zitat von: the ratman am 25 April 2017, 16:40:07
ich kauf schon mal bücher ... seit ich weiß, das kombjuda anders geschrieben wird, find ich auch infos dazu *g*
ich sollte mit der implementation von blockly in ca. 10 - 15 jahren fertig sein. kannst du bis dahin nix mehr am doif ändern bitte? sonst bin ich wieder verwirrt *bg*
Dann wird das wohl nix, es steht zu viel in der Pipeline.
Im ersten Post kann man die erste Version laden.
Die Definition der Readings habe ich bewusst in Perlsyntax belassen, um möglichst flexibel zu bleiben. Sie wird um DOIF-Syntax ergänzt. DOIF-Angaben in eckigen Klammern werden bei der Definition des Attributes wie bei DOIF-Bedingungen in Perl-Funktionen übersetzt. Beim Trigger wird nur noch eval ausgeführt - ein erneutes Parsen entfällt.
Doku fehlt noch. Die Beispiele im ersten Post wurden auf die aktuelle Syntax aktualisiert.
Zitat von: Damian am 23 April 2017, 17:15:14Angaben in eckigen Klammern wirken triggernd und aktualisieren das definierte Reading.
Das macht es bei mir, wenn ich das zugehörige Device direkt ändere. Ändere ich es über das betreffende DOIF, dann leider nicht immer. Ich habe aber noch kein System erkannt, um dir einen Tipp geben zu können.
Zitat von: Per am 21 Juni 2017, 23:40:25
Das macht es bei mir, wenn ich das zugehörige Device direkt ändere. Ändere ich es über das betreffende DOIF, dann leider nicht immer. Ich habe aber noch kein System erkannt, um dir einen Tipp geben zu können.
Wenn die Änderung durch MyReadings vorgenommen wird, dann ist Selbsttriggerung-Sperre ausgeschaltet - das eigene DOIF reagiert auf den Trigger. Wenn du aber per set eigene Readings änderst, dann schlägt die Selbsttriggerung-Sperre zu.
Geht das mit dem attr selftrigger einzustellen?
Gleich selbst beantwortet: geht!
hi Damian,
wann ist es geplant diese DOIF-Funktion offiziell zu verteilen?
Danke und Gruß,
Fixel
Zitat von: Fixel2012 am 03 Juli 2017, 10:53:59
hi Damian,
wann ist es geplant diese DOIF-Funktion offiziell zu verteilen?
Danke und Gruß,
Fixel
Vermutlich im Laufe des Monats.
Bevor es ein offizielles Release gibt, möchte ich den Attributnamen zur Diskussion stellen.
Ich meine, "my" ist etwas zu nichtssagend, "user" ist schon vergeben und "usor" für usorReadings, ist vieleicht nicht unterschiedlich genug.
Wäre nicht "optReadings" für optionalReadings oder "extReadings" für extendedReadings eine treffendere Bezeichnung?
Zitat von: Ellert am 09 August 2017, 14:08:51
Bevor es ein offizielles Release gibt, möchte ich den Attributnamen zur Diskussion stellen.
Ich meine, "my" ist etwas zu nichtssagend, "user" ist schon vergeben und "usor" für usorReadings, ist vieleicht nicht unterschiedlich genug.
Wäre nicht "optReadings" für optionalReadings oder "extReadings" für extendedReadings eine treffendere Bezeichnung?
Ich bin da offen, ggf. uReading oder doifReading, weitere Vorschläge kann man hier einbringen und dann schauen wir mal, was für die Anwender verständlich erscheint: für Userreadings mit DOIF Syntax
Zitat von: Damian am 09 August 2017, 17:52:38
Ich bin da offen, ggf. uReading oder doifReading, weitere Vorschläge kann man hier einbringen und dann schauen wir mal, was für die Anwender verständlich erscheint: für Userreadings mit DOIF Syntax
doifReading erscheint mir persönlich am geeignetsten. Und ist am besten verständlich, was überhaupt gemeint ist!
Zitat von: Fixel2012 am 09 August 2017, 18:11:10
doifReading erscheint mir persönlich am geeignetsten. Und ist am besten verständlich, was überhaupt gemeint ist!
Ja sehe ich genauso :)
Vote
doifReading
Ein Attributsname sollte einen Hinweis auf seinen Inhalt geben, da halte ich "doif" als Vorsilbe für nicht geeignet. Diese Vorsilbe könnte dann jedes doifspezifisches Attribut haben.
Die "Userreadings mit DOIF Syntax" werden in der Regel ausgeführt, sie leisten etwas, vollbringen etwas.
Daher wäre "performReadings" ein treffender Attributsname.
Zitat von: Ellert am 09 August 2017, 21:04:24Diese Vorsilbe könnte dann jedes doifspezifisches Attribut haben.
Genau darum ist es ja gut geeignet. Und es wird auch in Zukunft nicht zu namentlichen Doppelungen kommen, da es nur ein Device
DOIF gibt (geben kann).
Zitat von: Ellert am 09 August 2017, 21:04:24"Userreadings mit DOIF Syntax"
Ein weiterer Punkt
für doifReading.
Zitat von: Ellert am 09 August 2017, 21:04:24werden in der Regel ausgeführt, sie leisten etwas, vollbringen etwas.
Und nocheiner. Zumindest aus Sicht der DOIF-Fanboys* wie mich ;)
*) Bestes Beispiel: OliS. (https://forum.fhem.de/index.php?action=profile;u=10396) mit "DOIF, ich will ein Kind von dir" ;D.
Ich denke, dass dieses Attribut schon eine Sonderstellung als DOIF-Attribut hat, da es bereits ein Attribut Userreadings für ähnliche Funktionalität gibt.
So wie heute notify und DOIF als Eventhandler für Problemstellungen genannt werden, werden zukünftig möglicherweise Userreadings und "doifReadings" als Problemlösungen in einem Atemzug genannt werden.
"doifReading" ist kürzer zu schreiben als "...Readings im DOIF-Modul" denn es funktioniert ja im Gegensatz zu Userreadings nur im DOIF-Modul und das würde man am Namen des Attributes sonst nicht erkennen.
Außerdem kann man ein DOIF-Modul bauen, welches nur aus doifReadings besteht - daher Sonderstellung des Attributs.
Bevor sich der Attributname sich zu doifReadings verfestigt, aber der Modulname in Großbuchstaben geschrieben ist, sollte dann nicht auch die Großschreibung berücksichtigt werden, etwa DOIF_Readings, readingsDOIF, readings4DOIF, userReadingsDOIF u.ä.
Die Großschreibung des Modulnamen hat einen Wiedererkennungswert, der nicht verspielt werden sollte.
Die Syntax der Attribute ist "kleinGrossGross". Die Syntax der Devices wird leider nicht so stringent gehandhabt. Daher sollte man das nicht auch noch aufweichen.
Zitat von: Per am 11 August 2017, 16:44:16
Die Syntax der Attribute ist "kleinGrossGross". Die Syntax der Devices wird leider nicht so stringent gehandhabt. Daher sollte man das nicht auch noch aufweichen.
"kleinGrossGross" ist keine festgeschriebene Syntax, eher eine geübte Paxis, von der es genügend Abweichungen gibt, beispielsweise in den Modulen Text2Speech, DbLog, SOMFY, IT und namentlich die Attribute IODev, event-on.*, userattr , um einige zu nennen und viele globale Attribute. Da gibt es nichts mehr aufzuweichen, es ist schon eine butterweiche Syntax. Insofern ist die Großschreibung des Modulnamen im Attributsnamen leicht zu tolerieren, zumal sie dazu dient den Wiedererkennungswert des Wortbildes DOIF aufrecht zu erhalten.
Die geübte Praxis spricht eher gegen die Kleinschreibung von DOIF im Attributnamen, z.B. wird die Schreibung des Modulnamen beibehalten in DOIFtoolsEventMonitorInDOIF und ITrepetition.
Dann schlage ich "DOIF_Readings" vor. DOIFReadings bzw. DOIFreadings liest sich schlecht.
Zitat von: Damian am 11 August 2017, 20:00:06
Dann schlage ich "DOIF_Readings" vor. DOIFReadings bzw. DOIFreadings liest sich schlecht.
Damit wäre aus meiner Sicht ein guter Kompromiss gefunden, der die vorgebrachten Ansichten und die übliche Praxis angemessen berücksichtigt.
Hi Damian,
bin mir nicht sicher, aber das Feature ist noch nicht im Standard, oder?
Benutze gerade userreading, aber die werden nur beim Feuern des DOIF aktualisiert - aber nicht während der Laufzeit des DOIF (will über Hourcounter die aktuelle Laufzeit des Regners mit verwenden, der über eine Zeitspanne im DOIF an- und ausgeschaltet wird)
VG timmo
Zitat von: Tsturm am 06 September 2017, 22:20:28
Hi Damian,
bin mir nicht sicher, aber das Feature ist noch nicht im Standard, oder?
Benutze gerade userreading, aber die werden nur beim Feuern des DOIF aktualisiert - aber nicht während der Laufzeit des DOIF (will über Hourcounter die aktuelle Laufzeit des Regners mit verwenden, der über eine Zeitspanne im DOIF an- und ausgeschaltet wird)
VG timmo
Leider noch nicht. Das Attribut wird ja jetzt DOIF_Readings heißen.
DOIF_Readings kommt mit DOIF User Interface, es ist hier schon eingebaut https://forum.fhem.de/index.php/topic,77690.msg696203.html#msg696203