DOIF Aggregatfunktion state: Wie Deviceliste um 2. Reading erweitern?

[FFHEM]

Hallo zusammen,

ich benutze seit langem schon die Möglichkeit, im state-Reading eines DOIFs eine Liste von Geräten aufzuführen, die bei einem Reading einen bestimmten Wert haben.
Das sind z. Zt. alle Geräte mit einem "battery"-Reading, das entweder nicht "ok" (z. B. Homematic) oder nicht 100 (Hue-Geräte) ist.
Nun möchte ich noch die Geräte mit einem Reading "FAULT_REPORTING", die als Wert "LOWBAT" tragen, aufführen.
Das hier ist der bisherige Teil (das komplette DOIF weiter unten):

Code: [Auswählen]

attr di_battery_low_devices state [@":battery":battery:$_ ne "ok" and $_ ne "100","alle OK"]
Deshalb zunächst die Frage: kann man noch ein 2. Reading in den Ausdruck einsetzen?
Wenn ich battery durch (battery|FAULT_REPORTING) ersetze, kommt kein Unterschied.

Vielen Dank!

Code: [Auswählen]

define di_battery_low_devices DOIF ## Tägliche Sammelmeldung aller leeren Batterien \
([12:00] and [$SELF:state] ne "alle OK" )\
(\
   {DebianMail('ich@gmx.de', 'FHEM-Batteriemeldung', 'Batterie wechseln bei: '.'[$SELF:state]');;};;\
)
attr di_battery_low_devices group Batterieüberwachung
attr di_battery_low_devices room System,Übersicht
attr di_battery_low_devices state [@":battery":battery:$_ ne "ok" and $_ ne "100","alle OK"]
#   DEF        ## Tägliche Sammelmeldung aller leeren Batterien
#([12:00] and [$SELF:state] ne "alle OK" )
#(
#   {DebianMail('fkuech@gmx.de', 'FHEM-Batteriemeldung', 'Batterie wechseln bei: '.'[$SELF:state]');};
#)
#   FUUID      6233652d-f33f-26cd-8edc-03c396ff244bf7e1
#   MODEL      FHEM
#   NAME       di_battery_low_devices
#   NOTIFYDEV  global,.*().*,di_battery_low_devices
#   NR         1187
#   NTFY_ORDER 50-di_battery_low_devices
#   STATE      alle OK
#   TYPE       DOIF
#   VERSION    26703 2022-11-14 16:43:41
#   eventCount 8615
#   READINGS:
#     2022-11-16 12:00:02   cmd             2
#     2022-11-16 12:00:02   cmd_event       di_battery_low_devices
#     2022-11-16 12:00:02   cmd_nr          2
#     2022-11-22 16:35:06   e_di_battery_low_devices_state alle OK
#     2022-06-19 12:01:13   mode            enabled
#     2022-11-22 16:35:06   state           alle OK
#     2022-11-22 12:00:00   timer_01_c01    23.11.2022 12:00:00
#   Regex:
#     STATE:
#       :
#         STATE:
#           ":battery" :battery
#     accu:
#     collect:
#     cond:
#       di_battery_low_devices:
#         0:
#           state      ^di_battery_low_devices$:^state:
#   attr:
#     cmdState:
#     waitdel:
#   condition:
#     0          ::DOIF_time_once($hash,0,$wday) and ::ReadingValDoIf($hash,'di_battery_low_devices','state') ne "alle OK"
#   days:
#   do:
#     0:
#       0              {DebianMail('fkuech@gmx.de', 'FHEM-Batteriemeldung', 'Batterie wechseln bei: '.'[di_battery_low_devices:state]');};
#     1:
#   helper:
#     NOTIFYDEV  global,.*().*,di_battery_low_devices
#     event      alle OK,e_di_battery_low_devices_state: alle OK
#     globalinit 1
#     last_timer 1
#     sleeptimer -1
#     timerdev   di_battery_low_devices
#     timerevent alle OK
#     triggerDev di_battery_low_devices
#     timerevents:
#       alle OK
#       e_di_battery_low_devices_state: alle OK
#       alle OK
#     timereventsState:
#       state: alle OK
#     triggerEvents:
#       alle OK
#       e_di_battery_low_devices_state: alle OK
#       alle OK
#     triggerEventsState:
#       state: alle OK
#   internals:
#   interval:
#   intervalfunc:
#   localtime:
#     0          1669201200
#   perlblock:
#   readings:
#     all         di_battery_low_devices:state
#   realtime:
#     0          12:00:00
#   time:
#     0          12:00:00
#   timeCond:
#     0          0
#   timer:
#     0          0
#   timers:
#     0           0
#   trigger:
#   triggertime:
#     1669201200:
#       localtime  1669201200
#       hash:
#   uiState:
#   uiTable:
#
setstate di_battery_low_devices alle OK
setstate di_battery_low_devices 2022-11-16 12:00:02 cmd 2
setstate di_battery_low_devices 2022-11-16 12:00:02 cmd_event di_battery_low_devices
setstate di_battery_low_devices 2022-11-16 12:00:02 cmd_nr 2
setstate di_battery_low_devices 2022-11-22 16:35:06 e_di_battery_low_devices_state alle OK
setstate di_battery_low_devices 2022-06-19 12:01:13 mode enabled
setstate di_battery_low_devices 2022-11-22 16:35:06 state alle OK
setstate di_battery_low_devices 2022-11-22 12:00:00 timer_01_c01 23.11.2022 12:00:00



[Damian]

Deshalb zunächst die Frage: kann man noch ein 2. Reading in den Ausdruck einsetzen?
Wenn ich battery durch (battery|FAULT_REPORTING) ersetze, kommt kein Unterschied.

Aber selbstverständlich geht das

Statt Readingnamen kannst du eine Regex für deine Readingnamen angeben, die muss, so wie es in der Commandref steht, in Anführungszeichen angegeben werden:

[<function>:<format>:"<regex device>:<regex event>":<reading>|"<regex reading>":<condition>,<default>]

[FFHEM]

Prima, Damian, danke!!
Die Anführungszeichen hatte ich übersehen.

Trotzdem komme ich nicht weiter, da ich bei der Bedingungsprüfung an der Variablen $_ nicht sehen kann, welches Reading gerade geprüft wird.
Im Fall des battery-Readings ist die Prüfung ne "ok" and ne "100" richtig, aber beim Reading FAULT_REPORTING muss ich auf eq "LOWBAT" testen,
da FAULT_REPORTING 7 weitere Werte kennt, die nichts mit LOWBAT zu tun haben.

Kann ich die Prüfung deshalb Reading-abhängig machen?

Gruß,
Friedhelm

[Damian]

Es steht zwar nicht in der Doku, aber in der Variablen $reading sollte der Name des aktuellen Readings sein, also sollte gehen:

Code: [Auswählen]

$reading eq "battery" and $_ ne "ok" and $_ ne "100" or $reading eq "FAULT_REPORTING" and $_ eq "LOWBAT"

[FFHEM]

Ja, so funktioniert es!
Ich wusste doch, dass Du es schon in weiser Voraussicht vorhergesehen hast, dass irgendwann einmal jemand daherkommt und das braucht.
Nein, jetzt ehrlich: klasse programmiert!

Der Ausdruck sieht nun so aus:

Code: [Auswählen]

[@":battery|FAULT_REPORTING":"battery|FAULT_REPORTING":$reading eq "battery" and $_ ne "ok" and $_ ne "100" or $reading eq "FAULT_REPORTING" and $_ eq "LOWBAT"]
2 Unsicherheiten meinerseits: ich habe den Regex für das Reading auch auf FAULT_REPORTING erweitert: ":battery|FAULT_REPORTING"
Muss vor das FAULT_REPORTING auch noch ein Doppelpunkt, oder müssen die beiden Readings geklammert werden, also:

Code: [Auswählen]

":(battery|FAULT_REPORTING)"
Und bei der Bedingung: hat hier "and" Vorrang vor "or", oder muss man hier nicht klammern?

[Damian]

Ja, so funktioniert es!
Ich wusste doch, dass Du es schon in weiser Voraussicht vorhergesehen hast, dass irgendwann einmal jemand daherkommt und das braucht.
Nein, jetzt ehrlich: klasse programmiert!

Der Ausdruck sieht nun so aus:

Code: [Auswählen]

[@":battery|FAULT_REPORTING":"battery|FAULT_REPORTING":$reading eq "battery" and $_ ne "ok" and $_ ne "100" or $reading eq "FAULT_REPORTING" and $_ eq "LOWBAT"]
2 Unsicherheiten meinerseits: ich habe den Regex für das Reading auch auf FAULT_REPORTING erweitert: ":battery|FAULT_REPORTING"
Muss vor das FAULT_REPORTING auch noch ein Doppelpunkt, oder müssen die beiden Readings geklammert werden, also:

Code: [Auswählen]

":(battery|FAULT_REPORTING)"
Und bei der Bedingung: hat hier "and" Vorrang vor "or", oder muss man hier nicht klammern?

and ist immer vor or - in jeder Programmiersprache, auch in der Mathematik

Die Regex für das Device wegzulassen ist eine ganz schlechte Idee, damit steigt die Last deines Systems erheblich, da jedes Event im System geprüft werden muss.

[FFHEM]

and ist immer vor or - in jeder Programmiersprache, auch in der Mathematik

Die Regex für das Device wegzulassen ist eine ganz schlechte Idee, damit steigt die Last deines Systems erheblich, da jedes Event im System geprüft werden muss.

Ja, gut, dass Du da noch einmal drauf hinweist, bevor man sich sein System zumüllt. Aber ist das Weglassen des Device-Regex nicht gerade der "Witz" an dem Beispiel aus der DOIF-Referenz?
Geprüft werden doch nur die Events, deren Reading wie "battery" aussieht, oder?

Code: [Auswählen]

Statusanzeige: Alle Devices, deren Batterie nicht ok ist:

define di_battery DOIF

attr di_battery state [@":battery":battery:$_ ne "ok","alle OK"]

[Damian]

Ja, gut, dass Du da noch einmal drauf hinweist, bevor man sich sein System zumüllt. Aber ist das Weglassen des Device-Regex nicht gerade der "Witz" an dem Beispiel aus der DOIF-Referenz?
Geprüft werden doch nur die Events, deren Reading wie "battery" aussieht, oder?

Code: [Auswählen]

Statusanzeige: Alle Devices, deren Batterie nicht ok ist:

define di_battery DOIF

attr di_battery state [@":battery":battery:$_ ne "ok","alle OK"]

Ja, das muss ich noch anpassen. Inzwischen arbeitet DOIF mit dem NOTIFYDEV-Filter, zuvor wurden immer alle Nachrichten ausgewertet, da war der Lastzuwachs nicht zu deutlich, wie jetzt.

[FFHEM]

Ok, danke! Dann werde ich hin und wieder mal in der Referenz nachsehen, ob sich etwas geändert hat.

Ich habe aber noch ein Verständnisproblem, kannst Du bitte den Satz erläutern:

Inzwischen arbeitet DOIF mit dem NOTIFYDEV-Filter, zuvor wurden immer alle Nachrichten ausgewertet, da war der Lastzuwachs nicht zu deutlich, wie jetzt.

Heißt das, früher (ohne NOTIFYDEV-Filter) war der Lastzuwachs durch solche Konstrukte höher als jetzt, weil früher immer alle Nachrichten ausgewertet wurden?
Dann wäre das Battery-Beispiel jetzt nicht mehr so systembelastend, wie es früher einmal war?

Vielen Dank!

[Damian]

Ok, danke! Dann werde ich hin und wieder mal in der Referenz nachsehen, ob sich etwas geändert hat.

Ich habe aber noch ein Verständnisproblem, kannst Du bitte den Satz erläutern:Heißt das, früher (ohne NOTIFYDEV-Filter) war der Lastzuwachs durch solche Konstrukte höher als jetzt, weil früher immer alle Nachrichten ausgewertet wurden?
Dann wäre das Battery-Beispiel jetzt nicht mehr so systembelastend, wie es früher einmal war?

Vielen Dank!

Umgekehrt: jetzt ist die Last ohne Device, so wie früher (auch mit Device), das bedeutet, wenn man jetzt eine Regex für ein Device angibt, dann filtert FHEM bereits die Nachrichten und weckt das Modul nur noch, wenn Events vom Device kommen.

Das Battery-Beispiel ohne Device-Regex ist jetzt genauso belastend, wie früher, weil aufgrund fehlender Device-Regex nichts vorgefiltert wird, aber man kann es jetzt (durch NOTIFYDEV) mit Device-Regex reduzieren.

[FFHEM]

Ok, danke für die Erklärung, jetzt habe ich es verstanden!