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

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

Vorheriges Thema - Nächstes Thema

Loredo

Zitat von: CoolTux am 10 Mai 2019, 08:54:07Wie schaut es aus bei Euch?Kam irgendwas bezüglich Freitagsproblem?
Zitat von: CoolTux am 09 Mai 2019, 06:27:04
Die letzten Tage sind meine Rolllos im Kinderzimmer und der Küche korrekt nach Brightness gefahren.
Wie sehen Eure Erfahrungen mit der aktuellen Version aus?


Ich war die Tage nicht da, muss ich erstmal noch beobachten.


Aber als ich gestern nach Hause kam, da war noch nicht Abend und die Rollläden sind trotzdem nicht hochgefahren. Das hätten sie aber beim Wechsel von absent zu home tun sollen. Zuvor sind die seit dem Abend, an dem ich weg war, runtergefahren (was auch korrekt war). Ich war keine 3 Tage weg, somit gab es zwischendrin keinen Status "gone" bzw. beim heimfahren auch keine Wechsel gone->absent (nur zur Info).


Zitat von: CoolTux am 08 Mai 2019, 10:20:45Was könnte denn da Deiner Meinung nach für ein Event kommen welches nicht "erwünscht" ist?


Ich meine, dass es Zwischenevent gibt, weil nicht beide Sensoren exakt zur selben Zeit verarbeitet werden. Selbst für einen fhem.pl Loop Zyklus könnte es sein, dass der Status vom einen Sensor von dem structure Device schon verarbeitet ist und dann structure auch den dort korrekte Status hat. Aber dann kommt eben wenige Millisekunden später der zweite Sensor mit seinem neuen Status und die structure ändert wieder ihren Status, diesmal auf den endgültigen Status, den der User auch erwartet. In structure gibt es für die Verarbeitung der Sensorwerte bisher keinen Wartemechanismus dafür, also schlagen beide Statuswechsel direkt nacheinander bei ASC auf. Aber ASC kann damit glaube ich nicht umgehen. Entweder wird dann mehrfach gefahren oder das erste Zwischenergebnis "gewinnt", weil der endgültige Status direkt hinterher kommt und ASC noch gar nicht fertig ist mit der Verarbeitung des ersten Statuswechsel und daher wird das zweite Event überhaupt nicht mehr verarbeitet.


Zitat von: Typ1er am 08 Mai 2019, 10:30:10Das man warten muss ist seltsam. -Fenster ist Nachts auf Kipp, jetzt möchte ich es öffnen. -Fenster zu, Rollladen fährt runter-jetzt muss man warten bis es zu ist,  statt das Fenster gleich zu öffnen.


Nein, das ist nicht seltsam. Ich rede nicht davon, dass du als Anwender vor dem Rollladen stehst und aus irgendeinem Grund warten _musst_. Aber natürlich kann es trotzdem gewünscht sein, dass nicht sofort gefahren wird. Wenn ich beispielsweise auf den ROOMMATE Statuswechsel reagiere, dann kann es auch passieren, dass man den aus versehen mal falsch gesetzt hat und ihn dann wieder wechselt. Da muss also gar nicht sofort gefahren werden. Aber Marko sagte ja bereits, dass er Bedienfehler nicht abfangen möchte. IMHO macht diesen "Komfort" aber genau das aus, was man als Anwender bei einer Automation erwartet - Automatismus und Fehlertoleranz. Aber was weiß ich da schon...  :P  (Marko weiß hoffentlich, dass ich das nicht böse meine  :-* [size=78%])[/size]
Zitat von: Beta-User am 08 Mai 2019, 10:38:41Manche Kontakte (z.B. HM) kennen eine interne Verzögerung, um den von Typ1er geschilderten Effekt zu vermeiden; bei allen anderen fände ich es gut, eine kurze Zeit zuzuwarten, bis eine Reaktion (bzw. die Prüfung des Werts samt Reaktion) erfolgt. Es reichen in der Regel wenige Sekunden (meine HM haben in der Regel einen delay von 2 Sek. drin).Ich habe aber auch welche, die gleich reagieren, und bei denen soll dann auch direkt die Rolllade hoch. Vorschlag: Verzögerung optional einstellbar, als weitere Angabe zum Fensterkontakt; Format: attr ASC_WindowRec <device>[:delay in sek]


Diese Verzögerung habe ich natürlich auch eingestellt, um beim Wechsel von Offen zu Tilted nicht den Zwischenstatus Closed zu riskieren. Aber es ändert nichts daran, dass FHEM die 2 Status der Sensoren zeitversetzt bekommen kann und nicht im selben Verarbeitungszyklus.


Zitat von: CoolTux am 08 Mai 2019, 10:49:14Meinst Du ein verzögertes fahren nach dem Fensterkontakt Event oder generell eine verzögerte Auswertung des Fensterkontakt Events. Zweites ist eine Sau Arbeit wegen nicht blockieren von FHEM.


Ich meine man braucht zweiteres, Sau Arbeit hin oder her. Ich sag ja nicht, dass es einfach ist, aber es wäre das zuverlässigste und würde wahrscheinlich eine ganze Reihe von (auch zukünftigen) Problemen umschiffen ;-)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

CoolTux

Zitat von: Loredo am 11 Mai 2019, 14:22:32

Ich war die Tage nicht da, muss ich erstmal noch beobachten.


Aber als ich gestern nach Hause kam, da war noch nicht Abend und die Rollläden sind trotzdem nicht hochgefahren. Das hätten sie aber beim Wechsel von absent zu home tun sollen. Zuvor sind die seit dem Abend, an dem ich weg war, runtergefahren (was auch korrekt war). Ich war keine 3 Tage weg, somit gab es zwischendrin keinen Status "gone" bzw. beim heimfahren auch keine Wechsel gone->absent (nur zur Info).

elsif (
                    $shutters->getStatus == $shutters->getClosedPos
                and IsDay($shuttersDev)
                and $shutters->getRoommatesStatus eq 'none'
                and (  $getModeUp eq 'home'
                    or $getModeUp eq 'always' )
                and IsAfterShuttersTimeBlocking($shuttersDev)
                and not $shutters->getIfInShading
              )


Dann müsste die Passage für Dich eigentlich gegelten haben.
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

octek0815

Hallo,

warum fehlt bei mir das Attribut "ASC_autoShuttersControlShading" im ASC Device?

Grüße
Olli


CoolTux

Zitat von: octek0815 am 11 Mai 2019, 15:07:31
Hallo,

warum fehlt bei mir das Attribut "ASC_autoShuttersControlShading" im ASC Device?

Grüße
Olli

Das ist nun als setter angelegt.
controlShading
Und ja da fehlt noch die Anpassung an die Doku :)
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

maxritti

Zitat von: maxritti am 11 Mai 2019, 09:06:52
Hier das Rollo:

Internals:
   DEF        52D39F
   FUUID      5c549a89-f33f-b047-4026-1da5398849316fc7
   IODev      myHMLGW
   LASTInputDev myHMLGW
   MSGCNT     31
   NAME       EG_wz_RO_TerrasseRechts
   NOTIFYDEV  global
   NR         45
   NTFY_ORDER 50-EG_wz_RO_TerrasseRechts
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:6D - t:10 s:52D39F d:9A234E 0601C800
   myHMLGW_Buero_MSGCNT 21
   myHMLGW_Buero_RAWMSG 050000336DA41052D39F9A234E0601C800
   myHMLGW_Buero_RSSI -51
   myHMLGW_Buero_TIME 2019-05-11 08:07:34
   myHMLGW_MSGCNT 10
   myHMLGW_RAWMSG 050100316DA41052D39F9A234E0601C800
   myHMLGW_RSSI -49
   myHMLGW_TIME 2019-05-11 08:07:34
   protLastRcv 2019-05-11 08:07:34
   protRcv    16 last_at:2019-05-11 08:07:34
   protSnd    22 last_at:2019-05-11 08:07:34
   protState  CMDs_done
   rssi_at_myHMLGW cnt:10 min:-50 max:-37 avg:-43 lst:-49
   rssi_at_myHMLGW_Buero cnt:21 min:-56 max:-48 avg:-51.09 lst:-51
   rssi_myHMLGW cnt:4 min:-72 max:-70 avg:-71 lst:-70
   READINGS:
     2019-05-11 08:07:02   ASC_ShuttersLastDrive manual
     2019-05-11 05:53:47   ASC_Time_DriveDown 11.05.2019 - 22:30
     2019-05-11 05:53:47   ASC_Time_DriveUp 12.05.2019 - 05:52
     2019-05-11 08:07:02   CommandAccepted yes
     2019-05-05 10:25:06   D-firmware      2.3
     2019-05-05 10:25:06   D-serialNr      LEQ0042378
     2019-05-05 12:28:15   PairedTo        0x9A234E
     2019-05-05 12:28:16   R-driveDown     23.7 s
     2019-05-05 12:28:16   R-driveTurn     0.5 s
     2019-05-05 12:28:16   R-driveUp       27 s
     2019-05-05 12:28:15   R-pairCentral   0x9A234E
     2019-05-05 12:28:16   R-sign          off
     2019-05-05 12:28:15   RegL_00.        00:00 02:01 0A:9A 0B:23 0C:4E 15:FF 18:00
     2019-05-05 12:28:16   RegL_01.        00:00 08:00 09:00 0A:00 0B:00 0C:ED 0D:01 0E:0E 0F:05 10:00 30:06 57:24
     2019-05-08 21:39:39   associatedWith  myASC
     2019-05-11 08:07:34   deviceMsg       on (to myVCCU)
     2019-05-11 08:07:34   level           100
     2019-05-11 08:07:34   motor           stop:on
     2019-05-11 08:07:34   pct             100
     2019-05-11 08:07:34   recentStateType info
     2019-05-11 08:07:34   rssi_at_myHMLGW -49
     2019-05-11 08:07:34   rssi_at_myHMLGW_Buero -51
     2019-05-11 08:07:02   rssi_myHMLGW    -70
     2019-05-11 08:07:34   state           on
     2019-05-11 08:07:34   timedOn         off
   helper:
     HM_CMDNR   109
     cSnd       119A234E52D39F0201000000,119A234E52D39F0201C80000
     dlvlCmd    ++A0119A234E52D39F0201C80000
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +52D39F,00,00,00
       nextSend   1557554854.89615
       rxt        0
       vccu       myVCCU
       p:
         52D39F
         00
         00
         00
       prefIO:
         myHMLGW
     mRssi:
       mNo        6D
       io:
         myHMLGW:
           -41
           -41
         myHMLGW_Buero:
           -51
           -51
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         myHMLGW_Buero
       flg        A
       ts         1557554854.59735
       ack:
         HASH(0x559d6d795be0)
         6D80029A234E52D39F00
     rssi:
       at_myHMLGW:
         avg        -43
         cnt        10
         lst        -49
         max        -37
         min        -50
       at_myHMLGW_Buero:
         avg        -51.0952380952381
         cnt        21
         lst        -51
         max        -48
         min        -56
       myHMLGW:
         avg        -71
         cnt        4
         lst        -70
         max        -70
         min        -72
Attributes:
   ASC        2
   ASC_BrightnessSensor EG_dr_TS_Terrasse:luminosity 1.3
   ASC_Down   brightness
   ASC_Mode_Up off
   ASC_Pos_Reading pct
   ASC_Time_Down_Early 18:00
   ASC_Time_Down_Late 22:30
   IODev      myVCCU
   IOgrp      myVCCU:myHMLGW
   alias      Terr. Rechts
   autoReadReg 4_reqStatus
   devStateIcon off:fts_shutter_100@grey on:fts_window_2w@yellow 1\d.*:fts_shutter_90 2.*:fts_shutter_80 3.*:fts_shutter_70 4.*:fts_shutter_60 5.*:fts_shutter_50 6.*:fts_shutter_40 7.*:fts_shutter_30 8.*:fts_shutter_20 9.*:fts_shutter_10
   expert     2_full
   firmware   2.3
   group      Rollo
   model      HM-LC-BL1PBU-FM
   peerIDs    00000000,
   room       Rollo,Tablet
   rssiLog    1
   serialNr   LEQ0042378
   sortby     05
   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,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     pct:stop



Und das ASC Device:

FUUID      5ccdccb5-f33f-b9c3-1e50-d5907c9e49ddc3e8
   FVERSION   73_AutoShuttersControl.pm:v0.6.7-s19344/2019-05-07 UNDER DEVELOP
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       myASC
   NOTIFYDEV  global,myASC,EG_wz_RO_TerrasseRechts,EG_dr_TS_Terrasse,EG_wz_RO_TerrasseRechts
   NR         253
   NTFY_ORDER 51-myASC
   STATE      manual
   TYPE       AutoShuttersControl
   VERSION    0.6.7
   OLDREADINGS:
   READINGS:
     2019-05-11 08:07:34   EG_wz_RO_TerrasseRechts_PosValue 100
     2019-05-10 22:30:01   EG_wz_RO_TerrasseRechts_lastPosValue 0
     2019-05-11 05:53:47   EG_wz_RO_TerrasseRechts_nextAstroTimeEvent 11.05.2019 - 22:30
     2019-05-08 21:38:49   controlShading  off
     2019-05-05 10:25:06   hardLockOut     off
     2019-05-08 21:39:39   room_Rollo_Tablet EG_wz_RO_TerrasseRechts
     2019-05-05 10:25:06   selfDefense     off
     2019-05-11 08:07:02   state           manual
     2019-05-05 10:25:06   sunriseTimeWeHoliday off
     2019-05-08 21:39:39   userAttrList    rolled out
   helper:
     shuttersList:
       EG_wz_RO_TerrasseRechts
   monitoredDevs:
     EG_dr_TS_Terrasse:
       EG_wz_RO_TerrasseRechts ASC_BrightnessSensor
     EG_wz_RO_TerrasseRechts:
Attributes:
   ASC_autoAstroModeEvening REAL
   ASC_autoAstroModeMorning REAL
   ASC_autoShuttersControlEvening on
   ASC_autoShuttersControlMorning on
   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


Ich hoffe Du findest etwas....

Jetzt verstehe ich gar nichts mehr.
Helligkeitswert von 231 und der Rollo geht runter.  :o

CoolTux

Ja das ist richtig so

Setzte doch bitte beide Werte und nicht nur einen


EG_dr_TS_Terrasse:luminosity 0:1.3

Morgens bei größer 0 hoch und abends bei kleiner 1.3 runter
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

maxritti

Zitat von: CoolTux am 11 Mai 2019, 18:37:15
Ja das ist richtig so

Setzte doch bitte beide Werte und nicht nur einen


EG_dr_TS_Terrasse:luminosity 0:1.3

Morgens bei größer 0 hoch und abends bei kleiner 1.3 runter

Okay, und ASC_Mode_Up off reicht aus, damit morgens nichts passiert?
Aber sehe ich dann ja morgen früh.  ;)

CoolTux

So Gott will  ;D
Spaß, sollte dann morgen früh nicht fahren.
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

Typ1er

die ganze Woche über sind alle Rollos sauber gefahren, ich bin zufrieden.

Gelegentlich wird die Position nicht übertragen, hier denke ich liegt es daran das die Rollladen teilweise gleichzeitig fahren. Es gehen zwar mehrere Befehle gleichzeitig, scheinbar verschluckt sich das Z-wave Protokoll dann.

Heute das Update eingespielt, muss man jetzt nach jedem Update die Rollos neu Suchen und die Zeiten erneuern? Das hatte heute vergessen, so ist am Abend nicht ein Rollladen richtig gefahren.


Jetzt noch 2 Frage zu meinem Problem mit den Variablen Zeiten:
- ich möchte den ASC_Drive_OffsetStart wert mit Zufallszahlen auffüllen, muss ich danach die Zeiten im ASC Modul neuberechnet lassen oder merkt das Tool das automatisch?
- Zweite Frage im ASC Modul in den ShowShuttersinformation stehen Fahrzeiten mit Sekundenangaben, kann ich diese irgendwo einsehen oder ablesen zum Auswerten?

Zu den Fenstergriffen, ich habe früher immer sofort die aktuelle Position angefahren bei einer Änderung vom Status, der Letzte automatische Befehl war dabei ja egal. Als Beispiel:
-Nachts das Fenster geht auf Kipp = ASC_Ventilate_Pos
-Fenster ist auf = ASC_ComfortOpen_Pos
-Fenster ist zu, hier wird die aktuelle Sollstellung angefahren, zb Nachts zu

Zwischen diesen 3 gibt es ja keine Andere Regel die Das unterbinden würde somit müsste man nicht unbedingt warten bis die jeweilige Position erreicht ist.

CoolTux

Zitat von: Typ1er am 12 Mai 2019, 00:33:34
die ganze Woche über sind alle Rollos sauber gefahren, ich bin zufrieden.

Gelegentlich wird die Position nicht übertragen, hier denke ich liegt es daran das die Rollladen teilweise gleichzeitig fahren. Es gehen zwar mehrere Befehle gleichzeitig, scheinbar verschluckt sich das Z-wave Protokoll dann.

Heute das Update eingespielt, muss man jetzt nach jedem Update die Rollos neu Suchen und die Zeiten erneuern? Das hatte heute vergessen, so ist am Abend nicht ein Rollladen richtig gefahren.


Jetzt noch 2 Frage zu meinem Problem mit den Variablen Zeiten:
- ich möchte den ASC_Drive_OffsetStart wert mit Zufallszahlen auffüllen, muss ich danach die Zeiten im ASC Modul neuberechnet lassen oder merkt das Tool das automatisch?
- Zweite Frage im ASC Modul in den ShowShuttersinformation stehen Fahrzeiten mit Sekundenangaben, kann ich diese irgendwo einsehen oder ablesen zum Auswerten?

Zu den Fenstergriffen, ich habe früher immer sofort die aktuelle Position angefahren bei einer Änderung vom Status, der Letzte automatische Befehl war dabei ja egal. Als Beispiel:
-Nachts das Fenster geht auf Kipp = ASC_Ventilate_Pos
-Fenster ist auf = ASC_ComfortOpen_Pos
-Fenster ist zu, hier wird die aktuelle Sollstellung angefahren, zb Nachts zu

Zwischen diesen 3 gibt es ja keine Andere Regel die Das unterbinden würde somit müsste man nicht unbedingt warten bis die jeweilige Position erreicht ist.

Guten Morgen,

Man muss nicht nach jedem Neustart die Rolllos neu suchen. Das macht ASC von selbst. Wenn das bei Dir nicht so ist müssen wir da noch mal schauen.

1. Du musst nach dem Einstellen von OffsetStart nicht neu berechnen lassen. Die Zeiten für Sonne auf und unter bleiben ja so. Die Verzögerung kommt immer als letztes. Vorher hat das Modul den Befehl zum fahren schon ausgelöst. Nur der eigentliche Fahrbefehl wird dann verzögert.
2. Eigentlich kommst Du da nicht ran da diese Informationen in einem Objekt gespeichert werden. Aber ich muss mal schauen ob ich das irgendwie zugänglich machen kann.
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

Ich habe hier zwei Türen, die nicht über "times" hochfahren.
Lockout auf "off" und "soft" gesetzt.
ShuttersPlace auf "terrace" gesetzt.
WindowRec auf twostate (HM optisch).

Das habe ich bei einer dritten Tür auch alles gemacht. Diese fährt aber hoch.

Einziger Unterschied: die "defekten" Türen fahren nur hoch und nie per ASC herunter.

Debug Log vorhanden. Aber nicht mehr heute. 😄

mrfloppy

Ich bin gerade am ausprobieren und herantasten an ASC.
Kann ich ASC mit einem Schalter komplett deaktivieren?
Grund momentan läuft noch mein originales FHEM mit der Perl Geschichte
und somit könnt ich wenn ASC mal ned so tut wie ich will umswitchen.

LG
RaspiMatic, RFXtrx433 E USB, Div. Thermostate, CUL433, Fhemduino, Signalduino, Temp/luftfeuchesensoren,Fensterkontakte,Intertechno Schalter,....... HM-IP

Typ1er

Zitat von: CoolTux am 12 Mai 2019, 07:36:08
Man muss nicht nach jedem Neustart die Rolllos neu suchen. Das macht ASC von selbst. Wenn das bei Dir nicht so ist müssen wir da noch mal schauen.

Nicht nach einem Neustart, nach dem Update von 0.6.7 auf 0.6.8 hatte ich das Verhalten, ich kann gar nicht sagen ob das vorher auch immer so war.

volschin

Zitat von: CoolTux am 11 Mai 2019, 10:27:57
Das könnte in der Tat daran gelegen haben. Ich habe das vorhin schon gefixt und Du kannst wenn Du magst es von meinen Git aus dem Devel Branch holen. Zum morgen testen.
Generell funktioniert das wieder. Danke.  :)

Ich habe aber doch noch ungewöhnliches Verhalten, dass ich mir nicht erklären kann:
2019-05-11_20:21:29 RolloR.Schlafen ASC_ShuttersLastDrive: minimum brightness threshold fell below
2019-05-11_20:21:29 RolloR.Schlafen action: down to position 50
2019-05-11_20:21:49 RolloR.Schlafen operating_seconds: 385.53
2019-05-11_20:21:49 RolloR.Schlafen action: no action
2019-05-11_20:21:49 RolloR.Schlafen 50
2019-05-11_20:21:49 RolloR.Schlafen position: 50

2019-05-11_22:17:00 Fenster_R.Schlafen open

2019-05-11_22:17:00 RolloR.Schlafen ASC_ShuttersLastDrive: comfort - window open
2019-05-11_22:17:00 RolloR.Schlafen action: up to position 30
2019-05-11_22:17:09 RolloR.Schlafen operating_seconds: 394.09
2019-05-11_22:17:09 RolloR.Schlafen action: no action
2019-05-11_22:17:09 RolloR.Schlafen 30
2019-05-11_22:17:09 RolloR.Schlafen position: 30


2019-05-11_22:34:14 RolloR.Schlafen ASC_ShuttersLastDrive: window closed at night
2019-05-11_22:34:14 RolloR.Schlafen action: down to position 50
2019-05-11_22:34:22 RolloR.Schlafen operating_seconds: 402.04
2019-05-11_22:34:22 RolloR.Schlafen action: no action
2019-05-11_22:34:22 RolloR.Schlafen 50
2019-05-11_22:34:22 RolloR.Schlafen position: 50

Das war eine manuelle Aktion:
2019-05-12_00:36:41 RolloR.Schlafen action: up to position 35
2019-05-12_00:36:48 RolloR.Schlafen operating_seconds: 408.41
2019-05-12_00:36:48 RolloR.Schlafen action: no action
2019-05-12_00:36:48 RolloR.Schlafen 35
2019-05-12_00:36:48 RolloR.Schlafen position: 35

2019-05-12_05:42:14 Helligkeitsmelder.Outdoor brightness: 94.71

2019-05-12_05:57:36 Fenster_R.Schlafen closed

2019-05-12_05:59:38 Fenster_R.Schlafen open

2019-05-12_05:59:38 RolloR.Schlafen ASC_ShuttersLastDrive: comfort - window open
2019-05-12_05:59:38 RolloR.Schlafen action: up to position 30
2019-05-12_05:59:40 RolloR.Schlafen operating_seconds: 410.52
2019-05-12_05:59:40 RolloR.Schlafen action: no action
2019-05-12_05:59:40 RolloR.Schlafen 30
2019-05-12_05:59:40 RolloR.Schlafen position: 30

2019-05-12_08:54:33 Fenster_R.Schlafen closed

2019-05-12_08:54:33 RolloR.Schlafen ASC_ShuttersLastDrive: window closed at day
2019-05-12_08:54:33 RolloR.Schlafen action: down to position 35
2019-05-12_08:54:35 RolloR.Schlafen operating_seconds: 412.48
2019-05-12_08:54:35 RolloR.Schlafen action: no action
2019-05-12_08:54:35 RolloR.Schlafen 35
2019-05-12_08:54:35 RolloR.Schlafen position: 35


2019-05-12_09:42:39 RolloR.Schlafen ASC_ShuttersLastDrive: shading in
2019-05-12_09:42:39 RolloR.Schlafen action: down to position 50
2019-05-12_09:42:45 RolloR.Schlafen operating_seconds: 418.44
2019-05-12_09:42:46 RolloR.Schlafen action: no action
2019-05-12_09:42:46 RolloR.Schlafen 50
2019-05-12_09:42:46 RolloR.Schlafen position: 50

2019-05-12_11:36:20 RolloR.Schlafen ASC_ShuttersLastDrive: shading out
2019-05-12_11:36:20 RolloR.Schlafen action: up to position 35
2019-05-12_11:36:26 RolloR.Schlafen operating_seconds: 424.84
2019-05-12_11:36:27 RolloR.Schlafen action: no action
2019-05-12_11:36:27 RolloR.Schlafen 35
2019-05-12_11:36:27 RolloR.Schlafen position: 35


Die Aktionen 20:21 und 22:17 Uhr passen soweit. 22:34 Uhr fährt er jedoch wieder auf 50 mit der Bemerkung "window closed at night". Dort gab es definitiv kein Fensterevent.
Daraufhin musste ich 0:36 das Rollo manuell steuern. Dass er um 5:42 nicht auf die Überschreitung des brightness-Wertes reagiert, ist korrekt, da der Modus noch asleep ist.
Unklar ist wieder, wieso auf das Schließen des Fensters um 5:57 keine Reaktion erfolgte. Das erneute Öffnen des Fensters 5:59 brachte eine erwartete Reaktion. Um 6:45 war Übergang von asleep auf home. Andere Rollos mit öffneten, dieses nicht, vermutlich wegen geöffnetem Fenster. Um 8:54 wird das Fenster geschlossen. Anstatt zu Öffnen fährt das Rollo wieder in Position 35. Das Shading in funktioniert sauber, beim Shading out wird wieder in Position 35 gefahren. Ist das ein neues Feature, dass er immer wieder eine manuelle Position ansteuert?
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

CoolTux

Ganz kurz zur Beschattung. Den Rest schaue ich mir heute Abend an.

Er fährt im Shading Out nicht einfach eine manuelle Position an sondern die Position welche er vor dem Shading in fahren hatte.
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