[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[Beta-User]

-1 müßte schon passen, ich hatte erst mal nur 3 Jalousien aktiv geschaltet, und das hatte in der vorherigen Version schon funktioniert.

Was aber ein Thema war: das mit wind scheint früher eine reine "notify-Denke" gewesen zu sein, also nicht blockierend. Hast du da was dran geändert?

Sonst könnten wir mal theoretisch erörten, wann denn nun welche Art des Blockierens angesagt ist - ggf. mag sich dazu dann auch der eine oder andere weitere Anwender dazu äußern?

Generell: Wie war das mit dem "Fahrplan"?

Ansonsten: Bei Beschattung bin ich noch nicht "ernsthaft".

[CoolTux]

Was meinst du mit Art des blockierends?
FHEM blockierend oder wie.

[Beta-User]

Nein, ich meinte, dass man entweder - wie bei den Fensterkontakten - ein "inhibit" drauflegen könnte oder jedenfalls ausschließt, dass seitens ASC eine andere Position angefahren wird als die Wind-Position (softlock). Bin nicht sicher, ob letzteres bereits implementiert war, als ich neulich getestet hatte, glaube aber eher nicht.
Das "softblocking" wäre aber m.E. auf jeden Fall sinnvoll; ein inhibit sollte man einschaltbar machen, wenn sowas gewünscht ist (ich bin da nicht so der Freund von, aber das sehen andere mit kleinen Kindern ggf. wieder ganz anders...). Jetzt können wir wieder darüber spekulieren, ob der, der für FK's ein inhibit haben will, dasselbe auch für wind gut findet...

[CoolTux]

Ah verstehe. OK schaue ich mir. Aber glaube fahren sollte er nicht wenn Fenster auf oder zu sind in da ist dann ja auch die hard Blocker Methode mit dabei.
Aber ich schaue und teste da noch mal.

[Beta-User]

Nur um Sicherzugehen: Das mit dem Fensterkontakt war nur als Vergleich zur allgemeinen Funktionsweise gedacht, es ging erst mal nicht um irgendwelche Wechselwirkungen zwischen der Fensterkontakt-Funktionalität und der Wind-Sache.

Konkret: Soweit ich mich entsinne, gingen die Jalousien neulich wieder mit dem regulären Schließen-Timer zu, obwohl noch "zu viel" Wind war. Das sollte nicht sein, sondern frühestens, wenn die untere Grenze wieder unterschritten ist.


Aber zu dem angerissenen Thema eine generelle Frage: Wie wollen wir zukünftig Priorisieren, also konkret: das Verhältnis zwischen Fensterkontakt und Wind festlegen?
Da ich bei Wind in "offen" denke, ist das für mich selbst kein pratisches Problem, da ist dann nur die Frage, wie weit offen. Aber wenn jemand bei Sturm schließt, wird er es durchaus zu schätzen wissen, wenn er einstellen kann, dass der Rollladen nach oben soll, wenn er den Fluchtweg öffnet, weil es brennt... (oder er nur eine Rauchen gehen will und er eher niedrige Schwellwerte eingestellt hat, usw.; wir kennen ja die Kreativität unserer Nutzer im Allgemeinen bereits hinlänglich )

[CoolTux]

Ich habe mal geschaut wegen dem blockieren. Wenn der Kontaktsensor nicht geschlossen an zeigt und der Rolladen vom Platz als Terrasse gesetzt ist wird nicht gefahren.

Und ausgeschlossen wird wenn windMax < 0 ist. Also auf gut Deutsch, -1 passt

[Beta-User]

Ich habe mal geschaut wegen dem blockieren. Wenn der Kontaktsensor nicht geschlossen an zeigt und der Rolladen vom Platz als Terrasse gesetzt ist wird nicht gefahren.

Und ausgeschlossen wird wenn windMax < 0 ist. Also auf gut Deutsch, -1 passt

Sorry, da verstehe ich nicht, wie das zu Wind paßt.

Konkret: Soweit ich mich entsinne, gingen die Jalousien neulich wieder mit dem regulären Schließen-Timer zu, obwohl noch "zu viel" Wind war. Das sollte nicht sein, sondern frühestens, wenn die untere Grenze wieder unterschritten ist.

Will heißen: Sind die Rollläden gegen ASC-Fahrten blockiert, solange der Wind > max ist?

[CoolTux]

Sorry, da verstehe ich nicht, wie das zu Wind paßt.
Will heißen: Sind die Rollläden gegen ASC-Fahrten blockiert, solange der Wind > max ist?

Sorry

Wenn das Fenster oder besser in Fall wird es ja dann eine Terrasentür sein im Attribut Place mit Terrasse angegeben ist und die Tür/Fenster NICHT geschlossen (gekippt,offen) ist dann wird nicht gefahren.


Ich meinte wenn im Attribut windParameter der max Parameter mit -1 angegeben ist, dann wird gar nicht beachtet.

[Beta-User]

Wir reden vermutlich aneinander vorbei:

Ganz unabhängig von irgendeinem Fenster soll ein Rollladen NIE von ASC gefahren werden, solange wind > eingestellter Wert.
(Ausgenommen natürlich die Fälle: der Deaktivierungswert ist eingestellt (-1) oder der Rollladen soll gerade in die "windsave-Position" fahren) .

[CoolTux]

Jepp wir reden einander vorbei. 

Es ist abe rgenau so eingestellt wie Du es eben beschrieben hast.

[Beta-User]

Jetzt habe ich doch noch was gefunden, was irgendwie seltsam ist:

(Vorab: ich habe den wind um 9:02 Uhr nicht nachgeschaut, aber es war in der Realität nicht windig, jetzt steht das auf 12 und manuell angefaßt habe ich es auch nicht.)

Dieser (bzw. noch ein paar mehr) Rollladen sollte m.E. eigentlich offen sein, er ist (bzw. demnächst war) aber geschlossen - ausweislich des list wegen wind-unprotection. Das macht natürlich wenig Sinn .

Code Auswählen Erweitern

Internals:
   DEF        52A1F5
   FUUID      5c432276-f33f-d171-ac08-960487f251607654
   IODev      CUL_0
   NAME       Rollladen_Bad_OG
   NOTIFYDEV  global
   NR         193
   NTFY_ORDER 50-Rollladen_Bad_OG
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   READINGS:
     2019-03-22 09:02:23   ASC_ShuttersLastDrive wind un-protection
     2019-03-23 08:52:50   ASC_Time_DriveDown 23.03.2019 - 19:11
     2019-03-23 08:52:50   ASC_Time_DriveUp 24.03.2019 - 08:30
     2019-03-22 09:02:23   CommandAccepted yes
     2017-12-09 00:30:54   D-firmware      2.3
     2017-12-09 00:30:54   D-serialNr      LEQ0069461
     2017-12-21 07:35:16   PairedTo        0x425EE2
     2017-12-21 07:35:17   R-driveDown     15 s
     2017-12-21 07:35:17   R-driveTurn     0.5 s
     2017-12-21 07:35:17   R-driveUp       16 s
     2017-12-21 07:35:16   R-pairCentral   0x425EE2
     2017-12-21 07:35:17   R-powerUpAction off
     2017-12-21 07:35:17   R-sign          off
     2017-12-21 07:35:16   RegL_00.        02:01 0A:42 0B:5E 0C:E2 15:FF 18:00 00:00
     2017-12-21 07:35:17   RegL_01.        08:00 09:00 0A:00 0B:00 0C:96 0D:00 0E:A0 0F:05 10:00  30:06 57:06 56:00 00:00
     2018-08-02 21:41:33   automode        1
     2019-03-22 09:02:43   deviceMsg       off (to VCCU)
     2019-03-22 09:02:43   level           0
     2019-03-22 09:02:43   motor           stop:off
     2019-03-22 09:02:43   pct             0
     2019-03-22 09:02:43   recentStateType info
     2019-03-22 09:02:43   state           off
     2019-03-22 09:02:43   timedOn         off
   helper:
     HM_CMDNR   198
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +52A1F5,00,00,00
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         52A1F5
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   00
     role:
       chn        1
       dev        1
       prs        1
     tmpl:
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_Antifreeze_Pos 15
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_BlockingTime_afterManual 1200
   ASC_BlockingTime_beforDayOpen 3600
   ASC_BlockingTime_beforNightClose 3600
   ASC_BrightnessSensor Bewegungsmelder_1
   ASC_Closed_Pos 0
   ASC_ComfortOpen_Pos 80
   ASC_Down   astro
   ASC_Drive_Offset -1
   ASC_Drive_OffsetStart -1
   ASC_GuestRoom none
   ASC_LockOut soft
   ASC_LockOut_Cmd none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Reading pct
   ASC_PrivacyDownTime_beforNightClose -1
   ASC_PrivacyDown_Pos 50
   ASC_Roommate_Device rr_Kinder
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading_Angle_Left 75
   ASC_Shading_Angle_Right 75
   ASC_Shading_Direction 116
   ASC_Shading_Min_Elevation 35
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Mode off
   ASC_Shading_Pos 30
   ASC_Shading_StateChange_Cloudy 20000
   ASC_Shading_StateChange_Sunny 35000
   ASC_Shading_WaitingPeriod 1200
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 18:15
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 07:00
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 08:30
   ASC_Up     astro
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WiggleValue 5
   ASC_WindParameters 120
   ASC_WindowRec Fenster_Bad_OG
   ASC_WindowRec_subType threestate
   IODev      CUL_0
   IOgrp      VCCU
   alias      Rolladen Bad OG
   autoReadReg 4_reqStatus
   cmdIcon    on:fts_shutter_up off:fts_shutter_down up:control_plus down:control_minus toggle:fts_shutter_updown stop:control_x
   devStateIcon off:fts_shutter_up:up on:fts_shutter_down:down 9\d.*:fts_shutter_10:down 8\d.*:fts_shutter_20:down 7\d.*:fts_shutter_30:down 6\d.*:fts_shutter_40:down 5\d.*:fts_shutter_50:down 4\d.*:fts_shutter_60:up 3\d.*:fts_shutter_70:up 2\d.*:fts_shutter_80:up 1\d.*:fts_shutter_90:up 0\d.*:fts_shutter_100:up
   expert     2_full
   firmware   2.3
   group      Türen und Fenster
   icon       fts_shutter_updown
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Bad_OG
   serialNr   LEQ0069461
   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_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_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_WindowRec ASC_WindowRec_subType:twostate,threestate room_map structexclude
   webCmd     on:off:pct
   widgetOverride pct:colorpicker,BRI,0,1,100

[CoolTux]

Interessant. Das schaue ich mir später mal an.

[Beta-User]

Vielleicht noch eine Ergänzung:

Ich habe den _Verdacht_, dass ggf. auch via "un-protection" Rollläden gefahren werden, die auf -1 stehen. Da ich jüngst alle auf einen (teilweise hohen) Wert gesetzt habe, kann ich das nicht mehr konkret so einfach nachstellen, aber meine Regierung war nicht begeistert, dass häufig die Rollläden tagsüber unten waren, als sie deutlich vor Dämmerungseinbruch nach Hause kam... (das war die Beobachtung mit der Vorversion)

[CoolTux]

Ich habe den Fehler gefunden. Logikproblem. Aber da muß ich erstmal noch schauen wir ich das sauber gelöst bekomme.
Bis dahin empfehle ich alle Rolläden auf -1 für den Wind zu setzen.

[Beta-User]

Hmmm,

ich komme nochmal auf den Vorschlag zurück, das ganze eher in die Richtung umzubauen, dass bei einem relevanten Event ALLE (soll-) ZUSTÄNDE nochmal geprüft werden (Residents, Fensterkontakt, wind, shading...). Vermutlich brauchen wir in dem Rahmen eine Art Priorisierung (hatte ich hier schon mal am Beispiel Wind vs. Fensterkontakt versucht zu erläutern).

Ich habe den Fehler gefunden. Logikproblem. Aber da muß ich erstmal noch schauen wir ich das sauber gelöst bekomme.
Bis dahin empfehle ich alle Rolläden auf -1 für den Wind zu setzen.

Mist, jetzt habe ich gestern das notify gelöscht...

Und: Bist du sicher, dass das das Problem behebt? (Siehe meinen zwischenzeitlichen Beitrag).