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?