[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

[ChristianMUC]

Guten Morgen,

ich bekomme seit dem Update folgenden Fehler:

configfile: myASControl: unknown attribute ASC_autoShuttersControlShading. Type 'attr myASControl ?' for a detailed list.

Ist das versehentlich rausgeflogen, oder muss ich meine Config editieren?

Danke und Gruß

Christian

[CoolTux]

Guten Morgen,

ich bekomme seit dem Update folgenden Fehler:


Ist das versehentlich rausgeflogen, oder muss ich meine Config editieren?

Danke und Gruß

Christian

Es ist gewollt raus geflogen. Kannst also ruhigen Gewissens save drücken.
Man  aktiviert das Beschatten nun über

Code Auswählen Erweitern

set ASC_DEVICE controlShading on

[Loredo]

Was mir heute früh noch eingefallen ist: Ich weiß nicht, wen es sonst noch so betrifft, aber ich habe an Fenstertüren 2 Sensoren und kombiniere sie per structure zu einem virtuellen threestate Sensor. Nun kann es aber wahrscheinlich vorkommen, dass die beiden Sensoren beim öffnen/schließen nicht immer exakt in der selben Reihenfolge melden bzw. sich der Status innerhalb von wenigen Sekunden 2x ändert. Wahrscheinlich führt das dann aber zu ungewolltem Verhalten bei ASC, weil eben das erste Event kommt, aber nicht den eigentlich aus Benutzersicht endgültigem Status entspricht.


Ich hab noch nicht nachgesehen, ob sich das Status Event der structure irgendwie verzögern lässt oder ob man da noch komplizierter mit einem DOIF Timer dazwischen arbeite müsste oder sowas, um das zu entprellen.


Falls man das in ASC lösen wollte, müsste man wahrscheinlich nicht nur die Verzögerung einbauen (da ist doch auch schon was, eigentlich?), sondern man müsste vor allem das Event nur als Trigger nehmen und nicht mehr auch als Dateneingabe. Sprich: Event triggert, aber dann wird der Status nochmals über ReadingsVal explizit ausgelesen, weil er sich ja, wenn mehrere fhem.pl Loops dazwischen liegen, geändert haben könnte.


Vielleicht gibt das ja auch noch Ideen für mögliche Fehlerquellen, Marko.

[CoolTux]

Was könnte denn da Deiner Meinung nach für ein Event kommen welches nicht "erwünscht" ist?

[Typ1er]

Das man warten muss ist seltsam.

-Fenster ist Nachts auf Kipp, jetzt möchte ich es öffnen.
-Fenster zu, Rollladen fährt runter
-jetzt muss man warten bis es zu ist,  statt das Fenster gleich zu öffnen.


Wenn das Fenster Nachts auf öffnen steht, und man es im Anschluss gleich auf Kipp stellen will muss man den zufahren Befehl abwarten.

Ich sehe es so, Nachts kann die Position gerne sofort angefahren werden, gerne 10 Sekunden auch verzögert auf, dann kann man im Bad das Fenster öffnen und in Ruhe verlassen, ohne vorher gesehen zu werden.

[Beta-User]

Hmm,

Anmerkung dazu: Manche Kontakte (z.B. HM) kennen eine interne Verzögerung, um den von Typ1er geschilderten Effekt zu vermeiden; bei allen anderen fände ich es gut, eine kurze Zeit zuzuwarten, bis eine Reaktion (bzw. die Prüfung des Werts samt Reaktion) erfolgt. Es reichen in der Regel wenige Sekunden (meine HM haben in der Regel einen delay von 2 Sek. drin).

Ich habe aber auch welche, die gleich reagieren, und bei denen soll dann auch direkt die Rolllade hoch. Vorschlag: Verzögerung optional einstellbar, als weitere Angabe zum Fensterkontakt; Format:

Code Auswählen Erweitern

attr ASC_WindowRec <device>[:delay in sek]

[CoolTux]

Hmm,

Anmerkung dazu: Manche Kontakte (z.B. HM) kennen eine interne Verzögerung, um den von Typ1er geschilderten Effekt zu vermeiden; bei allen anderen fände ich es gut, eine kurze Zeit zuzuwarten, bis eine Reaktion (bzw. die Prüfung des Werts samt Reaktion) erfolgt. Es reichen in der Regel wenige Sekunden (meine HM haben in der Regel einen delay von 2 Sek. drin).

Ich habe aber auch welche, die gleich reagieren, und bei denen soll dann auch direkt die Rolllade hoch. Vorschlag: Verzögerung optional einstellbar, als weitere Angabe zum Fensterkontakt; Format:

Code Auswählen Erweitern

attr ASC_WindowRec <device>[:delay in sek]

Meinst Du ein verzögertes fahren nach dem Fensterkontakt Event oder generell eine verzögerte Auswertung des Fensterkontakt Events. Zweites ist eine Sau Arbeit wegen nicht blockieren von FHEM.

[Beta-User]

Da das Event eventuell "unsauber" bzw. erst vorläufig ist, benötigen wir m.E. letzteres, auch wenn es Aufwand macht.
Aber das sollte doch begrenzt sein, oder? Einen (benannten) InternalTimer (erst canceln, dann) aufrufen und dann "ganz normal" die Auswertung machen. Kann halt sein, dass man nicht einfach das Event weitergeben kann, aber soooo schwierig ist das auch nicht, oder?

[CoolTux]

Es ist schon ein wenig was zu tun dafür. Damit Du einen InternenTimer wieder canceln kannst benötigst Du eine Eindeutigkeit. Man kann hier einen Hash für nehmen in dem man dann auch gleich Daten drin ab legt. Auf jeden Fall muss eine weitere Funktion her da InternalTimer nur Funktionen mit einem Argument aufrufen kann.
Man kann sich das aber gerne einmal anschauen. Wenn das derzeitig umgesetzte sauber läuft.

[Beta-User]

Vielleicht sollte man den Funktionsaufruf mit dem Event (und dem eventauslösenden Gerät) machen - dann kann man vergleichen oder eben mit dem aktuellen Wert weitermachen.

[Typ1er]

Ich mache zb nach dem Duschen Baden das Fenster auf, nur beim auffahren verzögert, dann kann man nackig noch das Bad verlassen.

[majestro84]

Mir ist heute noch aufgefallen das wenn das Fenster am Abend gekippt ist fährt das Rollo in die Lüftungsposition es bleibt dort auch die ganze Nacht morgens dann wird normal hochgefahren.
Jetzt schließe ich das Fenster und die Rollade holt das Schließen der Nacht nach. Das sollte eigentlich ja nicht passieren. Rolllade wird mit Astro gesteuert.
Gruß Alex

[eurofinder]

Ist die Commandref bezüglich

set ASC_DEVICE controlShading on

noch nicht aktualisiert oder liegt nur bei mir hier ein "Fehler" vor?

Gruß
eurofinder

[CoolTux]

Mir ist heute noch aufgefallen das wenn das Fenster am Abend gekippt ist fährt das Rollo in die Lüftungsposition es bleibt dort auch die ganze Nacht morgens dann wird normal hochgefahren.
Jetzt schließe ich das Fenster und die Rollade holt das Schließen der Nacht nach. Das sollte eigentlich ja nicht passieren. Rolllade wird mit Astro gesteuert.
Gruß Alex

Normal hoch gefahren bedeutet das Du es von Hand gemacht hast? Oder ist das Rolllo nach Astro hoch gefahren?
Wenn es nach Astro hoch gefahren ist kannst Du es diese Nacht noch mal machen bitte und bevor Du dann am Ende morgen früh das Fenster schließt, also nach dem Astro hoch fahren schau bitte was

Code Auswählen Erweitern

{ FHEM::AutoShuttersControl::IsDay('RolloName') }
aus spuckt

[CoolTux]

Ist die Commandref bezüglichnoch nicht aktualisiert oder liegt nur bei mir hier ein "Fehler" vor?

Gruß
eurofinder

Noch nicht aktuell. Der liebe FunkOdyssey baut da gerade dran rum und macht sie schick für uns.