Hallo CoolTux,
ist folgendes Szenario mit ASC nicht möglich?
Es ist per brigthness hell um 7:13. Ein Rollladen soll erst um 7:15 fahren und nicht vorher. Aber, wenn es schon hell ist auch nicht später. Sollte es aber nach 7:15 hell sein, soll auch sofort gefahren werden. Ich hatte gehofft, dass ich das mit folgenden Parametern hinbekomme:
attr OG.kl.RO.KlRollladen ASC_Time_Up_Early 07:15
attr OG.kl.RO.KlRollladen ASC_Time_Up_Late 08:30
attr OG.kl.RO.KlRollladen ASC_Up brightness
So fährt der Rollladen aber nur dann nach brigthness, wenn diese nach 7:15 und vor 8:30 hell ergibt.Um 7:15 wird nicht gefahren, wenn es vorher hell wurde. In dem Fall wird erst um 8:30 gefahren.
Ggf. Habe ich einen Denkfehler oder ist das logische Szenario nicht möglich?
Dadurch das du bei ASC_Time... Perl Code verwendet kannst, solltest du das abbilden können.
Ah. Wo du es sagst... das habe ich tatsächlich mal irgendwo gelesen. Aber in der Doku steht es nicht oder habe ich es da übersehen?
Danke für den Schubs.
Ich hatte gerade einfach im ASC device unter device specific Help geschaut. Das müsste auch so in der commandref stehen.
Hmh. Die englische Commandref gibt das nicht her. Eigentlich sollte die maßgeblich sein. Ich schaue nur in die englische Version....
Naja. Danke.
Ja stimmt sollte eigentlich so sein. Aber ich glaube das sich @CoolTux auf der deutschen Seite wohler fühlt was ich so verfolgen konnte. ;D
Hauptsache es könnte dir geholfen werden. 8)
Die englische ist bisher etwas "stiefmütterlich" behandelt worden und wurde immer mal wieder (aber nicht konsequent) aus der DE-Fassung abgeleitet.
Leider ist aber die auch in zwei Aspekten unklar:
- Wenn Perl-Code, würde ich annehmen, dass das einmalig greift, also bei der Ermittlung der (nächsten?) Fahrzeit. Da ist aber die Helligkeit noch anders...
- Es ist auch unklar, warum nicht zur ersten Ausführungszeit (lesend) geschaut wird, wie der Helligkeitswert ist. Anscheinend wird hier immer auf einen trigger gewartet... Das steht vielleicht irgendwo (?)
Ja. Geschickt ist es nicht. Mit Perl in Time_up_late kann man es einigermaßen hinbekommen. Schöner wäre, wenn bei schon erreichter brigthness, Time_up_Early die Fahrzeit wäre.
Jetzt wo du es sagst, ja eigentlich sollte das so funktionieren. Bin auf dem Handy unterwegs und hatte es nicht so richtig gelesen ::)
Hast du vielleicht roommates definiert? Vielleicht schickst du Mal ein paar lists.
Keine roommates. Keine anderen Einschränkungen. Im Grunde weiß ich was ich tue. Es ist bewusst einfach gehalten ohne roommates oder andere Parameter. Time_up_Early funktioniert jedoch bei Astro, so wie ich das sehe. Nur bei brigthness nicht.
Wie oft sendet denn dein brightness Sensor ein Event? Denn am Anfang hatte ich die Zeit auch zu groß gewählt und wenn kein event kommt reagiert ASC auch nicht.
Die Zeit sollte nicht das Problem sein, wenn Time_up_Early das Event ist. Es sei denn es ist tatsächlich nur event-basiert. Dann kommt ein neues Event erst bei neuer Helligkeit. Das würde aber auch heißen, dass time up early nur die Grenze markiert, wenn brigthness verwendet wird. Bei Astro ist das anders (von daher logisch, da hier kein Event kommt). Heißt auch, event on change entfernen würde das Problem abmildern, wenn auch nicht lösen. Es kann dann noch immer mindestens 6 Minuten zu spät sein.
Heißt also, kommt im Intervall zwischen early und late eine neue Helligkeit die größer ist als die eingestellte, wird gefahren? Das würde es erklären. So ist man jedoch vom Sensor abhängig oder man generiert künstlich Events. Ich beobachte das. Ich hätte gedacht, dass das brigthness Event nur einmal ausgewertet wird.
Eigentlich sollte bei Brightness das Rollo fahren sobald die Time_up_Early Zeit erreicht und der Brightness-sensor ein Event generiert mit einem Wert höher wie des Morgen-Wertes.
Danke. Das bestätigt das zuletzt vermutete. Ok. Das ist unter Umständen bei HM Sensoren ein recht langer Zeitraum nach time up early. Ich denke aber, dass ich da mit Perl gegensteuern könnte. Kannst du sagen, wann das Perl für Time up early überprüft wird? Ich nehme an bei der vorherigen Fahrt oder?
Zitat von: marvin78 am 06 November 2021, 09:20:42
Danke. Das bestätigt das zuletzt vermutete. Ok. Das ist unter Umständen bei HM Sensoren ein recht langer Zeitraum nach time up early. Ich denke aber, dass ich da mit Perl gegensteuern könnte. Kannst du sagen, wann das Perl für Time up early überprüft wird? Ich nehme an bei der vorherigen Fahrt oder?
Die Timer werden immer bei der Tag oder Nachtfahrt entsprechend neu gesetzt. Also Einmal Morgens nach der Tagfahrt wird für Abends und nächsten Morgen gesetzt und Abends nach der Nachtfahrt wird wieder für nächsten Tag Morgens und nächsten Tag Abends neu gesetzt.