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

[blasterx]

@CoolTux
Ist es möglich beim abendlichen Runterfahren der Rollladen egal in welchem Modus (astro/time/brightness) eine weitere Bedingung einzubinden und zwar die Temperatur? Im Sommer fahre ich bei warmen Nächten die Rollladen nicht herunter, in meiner derzeitigen Steuerung werden die Rollladen nur runtergefahren wenn die astro Bedingung stimmt (sunset) und die Temperatur <20 Grad ist. Das kann ich für jedes Fenster separat einstellen.

Gruß BlasterX

[CoolTux]

@CoolTux:
Habe jetzt mal den Rolladen RAnkleide manuell gefahren.

Code Auswählen Erweitern

2019.05.03 14:13:58 3: RAnkleide: tahoma_applyRequest data={"label":"Ankleidezimmer - Positionieren auf 89 % - myFHEM","actions":[{"deviceURL":"io://1208-4648-3794/5491834","commands":[{"name":"setClosure","parameters":[89]}]}]}
2019.05.03 14:13:58 4: AutoShuttersControl (ASC) - Devname: RAnkleide Name: ASC Notify: $VAR1 = [
          'dim 89'
        ];

2019.05.03 14:13:59 4: AutoShuttersControl (ASC) - Devname: RAnkleide Name: ASC Notify: $VAR1 = [
          'RSSILevelState: 38.0'
        ];

2019.05.03 14:14:15 4: AutoShuttersControl (ASC) - Devname: RAnkleide Name: ASC Notify: $VAR1 = [
          'RSSILevelState: 44.0',
          'dim88',
          'ClosureState: 88',
          'devicestate: open',
          'OpenClosedState: open',
          'state: dim89',
          'ClosureState: 89',
          'devicestate: open',
          'OpenClosedState: open'
        ];

2019.05.03 14:14:15 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'RAnkleide_PosValue: 89'
        ];

2019.05.03 14:14:15 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'state: manual'
        ];

2019.05.03 14:14:58 3: RAnkleide: tahoma_applyRequest data={"label":"Ankleidezimmer - Positionieren auf 77 % - myFHEM","actions":[{"deviceURL":"io://1208-4648-3794/5491834","commands":[{"name":"setClosure","parameters":[77]}]}]}
2019.05.03 14:14:58 4: AutoShuttersControl (ASC) - Devname: RAnkleide Name: ASC Notify: $VAR1 = [
          'dim 77'
        ];

2019.05.03 14:15:01 4: AutoShuttersControl (ASC) - Devname: RAnkleide Name: ASC Notify: $VAR1 = [
          'dim78',
          'ClosureState: 78',
          'devicestate: open',
          'OpenClosedState: open',
          'RSSILevelState: 42.0',
          'state: dim76',
          'ClosureState: 76',
          'devicestate: open',
          'OpenClosedState: open'
        ];

2019.05.03 14:15:01 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'RAnkleide_PosValue: 76'
        ];

2019.05.03 14:15:01 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'state: manual'

Bei zwei Fahrversuchen weicht ClosureState vom Positionieren-Wert ab. Im zweiten Versuch weicht auch PosValue ab.

Dieses Phänomen habe ich vereinzelt bei drei von elf Rolläden.

Gruß
eurofinder

Ich muss mir das noch mal überlegen was man da machen könnte.

[volschin]

@CoolTux
Ist es möglich beim abendlichen Runterfahren der Rollladen egal in welchem Modus (astro/time/brightness) eine weitere Bedingung einzubinden und zwar die Temperatur? Im Sommer fahre ich bei warmen Nächten die Rollladen nicht herunter, in meiner derzeitigen Steuerung werden die Rollladen nur runtergefahren wenn die astro Bedingung stimmt (sunset) und die Temperatur <20 Grad ist. Das kann ich für jedes Fenster separat einstellen.

Gruß BlasterX

Eigentlich bräuchtest Du nur ein Notify auf die Temperatur, dass bei allen Rollläden das ASC_Mode_Down-Attribut auf off setzt und später wieder rücksetzt.
Falls Du noch keinen Roommate benutzt, könnte man auch den dafür missbrauchen.

[blasterx]

Natürlich kann man das durch andere Module regeln. Ich dachte nur wenn es kein zu großer Aufwand ist, alles in einem Modul zu verwalten.

Gruß BlasterX

[Loredo]

Ist aber wie immer, programmatisch Attribute ändern ist nicht ideal im Gegensatz zu Readings (per setter). Man bekommt zB den Config Änderungshinweis nicht weg. Attribute sind daher eher als dauerhafte Einstellung zu sehen. Das ist auch der Grund, weshalb das ASC Device einige Setter wie zB selfDefense hat und das nicht als Attribut ausgelegt ist.

[Beta-User]

Natürlich kann man das durch andere Module regeln. Ich dachte nur wenn es kein zu großer Aufwand ist, alles in einem Modul zu verwalten.

Ganz allgemein gesprochen:
Vielleicht sollten wir ein

Code Auswählen Erweitern

set ASC userSideBlocked xyz-Device set|unsetanbieten?

Also Verwaltung eines vorgelagerten Sperr-Status pro Rollladen unmittelbar im Zentraldevice.

Dann könnte jeder user im Prinzip eine beliebige Logik anflanschen, um einen Rollladen vorübergehend von der Steuerung durch ASC auszunehmen. Er müßte sich dann eben darum kümmern, dass er den Rollladen dann selbst fährt und (v.a.!) auch wieder entsperrt.

So kann jeder doch zugreifen, und erst wenn sich genug user finden, die dafür sind, bestimmte Basislogiken direkt in ASC abzubilden, könnte man es dann direkt einbauen (was dann auch Sinn macht). Ich sehe nur schon wieder ein Haufen User, die sich wundern, dass ASC nichts macht, aber vergessen haben, dass sie selbst das angewiesen hatten .

[FunkOdyssey]

Beim Debuggen ist mir gerade eine Kleinigkeit aufgefallen, die aber mit meinen ursprünglichen Probleme nichts zu tun hat.

Ich habe in der ASC-ShutterInfos bei zwei Jalousien den Status "Last drive: night close".
Beide Jalousien wurden manuell innerhalb von Early&Up geöffnet. Eigentlich müsste dann doch eigentlich "manual" dort stehen, oder?
Das ist nicht wirklich schlimm, aber vielleicht hat das ja auch noch Auswirkungen auf andere Dinge und es mag dich interessieren.

[dk3572]

Hallo,

laut Astro wäre die Fahrt um 20:39 Uhr.
Jetzt ca. 17 Uhr habe ich den Party Mode eingeschaltet und kurz darauf wieder aus.
Dabei wurden alle Rollläden geschlossen.
Ist das normal oder ein Fehler?
Ich hätte erwartet sie fahren gar nicht.

VG Dieter

[FunkOdyssey]

Kurze Frage in die Runde - auch wenn es hier schon mehrfach beantwortet wurde. Sorry.

Wenn der - im Jalousie-Device konfigurierte - Brightness-Wert bereits länger unterschritten ist und die Zeiten wie folgt gesetzt sind...

ASC_Time_Down_Early: 17:15
ASC_Time_Down_Late: 20:15

... fährt dann die Jalousie bereits um 17:15 Uhr herunter oder wenn ein neuer Helligkeitswert über ein Event hereinkommt?

Ich wundere mich bei einem erneuten Test nämlich gerade, dass trotz Unterschreiten des BrightnessMin-Wertes nicht um 17:15 Uhr, sondern um 17:19 Uhr (zzgl. Offset) heruntergefahren wurde. Um 17:19 Uhr kam ein neues Event.

Erst beim nächsten Event. Also so wie Du es beobachtet hast.

Darf man fragen, ob man den Wunsch äußern darf, ob man das vielleicht zukünftig erweitern kann?
Also das zu ASC_Time_Up_Early und ASC_Time_Down_Early geprüft wird, ob der Schwellwert vielleicht bereits erreicht ist? Oder kann es sein, dass dadurch die Programmierung komplett umgeschmissen werden muss? So vermute ich es aktuell. Dann wäre der Aufwand sicherlich zu enorm. Oder kann man sich an der Logik von getTimexyzLate orientieren? Ich kann das nicht beurteilen.

Warum? Weil - je nach Sensor - zwischen den Early- und Late-Zeitpunkten teilweise nur wenige Events gesetzt werden. Oft ist es aktuell bspw. zwischen 08:00 und 08:30 schon so hell, dass der Brightness-Wert sich gar nicht mehr ändert. Und mit gesetztem "event-on-change-reading" verhungert ASC dann natürlich und wartet auf den Late-Zeitpunkt.

[CoolTux]

Beim Debuggen ist mir gerade eine Kleinigkeit aufgefallen, die aber mit meinen ursprünglichen Probleme nichts zu tun hat.

Ich habe in der ASC-ShutterInfos bei zwei Jalousien den Status "Last drive: night close".
Beide Jalousien wurden manuell innerhalb von Early&Up geöffnet. Eigentlich müsste dann doch eigentlich "manual" dort stehen, oder?
Das ist nicht wirklich schlimm, aber vielleicht hat das ja auch noch Auswirkungen auf andere Dinge und es mag dich interessieren.

Es gibt das Attribut ASC_DriveUpMaxDuration wo man die maximal Zeit des Rollos für die Hochfahrt + 3 Sekunden Sicherheit eintragen kann. Damit wird etwas präziser das manuelle fahren festgestellt.

[eurofinder]

@CoolTux:
Danke. Würde mich sehr freuen, wenn du da eine Lösung hättest.

Gruß
eurofinder

[CoolTux]

Erst beim nächsten Event. Also so wie Du es beobachtet hast.


Darf man fragen, ob man den Wunsch äußern darf, ob man das vielleicht zukünftig erweitern kann?
Also das zu ASC_Time_Up_Early und ASC_Time_Down_Early geprüft wird, ob der Schwellwert vielleicht bereits erreicht ist? Oder kann es sein, dass dadurch die Programmierung komplett umgeschmissen werden muss? So vermute ich es aktuell. Dann wäre der Aufwand sicherlich zu enorm. Oder kann man sich an der Logik von getTimexyzLate orientieren? Ich kann das nicht beurteilen.

Warum? Weil - je nach Sensor - zwischen den Early- und Late-Zeitpunkten teilweise nur wenige Events gesetzt werden. Oft ist es aktuell bspw. zwischen 08:00 und 08:30 schon so hell, dass der Brightness-Wert sich gar nicht mehr ändert. Und mit gesetztem "event-on-change-reading" verhungert ASC dann natürlich und wartet auf den Late-Zeitpunkt.

Für Brightness hat early so gesehen keine Relevanz ausser das die Auswertung nur zwischen early und late erfolgt. Ansonsten ist early in keiner weiteren Auswertung drin.

Setze dich den early Zeitpunkt früher.

[CoolTux]

@CoolTux
Ist es möglich beim abendlichen Runterfahren der Rollladen egal in welchem Modus (astro/time/brightness) eine weitere Bedingung einzubinden und zwar die Temperatur? Im Sommer fahre ich bei warmen Nächten die Rollladen nicht herunter, in meiner derzeitigen Steuerung werden die Rollladen nur runtergefahren wenn die astro Bedingung stimmt (sunset) und die Temperatur <20 Grad ist. Das kann ich für jedes Fenster separat einstellen.

Gruß BlasterX

Würde sowas global reichen? Also gültig für alle Rolllos?

[ESP_Fan]

Hallöchen nochmal,

aaahhhh wie ärgerlich. Hatte das von Dir gelesen, aber irgendwie nicht in Verbindung mit meinem Problem gebracht, weil es verwunderlich war, warum es vorher funktioniert hat.... Ich habs bei mir jetzt auch geändert. Mal sehen was morgen herauskommt Vielen Dank.
Aber dennoch ist da irgendwie n Würmchen drin:

@CoolTux
Ich hab mal meine alten Backups (von vor dem Update) durchforstet, wo die zeitlich gesteuerte rauf / runter Fahrt bereits geklappt hat. Überall stand in den alten Readings "ASC_Pos_Reading position" also müsste da irgendwas im Update nebenher geändert worden zu sein, ohne bemerkt zu werden ?

Grüße
Andreas

Du hast einfach mit dem Update auch das Update vom Rollo-Modul bekommen, dort wurde von "position" auf "pct" geändert.

[CoolTux]

Hallo,

laut Astro wäre die Fahrt um 20:39 Uhr.
Jetzt ca. 17 Uhr habe ich den Party Mode eingeschaltet und kurz darauf wieder aus.
Dabei wurden alle Rollläden geschlossen.
Ist das normal oder ein Fehler?
Ich hätte erwartet sie fahren gar nicht.

VG Dieter

Beim Beenden vom Partymode sollte der letzte versetzte Fahrbefehl ausgeführt werden. Ich schaue mir das noch mal genau an.