[ASC] Seltsames Verhalten bei RainProtection

Begonnen von Romoker, 05 April 2022, 22:37:41

Vorheriges Thema - Nächstes Thema

Romoker

Hallo CoolTux,

aktuell zieht gerade die angekündigte Unwetterfront über das Münsterland. Ein schöner natürlicher Testfall, bei dem die Kombination aus Wind- und Rain-protection leider wieder nicht funktioniert hat.

Ich hatte ja schon berichtet, dass die Kombination aus Wind- und Rain-protection Probleme bereitete. Deshalb hatte ich für die Markise wind-protection deaktiviert. Das habe ich vor ca. 14 Tagen wieder rückgängig gemacht, da die Markise im Wind ziemlich wackelte. So weit, so gut - bis heute. Die Markise ist kurz vor dem Unwetter korrekt in rain-protected gefahren, dann aber durch ein wind-unprotected wieder in die Schattenposition 90 gewechselt, obwohl der rainSensor immer noch den Wert rain hatte. Ich habe die Markise dann manuell reingefahren.

Ich kann leider nicht mit einem ASC-Debug-Log dienen, da ich aber ein paar Events meiner Rollos in einem FileLog aufzeichne, kann ich das Verhalten nachvollziehen:
2022-05-18_13:52:00 Markise finalPos: 0
2022-05-18_13:52:00 Markise ASC_ShuttersLastDrive: wind protected
2022-05-18_14:01:26 Markise ASC_ShuttersLastDrive: shading in
2022-05-18_14:01:59 Markise finalPos: 90
2022-05-18_16:35:51 Markise ASC_ShadingMessage: INFO: current shading status is 'out reserved' - next check in 20m
2022-05-18_16:51:58 Markise ASC_ShadingMessage: INFO: current shading status is 'in reserved' - next check in 20m
2022-05-18_17:03:00 Markise ASC_ShadingMessage: INFO: current shading status is 'in' - next check in 20m
2022-05-18_17:35:51 Markise ASC_ShadingMessage: INFO: current shading status is 'out' - next check in 10m
2022-05-18_17:36:29 Markise finalPos: 0
2022-05-18_17:36:29 Markise ASC_ShuttersLastDrive: shading out
2022-05-18_18:05:51 Markise ASC_ShadingMessage: INFO: current shading status is 'out' - next check in 10m
2022-05-19_13:05:15 Markise ASC_ShadingMessage: INFO: current shading status is 'in reserved' - next check in 10m
2022-05-19_13:15:48 Markise ASC_ShadingMessage: INFO: current shading status is 'in' - next check in 20m
2022-05-19_13:15:52 Markise ASC_ShuttersLastDrive: shading in
2022-05-19_13:16:24 Markise finalPos: 90
2022-05-19_14:30:10 Markise finalPos: 0
2022-05-19_14:30:10 Markise ASC_ShuttersLastDrive: rain protected
2022-05-19_15:32:19 Markise ASC_ShuttersLastDrive: wind un-protected
2022-05-19_15:32:52 Markise finalPos: 90
2022-05-19_15:39:30 Markise ASC_ShuttersLastDrive: manual
2022-05-19_15:40:12 Markise finalPos: 0


Folgendes fällt mir auf:
Seit gestern 13:52 Uhr ist die Markise im Status "wind protected".
Trotzdem fährt die Markise neun Minuten später in die Schattenposition. Das darf nicht passieren - war gestern aber unschädlich.
Heute um 13:15 Uhr fährt die Markise wieder in die Schattenposition.
Um 14:30 Uhr hat mein Regensensor rechtzeitig den heranziehenden Regen bemerkt, die Markise ist in rain-protected gefahren.
62 Minuten später um 15:32 Uhr kommt ein "wind un-protected" daher, warum auch immer,  und fährt die Markise wieder in den Schattenmodus (finalPos 90), obwohl der Regensensor immer noch auf "rain" steht. Das darf auch nicht passieren. Ich musste die Markise dann im Regen manuell einfahren.

Vielleicht bin ich ja der einzige ASC-Markisen-Nutzer, der diese Probleme hat. Ich kann leider nicht sagen, ob das Verhalten an deiner ASC-Testversion liegt, die bei mir noch aktiv ist. Ich werde jetzt auf jeden Fall die ASC-Testversion deinstallieren und Wind-Protection dauerhaft deaktivieren. Für den Windschutz werde ich mir ein notify oder DOIF bauen, das dann die Wind-Wächterfunktion übernimmt. Damit kann ich - und meine Markise - dann leben.

Viele Grüße

BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

CoolTux

Ich verstehe was Du meinst und kann das auch mit dem Code nachvollziehen. Es gibt keine Gegenprüfung zwischen Regen, Wind und Beschattung.
Habe nur eine Frage. Was sollte Vorrang haben, Regen oder Wind Schutz?
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

Beta-User

Wenn nichtkonfigurierbar: bitte Wind sollte vorgehen!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Romoker

Ich stimme auch für den Vorschlag, dass Windschutz Vorrang haben sollte. Wind kann einen größeren Schaden anrichten als Regen.

Viele Grüße
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

CoolTux

Ich werde versuchen eine entsprechende Lösung in den nächsten Wochen zu erarbeiten.
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

Hallo CoolTux,
ich habe bei meinen Markisen RainProtection zwar noch nicht aktiv, hatte aber gerade dennoch "Spaß" mit Regen. Kam aber nicht vom Regen sondern durch "WindProtection"  :-[
Ich habe letzten Sonntag für meine Markisen WindProtection aktiviert. Hier die Attribute:

attr R_DumRAU ASC 2
attr R_DumRAU ASC_BlockingTime_afterManual 1800
attr R_DumRAU ASC_BrightnessSensor Brightness_Dum
attr R_DumRAU ASC_Down time
attr R_DumRAU ASC_DriveUpMaxDuration 65
attr R_DumRAU ASC_Drive_Delay 0
attr R_DumRAU ASC_Drive_DelayStart 0
attr R_DumRAU ASC_Mode_Down off
attr R_DumRAU ASC_Mode_Up off
attr R_DumRAU ASC_Pos_Reading pct
attr R_DumRAU ASC_Shading_InOutAzimuth 85:290
attr R_DumRAU ASC_Shading_MinMax_Elevation 28:70
attr R_DumRAU ASC_Shading_Min_OutsideTemperature 18
attr R_DumRAU ASC_Shading_Mode always
attr R_DumRAU ASC_Shading_Pos 0
attr R_DumRAU ASC_Shading_StateChange_SunnyCloudy 60000:30000 1
attr R_DumRAU ASC_Shading_WaitingPeriod 60
attr R_DumRAU ASC_ShuttersPlace awning
attr R_DumRAU ASC_TempSensor di_AvgTemp:temp
attr R_DumRAU ASC_Up time
attr R_DumRAU ASC_WindParameters 35:10 100
attr R_DumRAU ASC_WindProtection on

Dies ist ein Dummy Device zum Testen, ich habe aber die identischen Einstellungen an allen Markisen. Heute Abend fing es an zu regnen und zu stürmen. Vorher waren die Markisen mit "shading out" reingefahren, LastPos dürfte also 0 gewesen sein. Der Wind überschritt den oberen Schwellwert, ShuttersLastDrive blieb aber auf "shading out". Dann wurde die Hysterese unterschritten, ShuttersLastDrive ging in "wind un-protected" und die Markisen fuhren fröhlich raus (für die Steuerung unbedeutend aber es regnete noch). Ich habe das Ganze mit dem Dummy nachgestellt und siehe da, wenn LastDrive erst einmal auf 0 steht (wie durch shading out ausgelöst) fährt die Markise entsprechend den Windwerten rein und raus. Immer wieder und völlig unabhängig von Brightness, Elevation und Azimuth. Nach dem Rausfahren durch "wind un-protected" kommt zwar ein "shading out" wenn Br/El/Az nicht eingehalten werden und die Markise fährt wieder rein. Sobald aber ein "wind protected" ausgelöst wurde und darauf dann irgendwann un-protected kommt wiederholt sich das Spiel.
Mein Vorschlag an dieser Stelle: Rain oder Wind Protection Prio ist im Grunde ganz egal. Wenn irgendeine Protection zuschlägt sollte die Markise immer in die Schutzhülle fahren und alle Werte auf Reset. Erst eine normale "shading in" Bedingung sollte dann die Markise wieder in die Shading Position bringen. Nach einer Protection in die LastPos zu fahren ist zumindest für mich eine schlechte Lösung.
Wie siehst du das? Wäre es grundsätzlich möglich im Fall von "awning" so zu verfahren? Über Feedback würde ich mich freuen.

Gruß Reinhard

CoolTux

Guten Morgen,

Das von Dir beobachtete Verhalten könnte mit ShadingPos 0 zu tun haben. Ich gehe davon aus das diese Position auch die ClosePos ist. Es ist immer besser wenn die jeweiligen Positionen unterschiedlich sind. Kannst Du es mit ShadingPos 1 bitte testen.


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

Guten Morgen :)
Die ShadingPos hat auf das Verhalten keinerlei Einfluss. Wenn man davon absieht, dass die nach wind un-protected angefahrene Position der ShadingPos entspricht, also der LastPos. Das kann ich auch leicht verifizieren indem ich die LastPos mit einem anderen Wert überschreibe. Dann wird die überschriebene Postion angefahren und im ASCDevice auch angezeigt. Aus meiner Sicht: Nach einem un-protected wird die LastPos bedingungslos angefahren. Für Rain habe ich das noch nicht getestet, könnte ich bei Bedarf aber auch machen.

Gruß Reinhard

Reinhard.M

Guten Morgen CoolTux,
ich versuche gerade einen Workaround für das Problem zu finden. Ist aber nicht so einfach. Wahrscheinlich hast du aktuell gerade keine Zeit dafür. Kannst du mir sagen, ob du grundsätzlich eine Möglichkeit siehst das zu fixen?

Gruß Reinhard

CoolTux

Aktuell leider nicht. Mir fehlt einfach die Zeit.
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

Das dachte ich mir schon.
Ich habe ein DOIF zusammengebaut das die "LastPos" der Markise im Protection Fall mit dem "eingefahren" Wert überschreibt und damit verhindert, dass die Markise nach dem Wegfall der Protection Situation in die vermeintlich letzte Position fährt. Das ist nach einer ganz normalen Shading Fahrt immer die "inshading" Position. Das DOIF ist auf Regen und Wind Protection für Markisen ausgelegt. Sollte jemand der hier mitliest Interesse haben kann ich das DOIF zur Verfügung Stellen.

fuchsnase

Zitat von: Reinhard.M am 29 Mai 2022, 13:29:54[...]
Ich habe ein DOIF zusammengebaut das die "LastPos" der Markise im Protection Fall mit dem "eingefahren" Wert überschreibt und damit verhindert, dass die Markise nach dem Wegfall der Protection Situation in die vermeintlich letzte Position fährt. Das ist nach einer ganz normalen Shading Fahrt immer die "inshading" Position. Das DOIF ist auf Regen und Wind Protection für Markisen ausgelegt. Sollte jemand der hier mitliest Interesse haben kann ich das DOIF zur Verfügung Stellen.

Ist zwar schon eine Weile her aber ich habe das gleiche Problem und wäre deshalb an Deiner Lösung interessiert.

Gruß
fuchsnase

Reinhard.M

War schon lange nicht mehr im Forum, kann ich aber bei weiterem Interesse zur Verfügung stellen.

Gruß Reinhard 

fuchsnase

Das würde mir sicherlich weiterhelfen.

Gruß

Reinhard.M

Hallo Fuchsnase,

bin aktuell etwas knapp mit Zeit daher hier die Raw Definition mit allen wichtigen Informationen. Ich denke, die betroffenen Devices kannst du leicht durch deine eigenen in den Attributen ersetzen.

Gruß Reinhard

defmod di_Protection DOIF ProtectionSense\
{\
  my $ProtDev1  = AttrVal("$SELF", "ProtDev1", "error");;\
  my $ProtDev2  = AttrVal("$SELF", "ProtDev2", "error");;\
  my $ProtDev3  = AttrVal("$SELF", "ProtDev3", "error");;\
  my $WindMax   = ::ascAPIget("WindMax", "$ProtDev1");;\
  my $WindMin   = ::ascAPIget("WindMin", "$ProtDev1");;\
  my $LastPos   = ::ascAPIget("LastPos", "$ProtDev1") & ::ascAPIget("LastPos", "$ProtDev2") & ::ascAPIget("LastPos", "$ProtDev3");;\
  my $ProtVal   = [$SELF:ProtVal];;\
  my $rain      = [$SELF:rain] + [$SELF:WH4000_rain];;\
  my $wind      = [$SELF:WH4000_wind];;\
  my $pct       = [$SELF:pct1] & [$SELF:pct2] & [$SELF:pct3];;\
  if (($wind >= $WindMax or $rain > 0.5) and $ProtVal eq "unprotected") {\
    $ProtVal = "protected";;\
    set_Exec("Delay_Timer", 1, "set_Reading('ProtVal', '$ProtVal', 1)");;\
  } elsif (($wind <= $WindMin and $rain < 0.5) and $ProtVal ne "unprotected") {\
    $ProtVal = "unprotected";;\
    set_Exec("Delay_Timer", 1, "set_Reading('ProtVal', '$ProtVal', 1)");;\
  }\
  if ($ProtVal eq "protected" and $pct == 100 and $LastPos != 100) {\
    ::ascAPIset("LastPos", "$ProtDev1", 100);;\
    ::ascAPIset("LastPos", "$ProtDev2", 100);;\
    ::ascAPIset("LastPos", "$ProtDev3", 100);;\
    $LastPos = $LastPos."-reset";;\
  }\
  set_State("$ProtVal --> pct: $pct # LastPos: $LastPos");;\
}\
init\
{\
  set_Reading('ProtVal', "unprotected");;\
  set_Reading('rain', 0);;\
  set_Reading('WH4000_wind', 0);;\
}
attr di_Protection userattr ProtDev1 ProtDev2 ProtDev3
attr di_Protection DOIF_Readings pct1:[HM_RAU_Sued:pct],\
pct2:[HM_RAM_West:pct],\
pct3:[HM_RAU_FallArm:pct]
attr di_Protection ProtDev1 HM_RAU_Sued
attr di_Protection ProtDev2 HM_RAM_West
attr di_Protection ProtDev3 HM_RAU_FallArm
attr di_Protection event-on-change-reading .*
attr di_Protection event_Readings WH4000_wind:[WH4000SE:wind_gust],\
WH4000_rain:[WH4000SE:israining],\
rain:[di_Rain:rain]
attr di_Protection group other
attr di_Protection room ASC_Rollos
attr di_Protection sortby 40

setstate di_Protection protected --> pct: 100 # LastPos: 100
setstate di_Protection 2023-07-25 11:22:06 ProtVal protected
setstate di_Protection 2023-07-25 10:51:30 WH4000_rain 0
setstate di_Protection 2023-07-25 11:35:24 WH4000_wind 9.4
setstate di_Protection 2023-07-25 11:35:24 block_ProtectionSense executed
setstate di_Protection 2023-07-17 06:41:38 block_init executed
setstate di_Protection 2023-07-25 11:22:06 e_di_Protection_ProtVal protected
setstate di_Protection 2023-07-25 10:51:30 e_di_Protection_WH4000_rain 0
setstate di_Protection 2023-07-25 11:35:24 e_di_Protection_WH4000_wind 9.4
setstate di_Protection 2023-07-24 18:14:39 e_di_Protection_pct1 100
setstate di_Protection 2023-07-24 18:14:37 e_di_Protection_pct2 100
setstate di_Protection 2023-07-24 18:14:18 e_di_Protection_pct3 100
setstate di_Protection 2023-07-25 11:22:05 e_di_Protection_rain 1
setstate di_Protection 2023-07-18 14:31:20 mode enabled
setstate di_Protection 2023-07-24 18:14:39 pct1 100
setstate di_Protection 2023-07-24 18:14:37 pct2 100
setstate di_Protection 2023-07-24 18:14:18 pct3 100
setstate di_Protection 2023-07-25 11:23:48 rain 1
setstate di_Protection 2023-07-25 11:35:24 state protected --> pct: 100 # LastPos: 100