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

[CoolTux]

Thema fahrt des Rollos, wenn in oder out eintrifft. Wenn nun steht out, warten 5 min für nächsten check, wenn dann immer noch alles passt, fährt er dann erst hoch, kann das sein ? Das gleiche für in, er prüft, alle Bedingungen für in sind erfüllt, er wartet und testet nach der Wartezeit erneut, ist nun immer noch alles gegeben, fährt er runter ?

Nein er fährt sofort nachdem er das in bekommen hat.

[CoolTux]

wahrscheinlich liegt das am DriveDelay, das er erst ein paar min später fährt.
WaitingPeriode ist in Sekunden angegeben, also 300sec gleich 5 min. Komisch bei 600 steht 5min, bei 300 dann 2,5min irgendwie passt das nicht so ganz zusammen. Irgendwie komisch.

Das passt. 600 sind 10 min aber der Check für in erfolgt schon nach der hälfte der waitingPeriode also 300 5 min.
Beim out wartet er die volle waiting periode

[D3ltorohd]

Nein er fährt sofort nachdem er das in bekommen hat.

hm es dauert locker 3-4 min bis er fährt, da steht schon in.

[Eistee]

Hi wollte mal meine Lösung ohne ASC hier Vorstellen. ASC funktioniert bei mir leider nicht wegen meiner Wetterstation.

• Das ganze ist eine Jalousie mit verstellbaren Lamellen (Homematic Jalousie Aktor).
• Fenster Richtung Westen.
• Wetterstation froggit WH4000SE. Der Helligkeitssensor ist gerade nach oben in den Himmel gerichtet daher muss ich die am Abend immer flacher darauf scheinende Sonne etwas kompensieren um die Beschattung bei Sonne und Entschattung bei Wolken zu realisieren.
• Leinwand mit Intertechno Funkfenbedienung über MapleCUN
• Anwesenheit mit BLE Tags und entsprechend Presence und Residents Modul in FHEM umgesetzt.

Viellecht hilft es CoolTux ja auch zu sehen welche Anforderungen man noch so an ein ASC Modul haben kann.

Code Auswählen Erweitern

defmod mz.Rollo.di DOIF ## 1 : Rollo hoch\
(\
( ## or\
( ## and\
( ## Sonne hinter Berg\
[xx.Twilight:elevation] < 4.1\
and [xx.Twilight:azimuth] > 176\
)\
or ( ## Leinewand oben und Dämmerung\
[wz.Leinwand] eq "open"\
and [xx.Twilight:azimuth] < 260\
and [WeatherStation:luminosity] < 10000\
)\
or ( ## Leinewand oben und Dämmerung\
[wz.Leinwand] eq "open"\
and [xx.Twilight:azimuth] > 260\
and [WeatherStation:luminosity] < 3000\
)\
or ( ## Leinwand unten und Dunkel\
[wz.Leinwand] eq "closed"\
and [WeatherStation:luminosity] < 10\
)\
)\
and [Bewohner] !~ "sleep"\
)\
or [WeatherStation:wind_gust_max10m] > 25\
)\
( IF ([mz.HM.Rollo:pct] ne "100") (set mz.HM.Rollo pctSlat 40) )\
( IF ([mz.HM.Rollo:pct] ne "100") (set mz.HM.Rollo pctSlat 80) )\
( IF ([mz.HM.Rollo:pct] ne "100") (set mz.HM.Rollo 100) )\
\
## 2 : Rollo runter\
DOELSEIF (\
( ## and\
( ## Sonne auf Fenster\
[xx.Twilight:elevation] > 4.1\
and [xx.Twilight:azimuth] > 176\
and [WeatherStation:luminosity] > 42000\
)\
or ( ## Sonne auf Fenster später\
[xx.Twilight:elevation] > 4.1\
and [xx.Twilight:azimuth] > 230\
and [WeatherStation:luminosity] > 20000\
)\
or ( ## Sonne auf Fenster später\
[xx.Twilight:elevation] > 4.1\
and [xx.Twilight:azimuth] > 260\
and [WeatherStation:luminosity] > 10000\
)\
or ( ## Leinwand unten und hell\
[wz.Leinwand] eq "drive-down"\
and [WeatherStation:luminosity] > 10\
)\
or [Bewohner] =~ "sleep"\
)\
and [WeatherStation:wind_gust_max10m] < 20\
)\
( IF ([mz.HM.Rollo:pct] ne "0") (set mz.HM.Rollo 0) )
attr mz.Rollo.di alias Rollo
attr mz.Rollo.di cmdState Rollo hoch|\
Rollo runter
attr mz.Rollo.di cmdpause 65:65
attr mz.Rollo.di do always
attr mz.Rollo.di group Beschattung
attr mz.Rollo.di icon helper_doif
attr mz.Rollo.di room 9.1 DOIF
attr mz.Rollo.di wait 0,3,3:0
attr mz.Rollo.di widgetOverride cmdState:textField-long

[naund]

Ich verwende auch diese Wetterstation, allerdings mit ASC und kenne das Problem.  Bei niedrigem Sonnenstand bleibt das Rollo oben.  Ich habe auch schon überlegt, den Helligkeitswert durch den Sinus der Elevation zu teilen, um diesen Effekt zu verringern.

[meier81]

Der Helligkeitssensor ist gerade nach oben in den Himmel gerichtet daher muss ich die am Abend immer flacher darauf scheinende Sonne etwas kompensieren um die Beschattung bei Sonne und Entschattung bei Wolken zu realisieren.

Das Problem dürfte des öfteren auftreten, habe eine ELV WS980, da sieht es mit dem Helligkeitssensor genau so aus, ist auch senkrecht nach oben gerichtet.
Habe das Problem bei mir morgens, die Sonne kommt über den Berg und fällt sofort in die Fenster rein, der Helligkeitssensor hat aber erst 10000Lux, ich habe aber 35000Lux zum beschatten eingestellt. Würde ich den Wert runterstellen hätte ich das Problem das tagsüber selbst bei Bewölkung die Rollläden nicht mehr hochfahren würden, der Wert ist eigentlich okay, müsste eher noch etwas hochgesetzt werden.

Vielleicht kann man ja an dem Parameter "ASC_SHADING_STATECHANGE_SUNNYCLOUDY" Perl-tauglich machen, dann könnte man das verknüpfen z.B. Elevation < 30 dann nimm 15000Lux, Elevation > 30 dann nimm 35000Lux.

Gruß Markus

[JHo]

Vielleicht kann man ja an dem Parameter "ASC_SHADING_STATECHANGE_SUNNYCLOUDY" Perl-tauglich machen, dann könnte man das verknüpfen z.B. Elevation < 30 dann nimm 15000Lux, Elevation > 30 dann nimm 35000Lux.

Ich stehe vor dem gleichen Problem. Der Sonnensensor für ASC (ich nehme dafür eine Differenztemperatur) bringt mir morgens und abends Werte, die nicht ins "Muster" für tagsüber passen.
Verständnisfrage: könnte man nicht statt Perl im Statechange genauso einfach einen von Doif befüllen Dummy benutzen, der die im Statechange angegebenen Werte sinnvoll tageszeit/elevationabhängig normalisiert?

[Eistee]

von Doif befüllen Dummy

attr userReadings ist da deutlich sinvoller.
https://wiki.fhem.de/wiki/UserReadings

[Wardancer]

Moin,

Ich hätte ein Feature-Request. Und zwar ist mir jetzt bei den abendlichen Lüftungsaktionen aufgefallen, dass ASC bzw. meine Fenstersensoren sehr nervös und direkt auf das Schließen nach dem kippen und anschliessende ganzen öffnen reagieren. Meist erkennt ASC dann das schließen, fährt die Rollade komplett runter macht aber, vermutlich wegen einer Min-Verzögerung bei automatischer Fahrt, das Hochfahren nicht mehr mit. Ergo ist, dass ich dann die Rolladen dann doch wieder manuell öffnen muss. Bei einem, Threestate-Sensor den ich hab, ist das Problem noch etwas komplexer...
Ich kann in den Sensoren keinen Delay oder so etwas einstellen, wie das bei einigen Homematic-Sensoren funktioniert, sondern die Dinger feuern im Prinzip direkt.
Ich könnte jetzt natürlich jeweils einen Dummy bauen, der per DoIf und waits das ganze regelt, aber ich denke, das jeder mit zwave-Sensoren das gleiche Problem haben wird, daher die Frage ob es evtl möglich wäre einen Delay einzubauen, den ASC wartet bis es einen Fahrbefehl absetzt, wenn ein Sensor feuert, und natürlich dann den jeweils aktuellen Zustand auch nimmt, bzw. bei solchen relativ schnell auf einander folgenden Events nur das letzte nimmt?
Ich meine auch, dass es so etwas ähnliches mal in der 0.6 oder 0.7 gab. Kann mich aber leider an den Attributnamen von damals nicht mehr erinnern.

Ich hoffe das war halbwegs verständlich? Und nützt auch anderen....
Wenn das alles nur totaler Humbug ist, dann bastele ich mir auch was mit DOIFs...

Vg

Thomas

[CoolTux]

Moin,

Ich hätte ein Feature-Request. Und zwar ist mir jetzt bei den abendlichen Lüftungsaktionen aufgefallen, dass ASC bzw. meine Fenstersensoren sehr nervös und direkt auf das Schließen nach dem kippen und anschliessende ganzen öffnen reagieren. Meist erkennt ASC dann das schließen, fährt die Rollade komplett runter macht aber, vermutlich wegen einer Min-Verzögerung bei automatischer Fahrt, das Hochfahren nicht mehr mit. Ergo ist, dass ich dann die Rolladen dann doch wieder manuell öffnen muss. Bei einem, Threestate-Sensor den ich hab, ist das Problem noch etwas komplexer...
Ich kann in den Sensoren keinen Delay oder so etwas einstellen, wie das bei einigen Homematic-Sensoren funktioniert, sondern die Dinger feuern im Prinzip direkt.
Ich könnte jetzt natürlich jeweils einen Dummy bauen, der per DoIf und waits das ganze regelt, aber ich denke, das jeder mit zwave-Sensoren das gleiche Problem haben wird, daher die Frage ob es evtl möglich wäre einen Delay einzubauen, den ASC wartet bis es einen Fahrbefehl absetzt, wenn ein Sensor feuert, und natürlich dann den jeweils aktuellen Zustand auch nimmt, bzw. bei solchen relativ schnell auf einander folgenden Events nur das letzte nimmt?
Ich meine auch, dass es so etwas ähnliches mal in der 0.6 oder 0.7 gab. Kann mich aber leider an den Attributnamen von damals nicht mehr erinnern.

Ich hoffe das war halbwegs verständlich? Und nützt auch anderen....
Wenn das alles nur totaler Humbug ist, dann bastele ich mir auch was mit DOIFs...

Vg

Thomas

Hallo Thomas,

Vielen Dank für Deine Idee. Leider ist es aktuell so das ich aus persönlichen Gründen bis mindestens Ende kommenden Jahres keine weiteren Features in ASC einbauen kann.


Grüße

[D3ltorohd]

So nun an Rain Protection. Es regnet aktuell, aber es fährt kein einziges Fenster.

das hab ich beim ASC_RainSensro angegeben :: 0_userdata.0.Jalousiesteuerung.Regnet_es:state 1:0 0

1 wäre regen, 0 keiner. Bei den Rollos ist Rainprotect auf on. Fehlt noch was ?

EDIT. Ich hab das jetzt mal auf rain / dry umgestellt, das mein DP diesen Wert ausgibt, nun fahren sie.

So nun sitze ich aber im dunkeln, sollte der Protect nicht nur greifen, wenn die Fenster offen sind,die meisten sind zu, aber der Rollo dennoch unten.

Oder liegt das hier dran ? zigbee.0.04cf8cdf3c772184.illuminance:state 400:15 ?

Fährt hoch ab 400 und mehr Lux, fährt aber dann erst wieder runter wenn 15 und weniger ? Oder schon wenn er die 400 unterschreitet ?

Ne ASC_ShuttersLastDrive :: rain protected Also wegen Rain Protect.

Hier wäre noch klasse, die höhe individuell ein zu stellen, am Rollo extra. Habe bodentiefe Fenster im Wohnzimmer, hier würde die hälfte reichen, weil nur oben ein Flügel ist.

[xerion]

Ich stehe vor dem gleichen Problem. Der Sonnensensor für ASC (ich nehme dafür eine Differenztemperatur) bringt mir morgens und abends Werte, die nicht ins "Muster" für tagsüber passen.
Verständnisfrage: könnte man nicht statt Perl im Statechange genauso einfach einen von Doif befüllen Dummy benutzen, der die im Statechange angegebenen Werte sinnvoll tageszeit/elevationabhängig normalisiert?

Anstelle von Perl kann man es auch mit folgenden DOIF nutzen:

Code Auswählen Erweitern

([Daemmerungswert:elevation] < 30)
(attr Rollo_Kueche_Strasse ASC_Shading_StateChange_SunnyCloudy 25000:20000)
(attr Rollo_WC ASC_Shading_StateChange_SunnyCloudy 25000:20000)
(save)
DOELSE
(attr Rollo_Kueche_Strasse ASC_Shading_StateChange_SunnyCloudy 35000:20000)
(attr Rollo_WC ASC_Shading_StateChange_SunnyCloudy 35000:20000)
(save)

[CoolTux]

So nun an Rain Protection. Es regnet aktuell, aber es fährt kein einziges Fenster.

das hab ich beim ASC_RainSensro angegeben :: 0_userdata.0.Jalousiesteuerung.Regnet_es:state 1:0 0

1 wäre regen, 0 keiner. Bei den Rollos ist Rainprotect auf on. Fehlt noch was ?

EDIT. Ich hab das jetzt mal auf rain / dry umgestellt, das mein DP diesen Wert ausgibt, nun fahren sie.

So nun sitze ich aber im dunkeln, sollte der Protect nicht nur greifen, wenn die Fenster offen sind,die meisten sind zu, aber der Rollo dennoch unten.

Oder liegt das hier dran ? zigbee.0.04cf8cdf3c772184.illuminance:state 400:15 ?

Fährt hoch ab 400 und mehr Lux, fährt aber dann erst wieder runter wenn 15 und weniger ? Oder schon wenn er die 400 unterschreitet ?

Ne ASC_ShuttersLastDrive :: rain protected Also wegen Rain Protect.

Hier wäre noch klasse, die höhe individuell ein zu stellen, am Rollo extra. Habe bodentiefe Fenster im Wohnzimmer, hier würde die hälfte reichen, weil nur oben ein Flügel ist.

ASC_rainSensor - DEVICENAME[:READINGNAME] MAXTRIGGER[:HYSTERESE] [CLOSEDPOS:[WAITINGTIME]] - der Inhalt ist eine Kombination aus Devicename, Readingname, Wert ab dem getriggert werden soll, Hysterese Wert ab dem der Status Regenschutz aufgehoben werden soll und der "wegen Regen geschlossen Position", sowie der Wartezeit bis dann tatsächlich die aktion ausgeführt wird.

[moonsorrox]

ich muss jetzt nochmal fragen wegen der Beschattung...
Die Beschattung wird bei mir um einiges zu früh beendet, die 3 Attribute die dafür in Frage kommen sind ja die folgenden:

Code Auswählen Erweitern

ASC_Shading_InOutAzimuth  196:291
ASC_Shading_MinMax_Elevation  25
ASC_Shading_StateChange_SunnyCloudy  180:35

jetzt hatte ich gedacht das ich mit dem attr ASC_Shading_InOutAzimuth 196:291 dieses erreiche, wobei es hier der Wert 291 zum entschatten wäre, die Zeit wäre ungefahr um 20 Uhr dann hat er den Winkel erreicht..!
Aber die Entschattung findet bereits ca. um 18.20 Uhr statt.
Welcher Wert müßte denn jetzt noch verändert werden damit ich die Entschattung ca. 20 Uhr habe..? Ich sehe da irgendwie nicht durch und wollte jetzt nicht irgend etwas verändern. 

[Wolle02]

ich muss jetzt nochmal fragen wegen der Beschattung...
Die Beschattung wird bei mir um einiges zu früh beendet, die 3 Attribute die dafür in Frage kommen sind ja die folgenden:

Code Auswählen Erweitern

ASC_Shading_InOutAzimuth  196:291
ASC_Shading_MinMax_Elevation  25
ASC_Shading_StateChange_SunnyCloudy  180:35

jetzt hatte ich gedacht das ich mit dem attr ASC_Shading_InOutAzimuth 196:291 dieses erreiche, wobei es hier der Wert 291 zum entschatten wäre, die Zeit wäre ungefahr um 20 Uhr dann hat er den Winkel erreicht..!
Aber die Entschattung findet bereits ca. um 18.20 Uhr statt.
Welcher Wert müßte denn jetzt noch verändert werden damit ich die Entschattung ca. 20 Uhr habe..? Ich sehe da irgendwie nicht durch und wollte jetzt nicht irgend etwas verändern. 

Wahrscheinlich unterschreitet die Sonne gg. 18.20 Uhr den Höhenwinkel von 25°.