neue Features: checkall: timer|event|all, timertrigger, timerintervall

[Damian]

Das Attribut checkall funktioniert jetzt mit events und timern.

Anwendungsbeispiel:

Um 18:30 Uhr wird abhängig vom dummy ein set-Befehl ausgeführt:

Code Auswählen Erweitern

di DOIF ([mydummy] eq "1")
   (set bla 1)
DOELSEIF ([mydummy] eq "2")
  (set bla 2)
DOELSEIF ([mydummy] eq "3")
  (set bla 3)
DOELSEIF ([18:30])

attr di checkall timer

Edit: aktuelle Version wurde eingecheckt

[Damian]

Version 0.2 im ersten Post mit folgenden Features:

1) Zeitintervalle mit gleicher Anfangs- und Endzeit sind jetzt nicht wahr und triggern auch nicht.
2) Timer und Timerintervalle mit Wochentagangaben triggern jetzt nur noch an den angegebenen Tagen.
3) Attribut checkall mit timer|event|all
4) Die Fehlermeldung "no trigger" bei der Definition kommt nicht mehr, da aufgrund von checkall Bedingungen ohne Trigger Sinn machen können

[Ellert]

Reduzieren von Events

Es gibt DOIF, bei denen es nicht notwendig ist, dass sie irgendein Event generieren.

Man könnte das Attribut "event-on-change-reading" nutzen und es mit einem Reading angeben, das im DOIF nicht vorkommt, dann erzeugt DOIF keine Events.

Code Auswählen Erweitern

attr <DOIFname> event-on-change-reading none

Oder man lässt nur bestimmte Events zu, z.B. für alle Readingsnamen die mit "cmd" beginnen.

Code Auswählen Erweitern

attr <DOIFname> event-on-change-reading cmd.*

Manchmal ist es nur erforderlich, dass für das Reading "state" Events erzeugt werden, wenn z.B. "state" in einem weiteren DOIF als Auslöser eingesetzt wird.

Die Begrenzung von Events auf das Reading "state" ist jedoch bisher nicht möglich, weil event-on-(change|update)-reading für "state" nicht funktioniert.

Mein Vorschlag ist daher, ein Attribut im DOIF einzubauen, dass alle anderen Events unterdrückt und nur Events für "state" erzeugt.

@Damian: Hältst Du das für sinnvoll das im DOIF einzubauen?

[Damian]

Ja, allerdings gehört das Setzen des Status über die interne Funktion readingsBulkUpdate (es wird in DOIF nur das Reading state gesetzt, das Setzen von Status ist dann FHEM) sowie aller anderen dazugehörigen Readings (cmd...) zum gleichen Trigger (an der Zeit erkennbar). Wenn man also mit einem DOIF den Status eines anderen DOIFs abfragt, dann wird auch nur einmal getriggert, denn es gibt nur einen Trigger.

Edit:

Man könnte das Unterdrücken aller anderen Events ins DOIF einbauen, allerdings würde man wieder ein neues Attribut definieren und etwas eigenes programmieren, was meiner Meinung ins FHEM gehört. Denn es geht hier um den Wunsch nur STATE-Events durchzulassen, z. B. mit attr <DOIFname> event-on-change-reading none. Man könnte im Developer Forum diesen Wunsch äußern.

[Garbsen]

Die neuen Möglichkeiten in den DOIF sind wirklich gut!
Frage: gibt es eine Möglichkwit die webCmd zu "beschriften"?
Derzeit werden mir in FHEM nur die jeweiligen Buttons Dropdowns oder knobs angezeigt, aber nicht welche readings damit gesteuert werden. Es wäre toll, wenn man da Beschriftungen zufügen könnte.
Geht das?
Danke

[Ellert]

Die neuen Möglichkeiten in den DOIF sind wirklich gut!
Frage: gibt es eine Möglichkwit die webCmd zu "beschriften"?
Derzeit werden mir in FHEM nur die jeweiligen Buttons Dropdowns oder knobs angezeigt, aber nicht welche readings damit gesteuert werden. Es wäre toll, wenn man da Beschriftungen zufügen könnte.
Geht das?
Danke

Das kannst Du mit einer ReadingsGroup machen.

Oder einfach

Code Auswählen Erweitern

webCmd <Beschriftung 1>:<Reading 1>:<Beschriftung 2>:<Reading 2>

[Garbsen]

Ok, aber redingsgroup stellt die readings nur (separat) dar. Mit geht es darum, im DOIF die readings des DOIF, die als webcmd innerhln des DOIF gesteuert werden zu benennen.

Klar, innerhalb des webCmd kann man das so wie von Dir vorgeschlagen machen, ist aber ein Trick, der nicht ganz problemlos ist. Denn so werden die Namen quasi selbst als Reading behandelt, obwohl sie keines sind.
Das führt zu entsprechenden Fehlermeldungen, wenn man dann diesen "Namen" anklickt

[Ellert]

Ok, aber redingsgroup stellt die readings nur (separat) dar. Mit geht es darum, im DOIF die readings des DOIF, die als webcmd innerhln des DOIF gesteuert werden zu benennen.

Klar, innerhalb des webCmd kann man das so wie von Dir vorgeschlagen machen, ist aber ein Trick, der nicht ganz problemlos ist. Denn so werden die Namen quasi selbst als Reading behandelt, obwohl sie keines sind.
Das führt zu entsprechenden Fehlermeldungen, wenn man dann diesen "Namen" anklickt

Das Attribut webCmd wird in DOIF nicht ausgewertet, es ist ein Attribut zu Steuerung des Frontends (Raumansicht, Detailansicht, usw.), s. webCmd. Ich denke dort ist Deine Frage/Anregung besser aufgehoben.

[Garbsen]

Gute Idee, es habe dort ml als Frage eingestellt

[Per]

4) Die Fehlermeldung "no trigger" bei der Definition kommt nicht mehr, da aufgrund von checkall Bedingungen ohne Trigger Sinn machen können

Sprich, es fürde folgendes gehen:

Code Auswählen Erweitern

di DOIF ([?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([?mydummy] eq "3")
  (set bla 3)
DOELSEIF ([18:30])

attr di checkall timer
und dadurch nur 18:30 Uhr (oder welches Ereignis auch immer im DOELSEIF steht) auslösen?!

[Ellert]

Ok, aber redingsgroup stellt die readings nur (separat) dar. Mit geht es darum, im DOIF die readings des DOIF, die als webcmd innerhln des DOIF gesteuert werden zu benennen.

Klar, innerhalb des webCmd kann man das so wie von Dir vorgeschlagen machen, ist aber ein Trick, der nicht ganz problemlos ist. Denn so werden die Namen quasi selbst als Reading behandelt, obwohl sie keines sind.
Das führt zu entsprechenden Fehlermeldungen, wenn man dann diesen "Namen" anklickt

Mit einer readingsGroup ist nicht nur eine Darstellung möglich, die Readings können auch bedient werden.
Siehe DOIF: Ein-_und_Ausgabe_in_FHEMWEB_und_Tablet-UI_am_Beispiel_einer_Schaltuhr und readingsGroup

[Damian]

Sprich, es fürde folgendes gehen:

Code Auswählen Erweitern

di DOIF ([?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([?mydummy] eq "3")
  (set bla 3)
DOELSEIF ([18:30])

attr di checkall timer
und dadurch nur 18:30 Uhr (oder welches Ereignis auch immer im DOELSEIF steht) auslösen?!

Ja, das geht mit der neuen Version.

[Ellert]

Version 0.2 im ersten Post mit folgenden Features:

1) Zeitintervalle mit gleicher Anfangs- und Endzeit sind jetzt nicht wahr und triggern auch nicht.
2) Timer und Timerintervalle mit Wochentagangaben triggern jetzt nur noch an den angegebenen Tagen.
3) Attribut checkall mit timer|event|all
4) Die Fehlermeldung "no trigger" bei der Definition kommt nicht mehr, da aufgrund von checkall Bedingungen ohne Trigger Sinn machen können

Hallo Damian,

ich habe ausgehend von der Version 0.2 als Vorschlag

die Kurzreferenz mit den neuen checkall Werten ergänzt und zwei Readings zugefügt
das Inhaltsverzeichnis um die die Links zum DOIF-Unterforum und zum DOIF-Wiki ergänzt
und das Attribut setList mit textField-long vorbelegt, da die Standarteingabezeile recht kurz ist und die Einträge i.d.R. recht lang sind.

Ellert

[Damian]

Hallo Damian,

ich habe ausgehend von der Version 0.2 als Vorschlag

die Kurzreferenz mit den neuen checkall Werten ergänzt und zwei Readings zugefügt
das Inhaltsverzeichnis um die die Links zum DOIF-Unterforum und zum DOIF-Wiki ergänzt
und das Attribut setList mit textField-long vorbelegt, da die Standarteingabezeile recht kurz ist und die Einträge i.d.R. recht lang sind.

Ellert

ok. Allerdings ist die Beschreibung des checkall-Attributes nicht korrekt:
statt:

event Alle Bedingungen mit Event-Trigger (Ereignisauslöser) werden geprüft.
timer Alle Bedingungen mit Timer-Trigger (Zeitauslöser) werden geprüft.

müsste es heißen (ich werde es anpassen):

event Alle Bedingungen werden geprüft, wenn ein Event-Trigger (Ereignisauslöser) auslöst.
timer Alle Bedingungen werden geprüft, wenn ein Timer-Trigger (Zeitauslöser) auslöst.

Bsp:

Code Auswählen Erweitern

DOIF ([dummy1]) (set bla 1)
DOELSEIF ([dummy2]) (set bla 2)
DOELSEIF ([10:00]) (set bla 3)


mit checkall timer

Ereignis dummy2 -> set bla 2
Timer (10:00) -> set bla 1

mit checkall event
Ereignis dummy2 -> set bla 1
Timer (10:00) -> set bla 3

mit checkall all
Ereignis dummy2 -> set bla 1
Timer (10:00) -> set bla 1

ohne checkall (wie bisher)

Ereignis dummy2 -> set bla 2
Timer (10:00) -> set bla 3

Na da wollen wir mal hoffen, dass die Leute das verstehen

[Garbsen]

ok. Allerdings ist die Beschreibung des checkall-Attributes nicht korrekt:
statt:

event Alle Bedingungen mit Event-Trigger (Ereignisauslöser) werden geprüft.
timer Alle Bedingungen mit Timer-Trigger (Zeitauslöser) werden geprüft.

müsste es heißen (ich werde es anpassen):

event Alle Bedingungen werden geprüft, wenn ein Event-Trigger (Ereignisauslöser) auslöst.
timer Alle Bedingungen werden geprüft, wenn ein Timer-Trigger (Zeitauslöser) auslöst.

Bsp:

Code Auswählen Erweitern

DOIF ([dummy1]) (set bla 1)
DOELSEIF ([dummy2]) (set bla 2)
DOELSEIF ([10:00]) (set bla 3)


mit checkall timer

Ereignis dummy2 -> set bla 2
Timer (10:00) -> set bla 1

mit checkall event
Ereignis dummy2 -> set bla 1
Timer (10:00) -> set bla 3

mit checkall all
Ereignis dummy2 -> set bla 1
Timer (10:00) -> set bla 1

ohne checkall (wie bisher)

Ereignis dummy2 -> set bla 2
Timer (10:00) -> set bla 3

Na da wollen wir mal hoffen, dass die Leute das verstehen

Ehrlich gesagt nicht ganz.
Wenn das das Ergebnis von checkall ist, warum setzt man dann nicht einfach im ersten DOIF 'or' ein?
Bzw. Warum gibt man dann im doelseif überhaupt eine Aktion an, wenn doch nur die Aktion aus dem ersten DOIF ausgelöst wird?

[Damian]

Ehrlich gesagt nicht ganz.
Wenn das das Ergebnis von checkall ist, warum setzt man dann nicht einfach im ersten DOIF 'or' ein?
Bzw. Warum gibt man dann im doelseif überhaupt eine Aktion an, wenn doch nur die Aktion aus dem ersten DOIF ausgelöst wird?

Das war nur ein "einfaches" Beispiel zur Demonstration, bei dem ich bewusst, die ersten Bedingungen immer wahr gesetzt hatte (dummy ungleich Null), um das unterschiedliche Verhalten zu provozieren.

Normalerweise definiert man Bedingungen, die nicht immer wahr sind wie z. B. ([dummy1] eq "on").

Edit:

man könnte es auch so erklären:

mit checkall timer

Ereignis: Timer (10:00)

DOIF ([dummy1 eq "on"]) (set ...)        <- wird geprüft
DOELSEIF ([dummy2] eq "on") (set ...)  <- wird geprüft
DOELSEIF ([10:00]) (set ...)                    <- wird geprüft

Ereignis: dummy2

DOIF ([dummy1 eq "on"]) (set ...)     
DOELSEIF ([dummy2] eq "on") (set ...)  <- wird geprüft
DOELSEIF ([10:00]) (set ...)                 

mit checkall event

Ereignis: Timer (10:00)

DOIF ([dummy1 eq "on"]) (set ...)     
DOELSEIF ([dummy2] eq "on") (set ...)
DOELSEIF ([10:00]) (set ...)                    <- wird geprüft

Ereignis: dummy2

DOIF ([dummy1 eq "on"]) (set ...)        <- wird geprüft
DOELSEIF ([dummy2] eq "on") (set ...)  <- wird geprüft
DOELSEIF ([10:00]) (set ...)                  <- wird geprüft

mit checkall all

Ereignis: Timer (10:00)

DOIF ([dummy1 eq "on"]) (set ...)          <- wird geprüft
DOELSEIF ([dummy2] eq "on") (set ...)    <- wird geprüft
DOELSEIF ([10:00]) (set ...)                    <- wird geprüft

Ereignis: dummy2

DOIF ([dummy1 eq "on"]) (set ...)        <- wird geprüft
DOELSEIF ([dummy2] eq "on") (set ...)  <- wird geprüft
DOELSEIF ([10:00]) (set ...)                  <- wird geprüft

ohne checkall (wie bisher)

Ereignis: Timer (10:00)

DOIF ([dummy1 eq "on"]) (set ...)     
DOELSEIF ([dummy2] eq "on") (set ...)   
DOELSEIF ([10:00]) (set ...)                    <- wird geprüft

Ereignis: dummy2

DOIF ([dummy1 eq "on"]) (set ...)     
DOELSEIF ([dummy2] eq "on") (set ...)  <- wird geprüft
DOELSEIF ([10:00]) (set ...)             

[Ellert]

Sprich, es fürde folgendes gehen:

Code Auswählen Erweitern

di DOIF ([?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([?mydummy] eq "3")
  (set bla 3)
DOELSEIF ([18:30])

attr di checkall timer
und dadurch nur 18:30 Uhr (oder welches Ereignis auch immer im DOELSEIF steht) auslösen?!

Mit do always würde es auch gehen

Code Auswählen Erweitern

di DOIF ([18:30])
  (
  IF ([mydummy] eq "1") (set bla 1),
  IF ([mydummy] eq "2") (set bla 2),
  IF ([mydummy] eq "3") (set bla 3)
  )
attr di do always

[Damian]

Mit do always würde es auch gehen

Code Auswählen Erweitern

DOIF ([18:30])
  (
  IF ([mydummy] eq "1") (set bla 1),
  IF ([mydummy] eq "2") (set bla 2),
  IF ([mydummy] eq "3") (set bla 3)
  )

klar, checkall war ein Wunsch der User.

[Ellert]

klar, checkall war ein Wunsch der User.

Das weiss ich doch, aber ich hoffe immer noch auf ein schlagendes Beispiel.

Ich würde nicht auf die Idee kommen irgendwo einen Trigger einzusetzen und dann alle Bedingungen in einzelnen Zweigen aufzulisten.
Woher komm so ein Denkmuster?

Für mich wäre dies naheliegend:

Code Auswählen Erweitern

di DOIF ([18:30] and [?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([18:30] and [?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([18:30] and [?mydummy] eq "3")
  (set bla 3)


checkall würde es vereinfachen

Code Auswählen Erweitern

di DOIF ([18:30] and [?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([?mydummy] eq "3")
  (set bla 3)


Das sieht für mich irgendwie kraus aus.

[Damian]

Das weiss ich doch, aber ich hoffe immer noch auf ein schlagendes Beispiel.

Ich würde nicht auf die Idee kommen irgendwo einen Trigger einzusetzen und dann alle Bedingungen in einzelnen Zweigen aufzulisten.
Woher komm so ein Denkmuster?

Für mich wäre dies naheliegend:

Code Auswählen Erweitern

di DOIF ([18:30] and [?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([18:30] and [?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([18:30] and [?mydummy] eq "3")
  (set bla 3)


checkall würde es vereinfachen

Code Auswählen Erweitern

di DOIF ([18:30] and [?mydummy] eq "1")
   (set bla 1)
DOELSEIF ([?mydummy] eq "2")
  (set bla 2)
DOELSEIF ([?mydummy] eq "3")
  (set bla 3)


Das sieht für mich irgendwie kraus aus.

Naja, vielleicht kommt noch eine "Killer"-Definition mit checkall, die alles verändert

Es ist ja nur ein kleines Attribut, was man nicht setzen muss und wenn, dann sollte man sich dessen bewusst sein, dass die Vorgehensweise des Moduls, wie am Beispiel gezeigt, auf den Kopf gestellt werden kann.

[Ellert]

Vielleicht kann ich etwas Konstruktives beitragen:

Ich verwende öfter mal einen Zähler im DOIF. Könnte DOIF nicht welche per default bereitstellen?

ab Zeile 1137 einfügen

Code Auswählen Erweitern


     $cmd =~ s/\$COUNTER(\d)\-\-/setreading $pn counter_$1 {([$pn:counter_$1] - 1)}/g;
     $cmd =~ s/\$COUNTER(\d)\+\+/setreading $pn counter_$1 {([$pn:counter_$1] + 1)}/g;


Dann könnte man z.B. mit dem Befehl
($COUNTER1++) das Reading counter_1 um 1 erhöhen und mit
($COUNTER1--) das Reading counter_1 um 1 erniedrigen

Es müssten keine 10 Counter sein, ist aber einfach zu realisieren. Ob das Nebenwirkungen hat, kann ich nicht erkennen.

[Damian]

Vielleicht kann ich etwas Konstruktives beitragen:

Ich verwende öfter mal einen Zähler im DOIF. Könnte DOIF nicht welche per default bereitstellen?

ab Zeile 1137 einfügen

Code Auswählen Erweitern


     $cmd =~ s/\$COUNTER(\d)\-\-/setreading $pn counter_$1 {([$pn:counter_$1] - 1)}/g;
     $cmd =~ s/\$COUNTER(\d)\+\+/setreading $pn counter_$1 {([$pn:counter_$1] + 1)}/g;


Dann könnte man z.B. mit dem Befehl
($COUNTER1++) das Reading counter_1 um 1 erhöhen und mit
($COUNTER1--) das Reading counter_1 um 1 erniedrigen

Es müssten keine 10 Counter sein, ist aber einfach zu realisieren. Ob das Nebenwirkungen hat, kann ich nicht erkennen.

Es ist natürlich recht spezifisch, statisch und schlecht mit anderen Befehlen kombinierbar. Dann wären besser modulspezifische Perlvariablen, die innerhalb eines Moduls erhalten blieben, mit diesen könnte man zumindest beliebig "jonglieren" und nicht nur um eins hoch- bzw. runterzählen.

[Damian]

Das funktioniert heute schon: (set bla {($hash->{helper}{count}++)}) statt count kannst du beliebige Namen nehmen, statt ++ beliebige Rechenoperationen durchführen, der Wert bleibt innerhalb des Moduls erhalten und lässt sich sogar in der Bedingung direkt abfragen.

[Ellert]

Ja, es ist unflexibel. Mir ging es darum die Schreibweise kurz zu halten. Und ich dachte ein Zähler wird häufiger genutzt, da würde sich eine Präprozessoranweisung lohnen.

Alles andere ist dann Perl, das könnte auch in die 99_myUtils ausgelagert werden, damit es im DOIF kurz bleibt.

Ein Reading hätte den Vorteil, dass darauf getriggert werden könnte.

[Damian]

Ja, es ist unflexibel. Mir ging es darum die Schreibweise kurz zu halten. Und ich dachte ein Zähler wird häufiger genutzt, da würde sich eine Präprozessoranweisung lohnen.

Alles andere ist dann Perl, das könnte auch in die 99_myUtils ausgelagert werden, damit es im DOIF kurz bleibt.

Ein Reading hätte den Vorteil, dass darauf getriggert werden könnte.

ja, es ist natürlich etwas anderes. Wenn wir es einbauen, dann weiß ich jetzt schon, was der Nächste will

Das Modul lebt von seiner Flexibilität, weil es vieles an Perl weitergibt und nicht selbst macht. Daher war meine Idee, etwas mit Perlvariablen zu machen, weil es viel flexibler ist. Ansonsten entsteht ein Flickenteppich, an dem man für jedes Problemen "flicken" muss.

Es würde schon reichen [$SELF:myreading] statt auf die Funktion ReadingValDoIf (...) auf $defs{$SELF}{READINGS}{myreading}{VAL} abbilden, dann kann man schon sehr Vieles machen, z. B. : set bla {([$SELF:myreading]++)} oder set bla {([$SELF:myreading]=[$SELF:myreading]**2)}


Edit:

Man könnte ebenfalls im Perlbereich angeben: ({[$SELF:myreading]++}, set bla [$SELF:myreading],...

Die Fehlermeldung bei ungleich Null müsste ich dann auch bei Gelegenheit unterdrücken.

Allerdings wird dabei das Änderungsdatum der Readings nicht geändert, weil es nicht über setreading stattfindet.

[Ellert]

Ich meine es als Vorschlag und Du entscheidest, ob es in die "Vision" des DOIF passt. Wenn es nicht eingebaut wird, wechsle ich nicht zu at und notify 

Trotzdem hier ein etwas flexiblerer Vorschlag:

Code Auswählen Erweitern


     $cmd =~ s/\$VAR(\d)\=(\(.*?\))/setreading $pn var_$1 {($2)}/g;
     $cmd =~ s/\$VAR(\d)(\+|\-|\*|\/)(\(.*?\))/setreading $pn var_$1 {(ReadingsNum("$pn","var_$1","0") $2 $3)}/g;


Damit wären dann solche Befehle möglich, die dann das Reading $SELF:var_x setzen:
$VAR0=(25.23)
$VAR1=([LUM])
$VAR2=(time/3600/24/365)
$VAR3=([$SELF:var_3]+31.07)
$VAR4+(1) mit (erstmal) 4 Grundrechenarten

Das könnte man weglassen:

Code Auswählen Erweitern


     $cmd =~ s/\$VAR(\d)(\+|\-|\*|\/)(\(.*?\))/setreading $pn var_$1 {(ReadingsNum("$pn","var_$1","0") $2 $3)}/g;


Dann kann man fast alles kurz halten mit

$VAR<x>=(<Perl> und [DOIF-Syntax]) mit x [0-9]

Das ersetzt dann

setreading $SELF var_<x> {(<Rechnungen>)}

$VAR4+(1) das müsste dann so formuliert werden $VAR4=([$SELF:var_1] + 1)

Noch flexibler geht es so:

Code Auswählen Erweitern


     $cmd =~ s/\$\((.*?)\)\=(\(.*?\))/setreading $pn $1 {($2)}/g;


dann gilt diese Syntax

$(<Readingname>)=(<Perl> und [DOIF-Syntax])

z.B.

Code Auswählen Erweitern

$(abc)=([$SELF:abc] + 1) für setreading $SELF abc {([$SELF:abc] + 1)}

[Garbsen]

Zwischendrin mal ein großes Lob an die Entwickler
Die neuen Features des DOIF haben mir zwar ein wenig (Umstellungs-)Arbeit gemacht.
Jetzt habe ich 12 neue DOIF und dadurch ca. 20 notify and über 40 dummies löschen können.
Sehr viel übersichtlicher!
Vielen Dank

[Ellert]

Zwischendrin mal ein großes Lob an die Entwickler
Die neuen Features des DOIF haben mir zwar ein wenig (Umstellungs-)Arbeit gemacht.
Jetzt habe ich 12 neue DOIF und dadurch ca. 20 notify and über 40 dummies löschen können.
Sehr viel übersichtlicher!
Vielen Dank

Ich habe auch eine Menge Dummys eingespart und damit es in der Statistik:List of total used modules (with definitions)... sichtbar wird führe ich nach größeren Änderungen

Code Auswählen Erweitern

fheminfo send

aus.

[Garbsen]

Ich habe auch eine Menge Dummys eingespart und damit es in der Statistik:List of total used modules (with definitions)... sichtbar wird führe ich nach größeren Änderungen

Code Auswählen Erweitern

fheminfo send

aus.

Done!
Und dabei gesehen, es gibt noch zufiele dummies bei mir )
Da muss ich noch ran, #GuterVorsatz

[Damian]

Ich meine es als Vorschlag und Du entscheidest, ob es in die "Vision" des DOIF passt. Wenn es nicht eingebaut wird, wechsle ich nicht zu at und notify 

Trotzdem hier ein etwas flexiblerer Vorschlag:

Code Auswählen Erweitern


     $cmd =~ s/\$VAR(\d)\=(\(.*?\))/setreading $pn var_$1 {($2)}/g;
     $cmd =~ s/\$VAR(\d)(\+|\-|\*|\/)(\(.*?\))/setreading $pn var_$1 {(ReadingsNum("$pn","var_$1","0") $2 $3)}/g;


Damit wären dann solche Befehle möglich, die dann das Reading $SELF:var_x setzen:
$VAR0=(25.23)
$VAR1=([LUM])
$VAR2=(time/3600/24/365)
$VAR3=([$SELF:var_3]+31.07)
$VAR4+(1) mit (erstmal) 4 Grundrechenarten

Das könnte man weglassen:

Code Auswählen Erweitern


     $cmd =~ s/\$VAR(\d)(\+|\-|\*|\/)(\(.*?\))/setreading $pn var_$1 {(ReadingsNum("$pn","var_$1","0") $2 $3)}/g;


Dann kann man fast alles kurz halten mit Das ersetzt dann
$VAR4+(1) das müsste dann so formuliert werden $VAR4=([$SELF:var_1] + 1)

Noch flexibler geht es so:

Code Auswählen Erweitern


     $cmd =~ s/\$\((.*?)\)\=(\(.*?\))/setreading $pn $1 {($2)}/g;


dann gilt diese Syntax
z.B.

Code Auswählen Erweitern

$(abc)=([$SELF:abc] + 1) für setreading $SELF abc {([$SELF:abc] + 1)}

ja, wenn es FHEM-Ebene sein soll, dann wäre eine Lösung interessant, die intuitiv funktioniert ohne in der Commandref jedes mal nachzuschlagen. Ich würde einfach die bisherige Syntax erweitern:

[device:reading]++
[device:reading]--

[device:reading]=irgendeine Rechnung mit Readingangaben in DOIF-Syntax in eckigen Klammern

evtl. noch
[device:reading]+=...
[device:reading]-=...
[device:reading]*=...
[device:reading]/=...

Die Frage stellt sich dann nur noch: Was funktioniert dann nicht mehr, was bisher noch lief

Edit:

Und wenn man schon dabei ist, dann könnte man auch gleich das set Kommando für Stati realisieren:

[Device]=...

[Damian]

Die neuen Features des DOIF ...

Welches Features genau meinst du denn?

[Ellert]

ja, wenn es FHEM-Ebene sein soll, dann wäre eine Lösung interessant, die intuitiv funktioniert ohne in der Commandref jedes mal nachzuschlagen. Ich würde einfach die bisherige Syntax erweitern:

[device:reading]++
[device:reading]--

[device:reading]=irgendeine Rechnung mit Readingangaben in DOIF-Syntax in eckigen Klammern

evtl. noch
[device:reading]+=...
[device:reading]-=...
[device:reading]*=...
[device:reading]/=...

Die Frage stellt sich dann nur noch: Was funktioniert dann nicht mehr, was bisher noch lief

Edit:

Und wenn man schon dabei ist, dann könnte man auch gleich das set Kommando für Stati realisieren:

[Device]=...

Ja, das wäre ein großer Wurf, ich wollte eigentlich nur kurz und bündig einen Zähler erhöhen und ggf. auf 0 setzen. Den Umfang und Aufwand, den wir jetzt besprechen halte ich für zu groß, um eine schon funktionierende Methode (setreading name reading {(...)} zu ersetzen.

Es gibt allerdings noch eine Fragestellung im Zusammenhang mit der Beschriftung und Darstellung der Readings, s. https://forum.fhem.de/index.php/topic,63375.msg546664.html#msg546664

Man könnte die Definition einer ReadingsGroup über einen Get-Befehl zur Verfügung stellen, das wäre dann schon eine Basis fürs Frontend, wie es aussieht, habe ich angehängt.

Wäre das wünschenswert?

[Damian]

Ja, das wäre ein großer Wurf, ich wollte eigentlich nur kurz und bündig einen Zähler erhöhen und ggf. auf 0 setzen. Den Umfang und Aufwand, den wir jetzt besprechen halte ich für zu groß, um eine schon funktionierende Methode (setreading name reading {(...)} zu ersetzen.

Daher, lass uns etwas Zeit, bis wir eine einheitliche Lösung finden, bevor mehrere Lösungen das Gleiche leisten.

Es gibt allerdings noch eine Fragestellung im Zusammenhang mit der Beschriftung und Darstellung der Readings, s. https://forum.fhem.de/index.php/topic,63375.msg546664.html#msg546664

Man könnte die Definition einer ReadingsGroup über einen Get-Befehl zur Verfügung stellen, das wäre dann schon eine Basis fürs Frontend, wie es aussieht, habe ich angehängt.

Wäre das wünschenswert?

Die Frage ist, ob man alles in dieses eine Modul packt (es muss ja schließlich geladen werden), wenn man es auch im Wiki erklären kann, gerade wenn die Funktionalität außerhalb des Moduls ist und der User ohnehin Hand anlegen muss (auch wenn es für ihn einfacher wäre). Ich würde die Sachen lieber trennen.

[Garbsen]

Hallo

Wie löse ich folgende Aufgabe:

Ich habe in einem DOIF vier readings (Modus,SollAktuell,Tag,Nacht), immer wenn sich ein Reading ändert, soll an ein anderes Device ein set Befehl gegeben werden und zwar genau für das identische Reading und mit dem geänderten Wert.

Derzeit habe ich folgendes definiert:

Code Auswählen Erweitern

##CMD1
(["$SELF:.*"])


({fhem ("set FBSetBad Modus ".[$SELF:Modus])})
({fhem ("set FBSetBad SollAktuell ".[$SELF:SollAktuell])})
({fhem ("set FBSetBad Nacht ".[$SELF:Nacht])})
({fhem ("set FBSetBad Tag ".[$SELF:Tag])})


Das führt aber dazu, dass immer für alle vier readings der set befehlt ausgeführt wird. Das ist nicht erwünscht. Es soll beim FBSetBad immer nur das Reading neu gesetzt werden, dass sich im DOIF geändert hat.
Beim FBSetBad handelt es sich um ein httpmod, dass dann die Fußbodenheizung befüllt. Das lässt sich daher nicht direkt im DOIF abbilden.

Klar ich könnte im DOIF für jedes Reading ein eigenen DOELSEIF Zweig anlegen, finde das anders aber eigentlich schlanker, wenn es denn geht.
Ich habe bereits mit $EVTPART "gespielt" bekomme es ber nicht hin
Danke
K-H

[Ellert]

Daher, lass uns etwas Zeit, bis wir eine einheitliche Lösung finden, bevor mehrere Lösungen das Gleiche leisten.

Die Frage ist, ob man alles in dieses eine Modul packt (es muss ja schließlich geladen werden), wenn man es auch im Wiki erklären kann, gerade wenn die Funktionalität außerhalb des Moduls ist und der User ohnehin Hand anlegen muss (auch wenn es für ihn einfacher wäre). Ich würde die Sachen lieber trennen.

Ja, die Lösung sollte reifen.

Die set-Befehle tragen nicht erheblich zur Funktionalität bei, das könnte vielleicht als Tools ins Wiki, mal sehen.

[Per]

Mit do always würde es auch gehen

Code Auswählen Erweitern

di DOIF ([18:30])
  (
  IF ([mydummy] eq "1") (set bla 1),
  IF ([mydummy] eq "2") (set bla 2),
  IF ([mydummy] eq "3") (set bla 3)
  )
attr di do always

Aber cmdState würde an dieser Aufgabe scheitern

Ich habe auch eine Menge Dummys eingespart und damit es in der Statistik:List of total used modules (with definitions)... sichtbar wird führe ich nach größeren Änderungen

Code Auswählen Erweitern

fheminfo send

aus.

Problem: je besser ich DOIF verstehe und je mächtiger es wird, umso weniger wird es genutzt. Zumindest lt. Statistik, weil ich statt 4 nur noch 3 DOIF-Konstrukte brauche .

Wie löse ich folgende Aufgabe:

Sollte diese Frage wirklich HIER erscheinen?

Ich habe bereits mit $EVTPART "gespielt" bekomme es ber nicht hin

Sicher, dass es im DOIF $EVTPART gibt?!

[Garbsen]

Sollte diese Frage wirklich HIER erscheinen?
Sicher, dass es im DOIF $EVTPART gibt?!

Nun, ich habe es hier veröffentlicht, weil es ja um die neue Möglichkeit der readings im DOIF geht und wie ich dies für mich optimal nutze.
Ob es $EVTPART im DOIF gibt? Keine Ahnung, daher ja auch meine Frage
gibt es eine andere Möglichkeit für eine Lösung?

[Ellert]

@Damian: Mir ist aufgefallen, dass bei Zeiten mit Wochentagbeschränkung das Datum nicht mit dem voraussichtlich nächsten Triggerzeitpunkt übereinstimmt.

Soll das erstmal so bleiben? Wenn ja, würde ich das userReadings für den nextTimer mit ins Wiki aufnehmen.

[Damian]

@Damian: Mir ist aufgefallen, dass bei Zeiten mit Wochentagbeschränkung das Datum nicht mit dem voraussichtlich nächsten Triggerzeitpunkt übereinstimmt.

Soll das erstmal so bleiben? Wenn ja, würde ich das userReadings für den nextTimer mit ins Wiki aufnehmen.

Ja, das muss so bleiben, denn intern wird das Modul um diese Zeit geweckt, um zu prüfen, ob was zu tun ist. Bei indirekten Wochentagangaben könnte jemand kurz zuvor den Wochentag ändern und damit die Gültigkeit des Triggers verändern.

[Damian]

Version 0.3

Fehlerkorrektur: das Attribut initialize führte zum Initilialisieren des Moduls beim Neustart, obwohl das Attribut disable gesetzt war.

Dokuanpassung

[Ellert]

Anbei eine kleine optische Verbesserung (Basis V 0.3):

Das Eingabefeld für set disable,initialize,enable ist unnötig. Es kann mit disable:noArg initialize:noArg enable:noArg unterdrückt werden.

[Damian]

Anbei eine kleine optische Verbesserung (Basis V 0.3):

Das Eingabefeld für set disable,initialize,enable ist unnötig. Es kann mit disable:noArg initialize:noArg enable:noArg unterdrückt werden.

ich habe es übernommen, so dann testen wir noch bisschen, dann werde ich diese Version erst mal einchecken.

[Damian]

aktuelle Version wurde eingecheckt, sie ist ab morgen per Update verfügbar.

[Ellert]

Die neuen Möglichkeiten in den DOIF sind wirklich gut!
Frage: gibt es eine Möglichkwit die webCmd zu "beschriften"?
Derzeit werden mir in FHEM nur die jeweiligen Buttons Dropdowns oder knobs angezeigt, aber nicht welche readings damit gesteuert werden. Es wäre toll, wenn man da Beschriftungen zufügen könnte.
Geht das?
Danke

Die Widgets sollten mit dem morgigen Update den Readingnamen als Tooltip anzeigen, siehe https://forum.fhem.de/index.php/topic,70007.0.html

[oli_bru]

Hallo zusammen,

auf der Suche nach einer Lösung für mein gepostetes Problem (https://forum.fhem.de/index.php/topic,88278.0.html) bin ich auch über diesen Thread "gestolpert".
Dabei hat mich Ellert auf die falsche Fährte gelockt - daher möchte ich diese Erkenntnis gerne kund tun.

Weiter oben hatte Ellert gepostet:

Mit do always würde es auch gehen

Das ist aus meiner Sicht so aber nicht korrekt. Ich habe jetzt mal mit dummys und doifs rumgespielt:
Ein do always prüft immer nur die Bedingungen, welche auch die entsprechenden Events enthalten.
Ein checkall hingegen prüft alle Bedingungen, auch wenn für die in der Prüfung enthaltenen Elemente keine Events ausgelöst wurden.

Beispiel:

Code Auswählen Erweitern

([d_dummytest1] eq "on" and [d_dummytest2] eq "on") ({Log 1,"Test 1"}) DOELSEIF ([d_dummytest2] eq "on") ({Log 1,"Test 2"}) DOELSE ({Log 1, "Test 3"})

Zunächst setze ich dummytest1 und dummytest auf "on" -> ich lande im cmd_1

bei do_always:
ich setze d_dummytest1 auf "off" -> ich lande im cmd_3

bei check all:
ich setze d_dummytest1 auf "off" -> ich lande im cmd_2

[Damian]

Ein do always prüft immer nur die Bedingungen, welche auch die entsprechenden Events enthalten.
Ein checkall hingegen prüft alle Bedingungen, auch wenn für die in der Prüfung enthaltenen Elemente keine Events ausgelöst wurden.

Beide Attribute sind voneinander unabhängig.

do always bedeutet: Ausführung wiederholen

checkall bedeutet: alle Zweige prüfen

Wenn z. B. bei checkall, do always nicht gesetzt ist, wird trotz Überprüfung aller Zweige die Ausführung des gleichen cmd-Zweigs nicht wiederholt.

[Pfriemler]

Mal eine eher akademische Frage zu checkall event:
Dieses DOIF hat bis zum gestrigen Update (das erste nach längerer Zeit) funktioniert:

Code Auswählen Erweitern

defmod di_AlarmanlageZustand DOIF (([AAZS:value] & 8) == 0 and ([AAZS:value] & 4) == 0) (set DisplayAlarm dim06%, set AlarmanlageZustand Aus)\
DOELSEIF ([AAZS:value] & 8 and ([AAZS:value] & 4) == 0) (set DisplayAlarm dim50%, set AlarmanlageZustand Teilscharf, setreading AlarmanlageZustand teilscharf gesetzt)\
DOELSEIF (([AAZS:value] & 8) == 0 and [AAZS:value] & 4) (set DisplayAlarm on-for-timer 60, set AlarmanlageZustand WirdVollscharf)\
DOELSEIF ([AAZS:value] & 8 and [AAZS:value] & 4) (set DisplayAlarm on, set AlarmanlageZustand Vollscharf, setreading AlarmanlageZustand vollscharf gesetzt)\
DOELSE\
attr di_AlarmanlageZustand wait 0:1:0:0:0

Zur Erklärung: AAZS ist der 8-Bit-Kanal eines HM-Mod-EM-8bit. Änderungen an den Datenleitungen erzeugen also genau ein relevantes Event.
Das userReading "value" übersetzt den Hexcode in einen numerischen Wert.
Die Zweige des DOIF prüfen mit der Konstruktion "& <value>" ob ein Bit Null ist "== 0" oder gesetzt (ohne Vergleich, weil !=0 ja wahr ist)

Code Auswählen Erweitern

defmod AAZS CUL_HM xxxxxx
attr AAZS alias Zustandssensor
attr AAZS comment Bitmuster (Dezimalwert) [Name] Alarmanlagenzustand: \
0 (1) unused \
1 (2) BATT ok/low (Sensorbatterien Alarmanlage) \
2 (4) FAPA home/away (teilscharf/vollscharf wenn ARMD) \
3 (8) ARMD unscharf/scharf \
4 (16) HELP ok/help (Wartungsmodus) \
...
Bits 1, 4, 5 und 6 werden extra über DOIFs angezeigt, die restlichen Leitungen für AlarmanlageZustand direkt abgefragt, ebenso für die Sensorzusammenfassung
attr AAZS event-on-change-reading state
attr AAZS model HM-MOD-EM-8Bit
attr AAZS stateFormat Status: state, Wert: value
attr AAZS userReadings value {hex(substr(ReadingsVal("AAZS","state","unknown:FF"),8))}


Das o.g. DOIF arbeitete jetzt nur noch nach einem Schubs ("set <DOIF> checkall"). Neustarts und kleine Mods am DOIF änderten daran nichts.
Ich habe ein weiteres DOIF mit exakt diesen Auswertebedingungen (und ein paar mehr Zweigen), welches nur den Status von AAZS übersetzt. Das funktionierte weiterhin.
Dort hatte ich, im Zuge eines anderen Experimentes, aber mal attr <..> checkall event gesetzt.
Mit dieser Änderung funktioniert das o.g. DOIF jetzt auch wieder. Die Frage ist: warum brauchte es das neuerdings?

Ich hätte verstanden, wenn das DOIF sofort auf die Änderung des State reagiert (hier als der neue Hexwert vom Modul) und dann das noch nicht aktualisierte Reading "value" auswertet. Dann hätte die Reaktion aber schlicht nur "verspätet" ausfallen müssen - es tat sich aber gar nichts.

Versteckter Bug - oder hatte ich bisher versehentlich einen Bug ausgenutzt, der jetzt ausgemerzt ist?

[Damian]

Möglicherweise hängt es damit zusammen, dass das Reading value von AAZS keine Events produziert. Siehe https://forum.fhem.de/index.php/topic,82523.msg800555.html#msg800555

Mit checkReadingEvent 0 kannst du die alte Kompatibilität wiederherstellen.

[Pfriemler]

That's it. Die Änderungsankündigung hatte ich gekonnt überlesen. Danke für die wie immer prompte und einleuchtende Erklärung!

[Per]

Zum Verständnis:

Code Auswählen Erweitern

([AAZS] and ([AAZS:value] & 8) == 0)
würde das gleiche ergeben, weil AAZS(:stats) einen Event erzeugt?

@Pfriemler: du hast event-on-change-reading im Einsatz, ergänz das doch alternativ um

Code Auswählen Erweitern

attr AAZS event-on-change-reading state,value
Dann sollte value einen Event erzeugen.

[Damian]

Zum Verständnis:

Code Auswählen Erweitern

([AAZS] and ([AAZS:value] & 8) == 0)
würde das gleiche ergeben, weil AAZS(:stats) einen Event erzeugt?

@Pfriemler: du hast event-on-change-reading im Einsatz, ergänz das doch alternativ um

Code Auswählen Erweitern

attr AAZS event-on-change-reading state,value
Dann sollte value einen Event erzeugen.

Code Auswählen Erweitern

([AAZS] and ([AAZS:value] & 8) == 0)

abgesehen davon, dass die bisherigen Definitionen aufgrund einer neuen Version nicht geändert werden sollten, funktioniert dieser Vorschlag nicht immer, nämlich dann nicht wenn Status z. B. 0 sein sollte.

Besser ist dagegen der zweite Vorschlag damit value ein Event erzeugt, dann muss man nichts an der DOIF-Konfiguration ändern.

[Pfriemler]

Zusammenfassung:
1. bisher triggerte das Doif allein durch eine Statusänderung. Die Auswertung funktioniert sowieso.
2. der neue default checkReadingEvent = 1 führte zum Stillstand, weil value keine Events erzeugt. Das wunderte mich dann auch - und hatte die Ursache im event-on-reading schon vermutet bevor Ihr mir die Bestätigung liefertet.
3. checkall event hat wohl indirekt das Triggern wieder aktiviert.
4. Richtig ist für mich daher, value ein Event erzeugen zu lassen und sonst bei allen defaults zu bleiben.

Heute gehe ich dann sowieso mal durch alle Doifs. Schätze es wird nötig sein.

Danke allseits!

[Per]

Auch wenn es die Lösung schon gibt...

nämlich dann nicht wenn Status z. B. 0 sein sollte.

Das vergesse ich immer so gerne 

Wäre so besser?

Code Auswählen Erweitern

(["AAZS"] and ([AAZS:value] & 8) == 0)

[Damian]

Wäre so besser?

Code Auswählen Erweitern

(["AAZS"] and ([AAZS:value] & 8) == 0)

Das wäre auch nicht 100-prozentig eindeutig, dann eher Angaben der Art:

["^AAZS$"]

oder

[AAZS:""]

Sollte aber, wie gesagt, alles nicht erforderlich sein.