[gelöst] Verständnisfrage zu meinem DOIF

[Nobbynews]

Guten Morgen zusammen,

folgendes DOIF habe ich definiert:

Code: [Auswählen]

Internals:
   CFGFN     
   DEF        ([05:10-06:45|AT] and
 [ZWave_BWM_Garage_Lux:Helligkeit] < [?ZWave_BWM_Garage_Lux:Fikus] and
 [PraesenzNB:"on"])
(set Fikus_neu on)
DOELSE
(set Fikus_neu off)
   FUUID      61230f3e-f33f-8873-b3b0-bb3270eca71a62f1
   MODEL      FHEM
   NAME       di_Fikus_AT_tag
   NOTIFYDEV  global,PraesenzNB,ZWave_BWM_Garage_Lux
   NR         857323
   NTFY_ORDER 50-di_Fikus_AT_tag
   STATE      cmd_2
   TYPE       DOIF
   VERSION    24755 2021-07-15 16:40:59
   READINGS:
     2021-08-25 06:37:02   Device          ZWave_BWM_Garage_Lux
     2021-08-25 06:06:42   cmd             2
     2021-08-25 06:06:42   cmd_event       ZWave_BWM_Garage_Lux
     2021-08-25 06:06:42   cmd_nr          2
     2021-08-25 06:20:55   e_PraesenzNB_events off
     2021-08-25 06:37:02   e_ZWave_BWM_Garage_Lux_Helligkeit 120
     2021-08-24 17:13:06   mode            enabled
     2021-08-25 06:06:42   state           cmd_2
     2021-08-24 17:13:06   timer_01_c01    25.08.2021 05:10:00|AT
     2021-08-24 17:13:06   timer_02_c01    25.08.2021 06:45:00|AT
   Regex:
     accu:
     collect:
     cond:
       PraesenzNB:
         0:
           &STATE     ^PraesenzNB$
       ZWave_BWM_Garage_Lux:
         0:
           Helligkeit ^ZWave_BWM_Garage_Lux$:^Helligkeit:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          ::DOIF_time($hash,0,1,$wday,$hms,"AT") and   ::ReadingValDoIf($hash,'ZWave_BWM_Garage_Lux','Helligkeit') < ::ReadingValDoIf($hash,'ZWave_BWM_Garage_Lux','Fikus') and  ::EventDoIf('PraesenzNB',$hash,'on',1)
   days:
     0          AT
     1          AT
   devices:
   do:
     0:
       0          set Fikus_neu on
     1:
       0          set Fikus_neu off
   helper:
     DEVFILTER  ^global$|^PraesenzNB$|^ZWave_BWM_Garage_Lux$
     NOTIFYDEV  global|PraesenzNB|ZWave_BWM_Garage_Lux
     event      luminance: 120 Lux,Helligkeit: 120
     globalinit 1
     last_timer 2
     sleeptimer -1
     timerdev   ZWave_BWM_Garage_Lux
     timerevent luminance: 120 Lux,Helligkeit: 120
     triggerDev ZWave_BWM_Garage_Lux
     timerevents:
       luminance: 120 Lux
       Helligkeit: 120
     timereventsState:
       luminance: 120 Lux
       Helligkeit: 120
     triggerEvents:
       luminance: 120 Lux
       Helligkeit: 120
     triggerEventsState:
       luminance: 120 Lux
       Helligkeit: 120
   internals:
   interval:
     0          -1
     1          0
   intervalfunc:
   intervaltimer:
   localtime:
     0          1629861000
     1          1629866700
   readings:
     all         ZWave_BWM_Garage_Lux:Helligkeit
   realtime:
     0          05:10:00
     1          06:45:00
   time:
     0          05:10:00
     1          06:45:00
   timeCond:
     0          0
     1          0
   timer:
     0          0
     1          0
   timers:
     0           0  1
   trigger:
     all         PraesenzNB
   triggertime:
     1629866700:
       localtime  1629866700
       hash:
   uiState:
   uiTable:
Attributes:
   disable    0
   room       ZWave
Um 5:10 wird wie erwartet die Lampe eingeschaltet und das DOIF steht also im cmd_1.
Um 6:06:42 kommt vom Bewegungsmelder der erste event mit dem Helligkeitswert 2, wobei das Reading ZWave_BWM_Garage_Lux:Fikus den Wert 400 hat. PreaesenzNB ist ebenfalls auf "on".
Warum schaltet das DOIF in cmd_2??

Norbert

Edit:
Lt. Log-Datei wird die Lampe erst um 5:10:33 eingeschaltet. ?

[laberlaib]

Ich vermute mal:

https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events

Code: [Auswählen]

[PraesenzNB:"on"prüft auf ein Event, nicht auf einen Zustand.

D.h. "wie erwartet" stimmt so eigentlich nicht, da die Bedingung ja nur zu einem Zeitpunkt wahr ist, und zwar dann, wenn das Ding auf "on" schaltet und dazu ein Event auslöst (was es ja vielleicht zyklisch macht, keine Ahnung).
Und jetzt kommt um 06:06 ein Event (Update der Helligkeit), welches die Prüfung der Bedingungen übernimmt. Und diese muss dann logischerweise "falsch" ergeben, da das o.g. Event ja nicht kommt.
Also Sprung in cmd_2.

[Otto123]

Hi,

Lt. Log-Datei wird die Lampe erst um 5:10:33 eingeschaltet. ?

Du hattest erwartet das die gesamte Bedingung um 5:10 schon stimmt? Muss ja nicht so sein. Es wird wohl (zu deinem Glück) 5:10:33 ein Event von deinem PraesenzNB kommen, obwohl Du die ganze Zeit schon da warst . Aber das ist nur geraten, müsstest Du im Log mit allen Werten nachvollziehen.

Du solltest also überlegen: Was soll alles die gewünchte Reaktion auslösen und was soll nur zur Entscheidungsfindung abgefragt werden. So wie ich es verstehe ist

Code: [Auswählen]

[PraesenzNB:"on"] wohl besser

Code: [Auswählen]

[PraesenzNB] eq "on" falls das on im STATE kommt

Gruß Otto

[Damian]

wie schon hier mehrfach erwähnt, möchtest du einen Zustand abfragen, daher [PraesenzNB:state] eq "on", da die reine Ereignisabfrage [PraesenzNB:"on"] immer falsch ist, wenn ein anderer Trigger kommt hier z.B. von [ZWave_BWM_Garage_Lux:Helligkeit]

[Nobbynews]

prüft auf ein Event, nicht auf einen Zustand.

wie schon hier mehrfach erwähnt, möchtest du einen Zustand abfragen, daher [PraesenzNB:state] eq "on", da die reine Ereignisabfrage [PraesenzNB:"on"] immer falsch ist, wenn ein anderer Trigger kommt hier z.B. von [ZWave_BWM_Garage_Lux:Helligkeit]

Ah, ok, dieser Unterschied war mir so nicht bewusst, erklärt aber so einiges.

Es wird wohl (zu deinem Glück) 5:10:33 ein Event von deinem PraesenzNB kommen, obwohl Du die ganze Zeit schon da warst .

Stimmt, das PraesenzNB ist ein structure device was wiederum 2 PRESENCE devices zusammenfasst und die alle 30s aktualisiert werden.
Danke.

Norbert

[Otto123]

Stimmt, das PraesenzNB ist ein structure device was wiederum 2 PRESENCE devices zusammenfasst und die alle 30s aktualisiert werden.

Da solltest Du auch drüber nachdenken: kann so "gut" sein - muss aber auch nicht. Könnte dazu führen, dass dann alle 30 sec "nachgehämmert" wird (nicht in dem DOIF - DOIF verhindert genau das).
Folgen: höhere Systemlast (Events und Folgeevents), höherer Funklast, aufwecken von Batterie Funkempfängern (Stromverbrauch) usw.

[Nobbynews]

Könnte dazu führen, dass dann alle 30 sec "nachgehämmert" wird (nicht in dem DOIF - DOIF verhindert genau das).
Folgen: höhere Systemlast (Events und Folgeevents), höherer Funklast, aufwecken von Batterie Funkempfängern (Stromverbrauch) usw.

Bei den beiden device handelt es sich um Handies die per Lan-Ping abgeprüft werden. EOC ist jeweils gesetzt und von daher sollte da nach meinem Verständnis nix großartiges passieren.

[MadMax-FHEM]

Wieviel da so durch's System "rennt" sieht man sehr schön bei offenem Eventmonitor...
...manchmal ist man ganz schön erstaunt/erschrocken was da so alles rumfliegt...

ODER: DOIF-Tools hat da ein "Tool" für. Damit kann man Statistiken erzeugen (lassen), die einem zeigen welches Device wieviele Events etc. erzeugt und ob es bereits mit event-on-change-... "bearbeitet" wurde...

Gruß, Joachim

[Nobbynews]

ODER: DOIF-Tools hat da ein "Tool" für. Damit kann man Statistiken erzeugen (lassen), die einem zeigen welches Device wieviele Events etc. erzeugt und ob es bereits mit event-on-change-... "bearbeitet" wurde...

Damit erhält man in der Tat einen guten Überblick und kann dann noch Optimierungen durchführen.
Allerdings ist das mMn nur die halbe Wahrheit, da durch EOC ja lediglich die Reaktion auf einen Input unterdrückt wird, aber zunächst ja einmal trotzdem eine Verarbeitung bis zur Entscheidung EOC ja/nein durchgeführt werden muss.
Zu diesem Overhead habe ich aber bisher nichts konkretes gefunden.

[MadMax-FHEM]

Den Overhead bis zum Event-erzeugenden Device (meist ein physisches Gerät) kann man nur VOR dem Device "verbessern"...
...oft (z.B. Homematic) auch gar nicht...

Aber trotzdem ist event-on-change... gezielt eingesetzt schon mal gut, weil dadurch zumindest weitere "Last" verringert wird.

Ebenso helfen "klare RegEx" bei notify und Co...
Stichwort: NotifyDef...

Gruß, Joachim

[Damian]

Damit erhält man in der Tat einen guten Überblick und kann dann noch Optimierungen durchführen.
Allerdings ist das mMn nur die halbe Wahrheit, da durch EOC ja lediglich die Reaktion auf einen Input unterdrückt wird, aber zunächst ja einmal trotzdem eine Verarbeitung bis zur Entscheidung EOC ja/nein durchgeführt werden muss.
Zu diesem Overhead habe ich aber bisher nichts konkretes gefunden.

Das Schreiben eines Readings mit Event produziert im System zigfach größeren Overhead als ohne Event - das kann ich durch eigene Messungen bestätigen.

[Nobbynews]

Das Schreiben eines Readings mit Event produziert im System zigfach größeren Overhead als ohne Event - das kann ich durch eigene Messungen bestätigen.

Das habe ich mir schon so gedacht. Kann man das grob in Zahlen fassen um mal ein Gefühl dafür zu bekommen?

[Damian]

Das habe ich mir schon so gedacht. Kann man das grob in Zahlen fassen um mal ein Gefühl dafür zu bekommen?

Das kann sehr unterschiedlich sein, abhängig davon wieviele Module auf das jeweilige Event reagieren oder nicht.

Auch wenn kein einziges Modul auf das Event reagiert, löst das Event ohne Logging schon Faktor 30 und mehr an Overhead im System aus, als nur das reine Schreiben in den Speicher.

Allerdings reden wir hier immer noch von Millisekunden.

[Nobbynews]

Auch wenn kein einziges Modul auf das Event reagiert, löst das Event ohne Logging schon Faktor 30 und mehr an Overhead im System aus, als nur das reine Schreiben in den Speicher.

Allerdings reden wir hier immer noch von Millisekunden.

Das ist ja schon mal ein ganz gehöriger Unterschied.
Und aus vielen Millisekunden werden dann ganz schnell mal ein Sekündchen.

[Damian]

Das ist ja schon mal ein ganz gehöriger Unterschied.
Und aus vielen Millisekunden werden dann ganz schnell mal ein Sekündchen.

Es werden viel zu viele Events im System produziert. Die wenigsten davon nutzt man tatsächlich.

Ich habe bei mir inzwischen bei fast allen devices event-on-change-reading auf .* gesetzt, das reduziert unnötige Events erheblich.