Guten Morgen zusammen,
folgendes DOIF habe ich definiert:
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. ?
Ich vermute mal:
https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events
[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.
Hi,
ZitatLt. 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
[PraesenzNB:"on"]
wohl besser
[PraesenzNB] eq "on"
falls das on im STATE kommt :)
Gruß Otto
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]
Zitat von: laberlaib am 25 August 2021, 09:19:09
prüft auf ein Event, nicht auf einen Zustand.
Zitat von: Damian am 25 August 2021, 09:41:43
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.
Zitat von: Otto123 am 25 August 2021, 09:33:52
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
Zitat von: Nobbynews am 25 August 2021, 10:21:47
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.
Zitat von: Otto123 am 25 August 2021, 10:30:37
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.
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
Zitat von: MadMax-FHEM am 25 August 2021, 11:45:04
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.
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
Zitat von: Nobbynews am 25 August 2021, 14:52:19
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.
Zitat von: Damian am 25 August 2021, 21:15:22
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?
Zitat von: Nobbynews am 26 August 2021, 10:45:57
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.
Zitat von: Damian am 26 August 2021, 11:13:21
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.
Zitat von: Nobbynews am 26 August 2021, 17:03:22
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.