Stati in Bedingungen werden ignoriert, ich verstehe es nicht...

[Bartimaus]

??

Im Log steht doch

Code Auswählen Erweitern

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...

[viegener]

??

Im Log steht doch

Code Auswählen Erweitern

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?

[Bartimaus]

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

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.

[viegener]

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...

[amenomade]

Im 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:

Code Auswählen Erweitern

([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.

Code Auswählen Erweitern

[([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.

[Bartimaus]

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.

[amenomade]

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???

[Damian]

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)

[viegener]

Es sieht aber laut log so aus, als ob das DOIF-Modul erst um 9:00:11 wieder zur Überprüfung gekommen ist:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

([([RolloWEHinten]+[00:00:02])-23:02] and [RolloSteuerungHinten] eq "77")
inzwischen wahr, oder sehe ich das falsch?

[Damian]

Es sieht aber laut log so aus, als ob das DOIF-Modul erst um 9:00:11 wieder zur Überprüfung gekommen ist:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

([([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.

[Bartimaus]

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....

[Damian]

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.

[Bartimaus]

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 !!!

[viegener]

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:

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

[Bartimaus]

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