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

[CoolTux]

Mahlzeit noch einmal eine Frage zur Verständis. Ich habe meine beiden Rollladen zur Terrasse in der Beschattung, sie sollen aber nur beschatten wenn keiner Zuhause ist das klappt auch soweit. Nun hatte ich erwartet das wenn ich nach Hause kommen die Beschattung für die beiden Fenster beendet wird und sie wieder öffnen. Sie blieben aber unten. Ist das so gewollt oder ein Bug.

Gruß Alex

Habe ich gefixt. Geht nun.
Kann man schon in der aktuellen Developer testen wenn man will.

[Loredo]

Ich versuche gerade noch die Markise vor meinem Rollladen mit zu steuern, bin aber nicht sicher, ob das wirklich aktuell funktioniert.


Ich bin unsicher, weil eine Markise eben umgekehrt zu einem Rollladen funktioniert und zudem auch nur für die Beschattung zuständig ist - es braucht also keine morgendliche Fahrt, sondern nur die Abendliche für den Fall, dass die Markise außerhalb der Beschattung tagsüber manuell betätigt wurde. WindProtect ist natürlich zwingend notwendig und dabei muss die Markise natürlich rein und nicht aus gefahren werden. Das kann ich natürlich erreichen, indem ich Closed_Pos und Open_Pos einfach umdrehe. Allerdings kann ich dann den Regenschutz wiederum nicht verwenden, weil dieser die Markise dann raus statt rein fahren würde. Ich dieser Schutz ist neben Wind natürlich unerlässlich für eine Markise. Aber vielleicht geht es wenn ich Closed_Pos und Open_Pos einfach beide auf 0 (=eingefahren) setze? Hm... 


Hat sich schonmal jemand Gedanken gemacht, wie die richtige Kombination von Werten hier aussieht?


Was ich bisher habe:


1. ASC = 1 --> reell an der Markise bedeutet 0 eingefahren und 100 komplett ausgefahren.
2. ASC_AntiFreeze = hard --> im Winter soll die Markise gar nicht betätigt werden können
3. ASC_Antifreeze_Pos = 0 --> Winter Position
4. ASC_BrightnessSensor = WeatherStation:luminosity --> Helligkeit außen in Lux für Beschattungssteuerung (sonnig vs bewölkt)
5. ASC_Closed_Pos = 0 --> also die Abend Position
6. ASC_Open_Pos = 0 --> ebenfalls 0, da nur beschattet werden soll
7. ASC_Down = brightness --> sollte eigentlich egal sein, da Up_Pos und Down_Pos beide 0
8. ASC_Up = brightness --> sollte eigentlich egal sein, da Up_Pos und Down_Pos beide 0
9. ASC_Mode_Down = always --> könnte auch off sein, aber ich vermute dann funktioniert die Beschattung auch nicht mehr?
10. ASC_Mode_Up = always --> könnte auch off sein, aber ich vermute dann funktioniert die Beschattung auch nicht mehr?
11. ASC_Pos_Reading = pct --> es handelt sich eigentlich um ein Homematic Device (HM-LC-Bl1-SM), welches aber eben so eingestellt ist, dass 0=eingefahren ist
12. ASC_RainProtection = on --> hätte ich gerne, ob es mit ASC_Closed_Pos=0 dann auch so funktioniert wie es soll?
13. ASC_Self_Defense_Exclude = on --> nur zur Sicherheit
14. ASC_Shading_Angle_Left = 75 --> Versuch macht klug
15. ASC_Shading_Angle_Right = 75 --> Versuch macht klug
16. ASC_Shading_Direction = 273 --> Südlage
17. ASC_Shading_Min_Elevation = 25 --> Versuch macht klug
18. ASC_Shading_Min_OutsideTemperature = 13.5 --> Südlage mit großen Fenstern heizen innen schnell kräftig auf, also beschatten wir früh
19. ASC_Shading_Mode = home --> vorerst nur wenn wir zuhause sind
20. ASC_Shading_Pos = 65 --> Markise muss nicht ganz ausgefahren werden
21. ASC_Shading_StateChange_Cloudy = 20000 Lux --> Versuch macht klug
22. ASC_Shading_StateChange_Sunny = 35000 Lux --> Versuch macht klug
23. ASC_Shading_WaitingPeriod = 1200 --> ich nehme an Wind und Regen Events sind davon eh ausgenommen?
24. ASC_ShuttersPlace = window --> Self-Defense ist nicht rele[f|v]ant
25. ASC_Time_Down_Early = 19:00 --> sollte keine Rolle spielen
25. ASC_Time_Down_Late = 20:00 --> sollte zumindest dafür sorgen, dass die Markise nach manueller Benutzung immer spätestens um 21:00 reingefahren wird (weil Closed_Pos=0)
26. ASC_Time_Up_Early = 05:00 --> sollte gar keine Rolle spielen
27. ASC_Time_Up_Late = 05:00 --> sollte gar keine Rolle spielen
28. ASC_WiggleValue = 0 --> wir wollen nicht, dass sich die Markise bewegt
29. ASC_WindParameters = 30:20 0 --> ASC device hat windSensor="WeatherStation:wind_gust_max10m 30:20" (HP1000); ab 30 km/h Böhen bitte auf 0 fahren
30. ASC_WindProtection = on --> unerlässlich


Macht das so Sinn?

[diki]

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

Danke, ist die 0.6.3

Ein Rollladen in Beschattung fährt nach öffnen durch den Fensterkontakt und bei "ASC_ShuttersPlace = terrace" nach kurzer Zeit wieder in die Beschattung. Wenn das so gewollt ist, wie kann ich das verhindern ohne die Beschattung für den Rollladen auszuschalten?

[JHo]

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

Oh, das lese ich in der Commandref so nicht oder interpertiere es falsch. Für mich liest sich die Commandref so, als wäre Drive_OffsetStart nicht zwingend anzugeben, um die Verzögerung zu aktivieren - sondern, dass hierfür Drive_Offset ausreichend ist.
Hatte die gleiche Beobeachtung gemacht nach dem Update auf 0.6, es aber auf meine Dusseligkeit und die im Moment fehlende Zeit für nähere Beschäftigung geschoben. Aber Deine Erklärung macht die Fehlersuche einfacher, Danke!

Unabhängig von dem Drive_Offset-Thema würde ich in der kommenden Woche mal versuchen, die Readings-Erläuterungen im Wiki upzudaten und thematisch zu gliedern (z.B., welche Einstellungen für Shading gesetzt sein müssen / können), um hier mehr Durchblick in die einzelnen Bestandteile des Moduls zu bringen. Wenn das gelingt, könnte man ja so evtl. auch die Commandref strukturieren. Wäre m.E. für den ASC-Einsteiger sehr viel leichter zu verstehen... da ist durch die mit 0.6 versteckten Readings viel passiert, aber es gibt sicher noch Potenzial.

Viele Grüße
Jan

[Loredo]

Hi Marko,


ich hätte da noch ein Finding:


Wenn man seine Rollläden in mehreren Räumen hat, dann werden die Readings im ASC nicht richtig generiert. Ich weiß nicht, welche Auswirkungen das noch so hat...
Man muss wohl auch berücksichtigen, dass man Räume auch nur Gruppierung nach Gewerken missbraucht (zur einfacheren Verwaltung oder auch Anzeige). In meinem Beispiel sind die Geräte natürlich nur in einem physischen Raum. Ich weiß nicht, ob du da einfach so nur den erste Raum nehmen kannst, denn aktuell lassen sich die Raumzuweisungen über das room Attribut nicht sortieren. Man müsste dann also das Attribut manuell in die richtige Reihenfolge bringen.


Kann das auch der Grund sein, warum bei mir trotz allem der scanForShutters Setter nur ganz selten funktioniert? Manchmal tut er das was er soll, manchmal aber auch nicht. Was ich bisher dabei herausfinden konnte ist, dass event-on-change-reading unbedingt auf .* stehen solle. Ich setze das bei mir allerdings über ein DOIF direkt nach dem anlegen von jedem neuen Device auf "state" und passe es ggf. später an, wenn es notwendig wird. Vor einem "scanForShutters" muss man das also sicherstellen da ASC wohl sehr stark darauf setzt seine eigenen Events zu bekommen. (zwar OT, aber das ist mir schon oft aufgefallen, weshalb ich irgendwie schon lange Rudi fragen wollte, ob man an dem Punkt event-on-change-reading nicht per Modul internem Setting so überschreiben kann, dass man die Events immer bekommt, die NOTIFYDEV braucht). Danach funktioniert zwar der Scan, aber bei den gefundenen Devices wird dann ganz oft das userattr nicht gesetzt. Dabei fällt mir dann auf, dass im Internal NOTIFYDEV des ASC Devices auch teilweise falsche Sachen drin stehen (ist schwer nachzustellen ohne dauernd die ganze Konfig neu machen zu müssen... sieht aber aus wie Teile von Attributnamen) und erst ein createNewNotifyDev räumt das dann auf.


Ich habe versucht das im Code zu debuggen, finde mich aber nicht zurecht 

[CoolTux]

Danke, ist die 0.6.3

Ein Rollladen in Beschattung fährt nach öffnen durch den Fensterkontakt und bei "ASC_ShuttersPlace = terrace" nach kurzer Zeit wieder in die Beschattung. Wenn das so gewollt ist, wie kann ich das verhindern ohne die Beschattung für den Rollladen auszuschalten?

Ist nicht so gewollt und wurde heute gefixt. Sollte es morgen per Update geben.

[CoolTux]

Hi Marko,


ich hätte da noch ein Finding:


Wenn man seine Rollläden in mehreren Räumen hat, dann werden die Readings im ASC nicht richtig generiert. Ich weiß nicht, welche Auswirkungen das noch so hat...
Man muss wohl auch berücksichtigen, dass man Räume auch nur Gruppierung nach Gewerken missbraucht (zur einfacheren Verwaltung oder auch Anzeige). In meinem Beispiel sind die Geräte natürlich nur in einem physischen Raum. Ich weiß nicht, ob du da einfach so nur den erste Raum nehmen kannst, denn aktuell lassen sich die Raumzuweisungen über das room Attribut nicht sortieren. Man müsste dann also das Attribut manuell in die richtige Reihenfolge bringen.


Kann das auch der Grund sein, warum bei mir trotz allem der scanForShutters Setter nur ganz selten funktioniert? Manchmal tut er das was er soll, manchmal aber auch nicht. Was ich bisher dabei herausfinden konnte ist, dass event-on-change-reading unbedingt auf .* stehen solle. Ich setze das bei mir allerdings über ein DOIF direkt nach dem anlegen von jedem neuen Device auf "state" und passe es ggf. später an, wenn es notwendig wird. Vor einem "scanForShutters" muss man das also sicherstellen da ASC wohl sehr stark darauf setzt seine eigenen Events zu bekommen. (zwar OT, aber das ist mir schon oft aufgefallen, weshalb ich irgendwie schon lange Rudi fragen wollte, ob man an dem Punkt event-on-change-reading nicht per Modul internem Setting so überschreiben kann, dass man die Events immer bekommt, die NOTIFYDEV braucht). Danach funktioniert zwar der Scan, aber bei den gefundenen Devices wird dann ganz oft das userattr nicht gesetzt. Dabei fällt mir dann auf, dass im Internal NOTIFYDEV des ASC Devices auch teilweise falsche Sachen drin stehen (ist schwer nachzustellen ohne dauernd die ganze Konfig neu machen zu müssen... sieht aber aus wie Teile von Attributnamen) und erst ein createNewNotifyDev räumt das dann auf.


Ich habe versucht das im Code zu debuggen, finde mich aber nicht zurecht 

Hallo Julian,

Das mit den room Reading im ASC ist nur so ein Gimmick. Nicht so wichtig.
Bitte entferne event-on-* komplett aus dem ASC Modul. Dann sollte alles normal klappen. Auch das Scan und verteilen der Attribute.

[Loredo]

Bitte entferne event-on-* komplett aus dem ASC Modul. Dann sollte alles normal klappen. Auch das Scan und verteilen der Attribute.

Hab ich jetzt mal gemacht, ich beobachte.


Derweil habe ich noch ein (Schönheits?) Finding:
Wenn ich ASC_PrivacyDown* verwende, wird ein Reading mit dem Namen "Up" erstellt. Ich weiß noch nicht, ob es nur der Readingname ist oder ob auch falsch gefahren wird - mal sehen.




... und noch eine zwei Fragen:
1. Was bedeutet die Status "shading out" und "shading in"? Sollte es nicht eher "shading off" und "shading on" heißen? Das hat mich beim debuggen etwas verwirrt.
2. Kann man brightness und auch mit den Astro Zeiten zum fahren kombinieren? Falls brightness früher eintritt, wird ja bereits entsprechend gefahren. Aber für den Fall, dass z.B. der Sensor ausfällt, wird dann auf die fest definierte Zeit zurückgegriffen. Schicker wäre natürlich, wenn ich die Astro Zeit nehmen könnte, weil die mir eine bessere Alternative als Fallback scheint.




PS:
Wegen der Markise brauchts nicht umgehend eine Antwort, aber es wäre klasse, wenn du es dir in Ruhe einmal ansehen und Feedback geben könntest.

[CoolTux]

Der Readingsname war in der Tat falsch und wird in der kommenden Version morgen gefixt werden.
1. shading in bedeutet das das Rolllo in die Beschattung gefahren ist und shading out das er raus gefahren ist aus der Beschattung.
2. Das kann man leider nicht.

[CoolTux]

Ich habe Brightness für Sunset gerade getestet. Funktioniert bei mir. Ich gebe die Version heute Abend erstmal frei so das wir die meisten Fixes morgen Früh per Update haben.

[CoolTux]

Hab ich jetzt mal gemacht, ich beobachte.


Derweil habe ich noch ein (Schönheits?) Finding:
Wenn ich ASC_PrivacyDown* verwende, wird ein Reading mit dem Namen "Up" erstellt. Ich weiß noch nicht, ob es nur der Readingname ist oder ob auch falsch gefahren wird - mal sehen.




... und noch eine zwei Fragen:
1. Was bedeutet die Status "shading out" und "shading in"? Sollte es nicht eher "shading off" und "shading on" heißen? Das hat mich beim debuggen etwas verwirrt.
2. Kann man brightness und auch mit den Astro Zeiten zum fahren kombinieren? Falls brightness früher eintritt, wird ja bereits entsprechend gefahren. Aber für den Fall, dass z.B. der Sensor ausfällt, wird dann auf die fest definierte Zeit zurückgegriffen. Schicker wäre natürlich, wenn ich die Astro Zeit nehmen könnte, weil die mir eine bessere Alternative als Fallback scheint.




PS:
Wegen der Markise brauchts nicht umgehend eine Antwort, aber es wäre klasse, wenn du es dir in Ruhe einmal ansehen und Feedback geben könntest.

Bezüglich Deiner Markise muss ich mir ein zwei Sachen anschauen. Aber eigentlich bilde ich mir ein das es einfach sein sollte.

[Loredo]

2. Das kann man leider nicht.

Schade. Denn wie mir auffällt, macht ACS_PrivacyDown natürlich nur Sinn, wenn man nicht über brightness steuert. In der Praxis kommt es aber sicherlich vor, dass man rein von der Astro Zeit und dem PrivacyDown Offset auf die Privacy Position fahren würde. Zumindest würde dann ein zweiter Helligkeits-Schwellenwert fehlen, bei dem in die Privacy Position gefahren wird. An sehr düsteren Tagen im Winter wird es aber schwer zu unterscheiden, ob es nur düster aufgrund des Wetters oder wegen des Sonnenuntergangs ist. Machst du da eine Plausibilitätsprüfung auf ASC_Time_Down_Early? Ich erinnere mich jedenfalls, dass ich auch schon 400 Lux gemessen habe hier tagsüber, es aber noch Mitten am Tag war. Das ist kaum über dem Schwellenwert von 300, den ich für die Tag/Nacht Grenze sonst angebe.

Ich habe Brightness für Sunset gerade getestet. Funktioniert bei mir. Ich gebe die Version heute Abend erstmal frei so das wir die meisten Fixes morgen Früh per Update haben.

War das auf meine Fragen bezogen? Ich kann dir da gerade nicht ganz folgen, sollte ich da nochmal was testen?

Bezüglich Deiner Markise muss ich mir ein zwei Sachen anschauen. Aber eigentlich bilde ich mir ein das es einfach sein sollte.

Mucho gracias! 








EDIT - PS (2019-05-01 15:51):

- ASC_GuestRoom scheint keine Funktion mehr zu haben

[mnl1234]

Tag zusammen! 
Ich habe an der Terrassentür bisher die Steuerung so, dass bei einer bestimmten Brightness nur bis zu einen Wert von 60% geschlossen wird (weil danach meistens die Katzen noch rein wollen) und erst am Ende des Zeitfensters (22:30) ganz geschlossen wird.

Kann ich das mit dem Autoshutter auch irgendwie realisieren?

Außerdem hab ich in meinen Homematic Rolloaktoren die Levelinvertierung drin, sodass der Rolladen bei ASC=2 morgen zu und Abends auffährt. Wenn ich es richtig verstanden habe muss ich dann nur ASC=1 setzen, richtig?

[CoolTux]

An sehr düsteren Tagen im Winter wird es aber schwer zu unterscheiden, ob es nur düster aufgrund des Wetters oder wegen des Sonnenuntergangs ist. Machst du da eine Plausibilitätsprüfung auf ASC_Time_Down_Early? Ich erinnere mich jedenfalls, dass ich auch schon 400 Lux gemessen habe hier tagsüber, es aber noch Mitten am Tag war. Das ist kaum über dem Schwellenwert von 300, den ich für die Tag/Nacht Grenze sonst angebe.

Das verstehe ich gerade ehrlich gesagt nicht. Die Brightnessevents werden nur innerhalb der Zeitspannen von Early und Late ausgewertet. Dazwischen nicht. Es kann also gerne auch mal gegen 15:20 Uhr 290 haben, so lange Early_Down 16:00 Uhr ist

War das auf meine Fragen bezogen? Ich kann dir da gerade nicht ganz folgen, sollte ich da nochmal was testen?

Nein das war eine allgemeine Meldung 

- ASC_GuestRoom scheint keine Funktion mehr zu haben

Hatte noch nie Funktion. Muss ich mir erst was zu überlegen.

[CoolTux]

Tag zusammen! 
Ich habe an der Terrassentür bisher die Steuerung so, dass bei einer bestimmten Brightness nur bis zu einen Wert von 60% geschlossen wird (weil danach meistens die Katzen noch rein wollen) und erst am Ende des Zeitfensters (22:30) ganz geschlossen wird.

Kann ich das mit dem Autoshutter auch irgendwie realisieren?

Aktuell leider nicht.

Außerdem hab ich in meinen Homematic Rolloaktoren die Levelinvertierung drin, sodass der Rolladen bei ASC=2 morgen zu und Abends auffährt. Wenn ich es richtig verstanden habe muss ich dann nur ASC=1 setzen, richtig?

Nein musst Du nicht. Setze einfach die Attribute ASC_Closed_Pos, ASC_Open_Pos entsprechend. Der Rest kann ja so bleiben.