[ASC] Morgendliche Fahrt primär nach brigthness

Begonnen von marvin78, 06 November 2021, 07:32:23

Vorheriges Thema - Nächstes Thema

marvin78

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?

xerion

Dadurch das du bei ASC_Time... Perl Code verwendet kannst, solltest du das abbilden können.
Ich würde mich  freuen, wenn du meinen Einladungscode für Tibber, der Stromanbieter, der dir hilft, deinen Stromverbrauch zu verstehen und zu reduzieren, nutzt: https://invite.tibber.com/5fc08jbs. So bekommen wir beide 50 Euro und 100 % Ökostrom / https://geld-fuer-eauto.de/ref/334561880

marvin78

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

xerion

Ich hatte gerade einfach im ASC device unter device specific Help geschaut. Das müsste auch so in der commandref stehen.
Ich würde mich  freuen, wenn du meinen Einladungscode für Tibber, der Stromanbieter, der dir hilft, deinen Stromverbrauch zu verstehen und zu reduzieren, nutzt: https://invite.tibber.com/5fc08jbs. So bekommen wir beide 50 Euro und 100 % Ökostrom / https://geld-fuer-eauto.de/ref/334561880

marvin78

Hmh. Die englische Commandref gibt das nicht her. Eigentlich sollte die maßgeblich sein. Ich schaue nur in die englische Version....

Naja. Danke.

xerion

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)
Ich würde mich  freuen, wenn du meinen Einladungscode für Tibber, der Stromanbieter, der dir hilft, deinen Stromverbrauch zu verstehen und zu reduzieren, nutzt: https://invite.tibber.com/5fc08jbs. So bekommen wir beide 50 Euro und 100 % Ökostrom / https://geld-fuer-eauto.de/ref/334561880

Beta-User

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 (?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

marvin78

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.

xerion

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.
Ich würde mich  freuen, wenn du meinen Einladungscode für Tibber, der Stromanbieter, der dir hilft, deinen Stromverbrauch zu verstehen und zu reduzieren, nutzt: https://invite.tibber.com/5fc08jbs. So bekommen wir beide 50 Euro und 100 % Ökostrom / https://geld-fuer-eauto.de/ref/334561880

marvin78

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.

xerion

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.
Ich würde mich  freuen, wenn du meinen Einladungscode für Tibber, der Stromanbieter, der dir hilft, deinen Stromverbrauch zu verstehen und zu reduzieren, nutzt: https://invite.tibber.com/5fc08jbs. So bekommen wir beide 50 Euro und 100 % Ökostrom / https://geld-fuer-eauto.de/ref/334561880

marvin78

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

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

marvin78

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?

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net