"Earliest time" condition in clock timer rules does not seem to have an effect.

[nikipore]

Describe the bug

In the screenshot, there is a rule "W" in a clock timer node which triggers although the "earliest time" has not yet been reached – it should trigger no earlier than 18:30:10 local time, but it is 18:22 local time.

Screenshot

Expected behavior

The rule should only be triggered when the "earliest time" condition is true.

System information (please complete the following information):

• Node Version 2.2.0-beta3
• Node-Red Version 2.2.2

Additional context

The local time of the frontend (upper right corner) is the same as that of the Home Assistant backend (time sensor) up to a minute, cf. the second screenshot.

[Hypnos3]

Die Regel ist "bis". Das bedeutet von vorhergehender Regel (oder Mitternacht) bis zu der angegebenen Zeit geht diese Regel aktiv.

18:22 Uhr ist vor der angegebenen End-Zeit.

Dabei ist de Zeit zum Winkel 280, jedoch nicht vor 263 und nicht nach 280.
Das min/max macht in meinen Augen diesem Falle wenig Sinn.

Mit einem der nächsten Release kann man dann für die Regeln Anfang und Ende definieren. Aktuell geht nur eines von beiden.

[nikipore]

Ich wollte erreichen, dass ein Rechteck 263 <= Azimut <= 280 und 0 <= Zenit <= 17 als Schatten aufgefasst wird. Ich meine, ich hätte ursprünglich bis 280 frühestens ab 263 eingestellt, was nicht funktioniert hatte. Deshalb die redundante spätestens bis Bedingung. Redundant, dadurch aber nicht sinnlos – weshalb ich das Verhalten weiterhin für einen Bug halte.

Das ursprüngliche Setup (bis 280, frühestens ab 263) stelle ich nach, komme aber erst in 2 Wochen dazu (unterwegs ohne gescheites Device für Node-RED).

[nikipore]

Mit dem Tablet ging das rauswerfen der redundanten „spätestens bis“ Bedingungen ganz gut. Ergebnis: Die „frühestens ab“ Bedingungen sind immer noch wirkungslos.

Gescheite Screenshots kann ich erst im 2 Wochen liefern.

[Hypnos3]

Die Regel lautet nicht "frühestens ab", sondern "frühestens bis":

Hier liegt ein Verständnisproblem vor.
eine Bis Regel ist immer von der vorhergehenden bis Regel (wenn es keine gibt von Mitternacht) bis zur angegebenen Zeit aktiv. das frühestens/spätestens ändert daran nichts.

Vielleicht wird es klarer, wenn ich mal zeige, was zukünftig möglich ist:

Aktuell kann man über das DropDown bis/von nur zwischen den blauen ODER gelben Block wählen.
Eine Regel sit also generell nur eine bis ODER eine von Regel. Das frühestens/spätestens ändert daran nichts, sondern limitiert nur das von ODER bis.

[nikipore]

Ich bin wieder zuhause und stehe auf dem Schlauch. Beschrieben steht in der aktuellen Doku des clock-timer-Nodes:

Das verstehe ich so, dass die bis-Regeln der Reihe nach abgearbeitet werden und die erste gewinnt, deren Bedingung zutrifft. Von vorherigen Regeln steht da nichts, und es würde für mich auch keinen rechten Sinn ergeben. Und ich meine, das auch genauso aus dem (von mir extensiv mit recht komplexen Regeln genutzten) blind-control-Node zu kennen.

Ich habe reine "bis"-Regeln (das sollte "spätestens" heißen, nicht "frühestens", oder nicht?), die aber durch "frühestens ab"-Bedingungen eingeschränkt sind (ja, die "spätestens bis"-Bedingungen sind redundant). Der Text mit den "von"-Regeln ist also egal.

Damit (bis, aber frühestens ab und mit einem Elevationswinkel kleiner als) sollten sich gemäß der aktuellen Beschreibung wunderbar disjunkte Rechtecke aus dem Firmament schneiden lassen.

[Hypnos3]

Das verstehe ich so, dass die bis-Regeln der Reihe nach abgearbeitet werden und die erste gewinnt, deren Bedingung zutrifft. Von vorherigen Regeln steht da nichts, und es würde für mich auch keinen rechten Sinn ergeben. Und ich meine, das auch genauso aus dem (von mir extensiv mit recht komplexen Regeln genutzten) blind-control-Node zu kennen.

das ist so richtig verstanden.
Eine bis Regel ist von der vorhergehenden bis Regel bis zur angegebenen bis Zeit aktiv. Gibt es keine bis Regel dann von Mitternacht bis zur angegebenen Zeit.

Immer wenn eine Nachricht eingeht wird die gerade aktive Regel bestimmt und der zugehörige Payload dann ausgegeben. Zusätzlich wird auch ohne eingehende Nachricht regelmäßig (wenn Auto-trigger eingestellt ist) die aktive Regel bestimmt und die zugehörige Payload dann ausgegeben.
Es gibt noch eine Prüfung ob sich diese von der ausgegebene Payload vorhergehenden Payload unterscheidet und die Ausgabe unterdrückt, wenn es keinen Unterschied gibt.

Die bis Zeit der Regel wird wie folgt bestimmt:

• Es wird die bis Zeit bestimmt.
• Es wird die "frühestens" Zeit bestimmt. ist die "bis Zeit" vor der "frühesten Zeit", ist die "bis Zeit" gleich der "frühesten Zeit"
• Es wird die "spätestens" Zeit bestimmt. ist die "bis Zeit" nach der "spätestens Zeit", ist die "bis Zeit" gleich der "spätestens Zeit"

Damit macht die Angabe von

• "bis Zeit" bei Winkel 280
• "früheste bis Zeit" bei Winkel 263
• "späteste bis Zeit" bei Winkel 280
  keinen Sinn, weil sich da immer eine "bis Zeit" bei Winkel 280 ergibt. Das "frühestens" und "spätesten" ist dafür gedacht einem volatilen Zeitpunkt fixe Grenzen zu setzen.

Bei einer bis Zeit" bei Winkel 280 von 19:58 Uhr:

• Wenn es also keine Regel vor dieser Regel gibt, wird der Payload "W" dann halt zwischen Mitternacht und 19:58 Uhr, sobald der Sonnenhöhenwinkel <=17 ist ausgegeben.

Kann also damit auch 18:22 Uhr oder sonst wann vor 19:58 sein.

Will man sowas haben wie "in der Zeit zwischen Winkel 263 und Winkel 280", wenn der Sonnenhöhenwinkel <=17 ist etwas ausgeben, braucht man 2 Regeln:

• Regel 1 - bis Zeit bei Winkel 263 und Sonnenhöhenwinkel <=17 => Payload ""
• Regel 2 - bis Zeit bei Winkel 280 und Sonnenhöhenwinkel <=17 => Payload "W"

Zur Ausgabe eines Payload zu einem bestimmten Zeitpunkt ist der Inject-Enhanced Node auch gut geeignet.

[nikipore]

Hab's mit etwas Abstand nun nochmal nachvollzogen und jetzt kapiert, danke für die ausführliche Erläuterung.