Moin zusammen,
ich verzweifel grade an einem echt simplen DOIF. Ich versuche auf die Änderung eines Readings zu triggern (genauer ein Reading in einem dummy das nichts anderes als ein Hilfs-Flag darstellt). Leider wird mein DOIF auch bei jedem anderen Event dieses Dummys getriggert obwohl ich checkReadingEvent 1 habe (ist ja mittlerweile auch Standard).
Wo ist mein Fehler? Findet ihn jemand von Euch?
Hier mal ein list von meinem DOIF:
Internals:
CFGFN
DEF ( [f_rollo_nacht] == 1 )
( set Rollo_EG_Bad off )
DOELSEIF
( [f_rollo_nacht] == 0 and [f_beschattung:nord] == 1 and [rollo_settings_beschattung:status] eq "aktiv" )
( {fhem "set Rollo_EG_Bad dim ".ReadingsVal('Rollo_EG_Bad','dim_Schatten',0)} )
DOELSE
( set Rollo_EG_Bad on )
MODEL FHEM
NAME di_Rollo_EG_Bad
NR 230
NTFY_ORDER 50-di_Rollo_EG_Bad
STATE initialized
TYPE DOIF
READINGS:
2018-10-20 23:03:55 cmd 0
2018-10-20 23:03:55 mode enabled
2018-10-20 23:03:55 state initialized
Regex:
attr:
cmdState:
0:
Nacht
1:
Beschattung
2:
Tag
wait:
waitdel:
condition:
0 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 1
1 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 0 and ::ReadingValDoIf($hash,'f_beschattung','nord') == 1 and ::ReadingValDoIf($hash,'rollo_settings_beschattung','status') eq "aktiv"
devices:
0 f_rollo_nacht
1 f_rollo_nacht f_beschattung rollo_settings_beschattung
all f_rollo_nacht f_beschattung rollo_settings_beschattung
do:
0:
0 set Rollo_EG_Bad off
1:
0 {fhem "set Rollo_EG_Bad dim ".ReadingsVal('Rollo_EG_Bad','dim_Schatten',0)}
2:
0 set Rollo_EG_Bad on
helper:
globalinit 1
last_timer 0
sleeptimer -1
internals:
0 f_rollo_nacht:STATE
1 f_rollo_nacht:STATE
all f_rollo_nacht:STATE
itimer:
readings:
1 f_beschattung:nord rollo_settings_beschattung:status
all f_beschattung:nord rollo_settings_beschattung:status
uiState:
uiTable:
Attributes:
checkReadingEvent 1
checkall all
cmdState Nacht|Beschattung|Tag
devStateIcon Nacht:weather_moon_phases_8 Beschattung:weather_summer Tag:weather_sun
event-on-change-reading state
room Rollos
Ich wäre über eine zündende Idee echt mehr als dankbar!
Grüße
der_oBi
Du musst auf das Reading state triggern:
( [f_rollo_nacht:state] == 1 )
Hi!
Sorry, ich hatte vergessen zu erwähnen, dass [f_beschattung:nord] mein Problem darstellt. Es wird leider bei jeder Reading-Änderung von f_beschattung getriggert, nicht nur wenn das Reading nord ein Event erzeugt.
f_rollo_nacht hingegen macht keine Probleme (ist ebenfalls ein Dummy, hat aber keinerlei Readings :-))
Oder kann das dennoch mein Problem sein?
Laut Deinem Listing hat das DOIF noch nie getriggert.
Kannst Du diesen Fall
ZitatEs wird leider bei jeder Reading-Änderung von f_beschattung getriggert
durch Events dokumentieren und posten.
Mein Fehler...In dem list ist nichts davon zu sehen, da ich gestern abend wieder gefühlt 1000mal redefined habe in der Hoffnung, eine Lösung zu finden.
Hier mal alle Events zum Zeitpunkt der letzten Triggerung:
2018-10-21 14:49:58 VCONTROL300 Vitotronic200 UpdateStatus: Inactive
2018-10-21 14:50:00 dummy f_beschattung Winkel_dach_ost: 30.4338878953486
2018-10-21 14:50:00 dummy f_beschattung Winkel_dach_west: 11.6625443362512
2018-10-21 14:50:00 dummy f_beschattung Winkel_nord: -59.527294145007
2018-10-21 14:50:00 dummy f_beschattung Winkel_ost: 15.4186077290514
2018-10-21 14:50:00 dummy f_beschattung Winkel_sued: 59.5751261995288
2018-10-21 14:50:00 dummy f_beschattung Winkel_west: -15.3369866407196
2018-10-21 14:50:00 at at_Rollo_Beschattung_setzen Next: 15:00:00
2018-10-21 14:50:00 dummy WW_tempgradient 2.09999999999998
2018-10-21 14:50:00 dummy WW_tempgradient alt: 50.8
2018-10-21 14:50:00 at at_wwtempgradient Next: 15:00:00
2018-10-21 14:50:00 at at_watchdog Next: 14:51:00
2018-10-21 14:50:05 SONOS Sonos LastProcessAnswer: 1540126205.85842
Und hier das List dazu (dieses Mal mit Triggerung ;-))
Internals:
CFGFN
DEF ( [f_rollo_nacht] == 1 )
( set Rollo_EG_Bad off )
DOELSEIF
( [f_rollo_nacht] == 0 and [f_beschattung:nord] == 1 and [rollo_settings_beschattung:status] eq "aktiv" )
( {fhem "set Rollo_EG_Bad dim ".ReadingsVal('Rollo_EG_Bad','dim_Schatten',0)} )
DOELSE
( set Rollo_EG_Bad on )
MODEL FHEM
NAME di_Rollo_EG_Bad
NR 230
NTFY_ORDER 50-di_Rollo_EG_Bad
STATE Tag
TYPE DOIF
READINGS:
2018-10-21 14:50:00 Device f_beschattung
2018-10-21 07:30:00 cmd 3
2018-10-21 07:30:00 cmd_event f_rollo_nacht
2018-10-21 07:30:00 cmd_nr 3
2018-10-21 07:30:00 e_f_rollo_nacht_STATE 0
2018-10-20 23:03:55 mode enabled
2018-10-21 07:30:00 state Tag
Regex:
attr:
cmdState:
0:
Nacht
1:
Beschattung
2:
Tag
wait:
waitdel:
condition:
0 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 1
1 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 0 and ::ReadingValDoIf($hash,'f_beschattung','nord') == 1 and ::ReadingValDoIf($hash,'rollo_settings_beschattung','status') eq "aktiv"
devices:
0 f_rollo_nacht
1 f_rollo_nacht f_beschattung rollo_settings_beschattung
all f_rollo_nacht f_beschattung rollo_settings_beschattung
do:
0:
0 set Rollo_EG_Bad off
1:
0 {fhem "set Rollo_EG_Bad dim ".ReadingsVal('Rollo_EG_Bad','dim_Schatten',0)}
2:
0 set Rollo_EG_Bad on
helper:
event Winkel_west: -15.3369866407196
globalinit 1
last_timer 0
sleeptimer -1
timerdev f_beschattung
timerevent Winkel_west: -15.3369866407196
triggerDev f_beschattung
DOIF_eventas:
cmd_nr: 3
cmd: 3
cmd_event: f_rollo_nacht
state: Tag
timerevents:
Winkel_west: -15.3369866407196
timereventsState:
Winkel_west: -15.3369866407196
triggerEvents:
Winkel_west: -15.3369866407196
triggerEventsState:
Winkel_west: -15.3369866407196
internals:
0 f_rollo_nacht:STATE
1 f_rollo_nacht:STATE
all f_rollo_nacht:STATE
itimer:
readings:
1 f_beschattung:nord rollo_settings_beschattung:status
all f_beschattung:nord rollo_settings_beschattung:status
trigger:
uiState:
uiTable:
Attributes:
checkReadingEvent 1
checkall all
cmdState Nacht|Beschattung|Tag
devStateIcon Nacht:weather_moon_phases_8 Beschattung:weather_summer Tag:weather_sun
event-on-change-reading state
room Rollos
Das passt schon:
2018-10-21 14:50:00 dummy f_beschattung Winkel_nord: -59.527294145007
2018-10-21 14:50:00 Device f_beschattung
Der letzte Schaltvorgang auf cmd_3 war durch:
2018-10-21 07:30:00 cmd_event f_rollo_nacht
Funktioniert wie programmiert.
Übrigens, falls Du mit einer aktuellen DOIF-Version arbeitest, ist checkReadingEvent auf 1 voreingestellt, Du musst es nur setzen, wenn Du die Voreinstellung nicht möchtest und dann auf 0.
Zitat von: Ellert am 21 Oktober 2018, 17:58:56
Übrigens, falls Du mit einer aktuellen DOIF-Version arbeitest, ist checkReadingEvent auf 1 voreingestellt, Du musst es nur setzen, wenn Du die Voreinstellung nicht möchtest und dann auf 0.
Ja, weiß ich ja. Die DOIFs sind schon etwas älter, da war default noch "0".
Zitat von: Damian am 21 Oktober 2018, 15:12:30
Der letzte Schaltvorgang auf cmd_3 war durch:
Das stimmt ja auch soweit. Jetzt kommt das aber:
Alle 10 Minuten wird das DOIF wieder durchlaufen, weil andere Readings von f_beschattung aktualisiert werden. Wenn ich in der Zwischenzeit etwas manuell per Schalter übersteuert habe, funkt mir das DOIF (ungewollt) wieder dazwischen.
Z.B. wenn ich in den Bedingungen von cmd_1 und cmd_2 einen Fensterkontakt prüfen lasse (nicht triggern, nur prüfen).
Es wird z.B. Nacht, Fenster ist zu, DOIF geht nach cmd_1. Alles super.
Danach mache ich das Fenster auf (da ich nur prüfe, sollte nichts passieren). Maximal 10 Minuten später wird das DOIF wieder durchlaufen, cmd_1 wird nicht mehr erfüllt und cmd_3 (ELSE) greift. Schon sind die Rollos wieder oben. Sehr unpraktisch ;-)
Wie aber kann es überhaupt sein, dass das hier zu einem Triggern führt, obwohl das checkReadingEvent gesetzt ist und nirgendwo von Winkel_west die Rede ist? Ich raffs echt nicht...
[code] timerevents:
Winkel_west: -15.3369866407196
timereventsState:
Winkel_west: -15.3369866407196
triggerEvents:
Winkel_west: -15.3369866407196
triggerEventsState:
Winkel_west: -15.3369866407196
[/code]
Letztlich kannst Du Dir die Fragen nur beantworten, wenn Du das Verhalten durch Aufzeichnung der Events dokumentierst und analysierst welche Events das DOIF tatsächlich schalten lassen.
ZitatAlle 10 Minuten wird das DOIF wieder durchlaufen, weil andere Readings von f_beschattung aktualisiert werden. Wenn ich in der Zwischenzeit etwas manuell per Schalter übersteuert habe, funkt mir das DOIF (ungewollt) wieder dazwischen.
Z.B. wenn ich in den Bedingungen von cmd_1 und cmd_2 einen Fensterkontakt prüfen lasse (nicht triggern, nur prüfen).
Es wird z.B. Nacht, Fenster ist zu, DOIF geht nach cmd_1. Alles super.
Danach mache ich das Fenster auf (da ich nur prüfe, sollte nichts passieren). Maximal 10 Minuten später wird das DOIF wieder durchlaufen, cmd_1 wird nicht mehr erfüllt und cmd_3 (ELSE) greift. Schon sind die Rollos wieder oben. Sehr unpraktisch ;-)
Dafür hast Du doch extra
checkall gesetzt.
Zitat von: Ellert am 21 Oktober 2018, 19:42:31
Dafür hast Du doch extra checkall gesetzt.
Da hast Du natürlich recht. Ich hatte das damals wegen irgendeinem Szenario gesetzt, ich weiß nur grade nicht mehr wieso. Wenn ich das lösche, sollte es erstmal funktionieren (glaube ich).
Nichts desto trotz hätte ich gerne verstanden, wieso checkReadingEvent nicht so funktioniert wie ich es erwarten würde.
Zitat von: Ellert am 21 Oktober 2018, 19:42:31
Letztlich kannst Du Dir die Fragen nur beantworten, wenn Du das Verhalten durch Aufzeichnung der Events dokumentierst und analysierst welche Events das DOIF tatsächlich schalten lassen.
Das hab ich doch getan. Offensichtlich triggert jede Aktualisierung von f_beschattung mein DOIF.
Im List und Event-Auszug von oben sehe ich doch, dass f_beschattung:Winkel_west das letzte Event war. Wenn ich das Event-Log anschaue, wurde das DOIF wahrscheinlich sogar 6x nacheinander getriggert:
2018-10-21 14:50:00 dummy f_beschattung Winkel_dach_ost: 30.4338878953486
2018-10-21 14:50:00 dummy f_beschattung Winkel_dach_west: 11.6625443362512
2018-10-21 14:50:00 dummy f_beschattung Winkel_nord: -59.527294145007
2018-10-21 14:50:00 dummy f_beschattung Winkel_ost: 15.4186077290514
2018-10-21 14:50:00 dummy f_beschattung Winkel_sued: 59.5751261995288
2018-10-21 14:50:00 dummy f_beschattung Winkel_west: -15.3369866407196
Ob dann was geschaltet wird, hängt natürlich von den Bedingungen ab. Dennoch wird es momentan alle 10 Minuten getriggert.
Ich frage mich halt, ob hier ein Bug begraben liegt, oder ob ich schlicht zu blöd bin.
Bisher fehlt mir hier der Nachweis, dass DOIF sich nicht korrekt verhalten sollte.
Alles, was ich bisher gesehen habe, lässt keine Aussage zum Fehlverhalten zu.
Du musst ein list vom DOIF vom vermeintlichen Zustand posten, mit den dazugehörigen Events aus dem Eventmonitor.
Hier das Szenario wie im letzten Post beschrieben: Fenster wurde geöffnet während eigentlich cmd_1 (Nacht) anliegt. Beim nächsten Durchlauf wird das Rollo leider hochgefahren, da das ELSE greift. Wenn nicht fälschlicherweise auf f_beschattung:Winkel_west getriggert würde, wäre mein Rollo geschlossen geblieben :-)
Event-Monitor:
2018-10-22 07:09:58 VCONTROL300 Vitotronic200 UpdateStatus: Inactive
2018-10-22 07:10:00 structure struct_Rollos_EG undefined
2018-10-22 07:10:00 ZWave Rollo_EG_Balkontuer on
2018-10-22 07:10:00 DOIF di_Rollo_EG_Balkon Tag
2018-10-22 07:10:00 dummy f_beschattung Winkel_dach_ost: 18.0096511383823
2018-10-22 07:10:00 dummy f_beschattung Winkel_dach_west: -37.575217471601
2018-10-22 07:10:00 dummy f_beschattung Winkel_nord: 34.9340463712588
2018-10-22 07:10:00 dummy f_beschattung Winkel_ost: 53.1306292848995
2018-10-22 07:10:00 dummy f_beschattung Winkel_sued: -34.8450523207303
2018-10-22 07:10:00 dummy f_beschattung Winkel_west: -53.2175657361181
2018-10-22 07:10:00 at at_Rollo_Beschattung_setzen Next: 07:20:00
2018-10-22 07:10:00 dummy WW_tempgradient 4.5
2018-10-22 07:10:00 dummy WW_tempgradient alt: 54
2018-10-22 07:10:00 at at_wwtempgradient Next: 07:20:00
2018-10-22 07:10:00 at at_watchdog Next: 07:11:00
2018-10-22 07:10:00 TRX_LIGHT Leuchte_Kz light: on
2018-10-22 07:10:00 TRX_LIGHT Leuchte_Kz on
2018-10-22 07:10:04 ZWave SD_Trockner power: 1.3 W
List DOIF:
Internals:
CFGFN
DEF ( [f_rollo_nacht:state] == 1 and [?Fensterkontakt_EG_Balkon] eq "closed")
( set Rollo_EG_Balkontuer off; set Rollo_EG_Balkonfenster off )
DOELSEIF
( [f_rollo_nacht:state] == 0 and [f_beschattung:sued] == 2 and [rollo_settings_beschattung:status] eq "aktiv" and [?Fensterkontakt_EG_Balkon] eq "closed")
( {fhem "set Rollo_EG_Balkontuer dim ".ReadingsVal('Rollo_EG_Balkontuer','dim_Schatten',0);
fhem "set Rollo_EG_Balkonfenster dim ".ReadingsVal('Rollo_EG_Balkonfenster','dim_Schatten',0)} )
DOELSE
( set Rollo_EG_Balkontuer on; set Rollo_EG_Balkontuer on )
MODEL FHEM
NAME di_Rollo_EG_Balkon
NR 231
NTFY_ORDER 50-di_Rollo_EG_Balkon
STATE Tag
TYPE DOIF
READINGS:
2018-10-22 07:10:00 Device f_beschattung
2018-10-22 07:10:00 cmd 3
2018-10-22 07:10:00 cmd_event f_beschattung
2018-10-22 07:10:00 cmd_nr 3
2018-10-22 07:06:13 mode enabled
2018-10-22 07:10:00 state Tag
Regex:
attr:
cmdState:
0:
Nacht
1:
Beschattung
2:
Tag
wait:
waitdel:
condition:
0 ::ReadingValDoIf($hash,'f_rollo_nacht','state') == 1 and ::InternalDoIf($hash,'Fensterkontakt_EG_Balkon','STATE') eq "closed"
1 ::ReadingValDoIf($hash,'f_rollo_nacht','state') == 0 and ::ReadingValDoIf($hash,'f_beschattung','sued') == 2 and ::ReadingValDoIf($hash,'rollo_settings_beschattung','status') eq "aktiv" and ::InternalDoIf($hash,'Fensterkontakt_EG_Balkon','STATE') eq "closed"
devices:
0 f_rollo_nacht
1 f_rollo_nacht f_beschattung rollo_settings_beschattung
all f_rollo_nacht f_beschattung rollo_settings_beschattung
do:
0:
0 set Rollo_EG_Balkontuer off; set Rollo_EG_Balkonfenster off
1:
0 {fhem "set Rollo_EG_Balkontuer dim ".ReadingsVal('Rollo_EG_Balkontuer','dim_Schatten',0); fhem "set Rollo_EG_Balkonfenster dim ".ReadingsVal('Rollo_EG_Balkonfenster','dim_Schatten',0)}
2:
0 set Rollo_EG_Balkontuer on; set Rollo_EG_Balkontuer on
helper:
event Winkel_west: -53.2175657361181
globalinit 1
last_timer 0
sleeptimer -1
timerdev f_beschattung
timerevent Winkel_west: -53.2175657361181
triggerDev f_beschattung
DOIF_eventas:
cmd_nr: 3
cmd: 3
cmd_event: f_beschattung
state: Tag
timerevents:
Winkel_west: -53.2175657361181
timereventsState:
Winkel_west: -53.2175657361181
triggerEvents:
Winkel_west: -53.2175657361181
triggerEventsState:
Winkel_west: -53.2175657361181
internals:
0 Fensterkontakt_EG_Balkon:STATE
1 Fensterkontakt_EG_Balkon:STATE
all Fensterkontakt_EG_Balkon:STATE
itimer:
readings:
0 f_rollo_nacht:state
1 f_rollo_nacht:state f_beschattung:sued rollo_settings_beschattung:status
all f_rollo_nacht:state f_beschattung:sued rollo_settings_beschattung:status
trigger:
uiState:
uiTable:
Attributes:
checkReadingEvent 1
checkall all
cmdState Nacht|Beschattung|Tag
devStateIcon Nacht:weather_moon_phases_8 Beschattung:weather_summer Tag:weather_sun
event-on-change-reading state
room Rollos
Ich vermute mal stark, dass der Befehl zum Öffnen (cmd_3) sogar 6 mal gesendet werden würde, wenn ich do always setze (wegen der 6 aktualisierten Readings von f_beschattung).
Auch hier funktioniert alles korrekt:
f_beschattung:sued kommt im zweiten Zeig vor. Es sendete ein Event um 7:10. Mit -34.8450523207303 ist es nicht 2 und damit bleibt nur noch DOELSE, welches auf cmd_3 schaltet.
f_beschattung:sued kommt in der Bedingung vor.
f_beschattung:Winkel_sued erzeugt aber ein Event.
Und in dem List wird doch Winkel_west als letzter Trigger aufgeführt ( da das als letztes aktualisiert wird)
Welche DOIF-Version benutzt du?
Es liegt am Attribut checkall, ich muss noch prüfen, ob es ein Bug oder ein Feature ist :)
Wozu brauchst du checkall?
Wie gesagt, ich weiß es nicht mehr. Die DOIFs gibts schon länger, nur die Abfrage nach dem Fensterkontakt ist relativ neu und hat mich auf den ,,Bug" aufmerksam gemacht.
Ich denke ohne checkall sollte das Verhalten erstmal wieder iO sein.
Trotzdem wäre es für das nächste Mal gut zu wissen, ob es nun ein Bug ist oder ein Feature ;-)
Laut commandref hätte ich eben ein anderes Verhalten erwartet.
Danke schonmal für deine Bemühungen. Ich hoffe du hältst uns auf dem Laufenden :-)
Zitat von: der_oBi am 22 Oktober 2018, 10:23:48
Wie gesagt, ich weiß es nicht mehr. Die DOIFs gibts schon länger, nur die Abfrage nach dem Fensterkontakt ist relativ neu und hat mich auf den ,,Bug" aufmerksam gemacht.
Ich denke ohne checkall sollte das Verhalten erstmal wieder iO sein.
Trotzdem wäre es für das nächste Mal gut zu wissen, ob es nun ein Bug ist oder ein Feature ;-)
Laut commandref hätte ich eben ein anderes Verhalten erwartet.
Danke schonmal für deine Bemühungen. Ich hoffe du hältst uns auf dem Laufenden :-)
Normalerweise braucht man checkall nicht. Es ist in diesem Falle eher ein Bug, allerdings ist die Ursache dafür etwas tiefer begraben. checkReadingEvent ist jetzt default, allerdings sind die Check-Mechanismen dazu schon ziemlich alt - sie greifen eigentlich zu spät. Die Umstellung auf effizientere Vorgehensweise (und gleichzeitig fehlerfreies Verhalten bei checkall) wird aber etwas aufwändiger und muss gut getestet sein, weil es an zentraler Stelle im Modul ist. Wenn ich eine Umstellung vorgenommen habe, werde ich das natürlich hier publik machen.
Super, herzlichen Dank! Auch an die anderen Beteiligten.
Solange lösche ich dann mal mein checkall :-)
Hi Damian,
hast Du Dir das Thema mal ansehen können?
Ich bin leider diese Woche an anderer Stelle schon wieder darüber gestolpert.
Gruß
Zitat von: der_oBi am 24 August 2019, 06:08:20
Hi Damian,
hast Du Dir das Thema mal ansehen können?
Ich bin leider diese Woche an anderer Stelle schon wieder darüber gestolpert.
Gruß
Leider habe ich es bisher nicht geschafft das Problem zu lösen, weil es mit größerem Umbau verbunden ist.
Ich habe versucht bei mir das Problem nachzustellen. Mit einem Dummy namens
bla und zwei Readings
test und
test2Beide Readings sind auf 1 gesetzt.
getriggert wird über
setreading bla test2 1
folgende Definition mit checkall all funktioniert allerdings entgegen meiner ursprünglichen Annahme korrekt:
ZitatInternals:
CFGFN
DEF ([bla:test] == 1) () DOELSEIF ([bla:test2] ==1) ()
MODEL FHEM
NAME checkall
NR 2859
NTFY_ORDER 50-checkall
STATE cmd_1
TYPE DOIF
READINGS:
2019-08-25 17:04:43 Device bla
2019-08-25 17:04:43 cmd 1
2019-08-25 17:04:43 cmd_event bla
2019-08-25 17:04:43 cmd_nr 1
2019-08-25 17:04:43 e_bla_test2 1
2019-08-25 17:04:30 mode enabled
2019-08-25 17:04:43 state cmd_1
..
Attributes:
checkall all
do always
room DOIF
es wird hier der erste Zweig ausgeführt aufgrund der Tatsache, dass checkall gesetzt ist und bla:test auf 1 gesetzt ist. Getriggert wurde über bla test2 1.
Ohne checkall-Attribut funktioniert die Definition ebenfalls korrekt, dann wird logischerweise cmd_2 ausgeführt.
Also, ich kann ein Problem mit checkall nicht erkennen.
und was passiert, wenn du ein drittes reading (test3) deines bla dummys beschreibst?
Ich erwarte dann zumindest, dass ebenfalls das DOIF getriggert wird, obwohl du keine Bedingung für test3 drinne hast.
In meinem konkreten Fall möchte ich bspw. bei aktiviertem checkall auf den Status eines THRESHOLD triggern. Leider erzeugen die THRESHOLDS auch immer events zB für den sensor_value. Und event-on-... Attribute gibt es beim THRESHOLD leider nicht (mehr???).
Das führt dazu, dass mein DOIF dauernd getriggert wird, auch wenn sich der Status des THRESHOLD schon ewig nicht mehr geändert hat.
Zitat von: der_oBi am 27 August 2019, 18:16:21
und was passiert, wenn du ein drittes reading (test3) deines bla dummys beschreibst?
Ich erwarte dann zumindest, dass ebenfalls das DOIF getriggert wird, obwohl du keine Bedingung für test3 drinne hast.
ja, es war der DOELSE-Fall, den ich nicht mehr vor Augen hatte. Ich denke, dass ich bis zum Wochenende eine Lösung finde.
das wär echt mega! 8)
Neue Version im Anhang, du kannst testen.
Hey Damian,
dake für die schnelle Rückmeldung.
Leider verhält es sich bei mir immer noch so wie zuvor (ich nutze dein test-DOIF mit den test:bla Readings).
Ich muss doch nur die neue DOIF.pm in den FHEM Ordner kopieren und dann ein "reload 98_DOIF.pm" ausführen, oder habe ich irgendwas vergessen?
Zitat von: der_oBi am 01 September 2019, 06:56:45
Hey Damian,
dake für die schnelle Rückmeldung.
Leider verhält es sich bei mir immer noch so wie zuvor (ich nutze dein test-DOIF mit den test:bla Readings).
Ich muss doch nur die neue DOIF.pm in den FHEM Ordner kopieren und dann ein "reload 98_DOIF.pm" ausführen, oder habe ich irgendwas vergessen?
Ja, du musst das System durchstarten.
Ein shutdown restart hat leider auch nichts geändert? :-[
Hast Du es denn mit Deinem test-DOIF geprüft?
Zitat von: der_oBi am 01 September 2019, 10:12:54
Ein shutdown restart hat leider auch nichts geändert? :-[
Hast Du es denn mit Deinem test-DOIF geprüft?
ja, poste mal list vom DOIF vom vermeintlich falschen Zustand.
Hier das list vom DOIF. Getriggert wurde über "setreading bla test3 1".
Internals:
DEF ([bla:test] == 1) () DOELSEIF ([bla:test2] == 1) ()
FUUID 5d655e38-f33f-a49e-3319-5009a29e254782e3
MODEL FHEM
NAME doif_test
NR 373
NTFY_ORDER 50-doif_test
STATE cmd_1
TYPE DOIF
READINGS:
2019-09-01 10:18:01 Device bla
2019-09-01 10:18:01 cmd 1
2019-09-01 10:18:01 cmd_event bla
2019-09-01 10:18:01 cmd_nr 1
2019-09-01 06:48:46 e_bla_test 1
2019-08-27 18:47:35 e_bla_test2 1
2019-08-27 18:45:44 mode enabled
2019-09-01 10:18:01 state cmd_1
Regex:
accu:
cond:
bla:
0:
test ^bla$:^test:
1:
test2 ^bla$:^test2:
attr:
cmdState:
wait:
waitdel:
condition:
0 ::ReadingValDoIf($hash,'bla','test') == 1
1 ::ReadingValDoIf($hash,'bla','test2') == 1
devices:
0 bla
1 bla
all bla
do:
0:
0
1:
0
2:
helper:
event test3: 1
globalinit 1
last_timer 0
sleeptimer -1
timerdev bla
timerevent test3: 1
triggerDev bla
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: bla
state: cmd_1
timerevents:
test3: 1
timereventsState:
test3: 1
triggerEvents:
test3: 1
triggerEventsState:
test3: 1
internals:
itimer:
perlblock:
readings:
all bla:test bla:test2
trigger:
uiState:
uiTable:
Attributes:
checkReadingEvent 1
checkall all
do always
room Homekit
Teste mal diese Version: https://forum.fhem.de/index.php/topic,103401.msg971005.html#msg971005
Sieht gut aus! Dankeschön!
Werde es nun die nächsten Tage mal genau im Auge behalten und berichten.
Hi Damian,
also bisher funktioniert alles wie gewünscht! Prima!
Ich habe jetzt erst gesehen, dass das THRESHOLD Modul auch aus Deiner Feder kommt.
Genau ein solches reading (nämlich der sensor_value) hat mir ja erst die Probleme gemacht. Daher muss ich jetzt mal fragen:
Wieso kann man beim THRESHOLD eigentlich keine event-on-... Attribute setzen?
Sonst hätte ich nämlich einfach den sensor_value von jeglichen Events ausschließen können.
Zitat von: der_oBi am 02 September 2019, 19:17:22
Hi Damian,
also bisher funktioniert alles wie gewünscht! Prima!
Ich habe jetzt erst gesehen, dass das THRESHOLD Modul auch aus Deiner Feder kommt.
Genau ein solches reading (nämlich der sensor_value) hat mir ja erst die Probleme gemacht. Daher muss ich jetzt mal fragen:
Wieso kann man beim THRESHOLD eigentlich keine event-on-... Attribute setzen?
Sonst hätte ich nämlich einfach den sensor_value von jeglichen Events ausschließen können.
THRESHOLD ist ein relativ altes Modul. Es war mein erstes Modul, da kannte ich die Möglichkeiten von event-on... noch nicht.
schade.
Die DOIF-Version (mit dem NOTIFYDEV Filter) wird nun aber noch nicht "offiziell" per Update verteilt, oder?
Zitat von: der_oBi am 03 September 2019, 16:52:16
schade.
Die DOIF-Version (mit dem NOTIFYDEV Filter) wird nun aber noch nicht "offiziell" per Update verteilt, oder?
Noch nicht, wenn sich keine Auffälligkeiten zeigen, möchte ich sie bald einchecken.
Eventuell hätte ich eine Auffälligkeit gefunden :-\
Obwohl ich in zwei Bedingungen einen Fensterkontakt mit vorangestelltem Fragezeichen abfrage, triggert mein DOIF auch auf den Fensterkontakt:
Internals:
DEF ( [f_rollo_nacht] == 1 and [?Fenster_EG_HWR:state] eq "closed" )
( set Rollo_EG_HWR off )
DOELSEIF
( [f_rollo_nacht] == 1 and [?Fenster_EG_HWR:state] ne "closed" )
( set Rollo_EG_HWR dim [Rollo_EG_HWR:dim_Lueften,10] )
DOELSEIF
( [f_rollo_nacht] == 0 and [f_beschattung:nord] == 1 and [rollo_settings_beschattung:status_eg] eq "aktiv" and [Waermebed_EG_HWR] eq "nein" )
( set Rollo_EG_HWR dim [Rollo_EG_HWR:dim_Schatten,20] )
DOELSE
( set Rollo_EG_HWR on )
FUUID 5c44afd5-f33f-a49e-8045-67ac6816ebe3a231
MODEL FHEM
NAME di_Rollo_EG_HWR
NOTIFYDEV global,f_rollo_nacht,Fenster_EG_HWR,f_beschattung,rollo_settings_beschattung,Waermebed_EG_HWR
NR 189
NTFY_ORDER 50-di_Rollo_EG_HWR
STATE Nacht
TYPE DOIF
READINGS:
2019-09-04 06:13:21 Device Fenster_EG_HWR
2019-09-04 06:13:21 cmd 1
2019-09-04 06:13:21 cmd_event Fenster_EG_HWR
2019-09-04 06:13:21 cmd_nr 1
2019-09-04 06:13:06 mode enabled
2019-09-04 06:13:21 state Nacht
Regex:
accu:
cond:
Fenster_EG_HWR:
0:
state ^Fenster_EG_HWR$:^state:
1:
state ^Fenster_EG_HWR$:^state:
Waermebed_EG_HWR:
2:
&STATE ^Waermebed_EG_HWR$
f_beschattung:
2:
nord ^f_beschattung$:^nord:
f_rollo_nacht:
0:
&STATE ^f_rollo_nacht$
1:
&STATE ^f_rollo_nacht$
2:
&STATE ^f_rollo_nacht$
rollo_settings_beschattung:
2:
status_eg ^rollo_settings_beschattung$:^status_eg:
attr:
cmdState:
0:
Nacht
1:
Lüften
2:
Beschattung
3:
Tag
wait:
waitdel:
condition:
0 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 1 and ::ReadingValDoIf($hash,'Fenster_EG_HWR','state') eq "closed"
1 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 1 and ::ReadingValDoIf($hash,'Fenster_EG_HWR','state') ne "closed"
2 ::InternalDoIf($hash,'f_rollo_nacht','STATE') == 0 and ::ReadingValDoIf($hash,'f_beschattung','nord') == 1 and ::ReadingValDoIf($hash,'rollo_settings_beschattung','status_eg') eq "aktiv" and ::InternalDoIf($hash,'Waermebed_EG_HWR','STATE') eq "nein"
do:
0:
0 set Rollo_EG_HWR off
1:
0 set Rollo_EG_HWR dim [Rollo_EG_HWR:dim_Lueften,10]
2:
0 set Rollo_EG_HWR dim [Rollo_EG_HWR:dim_Schatten,20]
3:
0 set Rollo_EG_HWR on
helper:
event closed
globalinit 1
last_timer 0
sleeptimer -1
timerdev Fenster_EG_HWR
timerevent closed
triggerDev Fenster_EG_HWR
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: Fenster_EG_HWR
state: Nacht
timerevents:
closed
timereventsState:
state: closed
triggerEvents:
closed
triggerEventsState:
state: closed
internals:
all f_rollo_nacht:STATE Waermebed_EG_HWR:STATE
readings:
all f_beschattung:nord rollo_settings_beschattung:status_eg
trigger:
uiState:
uiTable:
Attributes:
checkReadingEvent 1
checkall all
cmdState Nacht|Lüften|Beschattung|Tag
devStateIcon Nacht:weather_moon_phases_8 Lüften:vent_ambient_air Beschattung:weather_summer Tag:weather_sun
event-on-change-reading state
group DOIF_Rollos
room Rollos
Es war tatsächlich noch ein Fehler drin. Korrigierte Version v0.9 https://forum.fhem.de/index.php/topic,103401.msg971005.html#msg971005
Soeben getestet. Bedingungen mit vorangestelltem Fragezeichen führen nicht mehr zur Triggerung!
Top!
Mal eine Frage zum Verständnis:
wenn ich mit CheckReadingEvent auf den state (reading, nicht internal) triggern möchte, muss ich dann [xyz:state] als Trigger definieren, oder reicht auch [xyz]?
Scheint für mich so, als müsste ich in diesem Falle auch auf ...:state triggern, sonst kommen doch wieder auch alle anderen readings als Trigger durch.
Zitat von: der_oBi am 12 September 2019, 07:03:06
Mal eine Frage zum Verständnis:
wenn ich mit CheckReadingEvent auf den state (reading, nicht internal) triggern möchte, muss ich dann [xyz:state] als Trigger definieren, oder reicht auch [xyz]?
Scheint für mich so, als müsste ich in diesem Falle auch auf ...:state triggern, sonst kommen doch wieder auch alle anderen readings als Trigger durch.
[xyz] ist eine Statusabfrage, sie wird immer bei allen Events des Devices getriggert, unabhängig vom Attribut CheckReadingEvent - das war immer so und wird auch so bleiben.
CheckReadingsEvent hat nur einen Einfluss auf Readingangaben der Form: [device:reading]
Ok, dachte ich mir. Wenn man es weiß ist alles gut :-)
Gesendet von iPhone mit Tapatalk
Zitat von: der_oBi am 12 September 2019, 07:55:59
Ok, dachte ich mir. Wenn man es weiß ist alles gut :-)
Gesendet von iPhone mit Tapatalk
Das steht aber auch so in der Commandref zu
Statusabfragen:
ZitatAnwendungsbeispiel: Einfache Ereignissteuerung, "remotecontrol" ist hier ein Device, es wird in eckigen Klammern angegeben. Ausgewertet wird der Status des Devices - nicht das Event.
define di_garage DOIF ([remotecontrol] eq "on") (set garage on) DOELSEIF ([remotecontrol] eq "off") (set garage off)
Das Modul wird getriggert, sobald das angegebene Device hier "remotecontrol" ein Event erzeugt. Das geschieht, wenn irgendein Reading oder der Status von "remotecontrol" aktualisiert wird.