[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[CoolTux]

Hallo Zusammen,

ich lese schon seit geraumer Zeit mit und habe auch bereits auf meinen Testsystem die Version 0.4.0.9 installiert und soweit meine Devices eingefügt.
Sieht gut aus was Ihr hier gemacht habt. Gute Arbeit.
Bis jetzt nutze ich auf meinem Live-System eine von mir angepasste Version von Cluni's "Rollladensteuerung für HM/ROLLO inkl. Abschattung und Komfortfunktionen in Perl".

Meine Device-Konstellation ist etwas schwierig, deshalb waren auch damals bei Clunis Code Anpassungen nötig.
Ich lese meine realen Up- und Down- Taster über "230VACto5VDC"-High/Low-Wandler ein, welche über "PCF8574"-Module mittels I2C am RaspberryPI angeschlossen sind.
In Fhem nutze ich neben den Modulen: RPII2C, I2C_PCF8574 das 44_Taster.pm um jeweils für Up und Down drei Zustände zu ermöglichen:
1. SHORT-CLICK    = öffnet / schließt den Rollladen komplett, und sperrt den Rollo für automatische Fahrten (Manual Mode ON)
2. LONG-CLICK     = öffnet / schließt den Rolladen solange der Taster gedrückt wird und sperrt den Rollo für automatische Fahrten (Manual Mode ON). Beim loslassen stop.
3. DOUBLE-CLICK = Reset des Rollos in den Automatik Modus (Manual Mode OFF).

Diese Funktionalität habe ich beim aktuelle ASC mittels 99_myUtils.pm Skript und eines Notifies nachgebildet.

Um die Funktionalität 3 (Reset des Rollos in den Automatik Modus) zu realisieren, würde ich gerne wissen wie ich das Attribut "ASC_BlockingTime_afterManual" im diesem Fall umgehen kann. Soll heißen, wie kann die die "Warte"-Zeit an einem Rollo zurücksetzten?

Btw.
Für die Rollladen nutze ich das 44_ROLLO.pm Modul das wiederum über I2C_PCF8574 die "PCF8574"-Module und daran die Relais der "8-Kanal Relais Modul 5V/230V Optokoppler"-Platinen anspricht.
Als Fensterkontakte nutzte ich die "HM-SEC-SCo" welche über eine "FHEM2FHEM"-Verbindung von einem weiteren FHEM-System gespiegelt werden.

Ich hoffe ich konnte mein System soweit erklären, dass ihr mir hier weiterhelfen könnt.

Gruß
Rossi

Raus gelesen habe ich aus dem ganzen nur eine Frage

Soll heißen, wie kann die die "Warte"-Zeit an einem Rollo zurücksetzten?

Die Antwort ist einfach. Gar nicht. Man kommt von aussen nicht an die Informationen ran oder kann diese manipulieren.

[kjmEjfu]

Ich habe jetzt einige seltsame Dinge im Zusammenhang mit der Beschattung bemerkt.
Macht es sie die zu reporten oder lieber erstmal auf die nächste Version warten und dann schauen, ob die dann überhaupt noch enthalten sind?

[CoolTux]

Ich verwende die Beschattung sehr intensiv. Einzig das Problem das die Temperatur nicht Beachtung findet ist mir in der aktuellen stabilen Version bekannt.

Was ist Dir denn noch so auf gefallen?

[kjmEjfu]

Ich verwende die Beschattung sehr intensiv. Einzig das Problem das die Temperatur nicht Beachtung findet ist mir in der aktuellen stabilen Version bekannt.

Was ist Dir denn noch so auf gefallen?

Irgendwas scheint bei den Winkeln nicht zu stimmen.
Sonnenhöhe war über dem Sollwert. Temperatur war über dem Sollwert. Helligkeit war über dem Sollwert. Der Winkel (also Ausrichtung minus linker Winkel) war noch erreicht, aber trotzdem wurde schon abgeschattet. Gleiches dann später an einem Fenster mit dem rechten Winkel, der war noch nicht erreicht, alle anderen Werte noch über dem Sollwert, trotzdem wurde die Beschattung beendet.

Und dann habe ich noch zwei Fenster, bei denen die Beschattung gar nicht ausgelöst hat. Bin aber trotz Verbose 5 (im ASC gesetzt) nicht schlau daraus geworden, wieso die Abschattung nicht ausgelöst hat. Einziger Unterschied zu den Fenstern, die funktioniert haben, war ein etwas kleinerer linker Winkel und eine höhere Sonnenhöhe, die aber auch überschritten war.

Wäre cool ein Verbose-Level nur für die Abschattung zu haben, aus dem man dann ableiten kann, wieso die Beschattung gestartet, nicht gestartet, beendet, nicht beendet wurde Dann könnte ich besseres Feedback geben.

[CoolTux]

Irgendwas scheint bei den Winkeln nicht zu stimmen.
Sonnenhöhe war über dem Sollwert. Temperatur war über dem Sollwert. Helligkeit war über dem Sollwert. Der Winkel (also Ausrichtung minus linker Winkel) war noch erreicht, aber trotzdem wurde schon abgeschattet. Gleiches dann später an einem Fenster mit dem rechten Winkel, der war noch nicht erreicht, alle anderen Werte noch über dem Sollwert, trotzdem wurde die Beschattung beendet.

Und dann habe ich noch zwei Fenster, bei denen die Beschattung gar nicht ausgelöst hat. Bin aber trotz Verbose 5 (im ASC gesetzt) nicht schlau daraus geworden, wieso die Abschattung nicht ausgelöst hat. Einziger Unterschied zu den Fenstern, die funktioniert haben, war ein etwas kleinerer linker Winkel und eine höhere Sonnenhöhe, die aber auch überschritten war.

Wäre cool ein Verbose-Level nur für die Abschattung zu haben, aus dem man dann ableiten kann, wieso die Beschattung gestartet, nicht gestartet, beendet, nicht beendet wurde Dann könnte ich besseres Feedback geben.

In der aktuellen Developer Version gibt es ein debug Attribut wo auch die Beschattung Recht ausführlich geloggt wird.

[Dersch]

Ich muss nochmal auf das Thema lockout hard mit inhibit kommen. Ich finde die Funktion eigentlich sehr gut (grade mit frechen 3 Jahre alten Jungs im Haus)  aber leider ist es momentan noch unbenutzbar.

Es ist zwar so, dass beim geöffneter Tür der Rollladenaktor (HM) zuverlässig ein inhibit set_on bekommt aber sehr unzuverlässig bzw gar kein ein inhibit set_off nach dem schließen der Tür. Das hat zur Folge, dass die Aktoren eigentlich gar nicht mehr auf die Taster reagieren und ich muss regelmäßig manuell ein inhibit set_off senden. Ist das Problem bekannt?

Grüße
Dirk

[CoolTux]

Hallo Dirk,

Eigentlich solle das keine Probleme machen. Ein set sollte immer gesendet werden, ausser bei tilted.
Taucht der entsprechende set Befehl nicht mal im Log auf? Also für den Rollladen?

[stefanpf]

Ich konnte das noch nicht beobachten...
(Einzige Ausnahme: wenn in der dev Version der Rollladen beim shading trotz geöffneter Tür herunterfährt bleibt der Knopf gesperrt.

Hast du eventuell ASC_BlockingTime_afterManual an der Tür definiert und eventuell vorher irgendwann mal manuell gefahren?
Ich denke da gerade an die if Abfrage in Zeile 774

[Dersch]

Hallo Dirk,

Eigentlich solle das keine Probleme machen. Ein set sollte immer gesendet werden, ausser bei tilted.
Taucht der entsprechende set Befehl nicht mal im Log auf? Also für den Rollladen?

Richtig, es passiert meistens einfach gar nichts. Und der Aktor bleibt auf inhibit set_on stehen.

[Dersch]

Ich konnte das noch nicht beobachten...
(Einzige Ausnahme: wenn in der dev Version der Rollladen beim shading trotz geöffneter Tür herunterfährt bleibt der Knopf gesperrt.

Hast du eventuell ASC_BlockingTime_afterManual an der Tür definiert und eventuell vorher irgendwann mal manuell gefahren?
Ich denke da gerade an die if Abfrage in Zeile 774

Nein das habe ich nicht gesetzt.

[Dersch]

War gelogen da ist doch was im log

Code Auswählen Erweitern

00:07:44 3: CUL_HM set TeLichtKueche off
2019.04.18 00:07:44 1: PERL WARNING: Argument "set_off" isn't numeric in division (/) at (eval 997981) line 1.
2019.04.18 00:07:44 3: CUL_HM set KuRolladenTuer inhibit off
2019.04.18 00:07:44 1: PERL WARNING: Argument "set_off" isn't numeric in division (/) at (eval 997988) line 1.
2019.04.18 00:07:44 1: PERL WARNING: Argument "set_off" isn't numeric in division (/) at (eval 997999) line 1.
2019.04.18

[kjmEjfu]

Ich muss nochmal auf das Thema lockout hard mit inhibit kommen. Ich finde die Funktion eigentlich sehr gut (grade mit frechen 3 Jahre alten Jungs im Haus)  aber leider ist es momentan noch unbenutzbar.

Es ist zwar so, dass beim geöffneter Tür der Rollladenaktor (HM) zuverlässig ein inhibit set_on bekommt aber sehr unzuverlässig bzw gar kein ein inhibit set_off nach dem schließen der Tür. Das hat zur Folge, dass die Aktoren eigentlich gar nicht mehr auf die Taster reagieren und ich muss regelmäßig manuell ein inhibit set_off senden. Ist das Problem bekannt?

kann ich nicht bestätigen.
Funktioniert bei mir äußerst zuverlässig. Nutze allerdings HMCCU nicht CUL_HM.

[Dersch]

War gelogen da ist doch was im log

Code Auswählen Erweitern

00:07:44 3: CUL_HM set TeLichtKueche off
2019.04.18 00:07:44 1: PERL WARNING: Argument "set_off" isn't numeric in division (/) at (eval 997981) line 1.
2019.04.18 00:07:44 3: CUL_HM set KuRolladenTuer inhibit off
2019.04.18 00:07:44 1: PERL WARNING: Argument "set_off" isn't numeric in division (/) at (eval 997988) line 1.
2019.04.18 00:07:44 1: PERL WARNING: Argument "set_off" isn't numeric in division (/) at (eval 997999) line 1.
2019.04.18

Ich habe es mir nochmal genauer angeschaut und das PERL Warning hat nichts mit dem inhibit off zu tun...

Aber nun verstehe ich erst recht nicht warum der Aktor zwar zuverlässig auf inhibit on gesetzt wird aber nicht mehr auf inhibit off wenn doch der Befehl abgesetzt wird.

[Karflyer]

Irgendwie stehe ich mit den brightness-attributen auf 'Kriegsfuß'. Ich habe die aktuelle dev-Version 0.5.99.1 im Einsatz.
Im Modul habe ich:
ASC_brightnessDriveUpDown
ASC_brightnessMaxVal
ASC_brightnessMinVal
Am Rolladendevice gibt es dann noch:
ASC_BrightnessSensor

Welche Werte können diese Attribute beinhalten? Bei dem ASC_BrightnessSensor hatte ich mal gelesen, dass der Wert in etwa so lauten könnte 'brightness_eastside:brightness 40:-1'?
Wie wirken die einzelnen Attribute, bzw, wie interagieren sie miteinander? Wie müssten die Werte für die einzelnen Attribute lauten, wenn der Rolladen über brightness gesteuert, Abends bei unterschreiten einer bestimmten Helligkeit zufahren soll?
Wäre schön wenn ich hier ein wenig Aufklärung bekomme.

Gruß
Stefan

[CoolTux]

Hallo Stefan,

Damit ich und andere nicht durcheinander kommen möchte ich Dich bitten den Post noch einmal hier
https://forum.fhem.de/index.php/topic,97976.0.html
ein zu tragen.