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

[MCh76]

Setze mal bitte noch 5s Toleranz mit drauf.

mit den 5 sec toleranz hat es nun tatsächlich geklappt! vielen lieben Dank

[Beetle2003]

Das war nur ein Vorschlag für eine eventuelle Implementierung. Diese Attribute gibt es nicht!

Hallo,

ich habe die die Attribute in meinem ASC.
Wie kann ich die Werte ermitteln? Was sind sinvolle für einen ersten Test?

[ch.eick]

Hallo,

ich habe die die Attribute in meinem ASC.
Wie kann ich die Werte ermitteln? Was sind sinvolle für einen ersten Test?

Dann schick mal einen Screenshot, bei mit gibt es nur die ASC_Shading_*

[flummy1978]

Hallöchen,

soweit bekomme ich meine Rolläden zu 99% so gefahren wie ich sie haben möchte, soweit wie sie sollen und so schnell wieder runter wenn nötig. Außer einem ... dazu habe ich mal eine Verständniss bzw Funktionsfrage: (meine Annahmen stehen in Kursiv, diese habe ich aus dem Code heraus gelesen)

Die Beschattung funktioniert nur wenn isDay=1 ist. Dummerweise ist isDay nicht tatsächlich isDay sondern "ist der Rolladen im Tagesmodus" dieses wiederum wird durch die morgendliche Hochfahrt gesetzt. Wenn jetzt das Fenster nach Nord-Osten ist - wie bei mir, ist es so dass zwischen 7 und 12  sehr starke Sonnenstrahlung auf der Seite herrscht. Nun ist mein Sonnensensor außerhalb diesen Raumes, also sieht der Ablauf so aus:

Nacht -> Sonne geht auf -> Alle Bedingungen sind erfüllt um zu beschatten -> es passiert nichts weil die morgendliche Fahrt noch nicht erfolgt ist als isDay=0-> TimeUP zeit kommt -> Rolladen fährt komplett nach oben -> isDay=1 + Bedingungen sind immernoch alle da -> innerhalb weniger Minuten (Ablauf der Wartezeit) fährt das Rollo in Beschattung -> Alles weitere funktioniert wie gehabt / wie es soll...

Dass ein Rollo Beschattungsoptionen nicht beachten soll, wenn es Nacht ist, macht Sinn, aber in diesem Fall werden ja erst alle anderen Sachen abgefragt (Sonnenstand, Temperatur, Helligkeit etc) erst dann kommt die Abfrage "isDay" (kann man immer Debug Log ganz gut sehen) und dann bricht er ab weil für den Rolladen noch kein Tag ist (obewohl die Sonne 4 Std zuvor aufgegangen ist)

Nun meine Frage(n):
1. Kann man die isDay Abfrage irgendwie umgehen (für den einen Rolladen manipulieren) ?
2. Wie haben andere es gelöst, wenn ein Rolladen aus Nachtposition direkt in Shading gehen soll?
3. Alternative Ideen ?

Meine Frage bezieht sich auf ein Fenster dass Du, Cooltux, glaube ich in der Art auch mal erwähnt hattest.

Viele Grüße
Andreas

[CoolTux]

Hallöchen,

soweit bekomme ich meine Rolläden zu 99% so gefahren wie ich sie haben möchte, soweit wie sie sollen und so schnell wieder runter wenn nötig. Außer einem ... dazu habe ich mal eine Verständniss bzw Funktionsfrage: (meine Annahmen stehen in Kursiv, diese habe ich aus dem Code heraus gelesen)

Die Beschattung funktioniert nur wenn isDay=1 ist. Dummerweise ist isDay nicht tatsächlich isDay sondern "ist der Rolladen im Tagesmodus" dieses wiederum wird durch die morgendliche Hochfahrt gesetzt. Wenn jetzt das Fenster nach Nord-Osten ist - wie bei mir, ist es so dass zwischen 7 und 12  sehr starke Sonnenstrahlung auf der Seite herrscht. Nun ist mein Sonnensensor außerhalb diesen Raumes, also sieht der Ablauf so aus:

Nacht -> Sonne geht auf -> Alle Bedingungen sind erfüllt um zu beschatten -> es passiert nichts weil die morgendliche Fahrt noch nicht erfolgt ist als isDay=0-> TimeUP zeit kommt -> Rolladen fährt komplett nach oben -> isDay=1 + Bedingungen sind immernoch alle da -> innerhalb weniger Minuten (Ablauf der Wartezeit) fährt das Rollo in Beschattung -> Alles weitere funktioniert wie gehabt / wie es soll...

Dass ein Rollo Beschattungsoptionen nicht beachten soll, wenn es Nacht ist, macht Sinn, aber in diesem Fall werden ja erst alle anderen Sachen abgefragt (Sonnenstand, Temperatur, Helligkeit etc) erst dann kommt die Abfrage "isDay" (kann man immer Debug Log ganz gut sehen) und dann bricht er ab weil für den Rolladen noch kein Tag ist (obewohl die Sonne 4 Std zuvor aufgegangen ist)

Nun meine Frage(n):
1. Kann man die isDay Abfrage irgendwie umgehen (für den einen Rolladen manipulieren) ?
2. Wie haben andere es gelöst, wenn ein Rolladen aus Nachtposition direkt in Shading gehen soll?
3. Alternative Ideen ?

Meine Frage bezieht sich auf ein Fenster dass Du, Cooltux, glaube ich in der Art auch mal erwähnt hattest.

Viele Grüße
Andreas

Ja ich habe das auch. Allerdings habe ich diese 2 Fenster, Wohnzimmer, mittels ASC_ModeUp home fahren lassen. Sobald also Residents auf home gegangen ist, ist das Rollo erst gefahren und dann war im Sommer immer schon Tag und Shading war in gesetzt. Aber ich gebe Dir Recht, ich muss hier mal was bauen.

[CoolTux]

Hallöchen,

soweit bekomme ich meine Rolläden zu 99% so gefahren wie ich sie haben möchte, soweit wie sie sollen und so schnell wieder runter wenn nötig. Außer einem ... dazu habe ich mal eine Verständniss bzw Funktionsfrage: (meine Annahmen stehen in Kursiv, diese habe ich aus dem Code heraus gelesen)

Die Beschattung funktioniert nur wenn isDay=1 ist. Dummerweise ist isDay nicht tatsächlich isDay sondern "ist der Rolladen im Tagesmodus" dieses wiederum wird durch die morgendliche Hochfahrt gesetzt. Wenn jetzt das Fenster nach Nord-Osten ist - wie bei mir, ist es so dass zwischen 7 und 12  sehr starke Sonnenstrahlung auf der Seite herrscht. Nun ist mein Sonnensensor außerhalb diesen Raumes, also sieht der Ablauf so aus:

Nacht -> Sonne geht auf -> Alle Bedingungen sind erfüllt um zu beschatten -> es passiert nichts weil die morgendliche Fahrt noch nicht erfolgt ist als isDay=0-> TimeUP zeit kommt -> Rolladen fährt komplett nach oben -> isDay=1 + Bedingungen sind immernoch alle da -> innerhalb weniger Minuten (Ablauf der Wartezeit) fährt das Rollo in Beschattung -> Alles weitere funktioniert wie gehabt / wie es soll...

Dass ein Rollo Beschattungsoptionen nicht beachten soll, wenn es Nacht ist, macht Sinn, aber in diesem Fall werden ja erst alle anderen Sachen abgefragt (Sonnenstand, Temperatur, Helligkeit etc) erst dann kommt die Abfrage "isDay" (kann man immer Debug Log ganz gut sehen) und dann bricht er ab weil für den Rolladen noch kein Tag ist (obewohl die Sonne 4 Std zuvor aufgegangen ist)

Nun meine Frage(n):
1. Kann man die isDay Abfrage irgendwie umgehen (für den einen Rolladen manipulieren) ?
2. Wie haben andere es gelöst, wenn ein Rolladen aus Nachtposition direkt in Shading gehen soll?
3. Alternative Ideen ?

Meine Frage bezieht sich auf ein Fenster dass Du, Cooltux, glaube ich in der Art auch mal erwähnt hattest.

Viele Grüße
Andreas

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/commit/3535042915a041b4914362e1668e5284d0493845

Müsstest dann mal bei Gelegenheit testen.

[teufelchen]

Hallo CoolTux,

noch ist es warm aber wenn es Frost gibt, bildet sich durch das offene Schlafzimmerfenster Wasser und dann Eis am Rollo, so dass dieser einfriert und nicht mehr fahren soll.

Da es ein Spezialfall ist würde ich versuchen die Auswertung losgelöst von ASC hinzubekommen.

Meine Frage bzw. Wunsch wäre, wenn es in ASC jeweils eine Variable für hoch und runter gäbe die die automatische Fahrt unterbindet, wenn die Bedingung nicht zutrifft sollen die Fahrten nachgeholt werden.

z. B:
ASC_not_up: DEVICENAME[:READINGNAME]:[Bedingung], Wenn Bedingung zutrifft wird die geplante Öffnung unterbunden, wenn diese nicht (mehr) zutrifft öffnet ASC normal bzw. holt unterdrückte Fahrt nach.
ASC_not_down: DEVICENAME[:READINGNAME]:[Bedingung], Wenn Bedingung zutrifft wird die geplante Schließung unterbunden, wenn diese nicht (mehr) zutrifft schließt ASC normal bzw. holt unterdrückte Fahrt nach.

Meinst Du solch eine Funktion könnte irgendwann (möglichst vor Wintereinbruch) eingebaut werden?

[CoolTux]

Hallo CoolTux,

noch ist es warm aber wenn es Frost gibt, bildet sich durch das offene Schlafzimmerfenster Wasser und dann Eis am Rollo, so dass dieser einfriert und nicht mehr fahren soll.

Da es ein Spezialfall ist würde ich versuchen die Auswertung losgelöst von ASC hinzubekommen.

Meine Frage bzw. Wunsch wäre, wenn es in ASC jeweils eine Variable für hoch und runter gäbe die die automatische Fahrt unterbindet, wenn die Bedingung nicht zutrifft sollen die Fahrten nachgeholt werden.

z. B:
ASC_not_up: DEVICENAME[:READINGNAME]:[Bedingung], Wenn Bedingung zutrifft wird die geplante Öffnung unterbunden, wenn diese nicht (mehr) zutrifft öffnet ASC normal bzw. holt unterdrückte Fahrt nach.
ASC_not_down: DEVICENAME[:READINGNAME]:[Bedingung], Wenn Bedingung zutrifft wird die geplante Schließung unterbunden, wenn diese nicht (mehr) zutrifft schließt ASC normal bzw. holt unterdrückte Fahrt nach.

Meinst Du solch eine Funktion könnte irgendwann (möglichst vor Wintereinbruch) eingebaut werden?

Es gibt bereits eine Frost Implementierung in ASC.

[flummy1978]

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/commit/3535042915a041b4914362e1668e5284d0493845

Müsstest dann mal bei Gelegenheit testen.

Wenn ich es heute noch schaffe, es einzubinden, teste ich es morgen 

Was hast Du dort geändert ? Muss ich was beachten ?

p.s. jetzt bin ich doch grad mal total dämlich: Wie installiere ich denn ein entsprechdens Feature ? Oder muss ich das händisch in entsprechenden Dateien ändern?

[teufelchen]

Es gibt bereits eine Frost Implementierung in ASC.

Hallo,

Du meinst sicherlich ASC_Antifreeze
Für mich ist das etwas zu unflexibel. Denn die Temperatur ist der einzige Trigger. Unterschritten (bei am/pm/hard) fährt nicht, überschritten fährt.

Für meine Anwendung wäre etwas mit Verzögerung und dazu noch Temperaturabhängig wünschenswert.
Sicherlich im ASC Modul zuviel Sonderfall eines einzelnen Users.
Das Attribut ASC_ExternalTrigger ist auch schon etwas für die externe Ansteuerung, trifft es aber nicht ganz.

[CoolTux]

Wenn ich es heute noch schaffe, es einzubinden, teste ich es morgen 

Was hast Du dort geändert ? Muss ich was beachten ?

p.s. jetzt bin ich doch grad mal total dämlich: Wie installiere ich denn ein entsprechdens Feature ? Oder muss ich das händisch in entsprechenden Dateien ändern?

Code Auswählen Erweitern


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

update


[Reinhard.M]

Code Auswählen Erweitern

ASC_Shading_StateChange_SunnyCloudy - Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte. Ein optionaler dritter Wert gibt an wie, viele Brightnesswerte für den aktuellen Brightness-Durchschnitt berücksichtigt werden. Standard ist 3, es sollten nicht mehr als 5 berücksichtigt werden. (default: 35000:20000 [3])

Hallo CoolTux,
ich wollte den Average Wet von 3 auf 1 ändern und habe dabei festgestellt, dass immer mindesten 3 Werte genommen werden. Die Settings 1, 2 und 3 erzeugen immer den gleichen Average-Wert ("BrightnessAverage") aus den letzten 3 Values. Erst ab 4 werden tatsächlich die letzten 4 statt der letzten 3 Werte für den Durchschnitt verwendet. Ist das so gewollt? Dann wäre eine kleine Anpassung in der Comandref nicht schlecht Zum testen würde mir persönlich aber eine Korrektur des Verhaltens besser gefallen. Ich teste viele Settings zuerst mit einem kompletten Dummy Setup und immer die Werte mehrfach eingeben ist ein wenig lästig 

Gruß Reinhard

[Beetle2003]

Code Auswählen Erweitern

ASC_Shading_StateChange_SunnyCloudy - Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte. Ein optionaler dritter Wert gibt an wie, viele Brightnesswerte für den aktuellen Brightness-Durchschnitt berücksichtigt werden. Standard ist 3, es sollten nicht mehr als 5 berücksichtigt werden. (default: 35000:20000 [3])

Hallo CoolTux,
ich wollte den Average Wet von 3 auf 1 ändern und habe dabei festgestellt, dass immer mindesten 3 Werte genommen werden. Die Settings 1, 2 und 3 erzeugen immer den gleichen Average-Wert ("BrightnessAverage") aus den letzten 3 Values. Erst ab 4 werden tatsächlich die letzten 4 statt der letzten 3 Werte für den Durchschnitt verwendet. Ist das so gewollt? Dann wäre eine kleine Anpassung in der Comandref nicht schlecht Zum testen würde mir persönlich aber eine Korrektur des Verhaltens besser gefallen. Ich teste viele Settings zuerst mit einem kompletten Dummy Setup und immer die Werte mehrfach eingeben ist ein wenig lästig 

Gruß Reinhard

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.

Vielen Dank

Gruss

Ralf

[ch.eick]

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.

Ich hatte das hier bei meiner Einrichtung geschrieben. Eventuell findest Du da ja noch Informationen.
https://forum.fhem.de/index.php/topic,102199.msg957534.html#msg957534
Insbesondere Punkt 6)

Und das hier https://forum.fhem.de/index.php/topic,102199.msg967512.html#msg967512 , die dritte CodeBox von oben

Und diese Seite hat mir geholfen: www.sonnenverlauf.de, da kannst Du ermitteln, wo die Sonne zu einer bestimmten Zeit steht.
Das ganze dann für jedes Fenster und Du hast gute Einstiegswerte für die Winkel.

Gruß
    Christian

[CoolTux]

Code Auswählen Erweitern

ASC_Shading_StateChange_SunnyCloudy - Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte. Ein optionaler dritter Wert gibt an wie, viele Brightnesswerte für den aktuellen Brightness-Durchschnitt berücksichtigt werden. Standard ist 3, es sollten nicht mehr als 5 berücksichtigt werden. (default: 35000:20000 [3])

Hallo CoolTux,
ich wollte den Average Wet von 3 auf 1 ändern und habe dabei festgestellt, dass immer mindesten 3 Werte genommen werden. Die Settings 1, 2 und 3 erzeugen immer den gleichen Average-Wert ("BrightnessAverage") aus den letzten 3 Values. Erst ab 4 werden tatsächlich die letzten 4 statt der letzten 3 Werte für den Durchschnitt verwendet. Ist das so gewollt? Dann wäre eine kleine Anpassung in der Comandref nicht schlecht Zum testen würde mir persönlich aber eine Korrektur des Verhaltens besser gefallen. Ich teste viele Settings zuerst mit einem kompletten Dummy Setup und immer die Werte mehrfach eingeben ist ein wenig lästig 

Gruß Reinhard

Hallo Reinhard,

Kannst Du das Verhalten bitte nach einem Neustart von FHEM noch mal testen. Also den Average Wert ändern und dann einen Neustart machen bitte.


Grüße