MoinMoin,
vielleicht kann mir einer mal auf die Sprünge helfen, denn ich stehe auf dem Schlauch.
Folgende Bedingung habe ich:
((([06:25-22:15] and [RolloSteuerungHinten] eq "88") ## Heute + morgen Arbeit
or
([06:25:30-23:01] and [RolloSteuerungHinten] eq "87") ## Heute Arbeit + morgen frei
or
([([RolloWEHinten]+[00:00:01])-22:16] and [RolloSteuerungHinten] eq "78") ## Heute Frei + morgen Arbeit
or
([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77") ## Heute + morgen Frei
)
and [1wire_Lux:Helligkeit] > [1wireLuxRollo]) ## wenn hell
(set Rollo.Wohnzimmer on)
DOELSE
(set Rollo.Wohnzimmer pct 8)
"RolloSteuerungHinten" hat heute als Status "77".
Dennoch wurde Timer No. 5 heute morgen ausgeführt. TimerNo 5 hat aber als Bedingung "78"...
Erwartet habe ich Timer No.7
Bleibt mir rätselhaft, auch beim zweiten durchlesen. Was ist timer 5 und warum sollte es beim status 77 nicht ausgeführt werden?
Ganz zu schweigen davon, dass die Werte von RolloWEHinten und den lux werten im wahrsten sinne des Wortes im Dunkeln liegen
eq gilt doch nur für Zeichenketten. Sollte da nicht eher == hin?
Grüße
Auf der perl ebene sollte das keine Rolle spielen, denn auch der Vergleichswert ist ja als String angegeben. Ich denke dass gilt auch für DOIF. Normalerweise tritt ja nur umgekehrt ein Problem auf.
Ok:
RolloWEHinten ist ein Dummy mit Zeitangaben. zZt = 09:00 Uhr
Lux ist um diese Uhrzeit > 1wireLuxRollo
Um 09:00 Uhr ist "and [1wire_Lux:Helligkeit] > [1wireLuxRollo]" = true
Timer 5 ist IMO lt. zählweise die 5. Uhrzeit, also die in der 3. OR-Verknüpfung zu der wiederum als Bedingung [RolloSteuerungHinten] eq "78" gehört.
Da das State von RolloSteuerungHinten heute "77" ist, ist diese Bedingung aus der 3.OR-Verknüpfung jedoch nicht wahr. Dennoch hat diese Bedingung ausgelöst und "Timer 5" "aktiviert...
Zu sehen hier im Log:
2017-10-07_09:00:22 Ti_RolloWzDOELSE fts_shutter_10
2017-10-07_09:00:22 Ti_RolloWzDOELSE cmd_event: timer_5
2017-10-07_09:00:22 Ti_RolloWzDOELSE cmd: 1
2017-10-07_09:00:22 Ti_RolloWzDOELSE cmd_nr: 1
2017-10-07_09:00:21 Ti_RolloWzDOELSE cmd_count: 1
2017-10-07_09:00:21 Ti_RolloWzDOELSE wait_timer: no timer
2017-10-07_09:00:11 Ti_RolloWzDOELSE wait_timer: 07.10.2017 09:00:21 cmd_1 timer_5
2017-10-07_09:00:11 Ti_RolloWzDOELSE wait_timer: no timer
Poste mal ein vollständiges "list" vom DOIF und die Version.
Bitte:
FHEM ist aktuell. Wo bekomme ich die DOIF-Versionsnummer heraus ? 98_DOIF.pm 14790 2017-07-26 10:27:41Z Damian $ ?
Internals:
DEF ((([06:25-22:15] and [RolloSteuerungHinten] eq "88") ## Heute + morgen Arbeit
or
([06:25:30-23:01] and [RolloSteuerungHinten] eq "87") ## Heute Arbeit + morgen frei
or
([([RolloWEHinten]+[00:00:01])-22:16] and [RolloSteuerungHinten] eq "78") ## Heute Frei + morgen Arbeit
or
([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77") ## Heute + Frei
)
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn hell
and [AufArbeit] eq "off") ## wenn Anwesend
(set Rollo.Wohnzimmer on)
DOELSE
(set Rollo.Wohnzimmer pct 8)
NAME Ti_RolloWzDOELSE
NR 964
NTFY_ORDER 50-Ti_RolloWzDOELSE
STATE fts_shutter_10
TYPE DOIF
READINGS:
2017-10-07 20:10:09 Device 1wire_Lux
2017-10-07 09:58:50 cmd 1
2017-10-07 09:58:49 cmd_count 1
2017-10-07 09:58:50 cmd_event 1wire_Lux
2017-10-07 09:58:50 cmd_nr 1
2017-10-07 20:10:09 e_1wire_Lux_Helligkeit 4.076
2017-10-07 09:58:50 state fts_shutter_10
2017-10-07 09:53:36 timer_01_c01 08.10.2017 06:25:00
2017-10-07 09:53:36 timer_02_c01 07.10.2017 22:15:00
2017-10-07 09:53:36 timer_03_c01 08.10.2017 06:25:30
2017-10-07 09:53:36 timer_04_c01 07.10.2017 23:01:00
2017-10-07 09:53:36 timer_05_c01 08.10.2017 09:00:01
2017-10-07 09:53:36 timer_06_c01 07.10.2017 22:16:00
2017-10-07 09:53:36 timer_07_c01 08.10.2017 09:00:02
2017-10-07 09:53:36 timer_08_c01 07.10.2017 23:02:00
2017-10-07 19:10:06 wait_timer 07.10.2017 21:10:06 cmd_2 1wire_Lux
condition:
0 ((DOIF_time($hash,0,1,$wday,$hms) and InternalDoIf($hash,'RolloSteuerungHinten','STATE') eq "88") or (DOIF_time($hash,2,3,$wday,$hms) and InternalDoIf($hash,'RolloSteuerungHinten','STATE') eq "87") or (DOIF_time($hash,4,5,$wday,$hms) and InternalDoIf($hash,'RolloSteuerungHinten','STATE') eq "78") or (DOIF_time($hash,6,7,$wday,$hms) and InternalDoIf($hash,'RolloSteuerungHinten','STATE') eq "77") ) and ReadingValDoIf($hash,'1wire_Lux','Helligkeit') > InternalDoIf($hash,'1wireLuxRollo','STATE') and InternalDoIf($hash,'AufArbeit','STATE') eq "off"
days:
devices:
0 RolloSteuerungHinten 1wire_Lux 1wireLuxRollo AufArbeit
all RolloSteuerungHinten 1wire_Lux 1wireLuxRollo AufArbeit
do:
0:
0 set Rollo.Wohnzimmer on
1:
0 set Rollo.Wohnzimmer pct 8
helper:
event Helligkeit: 4.076
globalinit 1
last_timer 8
sleepdevice 1wire_Lux
sleepsubtimer 0
sleeptimer 1
timerdev 1wire_Lux
timerevent Helligkeit: 4.076
triggerDev 1wire_Lux
timerevents:
Helligkeit: 4.076
timereventsState:
Helligkeit: 4.076
triggerEvents:
Helligkeit: 4.076
triggerEventsState:
Helligkeit: 4.076
internals:
0 RolloSteuerungHinten:STATE 1wireLuxRollo:STATE AufArbeit:STATE
all RolloSteuerungHinten:STATE 1wireLuxRollo:STATE AufArbeit:STATE
interval:
0 -1
1 0
2 -1
3 2
4 -1
5 4
6 -1
7 6
itimer:
all RolloWEHinten
localtime:
0 1507436700
1 1507407300
2 1507436730
3 1507410060
4 1507446001
5 1507407360
6 1507446002
7 1507410120
readings:
0 1wire_Lux:Helligkeit
all 1wire_Lux:Helligkeit
realtime:
0 06:25:00
1 22:15:00
2 06:25:30
3 23:01:00
4 09:00:01
5 22:16:00
6 09:00:02
7 23:02:00
regexp:
0:
all:
state:
STATE:
time:
0 06:25:00
1 22:15:00
2 06:25:30
3 23:01:00
4 ([RolloWEHinten]+[00:00:01])
5 22:16:00
6 ([RolloWEHinten]+[00:00:02])
7 23:02:00
timeCond:
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
timer:
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
timers:
0 0 1 2 3 4 5 6 7
trigger:
triggertime:
1507407300:
localtime 1507407300
hash:
1507407360:
localtime 1507407360
hash:
1507410060:
localtime 1507410060
hash:
1507410120:
localtime 1507410120
hash:
1507436700:
localtime 1507436700
hash:
1507436730:
localtime 1507436730
hash:
1507446001:
localtime 1507446001
hash:
1507446002:
localtime 1507446002
hash:
Attributes:
cmdState fts_shutter_10|fts_shutter_100
disable 0
group 01 Timer
repeatsame 1:1
room DOIF,Jalousien
setList state:on,off
timerWithWait 1
wait 10:[WaitWz]
webCmd on:off
Bei einer älteren Version gab es mal einen verschobenen Timer, das ist damit ausgeschlossen.
Aha, dennoch hierfür eine Idee wieso es nicht so funktioniert wie gewünscht?
Was ist zwischen 09:00:00 und 09:00:11 passiert?
Zitat von: amenomade am 08 Oktober 2017, 00:09:20
Was ist zwischen 09:00:00 und 09:00:11 passiert?
Ja das sieht komisch aus.
Ausserdem ich vermute die log-Einträge sind einfach in der Reihenfolge vertauscht worden (und die Zeit läuft nicht rückwärts)
Generell ist mir aber unklar wo das Problem liegt, denn das DOIF sollte doch heute morgen um 9 und eine Sekunde feuern, oder?
Also geht es nur darum, dass der cmd_event timer_5 nennt?
Zitat von: Bartimaus am 07 Oktober 2017, 23:35:13
Aha, dennoch hierfür eine Idee wieso es nicht so funktioniert wie gewünscht?
Setze mal DOIFtools darauf an und setze specialLog auf 1, s. https://wiki.fhem.de/wiki/DOIFtools#Erstellen_eines_Debug-Logfile
Wenn Du reverseLog nicht ausschaltest, musst Du Dir dass Logfile allein ansehen.
.sknil hcan sthcer nov nebierhcs eiw tsi goLesreveR
Zitat von: viegener am 08 Oktober 2017, 02:42:26
Also geht es nur darum, dass der cmd_event timer_5 nennt?
Korrekt, und auch ausführt !
Ja, ich habe ReverseLog eingeschaltet, wegen meiner langen Jahreslog bei Tempsensoren
DOIFTools schaue ich mir jetzt mal an.
Zitat von: amenomade am 08 Oktober 2017, 00:09:20
Was ist zwischen 09:00:00 und 09:00:11 passiert?
Jetzt ohne ReverseLog... ::)
2017-10-07_00:00:28 Ti_RolloHintenDoelse wait_timer: 07.10.2017 00:15:28 cmd_2 RolloSteuerungHinten
2017-10-07_00:15:28 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_06:25:00 Ti_RolloHintenDoelse wait_timer: 07.10.2017 06:40:00 cmd_2 timer_1
2017-10-07_06:40:00 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_07:33:17 Ti_RolloHintenDoelse wait_timer: 07.10.2017 07:48:17 cmd_2 1wire_Lux
2017-10-07_07:48:18 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_07:53:17 Ti_RolloHintenDoelse wait_timer: 07.10.2017 08:08:17 cmd_2 1wire_Lux
2017-10-07_08:08:17 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_08:13:16 Ti_RolloHintenDoelse wait_timer: 07.10.2017 08:28:16 cmd_2 1wire_Lux
2017-10-07_08:28:16 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_08:33:06 Ti_RolloHintenDoelse wait_timer: 07.10.2017 08:48:06 cmd_2 1wire_Lux
2017-10-07_08:48:06 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_08:48:12 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:03:12 cmd_2 1wire_Lux
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:00:41 cmd_1 timer_5
2017-10-07_09:00:42 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_09:00:42 Ti_RolloHintenDoelse cmd_count: 1
2017-10-07_09:00:43 Ti_RolloHintenDoelse cmd_nr: 1
2017-10-07_09:00:43 Ti_RolloHintenDoelse cmd: 1
2017-10-07_09:00:43 Ti_RolloHintenDoelse cmd_event: timer_5
2017-10-07_09:00:43 Ti_RolloHintenDoelse fts_shutter_10
Nichts....
Um Mitternacht wird "RolloSteuerungHinten" neu gesetzt. deswegen der Eintrag.
Es gibt die Ausprägungen:
77 = Heute + morgen frei; entspricht [NRW_Feiertag:today] ne "none + [NRW_Feiertag:tomorrow] ne "none"
78 = Heute frei + morgen Arbeit/Schule
87 = Heute Arbeit/Schule, morgen frei
88 = Heute + morgen Arbeit/Schule
Zitat von: Bartimaus am 08 Oktober 2017, 11:08:44
Korrekt, und auch ausführt !
Ja, um 9 Uhr und 2 Sekunden wurde gestern die letzte Timerbedingung Deines DOIFs
([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77") ## Heute + Frei wahr und damit der Befehl ausgeführt, also ist die Ausführung doch völlig in Ordnung.
Ich habe jetzt nicht den ganzen DOIF-Code durchgelesen und ich verstehe, dass timer_5 hier inkonsistent ist, es gibt ja erstmal kein Fehlverhalten oder übersehe ich etwas?
??
Im Log steht doch
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:00:41 cmd_1 timer_5
und Timer5 gehört zur Bedingung "78"
Im Sommer wenn die Zeit die ausführende Bedingung ist, hat es eben nicht korrekt funktioniert...
Zitat von: Bartimaus am 08 Oktober 2017, 12:29:47
??
Im Log steht doch
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:00:41 cmd_1 timer_5
und Timer5 gehört zur Bedingung "78"
Nochmal zur Erklärung gestern morgen um 9 Uhr sollte das DOIF schalten und hat es getan - also kein Problem damit, oder?
Hast Du eine Dokumentation gefunden, dass die Zählweise von timer in den events gleich der in den Readings sein muss, vielleicht ist durch die interne Logik die Zählweise anders? Ich versuche immer noch rauszufinden ob Du ein Fehlverhalten hast (und welches) oder ob es um einen Logeintrag geht?
Zitat von: viegener am 08 Oktober 2017, 12:45:33
Nochmal zur Erklärung gestern morgen um 9 Uhr sollte das DOIF schalten und hat es getan - also kein Problem damit, oder?
Ja, es hat geschaltet.
Aber ich finde aus den "falschen Gründen", auch wenn es augenscheinlich korrekt erscheint
Zitat von: viegener am 08 Oktober 2017, 12:45:33
Hast Du eine Dokumentation gefunden, dass die Zählweise von timer in den events gleich der in den Readings sein muss, vielleicht ist durch die interne Logik die Zählweise anders? Ich versuche immer noch rauszufinden ob Du ein Fehlverhalten hast (und welches) oder ob es um einen Logeintrag geht?
Wie gesagt, Im Sommer, wenn die Bedingung gem. Timer endet, hat er in der Tat falsch geschaltet, nämlich so wie es im Log gem. Timer steht, d.h. es wurde der falsche Timer ausgeführt, zu dem die Bedingung = false ist.
Eine Doku habe ich nicht gefunden, in der das mit den Timern/Events/Log definiert wird, es erschien mir nur logisch.
ich habe eine andere logische Erklärung für Dich, die ich aber nicht wirklich im Code von DOIF beweisen konnte. Die Bedingung timer_5 war um 9 Uhr als geschaltet wurde offensichtlich (ebenfalls) wahr. Mein Gefühl ist, dass DOIF prüft ob eine Timerbedingung wahr ist und dann die Bendingungen für einen cmd-Zweig abprüft (diese stehen ja als Gesamtbedingung im internal condition). Dann wird die Nummer eines gültigen Timers ausgegeben wenn die Bedingung wahr ist in diesem Fall ist timer_5 der erste Timer der wirklich wahr ist.
Also mein Vorschlag: Wenn Du einen Fehler beobachtest, versuche in dem Moment das zu dokumentieren, aber nicht wenn es einen möglicherweise missverständlichen logeintrag gibt, den ich als eher intern sehen würde.
Ich vermute heute morgen stand bei der Schaltung ebenfalls timer5 im log???
Du kannst auch einfach mal die beiden bedingungen mit timer5 und timer7 tauschen und am nächsten Samstag vermute ich wirst du im log wieder timer5 sehen. In diesem Fall ist es nach Deinem Verstädnis auch korrekt. Allerdings wirst Du dann am Sonntag auch timer5 sehen und das wäre dann nach Deiner Interpretation falsch...
ZitatIm Log steht doch
Code: [Auswählen]
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:00:41 cmd_1 timer_5
Die Frage, die ich gestellt habe, hat einen Grund:
([RolloWEHinten]+[00:00:01])-22:16]Sowas triggert um 09:00:01. Triggern heisst nicht "Befehl ausführen". Dann läuft der Timer bis 09:00:11. Das ist normal.
[([RolloWEHinten]+[00:00:02])-23:02]Sowas sollte um 09:00:02 triggern. Dann läuft der Timer bis 09:00:12. Aber nicht, wenn der andere Timer noch läuft. Wenn Du willst, dass die Bedingung wieder geprüft wird, musst Du das Attribute do resetwait setzen.
Deswegen meine Frage: was ist dann zwischen 09:00:00 und 09:00:11 passiert? Gibt es nix in der Log? Ein DOIF funktioniert mit Zustandwechseln. Deswegen ist es wichtig zu wissen, was passiert ist, um zu sehen, was nach und nach kommt.
Das ist eine gute Idee mit dem tauschen.
Heute morgen hat wieder Timer5 gefeuert, was ja wahr ist/war.
Parallel habe ich das Loggng mittels DOIFTools eingeschaltet, sowie ein ähnliches DOIF erstellt, jedoch ohne OR, dafür mit DOELSEIF. (Jedoch gab es da auch mal einen Bug mit gleichen Timern und Wochentagsabfrage, deswegen hatte ich auf OR-Bedingung) umgebaut.
Ich muss sagen, ich versteh nicht, was Du genau möchtest.
Wenn 78 dann um 09:00:11 schalten, und wenn 77 dann um 09:00:12? Welchen Sinn hat diese Sekunde Verzögerung???
Also man kann sagen:
1) die Reihenfolge der Timer stimmt mit der tatsächlichen überein
2) der Timer_5 gehört zu der Zeile ([([RolloWEHinten]+[00:00:01])-22:16] and [RolloSteuerungHinten] eq "78")
3) auch wenn der Timer_5 getriggert hat, muss nicht die obige Bedingung wahr sein
4) wenn cmd 1 durch Timer_5 ausgelöst worden ist, wird entweder ([06:25-22:15] and [RolloSteuerungHinten] eq "88") oder ([06:25:30-23:01] and [RolloSteuerungHinten] eq "87") wahr gewesen sein
5) ([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77") kann um [RolloWEHinten]+[00:00:01] (Auslösezeitpunkt von timer_5) nicht wahr gewesen sein, weil das Zeitintervall eine Sekunde später erst wahr ist
jetzt brauchen wir den Nachweis über den Zustand von [RolloSteuerungHinten] um [RolloWEHinten]+[00:00:01] (Triggerzeitpunkt von Timer 5)
Es sieht aber laut log so aus, als ob das DOIF-Modul erst um 9:00:11 wieder zur Überprüfung gekommen ist:
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:00:41 cmd_1 timer_5
und zu der Zeit war:
([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77")
inzwischen wahr, oder sehe ich das falsch?
Zitat von: viegener am 08 Oktober 2017, 13:55:37
Es sieht aber laut log so aus, als ob das DOIF-Modul erst um 9:00:11 wieder zur Überprüfung gekommen ist:
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: no timer
2017-10-07_09:00:11 Ti_RolloHintenDoelse wait_timer: 07.10.2017 09:00:41 cmd_1 timer_5
und zu der Zeit war:
([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77")
inzwischen wahr, oder sehe ich das falsch?
Wenn [RolloWEHinten] auf 09:00:00 stand, dann hat das System zwischen 09:00:01 und 09:00:11 sich mit anderen Sachen beschäftigt und dann wäre tatsächlich
([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77") wahr.
In solchen Fällen solltes du nach den Ursachen der Blockade im System schauen bzw. die Zeiten die aufeinander folgen nicht zu knapp wählen. Eine Sekunde kann dann schon zu wenig sein.
Zitat von: amenomade am 08 Oktober 2017, 13:35:12
Ich muss sagen, ich versteh nicht, was Du genau möchtest.
Wenn 78 dann um 09:00:11 schalten, und wenn 77 dann um 09:00:12? Welchen Sinn hat diese Sekunde Verzögerung???
Das habe ich nur gemacht, damit die Timer sich nicht ins Gehege kommen. Weiter unten hat Damian ja aufgeführt, das eine Sekunde schon zu wenig sein kann.
Darüberhinaus arbeiten meine ganzen HourCounter immer zur vollen Stunde, die sorgen scheinbar auch für Systemunterbrechungen, denn zur vollen Stunde steigt dann meistens mein HM-LAN mit kurzzeitigem Disconnect aus.
Einen Nachweis zu [RolloSteuerungHinten] kann ich leider nicht liefern, nachdem dieses eigene DOIF nach monatigem Testlauf fehlerfrei lief, und ich das Logging hierzu abgeschaltet habe.
Aber generell habe ich angenommen, das eigene geklammerte Bedingungen wie in meinem Fall, gekapselt betrachtet werden, d.h. auch wenn der Zeitrahmen=true ist, die zugehörige AND-Bedingung=false, somit der "String" als erledigt/false abgehakt ist, und dann die nächste geklammerte Bedingung geprüft wird....
Zitat von: Bartimaus am 08 Oktober 2017, 15:13:28
Aber generell habe ich angenommen, das eigene geklammerte Bedingungen wie in meinem Fall, gekapselt betrachtet werden, d.h. auch wenn der Zeitrahmen=true ist, die zugehörige AND-Bedingung=false, somit der "String" als erledigt/false abgehakt ist, und dann die nächste geklammerte Bedingung geprüft wird....
bei "and" ja bei "or" nein. Du hast hier or-Verknüpfungen definiert. Eine DOIF-Bedingung wird wie auch bei einem if komplett ausgewertet, egal welcher Trigger dieser Bedingung gerade getriggert hat.
Zitat von: Damian am 08 Oktober 2017, 15:20:28
bei "and" ja bei "or" nein. Du hast hier or-Verknüpfungen definiert. Eine DOIF-Bedingung wird wie auch bei einem if komplett ausgewertet, egal welcher Trigger dieser Bedingung gerade getriggert hat.
ÖHA !!!
Zitat von: Damian am 08 Oktober 2017, 15:20:28
bei "and" ja bei "or" nein. Du hast hier or-Verknüpfungen definiert. Eine DOIF-Bedingung wird wie auch bei einem if komplett ausgewertet, egal welcher Trigger dieser Bedingung gerade getriggert hat.
Das bestätigt meine Vermutung:
Zitat von: viegener am 08 Oktober 2017, 13:00:08
Mein Gefühl ist, dass DOIF prüft ob eine Timerbedingung wahr ist und dann die Bendingungen für einen cmd-Zweig abprüft (diese stehen ja als Gesamtbedingung im internal condition). Dann wird die Nummer eines gültigen Timers ausgegeben wenn die Bedingung wahr ist in diesem Fall ist timer_5 der erste Timer der wirklich wahr ist.
Danke
Ich habe jetzt mal ein von 3 RolladenDOIF von OR-Bedingung auf DOELSEIF-Bedingung umgestellt.
Beim verbleibendem mit OR habe ich das Attribut DO-Resetwait gesetzt. Ich bin gespannt.
Danke erstmal für die klärende Unterstützung
Moin,
ich muss das Thema aus akutem Anlass nochmal hochholen.
Ich habe die Definition wie folgt geändert:
defmod Ti_RolloVorneDoelse DOIF
([Schulferien] eq "none" ##Heute Schule\
and [Schulferien:tomorrow] eq "none" ##morgen Schule\
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert\
and [[Rollo8Morgens]-22:00])\
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize) \
DOELSEIF\
([Schulferien] eq "none" ##Heute Schule\
and [Schulferien:tomorrow] ne "none" ## morgen Schulfrei\
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert\
and [[Rollo8Morgens]-23:31])\
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)\
DOELSEIF\
([Schulferien] ne "none" ##Heute Schulfrei\
and [Schulferien:tomorrow] eq "none" ## morgen Schule \
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert\
and [[RolloWEVorne]-22:00])\
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)\
DOELSEIF\
([Schulferien] ne "none" ##Heute Schulfrei\
and [Schulferien:tomorrow] ne "none" ## morgen Schulfrei\
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert\
and [[RolloWEVorne]-23:32])\
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)\
DOELSE\
(set Rollo.Vorne pct 15, set Rollo.Seite pct 25, set Do_RolloSeiteSchatten disable, set Do_RolloVorneSchatten disable)
attr Ti_RolloVorneDoelse cmdState fts_shutter_10|fts_shutter_10|fts_shutter_10|fts_shutter_10|fts_shutter_100
attr Ti_RolloVorneDoelse disable 0
attr Ti_RolloVorneDoelse group 01 Timer
attr Ti_RolloVorneDoelse repeatsame 1:1:1:1:1
attr Ti_RolloVorneDoelse room DOIF,Jalousien
attr Ti_RolloVorneDoelse timerWithWait 1
attr Ti_RolloVorneDoelse wait 0:0:900:900:900
Heute morgen gingen die Rollos planmäßig um 06:35 hoch, da der Helligkeitsschwellenwert zu Timer 1 überschritten war. Soweit so gut.
2018-03-21_06:20:43 Ti_RolloVorneDoelse wait_timer: 21.03.2018 06:35:43 cmd_5 1wire_Lux
2018-03-21_06:35:00 Ti_RolloVorneDoelse wait_timer: no timer
2018-03-21_06:35:00 Ti_RolloVorneDoelse cmd_count: 1
2018-03-21_06:35:01 Ti_RolloVorneDoelse cmd_nr: 1
2018-03-21_06:35:01 Ti_RolloVorneDoelse cmd: 1
2018-03-21_06:35:01 Ti_RolloVorneDoelse cmd_event: timer_1
2018-03-21_06:35:01 Ti_RolloVorneDoelse fts_shutter_10
Um 08:45 wollten die Rollos wieder runter. Auslöser war Timer 5.
2018-03-21_08:30:00 Ti_RolloVorneDoelse wait_timer: 21.03.2018 08:45:00 cmd_5 timer_7
Kurze Zeit später triggerte der Helligkeitssensor und hat den aktiven WAIT-Timer wieder gelöscht. (Auslöser Timer 1 weil da alle Bedingungen heute WAHR sind)
Ich verstehe immer noch nicht, wieso "cmd_5 Timer 7" ausgelöst hat, obwohl die nachstehenden Bedingungen NICHT WAHR waren. (Schulferien:state = none)
Könnt Ihr Euch das erklären ?
Zu guter Letzt noch das List des Devices.
Internals:
DEF ([Schulferien] eq "none" ##Heute Schule
and [Schulferien:tomorrow] eq "none" ##morgen Schule
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert
and [[Rollo8Morgens]-22:00])
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)
DOELSEIF
([Schulferien] eq "none" ##Heute Schule
and [Schulferien:tomorrow] ne "none" ## morgen Schulfrei
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert
and [[Rollo8Morgens]-23:31])
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)
DOELSEIF
([Schulferien] ne "none" ##Heute Schulfrei
and [Schulferien:tomorrow] eq "none" ## morgen Schule
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert
and [[RolloWEVorne]-22:00])
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)
DOELSEIF
([Schulferien] ne "none" ##Heute Schulfrei
and [Schulferien:tomorrow] ne "none" ## morgen Schulfrei
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert
and [[RolloWEVorne]-23:32])
(set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize)
DOELSE
(set Rollo.Vorne pct 15, set Rollo.Seite pct 25, set Do_RolloSeiteSchatten disable, set Do_RolloVorneSchatten disable)
NAME Ti_RolloVorneDoelse
NR 957
NTFY_ORDER 50-Ti_RolloVorneDoelse
STATE fts_shutter_10
TYPE DOIF
READINGS:
2018-03-21 09:00:54 Device 1wire_Lux
2018-03-21 06:44:57 cmd 1
2018-03-21 06:44:56 cmd_count 1
2018-03-21 06:44:57 cmd_event Ti_RolloVorneDoelse
2018-03-21 06:44:57 cmd_nr 1
2018-03-21 09:00:54 e_1wire_Lux_Helligkeit 235.829
2018-03-21 06:43:41 mode enabled
2018-03-21 06:44:57 state fts_shutter_10
2018-03-21 06:43:42 timer_01_c01 22.03.2018 06:35:00
2018-03-21 06:43:42 timer_02_c01 21.03.2018 22:00:00
2018-03-21 06:43:42 timer_03_c02 22.03.2018 06:35:00
2018-03-21 06:43:42 timer_04_c02 21.03.2018 23:31:00
2018-03-21 06:43:42 timer_05_c03 21.03.2018 08:30:00
2018-03-21 06:43:42 timer_06_c03 21.03.2018 22:00:00
2018-03-21 06:43:42 timer_07_c04 21.03.2018 08:30:00
2018-03-21 06:43:42 timer_08_c04 21.03.2018 23:32:00
2018-03-21 08:40:57 wait_timer no timer
Regex:
condition:
0 InternalDoIf($hash,'Schulferien','STATE') eq "none" and ReadingValDoIf($hash,'Schulferien','tomorrow') eq "none" and ReadingValDoIf($hash,'1wire_Lux','Helligkeit') > InternalDoIf($hash,'1wireLuxRollo','STATE') and DOIF_time($hash,0,1,$wday,$hms)
1 InternalDoIf($hash,'Schulferien','STATE') eq "none" and ReadingValDoIf($hash,'Schulferien','tomorrow') ne "none" and ReadingValDoIf($hash,'1wire_Lux','Helligkeit') > InternalDoIf($hash,'1wireLuxRollo','STATE') and DOIF_time($hash,2,3,$wday,$hms)
2 InternalDoIf($hash,'Schulferien','STATE') ne "none" and ReadingValDoIf($hash,'Schulferien','tomorrow') eq "none" and ReadingValDoIf($hash,'1wire_Lux','Helligkeit') > InternalDoIf($hash,'1wireLuxRollo','STATE') and DOIF_time($hash,4,5,$wday,$hms)
3 InternalDoIf($hash,'Schulferien','STATE') ne "none" and ReadingValDoIf($hash,'Schulferien','tomorrow') ne "none" and ReadingValDoIf($hash,'1wire_Lux','Helligkeit') > InternalDoIf($hash,'1wireLuxRollo','STATE') and DOIF_time($hash,6,7,$wday,$hms)
days:
devices:
0 Schulferien 1wire_Lux 1wireLuxRollo
1 Schulferien 1wire_Lux 1wireLuxRollo
2 Schulferien 1wire_Lux 1wireLuxRollo
3 Schulferien 1wire_Lux 1wireLuxRollo
all Schulferien 1wire_Lux 1wireLuxRollo
do:
0:
0 set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize
1:
0 set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize
2:
0 set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize
3:
0 set Rollo.Vorne on, set Rollo.Seite on, set Do_RolloSeiteSchatten initialize, set Do_RolloVorneSchatten initialize
4:
0 set Rollo.Vorne pct 15, set Rollo.Seite pct 25, set Do_RolloSeiteSchatten disable, set Do_RolloVorneSchatten disable
helper:
DOIF_Readings_events
DOIF_eventas
event SolareEinstrahlung: 147.720
globalinit 1
last_timer 8
sleepdevice timer_7
sleepsubtimer 0
sleeptimer -1
timerdev 1wire_Lux
timerevent SolareEinstrahlung: 147.720
triggerDev 1wire_Lux
timerevents:
SolareEinstrahlung: 147.720
timereventsState:
SolareEinstrahlung: 147.720
triggerEvents:
SolareEinstrahlung: 147.720
triggerEventsState:
SolareEinstrahlung: 147.720
internals:
0 Schulferien:STATE 1wireLuxRollo:STATE
1 Schulferien:STATE 1wireLuxRollo:STATE
2 Schulferien:STATE 1wireLuxRollo:STATE
3 Schulferien:STATE 1wireLuxRollo:STATE
all Schulferien:STATE 1wireLuxRollo:STATE
interval:
0 -1
1 0
2 -1
3 2
4 -1
5 4
6 -1
7 6
itimer:
all Rollo8Morgens RolloWEVorne
localtime:
0 1521696900
1 1521666000
2 1521696900
3 1521671460
4 1521617400
5 1521666000
6 1521617400
7 1521671520
readings:
0 Schulferien:tomorrow 1wire_Lux:Helligkeit
1 Schulferien:tomorrow 1wire_Lux:Helligkeit
2 Schulferien:tomorrow 1wire_Lux:Helligkeit
3 Schulferien:tomorrow 1wire_Lux:Helligkeit
all Schulferien:tomorrow 1wire_Lux:Helligkeit
realtime:
0 06:35:00
1 22:00:00
2 06:35:00
3 23:31:00
4 08:30:00
5 22:00:00
6 08:30:00
7 23:32:00
time:
0 [Rollo8Morgens]
1 22:00:00
2 [Rollo8Morgens]
3 23:31:00
4 [RolloWEVorne]
5 22:00:00
6 [RolloWEVorne]
7 23:32:00
timeCond:
0 0
1 0
2 1
3 1
4 2
5 2
6 3
7 3
timer:
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
timers:
0 0 1
1 2 3
2 4 5
3 6 7
trigger:
triggertime:
1521666000:
localtime 1521666000
hash:
1521671460:
localtime 1521671460
hash:
1521671520:
localtime 1521671520
hash:
1521696900:
localtime 1521696900
hash:
uiState:
uiTable:
Attributes:
cmdState fts_shutter_10|fts_shutter_10|fts_shutter_10|fts_shutter_10|fts_shutter_100
disable 0
group 01 Timer
repeatsame 1:1:1:1:1
room DOIF,Jalousien
timerWithWait 1
wait 0:0:900:900:900
Für mich ist die Helligkeit für kurze Zeit unter Schwellenwert gegangen (dann DOELSE = cmd_5), und dann wieder rüber (dann cmd_1)
Gute Idee, hatte ich auch dran gedacht, aber kann ich widerlegen....
2018-03-20_19:39:04 1wire_Lux Helligkeit: 4.071
2018-03-21_06:20:41 1wire_Lux Helligkeit: 8.642
2018-03-21_06:25:42 1wire_Lux Helligkeit: 13.342
2018-03-21_06:30:50 1wire_Lux Helligkeit: 18.198
2018-03-21_06:35:49 1wire_Lux Helligkeit: 20.460
2018-03-21_06:40:35 1wire_Lux Helligkeit: 26.185
2018-03-21_06:45:51 1wire_Lux Helligkeit: 39.627
2018-03-21_06:50:52 1wire_Lux Helligkeit: 53.324
2018-03-21_06:55:55 1wire_Lux Helligkeit: 78.674
2018-03-21_07:00:48 1wire_Lux Helligkeit: 75.128
2018-03-21_07:05:45 1wire_Lux Helligkeit: 97.736
2018-03-21_07:10:51 1wire_Lux Helligkeit: 120.150
2018-03-21_07:15:47 1wire_Lux Helligkeit: 106.213
2018-03-21_07:20:48 1wire_Lux Helligkeit: 159.512
2018-03-21_07:25:48 1wire_Lux Helligkeit: 175.641
2018-03-21_07:30:42 1wire_Lux Helligkeit: 235.164
2018-03-21_07:56:01 1wire_Lux Helligkeit: 217.291
2018-03-21_08:01:03 1wire_Lux Helligkeit: 235.174
2018-03-21_10:46:19 1wire_Lux Helligkeit: 236.233
Dein 1wire_Lux Helligkeit meldet fleißig jede 5. Minute etwas, und dann ab 7:30 nicht mehr?
Was ist der Schwellenwert?
Korrekt, nur noch bei event-on-change-reading. Sonst habe ich zu Logs zu voll.
Schwellenwert ist 5.5
Ich hatte ein bisschen zu schnell gelesen.
Dein DOIF sagt aber :
2018-03-21 06:44:57 cmd 1
2018-03-21 06:44:56 cmd_count 1
2018-03-21 06:44:57 cmd_event Ti_RolloVorneDoelse
2018-03-21 06:44:57 cmd_nr 1
2018-03-21 06:43:41 mode enabled
Das heisst, er befindet sich seit 6:45 Uhr auf State "cmd_1" und hat sich seitdem nicht bewegt. Warum sagst Du jetzt:
ZitatUm 08:45 wollten die Rollos wieder runter. Auslöser war Timer 5.
?
Er hat zwar den Timer gemerckt (ich vermute RolloWEVorne = 8:45?), hat aber den Status nicht geändert. Sind die Rollos wirklich runter gegangen???
Hi,
erstmal danke für Deine Zeit&Analyse.
Vorweg: Ja, gestern sind sie runtergegangen.
2018-03-20_06:31:51 Ti_RolloVorneDoelse wait_timer: 20.03.2018 06:46:51 cmd_5 1wire_Lux
2018-03-20_06:35:00 Ti_RolloVorneDoelse wait_timer: no timer
2018-03-20_06:35:00 Ti_RolloVorneDoelse cmd_count: 1
2018-03-20_06:35:01 Ti_RolloVorneDoelse cmd_nr: 1
2018-03-20_06:35:01 Ti_RolloVorneDoelse cmd: 1
2018-03-20_06:35:01 Ti_RolloVorneDoelse cmd_event: timer_1
2018-03-20_06:35:01 Ti_RolloVorneDoelse fts_shutter_10
2018-03-20_08:45:01 Ti_RolloVorneDoelse cmd_count: 1
2018-03-20_08:45:02 Ti_RolloVorneDoelse cmd_nr: 5
2018-03-20_08:45:02 Ti_RolloVorneDoelse cmd: 5
2018-03-20_08:45:02 Ti_RolloVorneDoelse cmd_event: timer_7
2018-03-20_08:45:02 Ti_RolloVorneDoelse fts_shutter_100
2018-03-20_08:47:24 Ti_RolloVorneDoelse cmd_count: 1
2018-03-20_08:47:25 Ti_RolloVorneDoelse cmd_nr: 1
2018-03-20_08:47:25 Ti_RolloVorneDoelse cmd: 1
2018-03-20_08:47:25 Ti_RolloVorneDoelse cmd_event: 1wire_Lux
2018-03-20_08:47:25 Ti_RolloVorneDoelse fts_shutter_10
Anbei der gestriger LogEintrag aus dem DOIF-Log
und hier vom Rollo-Log:
2018-03-20_06:35:00 Rollo.Vorne set_on
2018-03-20_06:35:01 Rollo.Vorne 15
2018-03-20_06:35:19 Rollo.Vorne on
2018-03-20_07:06:30 Rollo.Vorne set_on
2018-03-20_07:06:32 Rollo.Vorne on
2018-03-20_08:45:01 Rollo.Vorne set_15
2018-03-20_08:45:02 Rollo.Vorne on
2018-03-20_08:45:17 Rollo.Vorne 15
2018-03-20_08:47:24 Rollo.Vorne set_on
2018-03-20_08:47:26 Rollo.Vorne 15
2018-03-20_08:47:43 Rollo.Vorne on
Danach habe ich das 15minütige WAIT-Attribut eingebaut. Wie ich heute gesehen habe, hat es geholfen. Der Befehl zum runterfahren, wurde kurz danach vom Helligkeitstrigger wieder aufgehoben.
Auch heute wieder das gleiche Spiel.
Was habe ich denn falsch definiert ?
Aus dem https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Beispiel_B.29:_Zeitsteuerung
Beispiel C): Kombinierte Ereignis- und Zeitsteuerung
Wenn die aktuelle Uhrzeit in der angegebenen Zeitspanne liegt, ist die Zeitspanne wahr. Wenn dann auch die Helligkeit unter 40 sinkt, wird die gesamte
Bedingung wahr, weil Zeitspanne und Hellikeitsvergleich and(und) verknupft sind. Der zu diesem Bedingungszweig gehörende Befehl wird dann ausgeführt.
Das DOIF di_lamp alias Lampenlogik setzt dann einen Befehl zum Schalten der Lampe lamp ab. Der DOELSE-Zweig wird ausgeführt, wenn die Bedingung im ersten Zweig unwahr wird.
define di_lamp DOIF ([06:00-19:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)
Ich mache hier nichts anderes, nur mit weiteren DOELSEIF.
Es wird ausgeführt, obwohl die gesamte Bedingung UNWAHR ist....
Ich bitte um Gegenbeweise....
Ich würde erstmal timerWithWait, wait und repeatsame Attribute löschen, und dann gucken, wie / wann er schaltet.
Zeig mal auch bitte ein "list 1wireLuxRollo" und ein "list Rollo8Morgens", da die in deinem DOIF auch triggern
Büdde:
Internals:
NAME Rollo8Morgens
NR 1049
STATE 06:35
TYPE dummy
READINGS:
2018-03-19 07:29:00 state 06:35
Attributes:
fm_type state
group DOIF
room Jalousien,Schwellenwerte
setList state:06:35,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:30,10:00,10:30
webCmd state:time
Internals:
NAME 1wireLuxRollo
NR 826
STATE 5.5
TYPE dummy
READINGS:
2017-06-08 19:59:01 state 5.5
Attributes:
fm_type state
group DOIF
room Jalousien,Schwellenwerte
setList state:0,5.5,6,7,8,9,10,11,12,13,14,15,15,17,18,19,20,21,25,50,60,70
webCmd state
Internals:
NAME RolloWEVorne
NR 822
STATE 08:45
TYPE dummy
READINGS:
2018-03-22 11:06:22 state 08:45
Attributes:
fm_type state
group DOIF
room Jalousien,Schwellenwerte
setList state:06:01,06:15,06:30,06:35,06:40,06:45,06:50,06:55,07:01,07:05,07:10,07:15,07:20,07:25,07:30,07:45,08:01,08:15,08:30,08:45,09:01,09:15,09:30,09:45,10:01,10:15,10:30,10:45,11:01,11:15,11:30,11:45,12:01
webCmd state:time
Ohne die Attribute läuft der Timer den ganzen Tag weil der Helligkeitssensor den ganzen Tag triggert, und Timerwithwait brauche ich, damit das wait-Attribut auch immer funktioniert.
Ohne wait, schaltet er die Rollos ohne Verzögerung, hab ich eine Woche lang mich geärgert
Habe ich alles schon durchprobiert.
Und die Dummys nutze ich als Variablen zum schnellen ändern ohne die Def ändern zu müssen. Triggern tun die nicht.
Zitatdie Dummys nutze ich als Variablen zum schnellen ändern ohne die Def ändern zu müssen. Triggern tun die nicht.
Die Triggern doch... sobald Du die änderst. Deswegen wollte ich ein list davon haben, um zu gucken, wann die sich letztes Mal geändert haben.
Wenn Du möchtest, dass die nicht triggern, musst Du [?dummy] statt [dummy] in der entspr. Bedingung schreiben.
Zitatläuft der Timer den ganzen Tag weil der Helligkeitssensor den ganzen Tag triggert
Ja, und? Das etwas triggert, bedeutet nicht, dass eine Bedingung wahr bzw. nicht mehr wahr wird. Ohne doalways bleibt dann der DOIF im vorherigen Zustand, wenn die Bedingungen sich nicht geändert haben, und kein Befehl wird ausgeführt. Wenn die Bedingungen von den verschiedenen Zweige sich gegenseitig ausschliessen, solltest Du kein Problem haben. Das war nicht der Fall mit deinem "OR" DOIF, aber mit diesem "DOELSEIF" Version ist es doch so.
ZitatOhne wait, schaltet er die Rollos ohne Verzögerung, hab ich eine Woche lang mich geärgert
Das war nur für ein Test. Das wait kannst Du danach wieder einbauen. Die andere aber m.A. nicht.
Das triggern müllt mir aber die Logs voll :)
Die Stati in den Dummys muss ich nur selten ändern, dann gehts aber so schneller.
Eine Erklärung für das schalten haben wir aber immer noch nicht.
Ich kann Dir mal mein Test-DOIF schicken, da will "er" auch schalten obwohl Bedingung=False.
Zitat von: Bartimaus am 23 März 2018, 15:11:31
Das triggern müllt mir aber die Logs voll :)
Die Stati in den Dummys muss ich nur selten ändern, dann gehts aber so schneller.
Eine Erklärung für das schalten haben wir aber immer noch nicht.
Ich kann Dir mal mein Test-DOIF schicken, da will "er" auch schalten obwohl Bedingung=False.
Ich bin mir sicher, dass die Bedingung nicht falsch ist, sonst wäre Perl falsch ;)
Dein Test-DOIF:
define di_test DOIF ([Schulferien] ne "none" ##Heute Schulfrei\
and [Schulferien:tomorrow] ne "none" ## morgen Schulfrei\
and [1wire_Lux:Helligkeit] > [1wireLuxRollo] ## wenn heller als Schwellenwert\
and [[RolloWEVorne]-23:32]) {Log 3,"[Schulferien] [Schulferien:tomorrow] [1wire_Lux:Helligkeit] [1wireLuxRollo"}
Zitat von: Damian am 23 März 2018, 15:40:41
Ich bin mir sicher, dass die Bedingung nicht falsch ist, sonst wäre Perl falsch ;)
Danke für die Bestätigung.... hab schon echt an mir gezweifelt.... ::)
Test-DOIF ist angelegt..... unnu ?
Neuer Ansatz:
Ich habe gesehen, das durch ein initialisieren eines DOIFs nicht alle Readings von Devices gelistet werden, die in der Bedingung aufgeführt sind.
Erst wenn das Device neu getriggert wird, erscheint es auch als Reading im DOIF.
Kann es sein, das dadurch die Bedingung ignoriert wird ? Weil im Moment rennen bei mir wieder DOIFs zu denen die Bedingung eines Devices = false ist
Zitat von: Bartimaus am 16 Mai 2018, 15:28:12
Ich habe gesehen, das durch ein initialisieren eines DOIFs nicht alle Readings von Devices gelistet werden, die in der Bedingung aufgeführt sind.
Erst wenn das Device neu getriggert wird, erscheint es auch als Reading im DOIF.
Das ist unwichtig, da ein DOIF (wie im allgemein FHEM) Ereignis-gesteuert ist. Das heisst: er reagiert auf Trigger. Erst wenn etwas triggert, werden die entspr. Bedingungen bewertet.
Zitat
Kann es sein, das dadurch die Bedingung ignoriert wird ? Weil im Moment rennen bei mir wieder DOIFs zu denen die Bedingung eines Devices = false ist
Zeig ein "list" des DOIFs, wenn es sich im ungewünschtem Zustand befindet.
Und ein DOIF "rennt" nicht, es reagiert auf Ereignisse, bewertet dann die Bedingungen und abhängig davon führt Befehle aus. Dann "schläft" es bis zum nächsten Trigger. In deinem oberen DOIF sind die Triggers:
Schulferien:STATE 1wireLuxRollo:STATE und dazu die Zeitperioden. Solange Schulferien:STATE oder 1wireLuxRollo:STATE sich nicht ändern, und du nicht eine Anfangszeit oder eine Endezeit erreichst, passiert NICHTS.