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

Begonnen von CoolTux, 27 April 2019, 08:04:52

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Zitat von: FunkOdyssey am 03 Mai 2019, 17:12:04
Beim Debuggen ist mir gerade eine Kleinigkeit aufgefallen, die aber mit meinen ursprünglichen Probleme nichts zu tun hat.

Ich habe in der ASC-ShutterInfos bei zwei Jalousien den Status "Last drive: night close".
Beide Jalousien wurden manuell innerhalb von Early&Up geöffnet. Eigentlich müsste dann doch eigentlich "manual" dort stehen, oder?
Das ist nicht wirklich schlimm, aber vielleicht hat das ja auch noch Auswirkungen auf andere Dinge und es mag dich interessieren. :-)

Zitat von: CoolTux am 03 Mai 2019, 17:58:52
Es gibt das Attribut ASC_DriveUpMaxDuration wo man die maximal Zeit des Rollos für die Hochfahrt + 3 Sekunden Sicherheit eintragen kann. Damit wird etwas präziser das manuelle fahren festgestellt.

Eine Info am Rande:
Ich habe ASC_DriveUpMaxDuration überball mit den entsprechenden Werten (inkl. Sicherheitspuffer) gesetzt.
8 Jalousien wurden manuell hochgefahren. Bei einer einzigen stimmt der Status "manual". Bei allen anderen wechselt der Last Drive-Status zwischen "maximum brightness threshold exceeded" und "night close".  Merkwürdig ist die Tatsache, dass diese Jalousien überhaupt nicht helligkeitsgesteuert fahren, aber der Status dennoch darauf hinweist.

Ich spiele noch einmal ein wenig mit den Zeiten und schaue morgen noch einmal.

FunkOdyssey

Weiterer Bug-Report:

Ich nutze derzeit die Version 0.6.5 mit aktiviertem Debug-Modus.
Wir hatten ja bereits über das Problem gesprochen, dass einige Jalousien bei mir nicht über das Brightness-Event fahren, sondern ausschließlich zum ASC_Time_Up_Late-Zeitpunkt.

Mal funktioniert es. Und dann wieder nicht. Ich erkenne hier noch kein Muster.
Nach den geprüften Stichproben kann ich fast mit Sicherheit sagen, dass die Jalousien am Wochenende korrekterweise über das Brightness-Event hochfahren. Zugegeben: Ich habe teilweise das Intervall zwischen WE_Early und Late recht knapp gewählt und vereinzelt kam kein Event in dieser Zeitspanne. Dies ignoriere ich einfach.

Aber fakt ist, dass es nun am Montag nicht funktioniert hat. Und das obwohl viele Brightness-Events vorhanden waren.

Log liegt vor.

CoolTux

Zitat von: eurofinder am 06 Mai 2019, 08:01:39
@CoolTux:
Danke, kein Problem.

Heute Morgen ist der Rolladen RGaeste_Velux geöffnet worden, obwohl das Device mit ASC_Mode_Up=off definiert wurde.
2019.05.06 05:24:22 3: RGaeste_Velux: tahoma_applyRequest data={"label":"Gäste Velux - Oeffnen - myFHEM","actions":[{"deviceURL":"io://1208-4648-3794/2835930","commands":[{"name":"open","parameters":[]}]}]}

Woher die Zeit kommt entzieht sich meiner Kenntnis, da berechnete Sonnenaufgangszeit bereits abgelaufen war - siehe Zeitstempel am Beispiel RWC, der korrekt gefahren wurde:
2019.05.06 05:22:13 3: RWC: tahoma_applyRequest data={"label":"Gäste-WC - Oeffnen - myFHEM","actions":[{"deviceURL":"io://1208-4648-3794/5837914","commands":[{"name":"open","parameters":[]}]}]}
Ich vermute mal, dass es daran lag, weil Last_Drive_Position im ASC-Device (get ASC showShuttersInformations) auf shading out steht.

Letzter Fahrbefehl war aber durch RGaeste_Velux_nextAstroTimeEvent ausgeführt:
2019.05.05 21:19:14 3: RGaeste_Velux: tahoma_applyRequest data={"label":"Gäste Velux - Schliessen - myFHEM","actions":[{"deviceURL":"io://1208-4648-3794/2835930","commands":[{"name":"close","parameters":[]}]}]}

Hatte vorher manuell "shading out" beendet, da mal wieder eine Abweichung dazu geführt hatte, dass shading out nicht ausgeführt wurde.
2019.05.05 16:29:52 3: RAnkleide_Velux: tahoma_applyRequest data={"label":"Ankleide Velux - Oeffnen - myFHEM","actions":[{"deviceURL":"io://1208-4648-3794/9176664","commands":[{"name":"open","parameters":[]}]}]}

Hier List vom ASC:
Internals:
   FUUID      5cc2c9b7-f33f-d9bf-3bae-c170cbd696a4bf1f
   FVERSION   73_AutoShuttersControl.pm:v0.6.5-s19304/2019-05-01 UNDER DEVELOP
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       ASC
   NOTIFYDEV  global,ASC,RAnkleide,RAnkleide_Velux,RBad,RBuero,RGaeste,RGaeste_Velux,RKueche,RPSK_Fenster_WZ,RPSK_TUER_WZ,RSZ,RWC,KBuero,Twilight,KWC
   NR         121
   NTFY_ORDER 51-ASC
   STATE      manual
   TYPE       AutoShuttersControl
   VERSION    0.6.5
   OLDREADINGS:
   READINGS:
     2019-05-06 05:22:33   RAnkleide_PosValue 0
     2019-05-06 07:15:35   RAnkleide_Velux_PosValue 0
     2019-05-06 05:22:13   RAnkleide_Velux_lastPosValue 99
     2019-05-06 05:22:13   RAnkleide_Velux_nextAstroTimeEvent  6.05.2019 - 21:21
     2019-05-06 05:22:13   RAnkleide_lastPosValue 100
     2019-05-06 05:22:13   RAnkleide_nextAstroTimeEvent  6.05.2019 - 21:21
     2019-05-06 05:22:35   RBad_PosValue   0
     2019-05-06 05:22:13   RBad_lastPosValue 100
     2019-05-06 05:22:13   RBad_nextAstroTimeEvent  6.05.2019 - 21:21
     2019-05-06 07:16:01   RBuero_PosValue 0
     2019-05-05 21:27:26   RBuero_lastPosValue 0
     2019-05-06 05:22:13   RBuero_nextAstroTimeEvent  6.05.2019 - 21:29
     2019-05-06 07:15:53   RGaeste_PosValue 0
     2019-05-06 05:25:02   RGaeste_Velux_PosValue 0
     2019-05-06 05:24:22   RGaeste_Velux_lastPosValue 100
     2019-05-06 05:22:13   RGaeste_Velux_nextAstroTimeEvent  6.05.2019 - 21:21
     2019-05-05 21:19:14   RGaeste_lastPosValue 0
     2019-05-06 05:22:13   RGaeste_nextAstroTimeEvent  6.05.2019 - 21:21
     2019-05-06 05:22:35   RKueche_PosValue 0
     2019-05-06 05:22:13   RKueche_lastPosValue 100
     2019-05-06 05:22:13   RKueche_nextAstroTimeEvent  6.05.2019 - 21:29
     2019-05-06 07:16:03   RPSK_Fenster_WZ_PosValue 0
     2019-05-05 21:27:26   RPSK_Fenster_WZ_lastPosValue 0
     2019-05-06 05:22:13   RPSK_Fenster_WZ_nextAstroTimeEvent  6.05.2019 - 21:29
     2019-05-06 07:16:03   RPSK_TUER_WZ_PosValue 0
     2019-05-05 21:27:26   RPSK_TUER_WZ_lastPosValue 0
     2019-05-06 05:22:13   RPSK_TUER_WZ_nextAstroTimeEvent  6.05.2019 - 21:29
     2019-05-06 07:15:53   RSZ_PosValue    0
     2019-05-05 21:19:14   RSZ_lastPosValue 0
     2019-05-06 05:22:13   RSZ_nextAstroTimeEvent  6.05.2019 - 21:21
     2019-05-06 05:22:33   RWC_PosValue    0
     2019-05-06 05:22:13   RWC_lastPosValue 100
     2019-05-06 05:22:13   RWC_nextAstroTimeEvent  6.05.2019 - 21:29
     2019-04-26 21:09:41   Rolladen_OG_lastPosValue 0
     2019-04-26 17:53:28   hardLockOut     off
     2019-04-30 06:50:39   partyMode       on
     2019-05-04 17:12:58   room_ASC_EG_tahoma RBuero,RKueche,RPSK_Fenster_WZ,RPSK_TUER_WZ,RWC
     2019-05-04 17:12:58   room_ASC_OG_tahoma RAnkleide,RAnkleide_Velux,RBad,RGaeste,RGaeste_Velux,RSZ
     2019-04-26 11:04:55   selfDefense     off
     2019-05-06 07:15:59   state           manual
     2019-04-30 06:45:52   sunriseTimeWeHoliday on
     2019-05-04 17:12:58   userAttrList    rolled out
   helper:
     shuttersList:
       RAnkleide
       RAnkleide_Velux
       RBad
       RBuero
       RGaeste
       RGaeste_Velux
       RKueche
       RPSK_Fenster_WZ
       RPSK_TUER_WZ
       RSZ
       RWC
   monitoredDevs:
     KBuero:
       RBuero     ASC_WindowRec
     KWC:
       RWC        ASC_WindowRec
     RAnkleide:
     RAnkleide_Velux:
     RBad:
     RBuero:
     RGaeste:
     RGaeste_Velux:
     RKueche:
     RPSK_Fenster_WZ:
     RPSK_TUER_WZ:
     RSZ:
     RWC:
     Twilight:
       ASC        ASC_twilightDevice
       RAnkleide  ASC_BrightnessSensor
       RAnkleide_Velux ASC_BrightnessSensor
       RBad       ASC_BrightnessSensor
       RGaeste_Velux ASC_BrightnessSensor
       RKueche    ASC_BrightnessSensor
       RPSK_Fenster_WZ ASC_BrightnessSensor
Attributes:
   ASC_autoAstroModeEvening HORIZON
   ASC_autoAstroModeEveningHorizon -5
   ASC_autoAstroModeMorning HORIZON
   ASC_autoAstroModeMorningHorizon -3
   ASC_autoShuttersControlComfort on
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   ASC_autoShuttersControlShading on
   ASC_blockAscDrivesAfterManual 0
   ASC_brightnessDriveUpDown 40:40
   ASC_expert 1
   ASC_tempSensor WetterProplanta:temperature
   ASC_twilightDevice Twilight
   devStateIcon selfeDefense.terrace:fts_door_tilt created.new.drive.timer:clock .*asleep:scene_sleeping roommate.(awoken|home):user_available residents.(home|awoken):status_available manual:fts_shutter_manual selfeDefense.active:status_locked selfeDefense.inactive:status_open day.open:scene_day night.close:scene_night shading.in:weather_sun shading.out:weather_cloudy
   icon       fts_shutter_automatic
   room       ASC
   verbose    1


und RGaeste_Velux:
Internals:
   COMMANDS   dim:slider,0,1,100 cancel:noArg close:noArg delayedStopIdentify down:noArg getName:noArg identify:noArg my:noArg open:noArg refreshMemorized1Position:noArg setClosure setDeployment setMemorized1Position setName setPosition setSecuredPosition startIdentify:noArg stop:noArg stopIdentify:noArg up:noArg wink
   DEF        DEVICE io://1208-4648-3794/2835930
   FUUID      5cc2c399-f33f-d9bf-ed65-371e73f0943141b1
   IODev      tahoma
   NAME       RGaeste_Velux
   NR         114
   NTFY_ORDER 50-RGaeste_Velux
   STATE      dim0
   SUBTYPE    DEVICE
   TYPE       tahoma
   device     io://1208-4648-3794/2835930
   fid        2835930
   inClass    RollerShutter
   inControllable io:RollerShutterVeluxIOComponent
   inExecId   finished
   inExecState COMPLETED
   inLabel    Gäste Velux
   inPlaceOID 7eaeefef-8124-4f8f-b36d-2d93418b81b9
   inType     1
   READINGS:
     2019-05-06 05:24:22   ASC_ShuttersLastDrive shading out
     2019-05-06 05:22:13   ASC_Time_DriveDown  6.05.2019 - 21:21
     2019-05-06 05:22:13   ASC_Time_DriveUp  7.05.2019 - 05:20
     2019-05-06 05:25:02   ClosureState    0
     2019-05-05 05:24:51   NameState       Gäste Velux
     2019-05-06 05:25:02   OpenClosedState open
     2019-05-05 05:24:51   PriorityLockTimerState 0
     2019-05-06 07:44:07   RSSILevelState  52.0
     2019-05-05 05:24:51   StatusState     available
     2019-05-04 17:12:58   associatedWith  ASC
     2019-05-06 05:25:02   devicestate     open
     2019-05-06 05:25:02   state           dim0
Attributes:
   ASC        1
   ASC_AutoAstroModeEvening HORIZON
   ASC_AutoAstroModeEveningHorizon -4
   ASC_BrightnessSensor Twilight:twilight 90:30
   ASC_Mode_Up off
   ASC_Pos_Reading ClosureState
   ASC_Shading_Angle_Left 75
   ASC_Shading_Angle_Right 55
   ASC_Shading_Direction 185
   ASC_Shading_Min_Elevation 25
   ASC_Shading_Min_OutsideTemperature 10
   ASC_Shading_Mode always
   ASC_Shading_Pos 100
   ASC_Shading_StateChange_Cloudy 40
   ASC_Shading_StateChange_Sunny 80
   ASC_ShuttersPlace window
   IODev      tahoma
   alias      Rolladen Gäste Velux
   devStateIcon 0:fts_window_2w 100:fts_shutter_100 [0-9]:fts_shutter_10 2\d.*:fts_shutter_20 3\d.*:fts_shutter_30 4\d.*:fts_shutter_40 5\d.*:fts_shutter_50 6\d.*:fts_shutter_60 7\d.*:fts_shutter_70 8\d.*:fts_shutter_80 9\d.*:fts_shutter_90 \d.*:fts_shutter_90
   room       ASC,OG,tahoma
   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,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_Exclude:on,off ASC_Shading_Angle_Left ASC_Shading_Angle_Right ASC_Shading_Direction ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace 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_subType:twostate,threestate
   webCmd     dim


War bisher davon ausgegangen, dass wenn ich ASC_Mode_Up=off beim Device setze, dieser definitiv nicht hochgefahren wird. Fehlt hier ggf. eine Aktualisierung der Last_Drive_Position, weil diese ja noch auf shading out stand?

Gruß
eurofinder



Zitat von: eurofinder am 06 Mai 2019, 08:01:39
RGaeste_Velux_PosValue 0
     2019-05-06 05:24:22   RGaeste_Velux_lastPosValue 100

Der alte Wert ist 0 und der neue 100

Laut Code

and $getShadingPos == $getStatus


Die eizige Erklärung. 0 ist auch die shadingPosition bei Dir. Nur dann kann es zu solchen Problemen kommen.
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

CoolTux

Zitat von: FunkOdyssey am 06 Mai 2019, 10:16:58
Weiterer Bug-Report:

Ich nutze derzeit die Version 0.6.5 mit aktiviertem Debug-Modus.
Wir hatten ja bereits über das Problem gesprochen, dass einige Jalousien bei mir nicht über das Brightness-Event fahren, sondern ausschließlich zum ASC_Time_Up_Late-Zeitpunkt.

Mal funktioniert es. Und dann wieder nicht. Ich erkenne hier noch kein Muster.
Nach den geprüften Stichproben kann ich fast mit Sicherheit sagen, dass die Jalousien am Wochenende korrekterweise über das Brightness-Event hochfahren. Zugegeben: Ich habe teilweise das Intervall zwischen WE_Early und Late recht knapp gewählt und vereinzelt kam kein Event in dieser Zeitspanne. Dies ignoriere ich einfach.

Aber fakt ist, dass es nun am Montag nicht funktioniert hat. Und das obwohl viele Brightness-Events vorhanden waren.

Log liegt vor.

Lässt Du mir das Log wieder zu kommen?
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

CoolTux

Zitat von: FunkOdyssey am 06 Mai 2019, 10:16:58
Weiterer Bug-Report:

Ich nutze derzeit die Version 0.6.5 mit aktiviertem Debug-Modus.
Wir hatten ja bereits über das Problem gesprochen, dass einige Jalousien bei mir nicht über das Brightness-Event fahren, sondern ausschließlich zum ASC_Time_Up_Late-Zeitpunkt.

Mal funktioniert es. Und dann wieder nicht. Ich erkenne hier noch kein Muster.
Nach den geprüften Stichproben kann ich fast mit Sicherheit sagen, dass die Jalousien am Wochenende korrekterweise über das Brightness-Event hochfahren. Zugegeben: Ich habe teilweise das Intervall zwischen WE_Early und Late recht knapp gewählt und vereinzelt kam kein Event in dieser Zeitspanne. Dies ignoriere ich einfach.

Aber fakt ist, dass es nun am Montag nicht funktioniert hat. Und das obwohl viele Brightness-Events vorhanden waren.

Log liegt vor.

Möglich das ich was gefunden habe. Dafür brauche ich aber eine erweiterte Ausgabe des debug Modes welchen ich heute fertig mache und Dich bitten würde dann zu testen. Würde mich bei Dir melden.
Ausserdem habe ich in der Tat noch ein Problem bezüglich Wochenende und brightness erkennen können.
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

FunkOdyssey

Das beruhigt mich. Ich bin den Code jetzt schon mehrfach durchgegangen, aber die große Abfrage in 'EventProcessingBrightness' hat mich ordentlich beschäftigt.
Vor allem wundere ich mich, wie das Debug-Log zeitgleich in 'EventProcessingShadingBrightness' weitermacht, obwohl die Schritte in 'EventProcessingBrightness' noch nicht zu Ende gearbeitet wurden.

Mit meinem Anfängerwissen bleibe ich immer an dieser if-Abfrage hängen. Diese scheint nicht zuzutreffen. Müsste es aber.


sub EventProcessingBrightness($@) {
...
        if (
            int( gettimeofday() / 86400 ) != int(
                computeAlignTime( '24:00', $shutters->getTimeUpEarly ) / 86400
            )
            and int( gettimeofday() / 86400 ) == int(
                computeAlignTime( '24:00', $shutters->getTimeUpLate ) / 86400
            )
            and $1 > $brightnessMaxVal
            and $shutters->getUp eq 'brightness'
            and not $shutters->getSunrise
          )
...
}

eurofinder

@CoolTux:
ZitatDie eizige Erklärung. 0 ist auch die shadingPosition bei Dir. Nur dann kann es zu solchen Problemen kommen.
Nein, für RGaeste_Velux  ist ASC_Shading_Pos definiert als 100. Das wurde auch nie geändert.

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

CoolTux

Zitat von: eurofinder am 06 Mai 2019, 13:16:44
@CoolTux:Nein, für RGaeste_Velux  ist ASC_Shading_Pos definiert als 100. Das wurde auch nie geändert.

Gruß
eurofinder

Sorry ich habe mich da vertan. Ich meinte auch 100.
So steht es ja auch drin. LastPos 100 Pos 0

Und 100 ist auch Dein Shading. Dem zufolge macht er genau das was er soll. Er schaut nach ob die Position gleich der ShadinPosition ist und wenn ja und out ist gesetzt fährt er raus aus der shading.
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

eurofinder

@CoolTux:
Also, nochmal zur Klarstellung. Sonntag klappte mal wieder shading out beim Rolladen nicht. Habe ihn dann manuell auf Position 0 (geöffnet) gefahren. Die Voraussetzungen für shading out waren zu dem Zeitpunkt nicht mehr erfüllt. Spät abends wurde dann der Rolladen mit AstroModeEvening (HORIZON -5) automatisch in night close (Position 100) gefahren. Dann hätte doch Last Drive Position im ASC night close sein müssen und nicht weiterhin shading out.

Da im Device RGaeste_Velux ASC_Mode_Up=off ist, dürfte somit dann der Rolladen heute morgen auch nicht in Position O gefahren werden.

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

CoolTux

 Last DrivePosition ist die Position nicht der Fahrgrund.
Die Position auf Grund der night close war 100. Shading stand auf out. Irgendwann geht dann die Shading Routine noch mal an. Das muss ich noch mal prüfen, in der Routine wird festgestellt das Shading out ist und das die aktuelle Position gleich der Shading Position ist (100) und somit wird ein Fahrbefehl ausgegeben. Gefahren wird in die LastPosition und die war vor dem night close ja 0
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

eurofinder

OK, dachte die Logik wäre anders aufgebaut, was für mich eher nachvollziehbar wäre.

Würde sehr dafür plädieren, dass night close automatisch noch "ausstehende" shading out beendet. Sehe keinen Grund, warum ein Rolladen, der per night close geschlossen wird, anschließend nochmals in shading out gehen sollte.

Nochmals danke für diene Rückmeldungen und tolle Arbeit am Modul. Wenn ich "Kritik" äußere, dann dient sie einzig allein dazu, das Modul in der Funktionalität zu optimieren. 

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

eurofinder

@CoolTux:
Wie bekomme ich denn in der Zwischenzeit einen Rolladen, der noch im shading out ist in einen Zustand, der am nächsten Tag nicht dazu führt, dass der Rolladen morgens trotz  ASC_Mode_Up=off hochgefahren wird?

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

CoolTux

In dem Du die ShadingPos auf einen anderen Wert setzt als ein Wert den es schon wo anders in der Konfig gibt. Also kein open,closed,ventilate,comfort Wert. Nimm wegen meiner 98 oder so statt 100

Ich frage bei vielen Gelegenheiten ab um das Rolllo auch tatsächlich in der entsprechenden Pos ist für Routine aus der dann raus gefahren werden soll. Wenn nicht ist das wohl so vom User gewünscht worden und es wird halt nichts gemacht.
ClosedPos ist halt ungünstig gewählt da da noch mehr dran hängt.
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

eurofinder

RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

CoolTux

Ich habe mal die Rolllos vom Kinderzimmer auf Brightness eingestellt. Runter sind sie dann auch gefahren. Dabei ist mir aufgefallen das dann IsDay eigentlich hätte 0 ausgeben müssen dies aber nicht tat. Muss ich also noch mal ran.
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