[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.10

Begonnen von CoolTux, 22 Juni 2020, 12:38:36

Vorheriges Thema - Nächstes Thema

Reinhard.M

Zitat von: Beetle2003 am 06 September 2020, 15:30:34
Hallo Reinhard,

ich habe die Einrichtung der Beschattung bisher nicht verstanden.

Kannst Du mir helfen welche Einstellungen ich vornehmen muss und wie ich ggf die Werte ermittel. Was sind Werte mit denen ich erst einmal die Funktion an einem Rollo testen kann.

Hallo Ralf,

wenn du die grundsätzlichen Settings meinst möchte ich wie Christian https://www.sonnenverlauf.de/ als ersten Anlaufpunkt empfehlen. Auf dieser Webseite kannst du deine Adresse und beliebige Tage eingeben. Als "Base Map" (blaues Icon oben rechts auf der Map) aber nicht die "Esri Street" sondern die "OSM" selektieren. Die OSM Map zeigt neben den Straßen auch die Häuser und deren Position. Damit ist es jetzt ganz einfach die "Azimuth" Werte für das jeweilige Fenster abzulesen. Optimal wäre es, wenn du an einem Tag im Juni schaust ab welcher Uhrzeit die Sonne ins Fenster scheint und wann nicht mehr. Diese Zeiten stellst du auf der Webseite ein und hast sofort den Anfangs- und End-Azimuth. Das natürlich pro Fensterseite.
Die "Elevation" im ASC entspricht der Sonnenhöhe im Sonnenverlauf. In Deutschland wird der höchste Wert im Sommer mit ca. 67° ganz im Süden und ca. 59° ganz im Norden erreicht. In den meisten Fällen wollen wir die Beschattung auch bei Sonnenhöchststand beibehalten weswegen hier der zweite Elevation Wert von CoolTux per Default auf 100° gesetzt wurde. Dieser Wert wird an keinem Ort erreicht, es geht nicht über 90° hinaus. Damit ist aber sichergestellt, dass die Beschattung nicht gerade dann aufhört wenn es heiß wird. Wichtiger ist hier der erste Wert der Elevation. Die Wenigsten werden ihr Haus so allein im freien oder auf einem Berg stehen haben, dass sie mit einer Elevation von 0° beginnen. Die Meisten haben sicherlich einen Baum, ein Gebäude oder irgendetwas anderes über das die Sonne hinaus kommen muss. Wenn man weiß, wie weit dieser Gegenstand entfernt ist und wie hoch er ist kann man über den Tanges den Winkel für die Elevation berechnen. Geht aber viel einfacher wiederum mit Sonnenverlauf. Da kann ich auch die einzustellende Sonnenhöhe ablesen wenn ich wie beim Azimuth Tag und Zeit im Sonnenverlauf eintrage. Dieser Winkel ist übrigens unabhängig von der Jahreszeit, macht sich aber nur bei Sonnenauf- bzw. Sonnenuntergang bemerkbar.
Wenn die Winkel eingestellt sind kommt der von mir genannte "SunnyClaudy" Wert. Hier wird es etwas tricky wie bereits Christian angedeutet hat. Je nach Sensor können hier die Lux Werte bei vollem Sonnenschein 100.000 und mehr erreichen (ich habe hier schon Postings gesehen da wurde von Werten im 100er Bereich gesprochen. Das sind mit großer Wahrscheinlichkeit Watt/m² und nicht Lux!). Im Sommer möchte man morgens aber gerne bereits ab 10.000 beschatten damit das Zimmer sich nicht aufheitzt. Dieser Wert wird aber auch bei bewölktem Himmel zu einem späteren Zeitpunkt leicht erreicht, da brauche ich aber keine Beschattung. Hier muss man also irgendwie Ausgleich erzeugen damit es über den ganzen Tag richtig verhält. Neben Christian haben in diesem Thread auch andere bereits Lösungsvorschläge gepostet, z.B. "Eistee". Ich bin grade an einer algorithmischen Lösung, mal sehen ob ich es hinbekomme. Die beiden Werte hier muss man quasi als "Hysterese" betrachten. Würden wir hier nur einen Wert verwenden könnte es im Übergangsbereich, wenn der Wert also gerade überschritten wird, das Rollo im kurzen Abstand runter, rauf, runter fährt weil gerade eine dünne Wolke in der Nähe ist. Um das zu verhinder ist die Hysterese notwendig. Der Abstand ist ein wenig Geschmacks- und Gefühlssache, da gibt es keine falsch oder richtig. der zweite Wert muss auf alle Fälle kleiner als der erste sein. Der optionale dritte Wert gibt an wieviel letzten Werte für die Bildung des Mittelwertes herangezogen werden.
Hoffe das hilft dir ein wenig weiter, ansonsten hier posten.

Gruß Reinhard

Reinhard.M

Zitat von: CoolTux am 06 September 2020, 16:43:47
Kannst Du das Verhalten bitte nach einem Neustart von FHEM noch mal testen. Also den Average Wert ändern und dann einen Neustart machen bitte.

Nach einem Restart wird tatsächlich auch mit "1" bzw. "2" gearbeitet. Wenn man dann wieder versucht auf einen kleineren Wert einzustellen bleibt der Average beim höchsten selektierten Wert. Wenn man den Wert hoch setzt kommt man ohne Restart nicht mehr darunter. Also auch nicht von 4 auf 3.

CoolTux

Zitat von: Reinhard.M am 06 September 2020, 17:22:13
Nach einem Restart wird tatsächlich auch mit "1" bzw. "2" gearbeitet. Wenn man dann wieder versucht auf einen kleineren Wert einzustellen bleibt der Average beim höchsten selektierten Wert. Wenn man den Wert hoch setzt kommt man ohne Restart nicht mehr darunter. Also auch nicht von 4 auf 3.

Ich schaue mir das die Woche mal genauer an.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

flummy1978

Moinsen,

kleine Rückmeldung von mir: Funktioniert einwandfrei (zumindest das was ich testen wollte). Der betroffene Rolladen fährt jetzt sofort in die Beschattungsposition wenn die Bedingungen bereits vor der TimeUp Zeit erreicht worden sind UND die TimeUp Zeit erreicht ist. (diese hatte ich am Sa / So vergessen noch umzustellen, weshalb ich keinen Untschied gemerkt habe)

Zitat von: CoolTux am 04 September 2020, 16:40:29

update add https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/devel-testing/controls_AutoShuttersControl.txt

update

Muss ich jetzt etwas tun um die offiziellen Versionen weiterhin upzudaten, oder .... ?

Vielen Dank für die schnelle Umsetzung
Viele Grüße
Andreas

CoolTux

Zitat von: flummy1978 am 07 September 2020, 08:30:11
Moinsen,

kleine Rückmeldung von mir: Funktioniert einwandfrei (zumindest das was ich testen wollte). Der betroffene Rolladen fährt jetzt sofort in die Beschattungsposition wenn die Bedingungen bereits vor der TimeUp Zeit erreicht worden sind UND die TimeUp Zeit erreicht ist. (diese hatte ich am Sa / So vergessen noch umzustellen, weshalb ich keinen Untschied gemerkt habe)
Muss ich jetzt etwas tun um die offiziellen Versionen weiterhin upzudaten, oder .... ?

Vielen Dank für die schnelle Umsetzung
Viele Grüße
Andreas

Du entfernst nun wieder den zusätzlichen Update Strang und machst bitte die nächsten 3 Tage kein Update. Ich gebe die Version die Tage ins offizielle SVN frei.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

JWRu

Ich habe gestern ein etwas seltsames Verhalten von ASC bemerkt:
Die Beschattung lief (controlShading on) und zwei Rollläden sind in die Beschattung gefahren. Ich habe dann beide von Hand hochgefahren.
Um zu verhindern, dass die anderen Rollläden in die Beschattung fahren, habe ich controiShading auf "off" gesetzt.
Am nächsten Morgen sind diese beiden Rollläden nicht ganz nach oben gefahren, sondern in die Beschattungsposition (controlShading war immer noch "off").
In der letzten Spalte der ASC-Übersicht (Shading Info) stand für beide Rollläden immer noch "in".

ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

CoolTux

Zitat von: JWRu am 08 September 2020, 11:22:20
Ich habe gestern ein etwas seltsames Verhalten von ASC bemerkt:
Die Beschattung lief (controlShading on) und zwei Rollläden sind in die Beschattung gefahren. Ich habe dann beide von Hand hochgefahren.
Um zu verhindern, dass die anderen Rollläden in die Beschattung fahren, habe ich controiShading auf "off" gesetzt.
Am nächsten Morgen sind diese beiden Rollläden nicht ganz nach oben gefahren, sondern in die Beschattungsposition (controlShading war immer noch "off").
In der letzten Spalte der ASC-Übersicht (Shading Info) stand für beide Rollläden immer noch "in".

Danke Dir. Ich weiß bereits woran es liegt. Ich werde da einen Patch die Tage für machen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Reinhard.M


Reinhard.M

#713
Dafür werden jetzt allerdings die Fahrbefehle für das Shading zumindest bei den Markisen (awning) nicht mehr abgesetzt. Das ASC Modul sagt "Shading Info: in", ich sehe auch den Übergang von out auf in aber es werden keine Fahrbefehle gesendet. Rückwärts das gleiche Verhalten. Von out auf in aber keine Fahrbefehle. Bei den Fenstern geht es weiterhin ohne Probleme. Irgendeine Idee?
Nachtrag:
Kein vom ASC Modul ausgelöster Fahrbefehl. Das Rollo Modul macht und zeigt alles richtig.
Noch ein Nachtrag:
Nach einem scanForShutter, createNewNotifyDev, renewAllTimer funktionierte das Shading out. Shading in macht wieder Probleme. Ich muss mal genauer analysieren, bitte bis zum nächsten Post warten.

Reinhard.M

Das Problem lag in der ASC_Sleep_Pos. Die stand (seit Anfang an bei mir) auf 0. Ich weiß, alle einstellbaren Positionen sollten unterschiedlich sein. Meine bisherige Beobachtung: Das ist nicht immer so und kann sich ändern. In alle Richtungen. Diese Anforderung kommt wohl aus dem ursprünglichen Modul welches hierfür als Basis verwendet wurde. Verstanden habe ich die Notwendigkeit dafür aber bis heute nicht. Fazit: Alles gut, läuft :)

xerion

Guten Morgen CoolTux, ich habe die v0.10.9 seit ein paar Tagen im Einsatz und es sah so aus als wenn das IsDay Problem behoben war. Heute morgen leider aber nicht. Muss aber dabei sagen daß ich Weekend Steuerung aktiv habe kann es dort mit zusammen noch ein Problem geben?
Wechsel jetzt zu Octopus Energy und bekomme 150,00 € Bonus auf deine Rechnung. Die Anmeldung geht super leicht und schnell, klicke dafür einfach meinen persönlichen Empfehlungslink:
 https://share.octopusenergy.de/loved-heron-220.

xerion

Zitat von: xerion am 12 September 2020, 08:57:29
Guten Morgen CoolTux, ich habe die v0.10.9 seit ein paar Tagen im Einsatz und es sah so aus als wenn das IsDay Problem behoben war. Heute morgen leider aber nicht. Muss aber dabei sagen daß ich Weekend Steuerung aktiv habe kann es dort mit zusammen noch ein Problem geben?

Exit: das Rollo mit time hat IsDay richtig die brightness Rollos nicht.
Wechsel jetzt zu Octopus Energy und bekomme 150,00 € Bonus auf deine Rechnung. Die Anmeldung geht super leicht und schnell, klicke dafür einfach meinen persönlichen Empfehlungslink:
 https://share.octopusenergy.de/loved-heron-220.

thorsten299

Hallo,

benutzt jemand die Attribute ASC_Drive_Delay und/oder ASC_Drive_DelayStart und kann bestätigen, dass sie bei der Berechnung der Fahrzeiten eine Auswirkung zeigen. Bei mir ist dies leider nicht der Fall. Alles andere funktioniert soweit einwandfrei.

Vielen Dank

Reinhard.M


ms_steini

Guten Morgen zusammen,

irgendwie funktioniert mein "autoshuttercontrol" nicht wie es soll.

im ACS wird angezeigt:
Next DriveUp = 12.09.2020 - 09:15:01
Next DriveDown = 11.09.2020 - 22:00:01

zusätzlich ist eingestellt:
ASC_brightnessDriveUpDown 20.00:0.40


eingestellt ist:
ASC_Time_Down_Early         19:00
ASC_Time_Down_Late          22:00
ASC_Time_Up_Early             {setTimeUp('Early','OG.Rollo.Henna.Fenster')} Ergebnis = 06:15
ASC_Time_Up_Late              {setTimeUp('Late','OG.Rollo.Henna.Fenster')} Ergebnis = 09:15
ASC_Time_Up_WE_Holiday    09:00

hochgefahren ist das Rollo heute morgen um "2020-09-12_06:36:38 0.48" Uhrzeit des Brightness Sensor

irgendwie nimmt der nicht die eingestellte Uhrzeit von ASC_Time_Up_WE_Holiday  09:00

was wird benötigt und was muss ich einstellen damit man mir helfen kann?

Vielen Dank