Fhem/Perl-Funktion "Zählewenn" gesucht

[Marko1976]

Hallo, ich wollte mal fragen ob es so etwas wie Zählewenn aus Excel auch in Fhem oder Perl gibt.

Ich möchte verschiede Device zählen wenn ihr STATE oder ein vorgegebenes Reading einen bestimmten Wert enthält.

[Prof. Dr. Peter Henning]

Perl kennt von sich aus keine FHEM-Geräte. Man kann aber problemlos in einem Perl-Programm einen FHEM-Befehl mit FILTER-Direktive absetzen und die Anzahl der zurückgegebenen Zeilen auswerten.

Allerdings erschließt sich mir der Sinn einer solchen Zählung nicht so ganz.

LG

pah

[betateilchen]

Ich möchte verschiede Device zählen wenn ihr STATE oder ein vorgegebenes Reading einen bestimmten Wert enthält.

im einfachsten Fall:

Code Auswählen Erweitern

count state=open
zählt bei mir alle offenen Rollläden und Türen/Fenster.

https://commandref.fhem.de/#count

Allerdings erschließt sich mir der Sinn einer solchen Zählung nicht so ganz.

Es muss doch nicht alles einen Sinn haben.

[Marko1976]

Allerdings erschließt sich mir der Sinn einer solchen Zählung nicht so ganz.

Man muss ja auch nicht alles verstehen, oder?

Hintergrund ist aber eigentlich ganz einfach.
Ich habe für verschiedene Aufgaben jeweils ein DOIF als Aufgabe erstellt, zb für Hausarbeiten oder Fahrzeugwartung. Diese werden in Abhängigkeit in verschiedene Stati versetzt None/Alert/Priority. Entsprechend des Status lasse ich Benachrichtigungen per Push und Alexa verteilen.
In miener FTUI3-Startseite habe ich nun eine Kachel die auf diese "Aufgaben" verweist und ich würde ganz gerne anzeigen lassen ob und eventuell wie viele Aufgaben anstehen, sprich das Icon anpassen.

[Marko1976]

count state=open

Also so wie ich das verstehe handelt es sich um einen Befehl für die Commandzeile der einmal abgesetzt einen Rückgabewert liefert.

Sollte ich mich da jetzt nicht vertuen kann ich es für meinen Sinn weniger gebrauchen, da ich den Wert ja dauerhaft berechnet und immer im Zugriff haben muss um die Anzeige im FTUI3 entsprechend reagieren zu lassen. Andernfalls müsste ich den Befehle ja immer wieder in regelmäßigen Abständen ausführen.
Oder verstehe ich  die commandref da falsch?

[passibe]

Ja, du müsstest das dann immer aktualisieren, z.B. mit einem notify mit entsprechender Regex, die dann auf das Event des zu zählenden Readings triggert.

Aber sowas geht wohl auch "aus einer Hand" mit einem DOIF, siehe hier https://fhem.de/commandref_DE.html#DOIF_aggregation bzw. das wurde hier diskutiert: https://forum.fhem.de/index.php?topic=90224.0 und auch hier: https://forum.fhem.de/index.php/topic,87144.msg795823.html

Denke damit solltest du dir was zusammenbauen können; wenn nicht, dann evtl. das Thema in das DOIF-Unterforum verschieben und dort wird dir dann sicherlich auch geholfen. Viel Erfolg!

P.S.: Gefunden habe ich das übrigens über eine Google-Suche nach

Code Auswählen Erweitern

site:fhem.de readings zählen

[Prof. Dr. Peter Henning]

@Marko1976: Zunächst einmal empfehle ich, die Doku zu lesen. Dort ist dokumentiert, wie man einen Befehl periodisch absetzt. Den Rückgabewert in ein Reading zu schreiben, ist dort auch zu finden - einfach als userReading.

Das mit den verschiedenen DOIF als "Aufgabe" erscheint mir unnötig kompliziert und mit ziemlich viel manuellem Aufwand verbunden. Für so etwas gibt es u.a. das Modul "PostMe", das erlaubt "gelbe Klebezettel" mit entsprechenden Erinnerungen per Mail oder Telegram.

Schließlich:

verschiedene Stati versetzt

Die Mehrzahl von "Status" lautet "Status".

LG

pah

[Marko1976]

@Marko1976: Zunächst einmal empfehle ich, die Doku zu lesen. Dort ist dokumentiert, wie man einen Befehl periodisch absetzt. Den Rückgabewert in ein Reading zu schreiben, ist dort auch zu finden - einfach als userReading.

Es geht nicht um die Umsetzung, sondern die Sinnhaftigkeit. Der Wert MUSS immer aktuell sein. Alles was periodisch abgefragt wird ist nicht dauerhaft aktuell - somit für meinen Sinn und Zweck nicht brauchbar.

@Marko1976: Das mit den verschiedenen DOIF als "Aufgabe" erscheint mir unnötig kompliziert und mit ziemlich viel manuellem Aufwand verbunden. Für so etwas gibt es u.a. das Modul "PostMe", das erlaubt "gelbe Klebezettel" mit entsprechenden Erinnerungen per Mail oder Telegram.

Wenn Sie wüssten was an den DOIF's dranhängt, würden Sie wahrscheinlich Anderes sagen. Aber da ich überhaupt keine Lust habe meine Beweggründe oder die Umsetzung bis ins Kleinste mit jedem zu teilen oder zu diskutieren, muss es reichen wenn ich schreibe, dass dies die FÜR MICH besste Umsetzung ist.

@Marko1976: Die Mehrzahl von "Status" lautet "Status".

Sollten Sie sich eins zu Herzen nehmen - KEIN Mensch mag Oberlehrer die alles und jeden verbessern müssen! Wenn man einen Fehler findet, einfach mal überlesen und man hat viel mehr Freu(n)de.

Wer in einzelnen Sätzen Sarkasmus findet, darf ihn gerne behalten.

[passibe]

finden - einfach

Das korrekte Zeichen für einen Gedankenstrich ist übrigens der Halbgeviertstrich und nicht der Viertelgeviertstrich (Bindestrich) ...

Alles was periodisch abgefragt wird ist nicht dauerhaft aktuell - somit für meinen Sinn und Zweck nicht brauchbar.

Aber mal zurück zum Thema, ich denke, dass die DOIF-aggregation hier, wie erwähnt, ganz gut passt. Habe das gerade mal bei mir getestet – mit

Code Auswählen Erweitern

define offene_fenster DOIF
attr offene_fenster state [#"^[a-z]_fenster":contact:"false"]aktualisiert sich im state des DOIF die Anzahl der offenen Fenster, sobald ich eins öffne/schließe.

[betateilchen]

Und wenn es darum geht, readings in einem Frontend laufend aktuell zu halten, fällt mir das Stichwort ,,longpoll" ein, da übernimmt das Frontend die Aktualisierung höchstselbst.
Die eine oder andere in FHEM verfügbare Frontendvariante bietet longpoll out-of-the-box

[Marko1976]

Schon gut,
Habe jetzt ein DOIF genommen und per EventReading die Summe bzw. den Mittelwert berechnen lassen. Darauf kann ich per ftui3 jederzeit zugreifen und es wird bei jeder Wertänderung in den Aufgaben-DOIF's automatisch neuberechnet.

Danje @passibe

[Prof. Dr. Peter Henning]

Alles was periodisch abgefragt wird ist nicht dauerhaft aktuell

Das ist schlichtweg falsch. FHEM ist ebensowenig wie die meisten anderen Systeme in der Lage, irgendwelche Daten in Nullzeit zu aktualisieren.

LG

pah

[Marko1976]

Alles was periodisch abgefragt wird ist nicht dauerhaft aktuell

Das ist schlichtweg falsch. FHEM ist ebensowenig wie die meisten anderen Systeme in der Lage, irgendwelche Daten in Nullzeit zu aktualisieren.

Ehrliche Frage, wer oder was sind Sie? Macht es Ihnen Spaß andere für Dumm zu verkaufen? Oder was soll der Kindergarten?
JEDER versteht unter "dauerhaft aktuell" nicht Nullzeit sondern einfach umgehend danach. Was soll diese Überspitzung? Macht es Ihnen einfach Spaß andere damit zu ärgern oder sind Sie einfach so einfältig, dass es Ihnen nicht auffällt wie das auf andere wirkt? Logik ist sicher nicht jedermanns Stärke, dennoch verfügt jeder Mensch über eine Grundlogik - und die sollte man nicht dauernd durch solche Kommentare in Frage stellen.

@passibe
Ich bräuchte noch mal deine Hilfe.
Ich habe wie gesagt ein DOIF erstellt bei dem mit "event reading" auch die Summe erstellt wird. Allerdings habe ich jetzt bemerkt, dass dies nur erfolgt wenn das Dev des DOIF's geändert wird und nicht wenn das DOIF getriggertoder ein Fall ausgelöst wird. Das Attribut Always steht schon auf Do. Mehr fällt mir aktuell leider nicht ein.

Wie kann ich erreichen, dass das DOIF bei Änderung eines betroffenen Readings in einem anderen DOIF neuberechnet wird?

Hier das List des berechnenden DOIF's:

Code Auswählen Erweitern

Internals:
  CFGFN     
  DEF        (["^Hausarbeit_.* counter:.*$"])
    ()
  FUUID      688686c7-f33f-7706-90e1-a1f79814bc4c2d1d
  MODEL      FHEM
  NAME      Aufgabencounter
  NOTIFYDEV  .*(^Hausarbeit_.* counter).*,.*(^Hausarbeit_.*).*,.*(^Tasks_.*).*,global
  NR        75618
  NTFY_ORDER 50-Aufgabencounter
  STATE      initialized
  TYPE      DOIF
  VERSION    29460 2024-12-29 20:25:48
  eventCount 346
  OLDREADINGS:
  READINGS:
    2025-07-31 11:38:59  Aufgaben        0
    2025-07-31 11:38:59  Hausarbeiten    1
    2025-07-31 11:38:59  cmd            0
    2025-07-31 11:38:59  mode            enabled
    2025-07-31 11:38:59  state          initialized
  Regex:
    accu:
    bar:
    barAvg:
    collect:
    cond:
      :
        0:
          "^Hausarbeit_.* counter:.*$" ^Hausarbeit_.* counter:.*$
    event_Readings:
      :
        Aufgaben:
          "^Tasks_.*" ^Tasks_.*
        Hausarbeiten:
          "^Hausarbeit_.*" ^Hausarbeit_.*
  attr:
    cmdState:
    wait:
    waitdel:
  condition:
    0          ::EventDoIf('^Hausarbeit_.* counter',$hash,'.*$',0)
  do:
    0:
      0         
    1:
  event_Readings:
    Aufgaben  ::AggregateDoIf($hash,'#sum:a:','^Tasks_.*','counter')
    Hausarbeiten ::AggregateDoIf($hash,'#sum:a:','^Hausarbeit_.*','counter')
  helper:
    NOTIFYDEV  .*(^Hausarbeit_.* counter).*,.*(^Hausarbeit_.*).*,.*(^Tasks_.*).*,global
    globalinit 1
    last_timer 0
    sleeptimer -1
    triggerDev
    triggerEvents
    triggerEventsState
  uiState:
  uiTable:
Attributes:
  alias      Aufgabezähler
  do        always
  event_Readings Hausarbeiten:[#sum:a:"^Hausarbeit_.*":counter],
Aufgaben:[#sum:a:"^Tasks_.*":counter],
  room      Dummy
An anderer Stelle funktioniert es wunderbar. Beispielsweise bei der Berechnung des Durchschnittpreises von meinen überwachten Tankstellen. Auch alles DOIF's. Sobald ein Preis in einem der Tankstellen-DOIF's sich ändert, wird der Durchschnittpreis im Rechnungs-DOIF neu berechnet. Ich sehe aber keinen Unterschied. Wieso also funktioniert es dort und nicht hier?
Hast du irgendeine Idee?

[betateilchen]

@pah: wie wäre es mit etwas Altersmilde?

Ich mache mal Popcorn...