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

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