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

[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]=...