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

[CoolTux]

Hatte ich getestet die Tage. Ging.
Wird denn generell der Event vom Türkontakt erfasst?

[FunkOdyssey]

Hatte jemand heute zufällig auch das Problem, dass die Jalousien zum Zeitpunkt ASC_Time_Up_Late hochgefahren sind? Der Brightness-Wert wäre eigentlich schon zum Early-Zeitpunkt richtig gewesen. Dennoch fuhren alle Jalousien zum Late-Zeitpunkt hoch.

Ich meine, dass dieser Fehler erst nach der offiziellen 0.6 aufgetreten ist.

[kjmEjfu]

Hatte ich getestet die Tage. Ging.
Wird denn generell der Event vom Türkontakt erfasst?

ja, das sieht gut aus. Auch ASC reagiert drauf. Fährt trotzdem in die Abschattung (inhibit setzt ja leider nur den Schalter selbst außer Betrieb, lässt aber Steuerungskommandos zu).

Code Auswählen Erweitern

2019-04-30 20:36:09.381 HMCCUDEV HM_Rollo_EG_Wohnzimmer_Tuer_West inhibit off
2019-04-30 20:36:09.390 HMCCUDEV HM_Tuergriff_EG_Terrassentuer 1.STATE: closed
2019-04-30 20:36:09.390 HMCCUDEV HM_Tuergriff_EG_Terrassentuer control: closed
2019-04-30 20:36:09.390 HMCCUDEV HM_Tuergriff_EG_Terrassentuer closed
2019-04-30 20:36:09.390 HMCCUDEV HM_Tuergriff_EG_Terrassentuer hmstate: closed
2019-04-30 20:36:09.614 HMCCUDEV HM_Rollo_EG_Wohnzimmer_Tuer_West inhibit: unlocked
2019-04-30 20:36:09.614 HMCCUDEV HM_Rollo_EG_Wohnzimmer_Tuer_West lock: unlocked
2019-04-30 20:36:09.614 HMCCUDEV HM_Rollo_EG_Wohnzimmer_Tuer_West hmstate: open

[CoolTux]

Ja natürlich fährt es in die Abschattung. Das harte sperren ist ja nur für den Taster.

[FunkOdyssey]

Hatte jemand heute zufällig auch das Problem, dass die Jalousien zum Zeitpunkt ASC_Time_Up_Late hochgefahren sind? Der Brightness-Wert wäre eigentlich schon zum Early-Zeitpunkt richtig gewesen. Dennoch fuhren alle Jalousien zum Late-Zeitpunkt hoch.

Ich meine, dass dieser Fehler erst nach der offiziellen 0.6 aufgetreten ist.

Die einzige Änderung an den Zeiten war hier:
https://github.com/LeonGaultier/fhem-AutoShuttersControl/commit/ee20005806aa3231a3fa49ab3a184d274f311b98

Ich sehe nur keine einzige Änderung bzgl. "ASC_Time_Up_Late".

Keine einzige Jalousie hat im Reading "ASC_Time_DriveUp" den Early-Zeitpunkt stehen. Müsste aber nicht dann bereits die erste Prüfung durchgeführt werden?



Kann es sein, dass in diesem Hinweis im CommandRef-Teil das Attribut noch mehr beschrieben werden muss?:

"ACHTUNG!!! in Verbindung mit Brightness für ASC_Up muss die Uhrzeit kleiner sein wie die Uhrzeit aus ASC_Time_Up_Late"

Ist damit "ASC_Time_Up_WE_Holiday" gemeint?

[kjmEjfu]

Ja natürlich fährt es in die Abschattung. Das harte sperren ist ja nur für den Taster.

Es soll aber ja nicht abgeschattet werden, weil der Drehgriff nicht geschlossen war und somit der Aussperrschutz greifen müsste, wie es halt vor der 0.6.x funktioniert hat.
Der Ausschnitt aus dem Event-Log sollte ja nur zeigen, dass die Events vom Drehgriff generell gesendet, erkannt und von ASC auch verarbeitet werden (inhibit wurde aufgehoben, nach Schließen des Griffs).
Die Frage bleibt, wieso das Rollo automatisch abgeschattet hat, was es nicht hätte tun dürfen 

Gemäß commandref, sperrt hard ja Taster und Befehle durch ASC

Code Auswählen Erweitern

Stellt man global auf hard, wird bei entsprechender Möglichkeit versucht den Rollladen hardwareseitig zu blockieren. Dann ist [b]auch [/b]ein Fahren über die Taster nicht mehr möglich.

[CoolTux]

Kann es sein, dass in diesem Hinweis im CommandRef-Teil das Attribut noch mehr beschrieben werden muss?: Ist damit "ASC_Time_Up_WE_Holiday" gemeint?

Ja damit ist ASC_Time_Up_WE_Holiday in Verbindung mit Brightness gemeint.

[CoolTux]

Es soll aber ja nicht abgeschattet werden, weil der Drehgriff nicht geschlossen war und somit der Aussperrschutz greifen müsste, wie es halt vor der 0.6.x funktioniert hat.
Der Ausschnitt aus dem Event-Log sollte ja nur zeigen, dass die Events vom Drehgriff generell gesendet, erkannt und von ASC auch verarbeitet werden (inhibit wurde aufgehoben, nach Schließen des Griffs).
Die Frage bleibt, wieso das Rollo automatisch abgeschattet hat, was es nicht hätte tun dürfen 

Gemäß commandref, sperrt hard ja Taster und Befehle durch ASC

Code Auswählen Erweitern

Stellt man global auf hard, wird bei entsprechender Möglichkeit versucht den Rollladen hardwareseitig zu blockieren. Dann ist [b]auch [/b]ein Fahren über die Taster nicht mehr möglich.

Ah jetzt verstehe ich. Die Terrassetür war offen und das Rolllo hat sich geschlossen. Stimmt das sollte in der Tat nicht passieren.Habe eben mal geschaut. Für das Beschatten gibt es in der Tat noch keine Beachtung für offene Terrassentüren.

[Typ1er]

Ich bin es nochmal, heute wieder keine einzige gefahren verbose 4, hatte ich schon wieder rausgenommen, vorher ein paar Room-Bezeichnungen geändert

-Das Reading ,,ASC_Time_PrivacyDriveUp" müsste ja Down heißen es folgt ja auf ,,ASC_PrivacyDownTime_beforNightClose"
-Das Attribut ASC_Time_Up_Wochenende_Holiday fehlt.

Diese 2 Readings ,,ASC_Time_DriveDown, ASC_Time_DriveUp" zeigen ja momentan nur den Sunrise und Sunset Wert an, kannst du CoolTux die so erweitern das, die beiden Attribute  ,,ASC_Drive_Offset und ASC_Drive_OffsetStart" mit einbezogen werden, dann gerne auch mit Sekundenangabe. Dann sieht man die Absoluten Zeiten für Auf- und Abfahrt beginn. In meinem Doif vorher habe die Zeiten absolut ausgerechnet, und ich konnte der Frau die Werte übermitteln. Oder kann ich mir die Irgendwie anders anzeigen/ausrechen lassen?

[CoolTux]

Ich bin es nochmal, heute wieder keine einzige gefahren verbose 4, hatte ich schon wieder rausgenommen, vorher ein paar Room-Bezeichnungen geändert

-Das Reading ,,ASC_Time_PrivacyDriveUp" müsste ja Down heißen es folgt ja auf ,,ASC_PrivacyDownTime_beforNightClose"

Danke Dir das habe ich gefixt

-Das Attribut ASC_Time_Up_Wochenende_Holiday fehlt.

Das ist richtig, das gibt es auch gar nicht. Hat es nie gegeben. Konnte auch im Code oder Commandref sowas nicht finden. Wo hast Du das gelesen?

Diese 2 Readings ,,ASC_Time_DriveDown, ASC_Time_DriveUp" zeigen ja momentan nur den Sunrise und Sunset Wert an, kannst du CoolTux die so erweitern das, die beiden Attribute  ,,ASC_Drive_Offset und ASC_Drive_OffsetStart" mit einbezogen werden, dann gerne auch mit Sekundenangabe. Dann sieht man die Absoluten Zeiten für Auf- und Abfahrt beginn. In meinem Doif vorher habe die Zeiten absolut ausgerechnet, und ich konnte der Frau die Werte übermitteln. Oder kann ich mir die Irgendwie anders anzeigen/ausrechen lassen?

Die Zeiten für OffSet sollte lediglich ein paar Sekunden betragen. Und in den Rolllos stehen ja auch nur die Stunden und Minuten Werte drin.
Du kannst aber selbst so ein Reading erstellen. Einfach ein notify welches auf die Readings triggert und dann Dein Offset hinzufügen. Wäre aber wie gesagt ungenau da ja nur bis Minute angegeben wird.

[CoolTux]

Ich bin gerade daran die gemeldeten Bugs zu fixen. Vielen Dank an Euch alle dafür.
Ich habe auch noch das ein oder andere im Nachgang gefunden. So scheint das Shading nicht zu funktionieren an den Rollläden wo man für Sunset Sunrise mit brightness gefahren ist.

[Typ1er]

Das ist richtig, das gibt es auch gar nicht. Hat es nie gegeben. Konnte auch im Code oder Commandref sowas nicht finden. Wo hast Du das gelesen?

Tippfehler die Autokorrektur hat zugeschlagen bei mir.

im ASControl fehlt diese Attribut bei mir: ASC_Time_Up_WE_Holiday

aus der Comandref:
sunriseTimeWeHoliday - on/off - wird das Rollladen Device Attribut ASC_Time_Up_WE_Holiday beachtet oder nicht

[CoolTux]

Das Attribut ist auch im Rollladen Device zu finden nicht im ASC Device

[diki]

Hallo zusammen,

ich habe eine Verständnisfrage:

Wenn im ASC Device

Code Auswählen Erweitern

ASC_shuttersDriveOffset = 300

und in den Rollladen Devices

Code Auswählen Erweitern

ASC_Drive_Offset = -1
ASC_Drive_OffsetStart = -1

gesetzt ist, dann sollten die Rollläden zufällig zeitversetzt im Zeitraum von 300 Sekunden fahren - fahren aber alle gleichzeitig?

[CoolTux]

Welche ASC Version?

Wenn 0.6.x dann musst Du auf jeden Fall ASC_Drive_OffsetStart = 1 setzen.