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

[flummy1978]

ASC_Shading_WaitingPeriod akzeptiert kein Perl. Das ganze war auch erstmal nur ein Vorschlag, da ist noch rein gar nichts von umgesetzt.

Schade,dachte ich könnte da etwas testen 
Wäre es ein großer Aufwand Perl akzeptierbar zu machen ? - Wie gesagt hier könnte jeder in seine Richtung gehen - Zumindest diejenigen die Perl selbst einsetzen (können).

Grüße
Andreas

[CoolTux]

Das müsste ich mir erstmal anschauen. Da werde ich dann in einigen Zeilen den aktuellen Teiler wenn dann raus nehmen müssen.
Denn aktuell wird ja die ShadingBlockingTime durch 2 geteilt für die Beschattung.

[Borkk]

Ich denke hier kann es Sinn machen das Verhalten als Attribut auswählbar zu machen.

Ich will das Thema Abwesenheit nochmal aufgreifen. Ich hatte gehofft den automatische Wechsel von "absent" nach "gone" im Roommate, könne man mit dem Attribut "rr_autoGoneAfter=0" abschalten. Dem ist leider nicht so. Heute sind wieder die Roommates und somit auch der Resident auf "gone" gesprungen. Diesmal hat aber direkt SelfDefence zugeschlagen und gleich mal alle entsprechend konfigurierten Rollos geschlossen. Ich hatte ganz vergessen das SelfDefence da auch noch reinfunkt. .

Wenn man also möchte, das im Urlaub die Rollos weiter fahren als wäre man zu Hause muss man derzeit über ein notify automatisch die Roommates von "gone" zurück auf "absent" stellen und SelfDefence abschalten. Das ist kein Problem aber irgendwie "unsauber"

Ich glaube mit dem Wunsch, die Rollos auch im Urlaub "normal" fahren zu lassen, bin ich nicht ganz alleine. Dafür hat man ja schließlich den ganzen Kram hier aufgebaut . Für alle Rollos "zu" wenn Resident = "gone", brauch man ja kein ASC.

Wer aus gutem Grund im Urlaub alle Rollos lieber zu haben möchte, würde doch vermutlich direkt beim Verlassen des Hauses bzw. der Wohnung alle Rollos schließen und dann ASC deaktivieren, damit sie auch zu bleiben?? Warum sollte man warten bis seine Roommates nach n Stunden oder Tagen auf "gone" springen, um es erst dann von ASC erledigen zu lassen. (gilt aus meiner Sicht auch für SelfDefence bei gone).

Wenn du das Verhalten über ein Attribut konfigurierbar machen willst (was super wäre ), würde aus meiner Sicht ein "IgnoreGone = |1/0]" genügen. Damit würde DayOpen, NightClose und Beschattung weiterlaufen. SelfDefence würde die Rollos bei "gone" nicht schliessen auch wenn die Fenster zu sind.

[Wolle02]

Ich hatte gehofft den automatische Wechsel von "absent" nach "gone" im Roommate, könne man mit dem Attribut "rr_autoGoneAfter=0" abschalten. Dem ist leider nicht so. Heute sind wieder die Roommates und somit auch der Resident auf "gone" gesprungen.

Kann ich nicht bestätigen. Bei mir ist auch bei allen Roommates "rr_autoGoneAfter=0" eingestellt. Da springt dann nix mehr auf "gone". Bei mir gibt es nur Home und Absent.

[Borkk]

Kann ich nicht bestätigen. Bei mir ist auch bei allen Roommates "rr_autoGoneAfter=0" eingestellt. Da springt dann nix mehr auf "gone". Bei mir gibt es nur Home und Absent.

Hast du mal 72h gewartet? Ich dachte auch es wäre abgeschaltet aber nach 72h ist der Status trotzdem auf gone gesprungen. In der Commandref ist zu "0" auch nichts dokumentiert.

Vielleicht bin ich auch diesem Bug erlegen, ich hatte nämlich wegen einer anderen Sache vorgestern ein Restart gemacht.
https://forum.fhem.de/index.php?topic=87455.0

Das wäre aber ärgerlich, wenn der nach 2 Jahren noch nicht behoben ist?!?!

[Wolle02]

Hast du mal 72h gewartet? Ich dachte auch es wäre abgeschaltet aber nach 72h ist der Status trotzdem auf gone gesprungen. In der Commandref ist zu "0" auch nichts dokumentiert.

Hmm, tja, zugegebenermaßen ist cronabedingt mein letzter Urlaub an dem ich min. 72 Stunden nicht zu Hause war schon ein Jahr her. Aber ich habe seit dem die Konfiguration nicht geändert bzw. damals auch schon die Attribute in den Roommates so eingestellt und da sind die Stati nicht auf "gone" gesprungen.
Da muss ich doch glatt mal meine Anwesenheitserkennung ausschalten und schauen was nach 3 Tagen passiert.

[kjmEjfu]

Für die Abschattung kann man derzeit kein eigenes Device festlegen, sondern es wird ausschließlich ASC_BrightnessSensor genutzt, richtig?

Hintergrund: meine Helligkeitssensoren liefern wegen der hohen Sonnenhöhe zu geringe Werte (s. auch https://forum.fhem.de/index.php/topic,112071.msg1063640.html). Dadurch ist es für die Beschattung von ASC immer bewölkt und es wird nicht abgeschattet.
Das ist zwar nicht ganz so schlimm, weil durch die hohe Sonne sowieso wenig Sonnenlicht direkt auf die Fenster gelangt, aber trotzdem nicht ideal.
Deshalb würde ich eigentlich gerne für die Beschattung von Licht (Brightness) hin zur Differenztemperatur wechseln. Wenn ich diesen Sensor aber in ASC_BrightnessSensor hinterlege, dann klappt natürlich das morgendliche und abendliche hoch und runter nach Brightness nicht mehr.

[Reinhard.M]

Ich teste gerade für mich die Comfort Funktion. Dabei ist mir aufgefallen, dass bei einem threestate Fensterkontakt die "ASC_ComfortOpen_Pos" nicht auf 0 gesetzt werden kann bzw. das mit 0 das Rollo bei geöffnetem Fenster (nicht gekippt!!) nicht mehr hoch fährt. Wenn ich stattdessen "ASC_ComfortOpen_Pos = 0.001" fährt das Rollo in die 0 Position. Wie gesagt, es funktioniert nur bei dem Wert 0 nicht. Bei allen anderen Werten und alle weiteren Features funktionieren wie erwartet.

[CoolTux]

Ich teste gerade für mich die Comfort Funktion. Dabei ist mir aufgefallen, dass bei einem threestate Fensterkontakt die "ASC_ComfortOpen_Pos" nicht auf 0 gesetzt werden kann bzw. das mit 0 das Rollo bei geöffnetem Fenster (nicht gekippt!!) nicht mehr hoch fährt. Wenn ich stattdessen "ASC_ComfortOpen_Pos = 0.001" fährt das Rollo in die 0 Position. Wie gesagt, es funktioniert nur bei dem Wert 0 nicht. Bei allen anderen Werten und alle weiteren Features funktionieren wie erwartet.

Ja das ist korrekt. Und es gehen nur ganze Zahlen als Wert.

[Reinhard.M]

Ja das ist korrekt. Und es gehen nur ganze Zahlen als Wert.

Das ist ja genau das Problem: Wenn ich als ASC_ComfortOpen_Pos die 0 wähle (Rollo ASC = 1) wird das Rollo bei offenem Fenster nicht hoch gefahren. Und die 0 gehört zum selektierbaren Bereich:

Code Auswählen Erweitern

ASC_ComfortOpen_Pos - in 10 Schritten von 0 bis 100 (Default: ist abhängig vom AttributASC 20/80) !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
Wenn ich Rollo ASC = 2 setze und alle Werte entsprechend anpasse, also ASC_ComfortOpen_Pos = 100, dann funktioniert es wie erwartet.
Ganz nebenbei, 0.001 ist "... eine positive Zahl/Dezimalzahl ..." und wird klaglos vom ASC-Device akzeptiert. Das ist momentan der einzige Weg das Rollo komplett hoch zu fahren wenn ich das Fenster/die Tür öffne.

[stefanpf]

Für die Abschattung kann man derzeit kein eigenes Device festlegen, sondern es wird ausschließlich ASC_BrightnessSensor genutzt, richtig?

Hintergrund: meine Helligkeitssensoren liefern wegen der hohen Sonnenhöhe zu geringe Werte (s. auch https://forum.fhem.de/index.php/topic,112071.msg1063640.html). Dadurch ist es für die Beschattung von ASC immer bewölkt und es wird nicht abgeschattet.
Das ist zwar nicht ganz so schlimm, weil durch die hohe Sonne sowieso wenig Sonnenlicht direkt auf die Fenster gelangt, aber trotzdem nicht ideal.
Deshalb würde ich eigentlich gerne für die Beschattung von Licht (Brightness) hin zur Differenztemperatur wechseln. Wenn ich diesen Sensor aber in ASC_BrightnessSensor hinterlege, dann klappt natürlich das morgendliche und abendliche hoch und runter nach Brightness nicht mehr.

Ich habe mir für solche erweiterte Logik einen Dummy (bzw. im Device "EspSolar") mit userreading Brightness angelegt.
In diesem kann dann die entsprechende Logik mit ein wenig If Else komfortabel umgesetzt werden.
Denkbar wäre ja z.B. ein Schwellenwert des Brightness Sensors bis zu dem dessen Werte verwendet werden und danach die Werte aus der Differenzsteuerung.
Oder eine Brightnessteuerung, die gestützt auf Twilight Zeiträume arbeitet (z.B. ab Sonnenstand < 10°)
Wg Toleranzen der Temperatursensoren kann man an dieser Stelle dann auch gleich so unschöne Dinge wie negative Brightness Werte abfangen.

Btw @Cooltux:
Werden die Rollläden eigentlich nachgeführt, wenn man die Perl Funktion in den Pos Attributen verwendet oder gilt der ermittelte Wert dann immer für einen Zyklus?
Ich denke da an so etwas wie den Rollladen mit steigendem Sonnenstand etwas weiter anzuheben, so dass noch ein wenig Licht in die Hütte kommt).

[CoolTux]

Das ist ja genau das Problem: Wenn ich als ASC_ComfortOpen_Pos die 0 wähle (Rollo ASC = 1) wird das Rollo bei offenem Fenster nicht hoch gefahren. Und die 0 gehört zum selektierbaren Bereich:

Code Auswählen Erweitern

ASC_ComfortOpen_Pos - in 10 Schritten von 0 bis 100 (Default: ist abhängig vom AttributASC 20/80) !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
Wenn ich Rollo ASC = 2 setze und alle Werte entsprechend anpasse, also ASC_ComfortOpen_Pos = 100, dann funktioniert es wie erwartet.
Ganz nebenbei, 0.001 ist "... eine positive Zahl/Dezimalzahl ..." und wird klaglos vom ASC-Device akzeptiert. Das ist momentan der einzige Weg das Rollo komplett hoch zu fahren wenn ich das Fenster/die Tür öffne.

Gut ich merke schon. Schreiben wir es anders. Ein bereits vergebener Positions Wert darf auf gar keinen Fall ein zweites mal als ein anderer Positionswert angegeben werden.
Ich denke so ist es ein ein deutig, oder?
Und 0.001 ist keine ganze Zahl, oder ich habe was in Mathe verpasst. (Was durch aus sein kann, bin nicht so der begabte in Mathe)

[CoolTux]

Ich habe mir für solche erweiterte Logik einen Dummy (bzw. im Device "EspSolar") mit userreading Brightness angelegt.
In diesem kann dann die entsprechende Logik mit ein wenig If Else komfortabel umgesetzt werden.
Denkbar wäre ja z.B. ein Schwellenwert des Brightness Sensors bis zu dem dessen Werte verwendet werden und danach die Werte aus der Differenzsteuerung.
Oder eine Brightnessteuerung, die gestützt auf Twilight Zeiträume arbeitet (z.B. ab Sonnenstand < 10°)
Wg Toleranzen der Temperatursensoren kann man an dieser Stelle dann auch gleich so unschöne Dinge wie negative Brightness Werte abfangen.

Btw @Cooltux:
Werden die Rollläden eigentlich nachgeführt, wenn man die Perl Funktion in den Pos Attributen verwendet oder gilt der ermittelte Wert dann immer für einen Zyklus?
Ich denke da an so etwas wie den Rollladen mit steigendem Sonnenstand etwas weiter anzuheben, so dass noch ein wenig Licht in die Hütte kommt).

Er sollte immer nachgeführt werden sobald ein Event des Brightness oder des Twilight Devices kommt.


Grüße

[FunkOdyssey]

FVERSION: 73_AutoShuttersControl.pm:v0.8.32-s22110/2020-06-04 TESTING

Ich habe hier einige Jalousien, die eigentlich in 19:15 (zzgl. Delay) herunterfahren sollten. Jedoch sind die  erst etwas spät aus dem Shading Out zurückgekehrt und haben somit scheinbar ihren NightClose verpasst.

Danach habe ich ab 19:29 Uhr merkwürdige Fahrbefehle im Log (siehe unten).

Könntest du dir das bitte mal anschauen. Danke.

Code Auswählen Erweitern


Attributes:
   ASC        2
   ASC_BrightnessSensor sensor:lux 400:400
   ASC_Closed_Pos 20
   ASC_Down   brightness
   ASC_DriveUpMaxDuration 25
   ASC_Drive_Delay 180
   ASC_Drive_DelayStart 120
   ASC_Mode_Down always
   ASC_Mode_Up absent
   ASC_Partymode on
   ASC_Pos_Reading pct
   ASC_Shading_InOutAzimuth 55:275
   ASC_Shading_MinMax_Elevation 25
   ASC_Shading_Min_OutsideTemperature 22
   ASC_Shading_Mode always
   ASC_Shading_Pos 10
   ASC_Shading_StateChange_SunnyCloudy 75000:25000
   ASC_Shutter_IdleDetection motor:stop.*
   ASC_Time_Down_Early 16:00
   ASC_Time_Down_Late 19:15
   ASC_Time_Up_Early 08:00
   ASC_Time_Up_Late 10:00
   ASC_Time_Up_WE_Holiday 09:30
   ASC_Up     brightness
   ASC_WiggleValue 15
 

Code Auswählen Erweitern


2020-06-12_19:19:26 ankleide_jal ASC_ShuttersLastDrive: night close
2020-06-13_09:33:38 ankleide_jal commState: CMDs_pending
2020-06-13_09:33:38 ankleide_jal level: set_100
2020-06-13_09:33:38 ankleide_jal set_100
2020-06-13_09:33:38 ankleide_jal commState: CMDs_processing...
2020-06-13_09:33:38 ankleide_jal commState: CMDs_done
2020-06-13_09:33:38 ankleide_jal level: 20
2020-06-13_09:33:38 ankleide_jal motor: up:20
2020-06-13_09:33:38 ankleide_jal 20
2020-06-13_09:33:58 ankleide_jal deviceMsg: on (to VCCU)
2020-06-13_09:33:58 ankleide_jal level: 100
2020-06-13_09:33:58 ankleide_jal motor: stop:on
2020-06-13_09:33:58 ankleide_jal pct: 100
2020-06-13_09:33:58 ankleide_jal on
2020-06-13_09:33:58 ankleide_jal ASC_ShuttersLastDrive: day open
2020-06-13_12:22:51 ankleide_jal commState: CMDs_pending
2020-06-13_12:22:51 ankleide_jal level: set_10
2020-06-13_12:22:51 ankleide_jal set_10
2020-06-13_12:22:51 ankleide_jal commState: CMDs_processing...
2020-06-13_12:22:51 ankleide_jal commState: CMDs_done
2020-06-13_12:22:51 ankleide_jal level: 100
2020-06-13_12:22:51 ankleide_jal motor: down:on
2020-06-13_12:22:51 ankleide_jal on
2020-06-13_12:23:11 ankleide_jal deviceMsg: 10 (to VCCU)
2020-06-13_12:23:11 ankleide_jal level: 10
2020-06-13_12:23:11 ankleide_jal motor: stop:10
2020-06-13_12:23:11 ankleide_jal pct: 10
2020-06-13_12:23:11 ankleide_jal 10
2020-06-13_12:23:11 ankleide_jal ASC_ShuttersLastDrive: shading in
2020-06-13_19:17:24 ankleide_jal commState: CMDs_pending
2020-06-13_19:17:24 ankleide_jal level: set_100
2020-06-13_19:17:24 ankleide_jal set_100
2020-06-13_19:17:24 ankleide_jal commState: CMDs_processing...
2020-06-13_19:17:25 ankleide_jal commState: CMDs_done
2020-06-13_19:17:25 ankleide_jal level: 10
2020-06-13_19:17:25 ankleide_jal motor: up:10
2020-06-13_19:17:25 ankleide_jal 10
2020-06-13_19:17:46 ankleide_jal deviceMsg: on (to VCCU)
2020-06-13_19:17:46 ankleide_jal level: 100
2020-06-13_19:17:46 ankleide_jal motor: stop:on
2020-06-13_19:17:46 ankleide_jal pct: 100
2020-06-13_19:17:46 ankleide_jal on
2020-06-13_19:17:46 ankleide_jal ASC_ShuttersLastDrive: shading out
2020-06-13_19:19:42 ankleide_jal commState: CMDs_pending
2020-06-13_19:19:42 ankleide_jal level: set_10
2020-06-13_19:19:42 ankleide_jal set_10
2020-06-13_19:19:42 ankleide_jal commState: CMDs_processing...
2020-06-13_19:19:42 ankleide_jal commState: CMDs_done
2020-06-13_19:19:42 ankleide_jal level: 100
2020-06-13_19:19:42 ankleide_jal motor: down:on
2020-06-13_19:19:42 ankleide_jal on
2020-06-13_19:20:02 ankleide_jal deviceMsg: 10 (to VCCU)
2020-06-13_19:20:02 ankleide_jal level: 10
2020-06-13_19:20:02 ankleide_jal motor: stop:10
2020-06-13_19:20:02 ankleide_jal pct: 10
2020-06-13_19:20:02 ankleide_jal 10
2020-06-13_19:20:09 ankleide_jal commState: CMDs_pending
2020-06-13_19:20:09 ankleide_jal level: set_100
2020-06-13_19:20:09 ankleide_jal set_100
2020-06-13_19:20:09 ankleide_jal commState: CMDs_processing...
2020-06-13_19:20:09 ankleide_jal commState: CMDs_done
2020-06-13_19:20:09 ankleide_jal level: 10
2020-06-13_19:20:09 ankleide_jal motor: up:10
2020-06-13_19:20:09 ankleide_jal 10
2020-06-13_19:20:31 ankleide_jal deviceMsg: on (to VCCU)
2020-06-13_19:20:31 ankleide_jal level: 100
2020-06-13_19:20:31 ankleide_jal motor: stop:on
2020-06-13_19:20:31 ankleide_jal pct: 100
2020-06-13_19:20:31 ankleide_jal on



[daschauher]

Hallo Zusammen,
ich möchte bei mir auch das ASC Modul einbauen und mein selbstgebasteltes raus werfen.
Erstmal ein großes Lob an alle Beteiligten was ihr hier leistet. Vielen Dank dafür.

Ich müsste für weitere automatisierte Aufgaben wissen ob gerade Tag oder Nacht ist. Bzw auch darauf reagieren.
Z.B. im Wohnzimmer wenn jemand Zuhause ist das Licht einschalten wenn die Rollos wegen der Nacht Schließung runter fahren.
Gibt es da vielleicht schon etwas das ich noch nicht gefunden habe?
Oder falls nicht, welche Möglichkeiten habe ich?
Mir würde dazu einfallen mein vorhandenes Dummy für Tag/Nacht zu behalten und dieses über das Reading ASC_ShutterLastDrive:night Close und dayopen umzuschalten.

Was meint ihr dazu? Gibt es eine elegantere Lösung?