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

[CoolTux]

Nein, nicht wirklich. Das ganze sollte einfacher (in der Konfiguration) sein. Man stellt hierzu einen weiteren Parameter für den Privacy-Brightnesswert zur Verfügung.

Aktuell:

Code Auswählen Erweitern

ASC_BrightnessSensor - DEVICE[:READING] WERT-MORGENS:WERT-ABENDS /

Mit Brightness-Privacy:

Code Auswählen Erweitern

ASC_BrightnessSensor - DEVICE[:READING] WERT-MORGENS:WERT-ABENDS:WERT-PRIVACY-ABENDS

Oder vielleicht besser umgedreht:

Code Auswählen Erweitern

ASC_BrightnessSensor - DEVICE[:READING] WERT-MORGENS:WERT-PRIVACY-ABENDS:WERT-ABENDS

Die Idee finde ich gut. Ich trage es als Issues ein.

[FunkOdyssey]

Danke. Danke. Danke.

[kjmEjfu]

Die Idee finde ich gut. Ich trage es als Issues ein.

Wenn du schon daran baust, könntest du denn eventuell auch gleich mit umsetzen, dass man für die Abschattung einen anderen Sensor als für morgens/abends nutzen kann?

[CoolTux]

Wenn du schon daran baust, könntest du denn eventuell auch gleich mit umsetzen, dass man für die Abschattung einen anderen Sensor als für morgens/abends nutzen kann?

Ist das Anliegen denn in der Tat Praxisnahe? Ja ich weiß Du hattest da glaube Probleme mit der Auflösung. Für Morgens Abends war Dein Sensor nicht fein genug. Aber kann man da nicht mit einem Dummy arbeiten der entsprechend aus den Werten von 2 Sensoren mit ausgleich gefüttert wird?

[majestro84]

Die Idee finde ich gut. Ich trage es als Issues ein.

Die Idee finde ich gut. Ich trage es als Issues ein.

Da die Frage habe ich schon häufiger auf gekommen ist sollte man dann noch ein Wert für privacy morgens hinzufügen.

Code Auswählen Erweitern

ASC_BrightnessSensor - DEVICE[:READING] WERT-MORGENS:WERT-PRIVACY-MORGENS:WERT-ABENDS:WERT-PRIVACY-ABENDS

Gruß Alex

[MCh76]

Puh also das auf alle Anwendungsbeispiele zu erklären ist doch etwas viel.
Es wird sowohl aus Zustand wie auch auf Events reagiert. Schaltet die Residents von home auf absent und ein Fenster ist offen und selfDefense ist on wird das Rollo an dem Fenster geschlossen. Es wird auch geschlossen wenn das Fenster zu ist aber selfDefense Mode auf absent.
Und es wird geschlossen wenn es Nacht ist und ASC_Mode_Up oder Down auf always oder absent steht.

ich verstehe dass es zig anwendungsbeispiele gibt und sicher nicht alle konstellationen im detail beschrieben werden können.
das thema selfDefense hab ich jetzt persönlich noch gar nicht angegangen, wollte "einfach" starten.

daher interessiert mich aktuell nur die eine frage brennend:
wenn ich in den urlaub fahre, und folglich irgendwann das residents device von "absent" auf "gone" wechselt, wird dann am folgenden urlaubstag ein ASC_Mode_Down/ASC_Mode_Up das auf absent eingestellt ist, dazu führen dass ganz normal wieder gefahren wird (analog zum verhalten wenn residents auf absent steht)?

[ch.eick]

Für deinen Anwendungsfall wäre mir jetzt nicht klar, ob alle Montage wie $we behandelt werden sollen (und sich daher auf alle Rollladen auswirken sollen) oder ob das nur einzelne Rollläden sind, der Rest aber "normal" fahren soll. Wenn global, kannst du schlicht einen weekEnd.holiday definieren, der alle Montage enthält (cref-Beispiel: "3  0 Mon 05 Jeder Montag In Mai"), den in holiday2we einbinden und ein noWeekEnd dazu definieren, das du dann für die "muß doch mal Arbeiten"-Montage deiner Frau verwendest. Das noWeekEnd überspielt dann aber alle Feiertagskalender (auch z.B. Ostermontag), _wenn_ es dort einen Entrag gibt.

Oder du steuerst eben den/die einzelnen Rollladen Roommate-basiert. Dann mußt du halt dafür sorgen, dass das entsprechende Roommate-Device irgendwann "aufwacht".

Generell:
Das Thema wäre m.E. einen gesonderten Thread wert. Es gibt ziemlich sicher zu dem ganzen Thema mehrere unterschiedliche Lösungsansätze, und ich mag nicht behaupten, dass das o.g. der "beste" ist. Funktioniert aber, soweit erkennbar, und hat den Vorteil, dass der "reguläre Kalender" genutzt werden kann.

Vielen Dank für den Hinweis, Deine Implementierung schau ich mir einmal an.

In meinem Fall wäre es jeder Montag, was ich jedoch gerne generalisieren wollte und lieber in Form eines Arbeitskalenders implementieren würde.
Der Hinweis auf die myUtils war mir auch schon gekommen, das wäre dann wie beim Abfallkalender. Gedanklich fehlt mir dann nur noch, wie ich im ASC einzelne Attribute verändern muss, um meine Fahrwünsche um zu setzen. Diese Eingriffe werden doch dann eventuell als manuelle Fahrt gewertet?

Das mit den holiday Kalendern wirkt sich ja auf eine Erweiterung von $we im FHEM aus. Meiner bescheidenen Meinung nach ist das ja auch bereits so eine gewachsen vorgehensweise. Im ASC wird somit ein Wochenende und Feiertag zusammengefasst und als $we Wochenende betrachtet. Verstanden habe ich, dass ein Arbeitskalender noch nicht im ASC flexibel betrachtet wurde, was einen weiteren Thread sicherlich wert wäre.

Gruß
   Christian

[Beta-User]

In meinem Fall wäre es jeder Montag, was ich jedoch gerne generalisieren wollte und lieber in Form eines Arbeitskalenders implementieren würde.

Ich verstehe nicht, was ein "Arbeitskalender" sein soll.

Gedanklich fehlt mir dann nur noch, wie ich im ASC einzelne Attribute verändern muss, um meine Fahrwünsche um zu setzen. Diese Eingriffe werden doch dann eventuell als manuelle Fahrt gewertet?

Nein, was ASC kennt (über IsWe()/die Zeitgrenzen, die dazu eingetragen sind oder über Roommates), wird innerhalb der Automatik verwertet (das war ja der gedankliche Hintergrund des Einheitsmoduls, das "seine" Soll-Zustände zum jeweiligen Zeitpunkt kennt...).

Das mit den holiday Kalendern wirkt sich ja auf eine Erweiterung von $we im FHEM aus. Meiner bescheidenen Meinung nach ist das ja auch bereits so eine gewachsen vorgehensweise. Im ASC wird somit ein Wochenende und Feiertag zusammengefasst und als $we Wochenende betrachtet. Verstanden habe ich, dass ein Arbeitskalender noch nicht im ASC flexibel betrachtet wurde, was einen weiteren Thread sicherlich wert wäre.

Korrekt, entsprechende Einträge in holiday2we-Devices wirken sich auf die gesamte Steuerung aus. Ob man das haben will oder nicht, ist eine Vorfrage - deswegen hatte ich ja gefragt, was du "eigentlich" haben willst... Jedenfalls: auch ASC berücksichtigt diese Vorgaben automatisch und in gewissen Grenzen auch bei Änderungen (ein einmal gesetzter Timer (weil jetzt morgen doch Feiertag/freier Tag ist) wird nachträglich allerdings nur dann geändert, wenn es nicht grade der nächste ist).

Und da ich immer noch nicht weiß, was ein "Arbeitskalender" sein soll, ist alles weitere Spekulation. Für mich klingt es danach, als sollte der Arbeitskalender ein Calendar-Device sein, das bei der asleep-Steuerung der Roommates verwertet werden kann. Wie das prinzipiell geht, steht in der commandref, und faik arbeitet Loredo grade an einem Modul, das direkt mit RESIDENTS&Co zusammenarbeitet und mehrere "Kalender" verwenden kann. (Ich nutze aber beides bisher nicht, das also nur "vom hörensagen").

M.E. hilfreich wäre es, wenn du künftig die TYPE-Angaben hinzufügen könntest (oder den Hinweis, dass ein/mehrere ical relevant sind, und was da ggf. im Einzelnen wie drin steht), dann kann jedenfalls ich mich leichter orientieren...

[ch.eick]

Hallo nochmal,

mit Arbeitskalender meine ich einen oder mehrere Kalender für die Hausbewohner, wo jeder seine Arbeitstage eintragen kann.
Diese Tage können ja je nach Arbeitswoche, Urlaub oder Schichtarbeit variieren und ein Feiertag oder Wochenende ist bei vielen ja auch ein Arbeitstag.

Ich denke auch, dass das besser zu Residents&Co Roommate paßt und dann über den Status (home,absent, sleeping,...) in ASC eingebunden
werden sollte. Ich suche mal nach dem anderen Projekt und verfolge das dann noch etwas länger.

Vielen Dank für die Hinweise
      Christian

[CoolTux]

ich verstehe dass es zig anwendungsbeispiele gibt und sicher nicht alle konstellationen im detail beschrieben werden können.
das thema selfDefense hab ich jetzt persönlich noch gar nicht angegangen, wollte "einfach" starten.

daher interessiert mich aktuell nur die eine frage brennend:
wenn ich in den urlaub fahre, und folglich irgendwann das residents device von "absent" auf "gone" wechselt, wird dann am folgenden urlaubstag ein ASC_Mode_Down/ASC_Mode_Up das auf absent eingestellt ist, dazu führen dass ganz normal wieder gefahren wird (analog zum verhalten wenn residents auf absent steht)?

Nein. Wenn gone drin steht und du absent eingestellt hast wird nicht mehr gefahren. Muss ich mir noch mal anschauen der Bedarf.

[kjmEjfu]

Ist das Anliegen denn in der Tat Praxisnahe? Ja ich weiß Du hattest da glaube Probleme mit der Auflösung. Für Morgens Abends war Dein Sensor nicht fein genug. Aber kann man da nicht mit einem Dummy arbeiten der entsprechend aus den Werten von 2 Sensoren mit ausgleich gefüttert wird?

Nee, meine Sensoren lösen prima auf.

Mein Praxisfall sieht so aus, dass man dann z.B. die Abschattung statt über Brightness auch über Differenztemperatur steuern könnte (ist manchmal weitaus passender als reine Helligkeit), während morgens und abends ganz normal weiterhin Brightness genutzt wird.

[eurofinder]

@CoolTux:

Wer sagt das der Sensor ein Innensensor ist. Hierbei gibg es nur darum da einen anderen Sensor als global angeben zu können.

OK, so kann man das auch sehen Gerade wenn es sowohl Innen- als auch Aussensensor sein kann, dann wäre immer noch ASC_Shading_Min_Temperature verständlicher als ASC_Shading_Min_OutsideTemperature

Mal eine allgemeine Frage an alle:
Ich nutze von Homematic den HmIP-SLO Helligkeitssensor in ASC_BrightnessSensor (zum Süden ausgerichtet). Leider habe ich immer mal wieder das Problem, dass auch bei Bewölkung die Helligkeitswerte so hoch sind, dass die Rollläden in die Beschattung fahren. Hab jetzt schon viel mit ASC_Shading_StateChange_Sunny bzw. ASC_Shading_StateChange_Cloudy gespielt, ich finde aber irgendiwe keine passenden Werte. Setze ich ASC_Shading_StateChange_Sunny höher, scheint mir bei gutem Wetter die Sonne rein, dafür aber eben nicht bei starker Bewölkung - entsprechend umgekehrt bei ASC_Shading_StateChange_Cloudy.
Wie habt ihr das in den Griff bekommen. Nutzt ihr mehr als einen Helligkeitssensor? Wie könnte man ggf. feststellen ob es gerade bewölkt ist und in Abhängigkeit davon Shading aktivieren/deaktivieren?

Würde mich über Hinweise/Anregungen freuen.

Gruß
eurofinder
 

[moonsorrox]

da ich ja immer noch am Feintuning bin, hatte ich wohl etwas vergessen.
Gestern stand im Rollladen Device eine morgendliche Zeit zum Öffnen von 31.07.2019 - 07:55 drin, aber heute morgen war der Rollladen noch geschlossen.
Diese Attribute brauche ich doch alle zum morgendlichen Öffnen, richtig?

Code Auswählen Erweitern

ASC_Mode_Up always
ASC_Up time
ASC_Time_Up_Early 07:55

EDIT:// was mich wundert das ASC_Time_DriveUp auf AutoShuttersControl off steht
Ok das habe ich jetzt gefunden muss natürlich auf "on" stehen

Aktuell beschäftige ich mich noch mit der Beschattung

In den Rollladendevices benötigt ihr ein Helligkeitssensor als Attribut "ASC_BrightnessSensor", sofern noch nicht vorhanden. Findet der Sensor nur für die Beschattung Verwendung ist der Wert DEVICENAME[:READING] ausreichend.

Ich habe meinen "ASC_BrightnessSensor" so eingetragen

Code Auswählen Erweitern

Temperatur_Terrasse:luminosity

das habe ich auch probiert

Code Auswählen Erweitern

Temperatur_Terrasse[:luminosity]

aktuell so

Code Auswählen Erweitern

Temperatur_Terrasse:luminosity
Aber es findet keine Beschattung statt. Was habe ich vergessen, oder falsch eingestellt.?

Hier mein aktuelles list

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/Erdgeschoss.cfg
   DEF        5DDDBF
   FUUID      5c4319dd-f33f-a6c6-528b-1e1d849527d97b05
   HMUSB_MSGCNT 2
   HMUSB_RAWMSG R489326EE,0001,1747C323,FF,FFBA,12A4105DDDBF1EA12106015A0047
   HMUSB_RSSI -70
   HMUSB_TIME 2019-07-31 17:08:19
   IODev      HMUSB
   LASTInputDev HMUSB
   MSGCNT     2
   NAME       KU_Rollladen
   NOTIFYDEV  global
   NR         2249
   NTFY_ORDER 50-KU_Rollladen
   STATE      45
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:12 - t:10 s:5DDDBF d:1EA121 06015A0047
   protLastRcv 2019-07-31 17:08:18
   protRcv    1 last_at:2019-07-31 17:08:18
   protSnd    2 last_at:2019-07-31 17:08:18
   protState  CMDs_done
   rssi_HMUSB cnt:1 min:-71 max:-71 avg:-71 lst:-71
   rssi_at_HMUSB cnt:2 min:-70 max:-70 avg:-70 lst:-70
   READINGS:
     2019-07-31 17:06:54   ASC_Enable      on
     2019-07-31 17:08:19   ASC_ShuttersLastDrive none
     2019-07-31 17:19:53   ASC_Time_DriveDown 31.07.2019 - 21:59
     2019-07-31 17:19:53   ASC_Time_DriveUp  1.08.2019 - 07:55
     2019-07-31 15:31:58   CommandAccepted yes
     2018-06-15 00:26:40   D-firmware      2.11
     2018-06-15 00:26:40   D-serialNr      OEQ1222412
     2019-06-26 23:37:42   PairedTo        0x1EA121
     2018-06-15 17:07:42   R-driveDown     22 s
     2018-06-15 00:45:06   R-driveTurn     0.5 s
     2018-06-15 17:08:28   R-driveUp       23.5 s
     2018-06-15 00:45:05   R-pairCentral   0x1EA121
     2018-07-16 17:28:36   R-self01-lgActionType jmpToTarget
     2018-07-16 17:28:36   R-self01-lgOnLevel 100 %
     2018-07-16 17:28:36   R-self01-shActionType jmpToTarget
     2018-07-16 17:28:36   R-self01-shOnLevel 100 %
     2018-07-16 17:28:37   R-self02-lgActionType jmpToTarget
     2018-07-16 17:28:37   R-self02-lgOnLevel 100 %
     2018-07-16 17:28:37   R-self02-shActionType jmpToTarget
     2018-07-16 17:28:37   R-self02-shOnLevel 100 %
     2018-06-15 00:45:06   R-sign          off
     2019-06-26 23:37:42   RegL_00.        00:00 02:01 0A:1E 0B:A1 0C:21 15:FF 18:00
     2019-06-26 23:37:43   RegL_01.        00:00 08:00 09:00 0A:00 0B:00 0C:DC 0D:00 0E:EB 0F:05 10:00 30:06 56:00 57:24
     2019-07-31 17:08:09   associatedWith  Rollladenautomatik
     2019-07-31 17:08:18   deviceMsg       45 (to vccu)
     2019-07-31 17:08:18   level           45
     2019-07-31 17:08:18   motor           stop:45
     2019-07-31 17:08:18   pct             45
     2019-06-26 23:37:41   powerOn         2019-06-26 23:37:41
     2019-07-31 17:08:18   recentStateType info
     2019-07-31 17:08:18   state           45
     2019-07-31 17:08:18   timedOn         off
   helper:
     HM_CMDNR   18
     cSnd       ,011EA1215DDDBF010E
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5DDDBF,00,00,00
       nextSend   1564585699.10589
       prefIO     
       rxt        0
       vccu       
       p:
         5DDDBF
         00
         00
         00
     mRssi:
       mNo        12
       io:
         HMUSB:
           -68
           -68
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMUSB
       flg        A
       ts         1564585698.91032
       ack:
         HASH(0x5397800)
         1280021EA1215DDDBF00
     rssi:
       HMUSB:
         avg        -71
         cnt        1
         lst        -71
         max        -71
         min        -71
       at_HMUSB:
         avg        -70
         cnt        2
         lst        -70
         max        -70
         min        -70
     tmpl:
Attributes:
   ASC        2
   ASC_AutoAstroModeEvening CIVIL
   ASC_BrightnessSensor Temperatur_Terrasse:luminosity
   ASC_Closed_Pos 15
   ASC_Down   astro
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Pos_Reading pct
   ASC_Shading_Angle_Left 90
   ASC_Shading_Angle_Right 20
   ASC_Shading_Direction 270
   ASC_Shading_MinMax_Elevation 25.0:100.0
   ASC_Shading_Min_OutsideTemperature 22
   ASC_Shading_Mode always
   ASC_Shading_Pos 20
   ASC_Shading_StateChange_Cloudy 700
   ASC_Shading_StateChange_Sunny 20
   ASC_TempSensor Temperatur_Terrasse:temperature
   ASC_Time_Up_Early 07:55
   ASC_Time_Up_WE_Holiday 08:10
   ASC_Up     time
   IODev      HMUSB
   alias      Küche - Rollladen
   autoReadReg 4_reqStatus
   devStateIcon Oben:fts_shutter_10@#00FA9A  Unten:fts_shutter_100@blue Home:fts_shutter_30@blue 9\d.*:fts_shutter_10@#00bfff  8\d.*:fts_shutter_20@#00bfff  7\d.*:fts_shutter_30@#blue  6\d.*:fts_shutter_40@#00bfff  5\d.*:fts_shutter_50@#20B2AA  4\d.*:fts_shutter_60@#00bfff  3\d.*:fts_shutter_70@#00bfff  2\d.*:fts_shutter_80@#00bfff  1\d.*:fts_shutter_90@#FF6D00  0\d.*:fts_shutter_1@blue
   eventMap   on:Oben stop:Stop off:Unten 15:15 45:45 75:Home
   expert     2_raw
   firmware   2.11
   group      Rollläden EG
   icon       fts_shutter_automatic@#F0E68C
   model      HM-LC-BL1-FM
   peerIDs    00000000,
   room       Automation,Küche
   serialNr   OEQ1222412
   sortby     18
   subType    blindActuator
   userattr   ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness ASC_DriveUpMaxDuration ASC_Drive_Offset ASC_Drive_OffsetStart ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownTime_beforNightClose ASC_PrivacyDown_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Exclude:on,off ASC_Self_Defense_Mode:absent,gone ASC_Shading_Angle_Left ASC_Shading_Angle_Right ASC_Shading_Direction ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate
   webCmd     Oben:Stop:Unten:15:45:Home

[MCh76]

Nein. Wenn gone drin steht und du absent eingestellt hast wird nicht mehr gefahren. Muss ich mir noch mal anschauen der Bedarf.

danke für die aufklärung. für mich ist ein längeres wochenende oder eine dienstreise, natürlich erst recht ein urlaub, eine abwesenheit, genauso wie wenn ich nur wenige stunden weg bin.
daher wäre es für mich ideal wenn sich die rolläden in beiden fällen gleich verhalten.
ich werde es nun so lösen dass ich mir im residents device ein userreading erstelle, in welchem ich aus den 7 status die per definition sein können, auf "ASC-konforme" werte "home" und "absent" mache. im ASC werde ich dann dieses neue reading als relevantes für den anwesenheitsstatus setzen. 

[ch.eick]

ich werde es nun so lösen dass ich mir im residents device ein userreading erstelle, in welchem ich aus den 7 status die per definition sein können, auf "ASC-konforme" werte "home" und "absent" mache. im ASC werde ich dann dieses neue reading als relevantes für den anwesenheitsstatus setzen.

Das entspricht dann ja auch meiner Lösungsrichtung aus diesem post https://forum.fhem.de/index.php/topic,99980.msg963067.html#msg963067