[ASC] Lock out korrekt einrichten

[marvin78]

Hallo,

ich möchte einen Aussperrschutz mit der aktuellen ASC-Version einrichten. In einem entsprechenden Device habe ich folgende Attribute gesetzt:

Code Auswählen Erweitern


attr DEVICE ASC_LockOut hard
attr DEVICE ASC_LockOut_Cmd inhibit
attr DEVICE ASC_ShuttersPlace terrace
attr DEVICE ASC_WindowRec tk.TerrasseSeite:status
attr DEVICE ASC_WindowRec_subType threestate


(status ist ein userReading, das ein Event erzeugt)

Da es einen in der Doku erwähnten Befehl nicht mehr gibt (siehe unten), also folgendes:

Erwartung: Wenn ich das den Dehgriff auf open stelle, fährt der Rollladen danach weder per ASC noch per Taster (da inhibit gesetzt wird).

Realität: Per Taster kann ich den Rollladen fahren (ASC hatte noch keine Fahrt, das teste ich später noch). Inhibit wird bei open nicht gesetzt. Notifydev ist vorhanden, Inibit kann durch ASC gesetzt werden (siehe weiter unten).

Angestellte Vermutung nach dem groben durchforsten des Forums (die Doku gibt dazu ja wenig bis nichts her, da die Zusammenhänge nur in diversen Forenthreads vorhanden sind und die Befehle früher wohl andere Namen hatten bzw. nicht mehr existieren, die Zusammenhänge in der Doku aber offenbar noch auf den alten Stand sind): Ich muss den Befehl

Code Auswählen Erweitern

set ASC hardLockOut on

verwenden.

Erwartung: Nun funktioniert das gewünschte Verhalten.

Realität: Es blockiert sofort alle Rollladen hart mit inhibit (der Drehgriff hat keinen Einfluss, der Rollladen lässt sich per Taster nicht bedienen, alle so konfigurierten Rollladen erhalten den inhibit Befehl sofort). Das ist im Wiki gut beschrieben. Da habe ich es zunächst aber nicht gesucht. Ich verwende immer zuerst die Doku.


Die Frage ist also: Wie muss man einen Lockout-Schutz korrekt einrichten?

Als Hinweise: Es gibt keine Abhänigkeiten von Anwesenheiten. Es gibt keine weiteren ASC-Positionen für den Rollladen als auf, zu und lüften, sodass hier nichts weiter, als ein Threestatesensor, dessen Status von ASC (per API überprüpft) auch korrekt erkannt wird, einen Einfluss haben sollte. Der Rolladen war beim Test auf komplett geöffnet.  Das alles lässt sich beliebig reproduzieren. Es ist also nicht so, dass inhibit mal gesetzt wird und mal nicht. Ich habe all das per Log und API überprüft.

Danke.


Edit: Ein Hinweis zur Ergänzung: Den Befehl, der in der aktuellen Doku erwähnt wird:

Code Auswählen Erweitern

set ASC-Device lockOut soft

den es vermutlich auch mal mit hard gegeben hat, gibt es ja nicht (mehr). Ist der ersatzlos gestrichen? Die Doku macht so allerdings wenig Sinn, da der oben genannte Befehl für hardLockOut hier hin verweist und dieser offenbar ganz etwas anderes tut. Ist ein globales Setzen also nicht nötig? Reicht per Definition das Attribut ASC_LockOut? Das würde nicht erklären, dass inhibit zwar bei einem set ASC hardLockout on gesetzt wird, nicht aber durch den Kontakt, obwohl dessen Status richtig erkannt wird.

Ich werde hier noch weiter testen, möchte aber die Frage geklärt haben, ob oben genannte Attribute reichen sollten, um den Ausperrschutz für ein einzelnes Fenster zu realisieren und ich den Fehler bei mir suchen muss.


Weiteres Edit: Bei ASC_Debug=1 kommt nichts weiter ins Log, wenn ich einen Drehgriff auf open setze. Das Event ist aber im Eventmonitor erkennbar. Gibt es also weitere Voraussetzungen dafür, dass ASC das Event überhaupt erkennt? Wurde ein Attribut/ein möglicher Status vergessen? Ich habe nicht die Zeit durch den ganzen Code zu schauen, einen kurzen Blick habe ich aber rein geworfen. Funktioniert Lockout bzw. Drehgriff-Events nur dann, wenn manuell gefahren wurde (IsAfterShuttersManualBlocking)?

[marvin78]

Es ist tatsächlich, wie vermutet. Die manuelle Fahrt beeinflusst das Verhalten dieser Funktion (was extrem unlogisch ist - das mag bei Ventilate und Co. Sinn ergeben aber nicht hier).

Wenn also manuell gefahren wurde und die im Attribut oder per Default eingestellte Zeit für das Blocking noch nicht verstrichen ist, funktioniert der LockOut Schutz NICHT. Das ist natürlich so quatsch.

Schuld ist IsAfterShuttersManualBlocking($shuttersDev) - Zeile 247 in EventProcessingFunctions. Das darf natürlich beim LockOut so nicht geprüft werden. Das sollte nur für die entsprechenden Fahrten geprüft werden. Der Lockout-Schutz muss IMMER möglich sein, egal ob gerade manuell gefahren wurde oder nicht.

Danke für die Aufmerksamkeit

[CoolTux]

Danke Dir Marvin, das schaue ich mir gerne an.

[marvin78]

Super. Danke. Bitte auch nochmal über die commandref schauen und die Stelle mit dem genannten Befehl, den es nicht mehr gibt ggf. nachbessern.

[marvin78]

Folgefrage: Ich habe dazu noch nichts gefunden. Produziert ASC ein Event wenn ein Rollladen wegen eines Lockouts nicht gefahren werden kann (bspw. für eine entsprechende Benachrichtigung)?

[CoolTux]

Folgefrage: Ich habe dazu noch nichts gefunden. Produziert ASC ein Event wenn ein Rollladen wegen eines Lockouts nicht gefahren werden kann (bspw. für eine entsprechende Benachrichtigung)?

Nein.

[marvin78]

Schade. Ist nicht 100%ig wichtig aber ggf. kannst du es mal  auf ne Wunschliste setzen.

[marvin78]

Ein weiterer Punkt hierzu: eigentlich muss der Aussperrschutz nicht geschaltet werden, wenn der Rollladen unten ist und die Tür geöffnet wird. Dann sollte eher Lüften angefahren werden können. Aussperrschutz dann, wenn Rollladen geöffnet werden sollte (open pos). Ist aber sicher in der aktuellen Struktur schwer umzusetzen.

[CoolTux]

Ich habe eben mal in den Code geschaut. Also es sollte kein Unterschied machen ob Blocking Time oder nicht. Es sollte sofort und unmittelbar gesperrt werden sobald terrace, LockOut hard und LockOut_Cmd inhibit gesetzt ist.

[marvin78]

Hm. Ich lese den Code anders (wobei ich irren kann, ist ja nicht mein Code) und es verhält sich in der Praxis auch anders. Es wird nur gesperrt, wenn die Blockzeit abgelaufen ist. Das habe ich hin und her getestet. Ich habe deshalb die Blockzeit auf 1 Sekunde gesetzt. So läuft es.

Auch wird geblockt, wenn der Rollladen unten ist. Das ergibt, aus meiner Sicht, keinen großen Sinn. Es müsste dann erst wieder bei open_pos geblockt werden.

[CoolTux]

Sorry Du hast Recht. Ich habe es eben gesehen. Ich schau mal wie ich das am besten hinbekomme.

[marvin78]

Konnstest du dir diesen Komplex schon ansehen @CoolTux?

[CoolTux]

Leider noch keine Zeit gefunden. Bin aber dran.

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/issues/67

[marvin78]

Super. Danke.

[loetmeister]

Hallo,

wenn es eine neue ASC Version gibt, würde ich mich (auch) zum testen anbieten. 
Hatte heute an der Terassentür den ersten Fensterkontakt angeschlossen, um das Verhalten nachzuvollziehen.

Gruß,
Thomas

[CoolTux]

Könnt Ihr bitte einmal testen.
Dazu müsst Ihr in der FHEMWEB Kommandozeile folgendes tun

Code Auswählen Erweitern


update list

schauen ob dort bereits eine extra Quelle für ASC drin steht, wenn ja bitte mit update delete entfernen. Ansonsten

Code Auswählen Erweitern


update add https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/patch_issues67-Lockout_and_BlockingManualTime/controls_AutoShuttersControl.txt


Im Anschluss dann

Code Auswählen Erweitern


update


und

Code Auswählen Erweitern


shutdown restart




Grüße

[loetmeister]

Hi,

danke für die neue Version.
Soweit ich das beurteilen kann, ist das Problem behoben. "inhibit" wird nun gesetzt, egal ob vorher manuell gefahren wurde oder nicht. Ich habe noch keine weiteren Fenster mit einer andern Konfiguration d.h. Lüftungsfunktion, etc. kann ich aktuell nicht testen.

Code Auswählen Erweitern

attr EG_Rollo_WZ_TR ASC 2
attr EG_Rollo_WZ_TR ASC_BrightnessSensor Aussen_Helligkeit_raw:value 1000:200
attr EG_Rollo_WZ_TR ASC_Down brightness
attr EG_Rollo_WZ_TR ASC_Drive_Delay 6
attr EG_Rollo_WZ_TR ASC_LockOut hard
attr EG_Rollo_WZ_TR ASC_LockOut_Cmd inhibit
attr EG_Rollo_WZ_TR ASC_Pos_Reading level
attr EG_Rollo_WZ_TR ASC_Shutter_IdleDetection working:off
attr EG_Rollo_WZ_TR ASC_ShuttersPlace terrace
attr EG_Rollo_WZ_TR ASC_WindowRec EG_SC_WZ_Terasse

Gruß,
Thomas

[marvin78]

Ich kann/konnte noch nicht testen.

@loetmeister: Wird inhibit noch gesetzt, wenn der Rollladen untern ist und man den Griff auf offen stellt? Diese Funktion halte ich für Quatsch.

[CoolTux]

Ich kann/konnte noch nicht testen.

@loetmeister: Wird inhibit noch gesetzt, wenn der Rollladen untern ist und man den Griff auf offen stellt? Diese Funktion halte ich für Quatsch.

Diesbezüglich habe ich eben noch mal Änderungen eingebaut. Also bitte noch mal update machen. Danke

[loetmeister]

Hi,

ich habe keinen "threestate" Fensterkontakt. Sobald die Terrassentür offen, gekippt oder nur angelehnt ist, ist der Sensor im Status "open".
Ich testen morgen mal, wenn die Rollos automatisch hoch gefahren sind. Die Tests heute waren schon mit geschlossenen Rollos.

Im Detail:
Rollo war automatisch geschlossen

• Terrassentür geöffnet: Rollo fährt komplett hoch u. inhibit ist aktiv
• Terrassentür geschlossen: Rollo fährt komplett runter u. inhibit ist inaktiv

Rollo war automatisch geschlossen

• Rollo manuell komplett hoch gefahren (bei geschlossener Terrassentür )
• Terrassentür geöffnet: Rollo fährt nicht, inhibit wird aktiviert
• Terrassentür geschlossen: Rollo fährt komplett runter u. inhibit ist wieder inaktiv

PS: Ich hatte jeweils nur update all https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/patch_issues67-Lockout_and_BlockingManualTime/controls_AutoShuttersControl.txt gemacht (inkl. restart natürlich), so sollte später bei einem regulären update wieder das Standard ASC Modul heruntergeladen werden, oder?

Gruß,
Thomas

[CoolTux]

Hi,

ich habe keinen "threestate" Fensterkontakt. Sobald die Terrassentür offen, gekippt oder nur angelehnt ist, ist der Sensor im Status "open".
Ich testen morgen mal, wenn die Rollos automatisch hoch gefahren sind. Die Tests heute waren schon mit geschlossenen Rollos.

Im Detail:
Rollo war automatisch geschlossen

• Terrassentür geöffnet: Rollo fährt komplett hoch u. inhibit ist aktiv
• Terrassentür geschlossen: Rollo fährt komplett runter u. inhibit ist inaktiv

Rollo war automatisch geschlossen

• Rollo manuell komplett hoch gefahren (bei geschlossener Terrassentür )
• Terrassentür geöffnet: Rollo fährt nicht, inhibit wird aktiviert
• Terrassentür geschlossen: Rollo fährt komplett runter u. inhibit ist wieder inaktiv

PS: Ich hatte jeweils nur update all https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/patch_issues67-Lockout_and_BlockingManualTime/controls_AutoShuttersControl.txt gemacht (inkl. restart natürlich), so sollte später bei einem regulären update wieder das Standard ASC Modul heruntergeladen werden, oder?

Gruß,
Thomas

Du meinst du hast nicht das repo mit add hinzugefügt? Dann sollte später ein normales Update erfolgen.

[loetmeister]

ok, danke

Ich muss den zweiten Test nach dem letzten update & restart noch mal korrigieren.
Das verhalten hat sich geändert:
Rollo war automatisch geschlossen

• Rollo manuell komplett hoch gefahren (bei geschlossener Terrassentür)
• Terrassentür geöffnet: Rollo fährt nicht, inhibit wird nicht aktiviert
• Terrassentür geschlossen: Rollo fährt nicht, inhibit wird inaktiv gesetzt

Denke es ist ok den Rollo nach einer manuellen Öffnung nicht automatisch zu schließen, inhibit sollte aber beim öffnen gesetzt werden.

Gruß,
Thomas

[CoolTux]

Ok ich danke Dir. Da müssen wir noch nach bessern. Schaue ich mir nachher gleich noch mal an.

[CoolTux]

So eine neue Version ist online. Kann wieder getestet werden.

[marvin78]

Ich habe gerade keine Zeit, das näher zu analysieren aber bei mir wird inhibit mit der aktuellen Version überhaupt nicht mehr gesetzt. Die Rolladen fahren ganz normal, auch wenn der Griff auf open steht.

[CoolTux]

Ich habe gerade keine Zeit, das näher zu analysieren aber bei mir wird inhibit mit der aktuellen Version überhaupt nicht mehr gesetzt. Die Rolladen fahren ganz normal, auch wenn der Griff auf open steht.

Habe noch mal eine kleine Änderung vorgenommen. Jetzt sollte es gehen.

[marvin78]

Scheint zu funktionieren. Richtig testen mit allem drum und dran kann ich das frühestens morgen. Sorry.

Danke aber schone einmal für die Mühe!

[loetmeister]

Danke aber schone einmal für die Mühe!

Da schließe ich mich selbstverständlich an! 


Ich habe mein Rollo heute ein weniger weiter malträtiert.  So ganz richtig scheint es noch nicht zu funktionieren...

Es scheint problemlos zu sein, wenn der Rollo in einer bekannten Position ist (100%, 0%).
Rollo ist offen, Fenster auf: inhibit wird gesetzt.
Rollo ist zu, Fenster auf: inhibit wird gesetzt und Rollo wird geöffnet (ventilate open) - Rollo bleibt auch offen, wenn Fenster geschlossen wird (ist ok, ist ja auch Tag)

Wenn die aktuelle Position aber eine andere ist, z.B. 90% passiert nichts wenn das Fenster geöffnet wird (inhibit wird nicht gesetzt), beim schließen wird inhibit auf "off" gesetzt.
Denke hier wäre es gut wenn ebenfalls "ventilate open" gefahren würde.


Gruß,
Thomas

[CoolTux]

Da schließe ich mich selbstverständlich an! 


Ich habe mein Rollo heute ein weniger weiter malträtiert.  So ganz richtig scheint es noch nicht zu funktionieren...

Es scheint problemlos zu sein, wenn der Rollo in einer bekannten Position ist (100%, 0%).
Rollo ist offen, Fenster auf: inhibit wird gesetzt.
Rollo ist zu, Fenster auf: inhibit wird gesetzt und Rollo wird geöffnet (ventilate open) - Rollo bleibt auch offen, wenn Fenster geschlossen wird (ist ok, ist ja auch Tag)

Wenn die aktuelle Position aber eine andere ist, z.B. 90% passiert nichts wenn das Fenster geöffnet wird (inhibit wird nicht gesetzt), beim schließen wird inhibit auf "off" gesetzt.
Denke hier wäre es gut wenn ebenfalls "ventilate open" gefahren würde.


Gruß,
Thomas

Also das eigentliche anfahren der Fenster offen Position sollte immer gehen. Wichtig entweder die ManualBlockingTime ist vorbei oder du hast place terrace gesetzt.

[loetmeister]

Hi CoolTux,

ok, dann ist noch was im argen. Das Fenster/Tür mit dem ich teste hat ASC_ShuttersPlace terrace gesetzt.

Wenn die aktuelle Position aber eine andere ist, z.B. 90% passiert nichts wenn das Fenster geöffnet wird (inhibit wird nicht gesetzt), beim schließen wird inhibit auf "off" gesetzt.
Denke hier wäre es gut wenn ebenfalls "ventilate open" gefahren würde.

Seltsamerweise hatte es heute einmal funktioniert. Hatte den Rollo manuell auf ca. 30% gefahren, dann das Fenster geöffnet, woraufhin "ventilate open" gefahren wurde. Reproduziren ließ sich das Verhalten aber nicht.


@marvin78, wie sieht es bei dir aus? 


Gruß,
Thomas

[marvin78]

Was sind bei dir 30%? Recht weit unten oder oben?

Ich sehe es so, dass unten nicht behandelt werden darf, wie oben. Egal wo es da steht.

Aber ich konnte leider noch nicht testen. Aktuell ist hier der Teufel los. Sorry dafür.

Was ich nur im "Normalbetrieb" gemerkt habe ist, dass es die Rolllanden "in der Nacht" nicht mehr immer schließen, wenn man den den Grill auf closed stellt. Das war vor der Testversion hier zuverlässig der Fall. Außerdem sind zwei Rollladen gestern gar nicht nach Brightness runter gefahren, obwohl Griif auf closed. ASC "dachte" aber sie wären gefahren (Brigthness level ... below). Funkprobleme oder ähnliches kann ich komplett ausschließen. Es handelt sich in einem Fall um Wired und im anderen Fall ein HM und der Rollladen ist in den letzten 6 Jahren immer gefahren, wenn er sollte. Er hat keinen Funkbefehl bekomme. Das habe ich gecheckt.

[CoolTux]

Jetzt müssen wir dann langsam anfangen genauere Aussagen zu bekommen.
@loetmeister
Ich muss genau wissen was Fenster/Tür offen bei Dir bedeutet? Angeklappt oder wirklich offen. Hast Du twoState oder threeState? Bei threeState muss ControlComfort im ASC auf on stehen. Dann muss ich wissen was welche Positionen bei Euch sind. 100 offen oder geschlossen, 0 offen oder geschlossen. Das reicht mir schon.
Die Rollos fahren bei Fenster öffnen nur wenn die aktuelle Position unterhalb der entsprechenden FensterOffen Position ist. Also je nach Einstellung VentilatePos oder ComfortPos. Egal wie das Rollo muss immer unterhalb dieser Position sein wenn ein Fenster geöffnet wird.

Daher bitte immer versuchen ein klein wenig genau die aktuelle Situation beschreiben, dann was habt ihr gemacht und was ist passiert. Und gaaanz wichtig, habt ihr das auch erwartet oder wie war eure Erwartung..


Vielen Dank
Marko

[marvin78]

Wie gesagt: Ich habe aktuell keine Zeit, so genau zu testen.

Warum sich allerdings die Erwartungen zur Vorversion ändern sollten, ist nicht ganz klar. Die Erwartungen zum LockOut stehen hier im Thread.

[CoolTux]

Wie gesagt: Ich habe aktuell keine Zeit, so genau zu testen.

Warum sich allerdings die Erwartungen zur Vorversion ändern sollten, ist nicht ganz klar. Die Erwartungen zum LockOut stehen hier im Thread.

Ich habe eben in meiner kleinen Laborumgebung folgendes konfiguriert und getestet:

Rollo1 mit Fenster1/Terassentür (0%unten 100%oben)

• ASC_ShuttersPlace terrace
• ASC_ComfortOpen_Pos 100
• ASC_LockOut hard
• ASC_LockOut_Cmd inhibit
• ASC_WindowRec_subType threestate

Erster Durchlauf:
Es ist Nacht, die Rollos sind geschlossen. Ich stelle den Fenstergriff auf tilted und wie erwartet von mir fährt das Rollo in die Ventilate Position (default 30). inhibit wird nicht gesetzt. Fenster wird geschlossen das Rollo fährt in die geschlossen Position und da das Fenster als Terrasse deklariert ist wird Proforma inhibit off gesetzt (das sollte ich nich mal überarbeiten. Wenn schon off ist sollte da nicht noch mal ein set off kommen).
Verhalten wie von mir erwartet

Zweiter Durchlauf:
Es ist Nacht, die Rollos sind geschlossen. Ich stelle den Fenstergriff auf open und wie erwartet öffnet sich das Rollo ganz (100%), inhibit wird auf on gesetzt. Fenster wird wieder geschlossen, Rollo fährt runter auf 0 (ganz zu) und inhibit wird off gesetzt.

Dritter Durchlauf:
Ich fahre das Rollo manuell. Das Attribut BlockintTimeAfterManual ist nicht gesetzt daher default 20min. Das Fenster steht auf 10 Prozent also ganz knapp geöffnet und somit unterhalb jeglicher Fenster offen Positionen. ASC_ShuttersLastDrive steht manual. Sofort nach der manuellen Fahrt kippe ich das Fenster und das Rollo fährt in die ventilate Position. inhibit wird nicht gesetzt. Ich schließe das Fenster und das Rollo fährt zu. inhibit wird off gesetzt. Ich öffne das Fenster ganz und das Rollo fährt auf 100%, Comfort Position also, inhibit wird on gesetzt.
Ich schließe das Fenster und das Rollo fährt nicht!!!! (so nicht von mir erwartet). inhibit wird off gesetzt.

Verhalten wie von mir erwartet mit Ausnahme des 3. Durchlaufes.


Selbige Tests bei einem Rollo welches nicht als Terrasse deklariert ist und die Attribute

• ASC_LockOut
• ASC_LockOut_Cmd

nicht gesetzt sind.
das Rollo öffnet in ventilate Position wenn Fenster gekippt und schließt sich wieder wenn Fenster geschlossen. Fenster öffnen Rollo fährt in Comfort Position (80) und schließt sich wieder wenn Fenster geschlossen wird.
Ich fahre manuell auf 10 Prozent, also unterhalb aller Fenster offen/gekippt Positionen. ASC_ShuttersLastDrive steht manual. Ich kippe das Fenster und das Rollo fährt nicht.

Wie erwartet.



Bei der ganzen Testerei habe ich bemerkt das es in der Tat noch einen Bug gibt wenn vorher manuell gefahren wurde. Dann wird nach einem Fenster schließen nicht gefahren, also das Rollo nicht geschlossen.

[marvin78]

Bei der ganzen Testerei habe ich bemerkt das es in der Tat noch einen Bug gibt wenn vorher manuell gefahren wurde. Dann wird nach einem Fenster schließen nicht gefahren, also das Rollo nicht geschlossen.

Das wird es sein. Das könnte zu beiden Fenstern gestern passen. Jedoch nicht nur bei Fenstern schließen. Auch bei brightness-Event nicht.

[CoolTux]

Bei meinen Überlegungen bezüglich BlockingAfterManual kam mir nun die Frage auf wie das bei Terrasse und/oder gesetzten ASC_LockOut interpretiert werden soll.

Einig sind wir uns das wenn ASC_LockOut gesetzt wird es auf jeden Fall auch immer angewendet werden soll. Es soll also das, in Eurem Fall inhibit gesetzt werden so das nicht mehr von einem Taster aus gefahren werden kann und ASC auch nichts mehr macht.

Aber soll trotz BlockingAfterManual ASC das Rollo noch bewegen wenn das Fenster geöffnet/gekippt wird oder soll nur das inhibit gesetzt werden? Es ist also die Frage ob sich ASC anders verhalten soll wenn ein ASC_LockOut gesetzt wird? Wobei ich der Meinung bin das es eigentlich nichts mit dem ASC_LockOut zu tun haben sollte. Wenn dann eher das der Platz auf Terrasse steht. Sollen also Rollos mit ASC_ShuttersPlace terrace anders bewertet werden was BlockingAfterManual  an geht.

[CoolTux]

Das wird es sein. Das könnte zu beiden Fenstern gestern passen. Jedoch nicht nur bei Fenstern schließen. Auch bei brightness-Event nicht.

Ja natürlich. Da wurde ja nichts geändert. ASC Verhält sich mit Ausnahme der hier besprochenen Fenster/Tür offen schließen und sperren Einstellungen wie sonst auch. Also wenn manuell gefahren wurde wird ASC innerhalb der BlockingAfterManualTime keine weiteren Aktionen durchführen.

[marvin78]

Folgendes:


- Rollladen offen, Griff wird auf offen gesetzt: ASC_LockOut und inibit
- Rollladen offen, Griff wird auf gekippt gesetzt: Aus meiner Sicht kein LockOut Schutz nötig. Warum auch? Es ist sicher niemand durch diese Tür gegangen.
- Rollladen zu, Griff wird auf offen oder tiltet gesetzt gesetzt: aus meiner Sicht muss ventilate angefahren werden (aus meiner Sicht sogar egal, ob vorher manual vorlag), wenn gesetzt, KEIN inhbit
- Rollladen manuell über Zentrale runter gefahren, wenn Griff schon auf offen: ASC sollte nicht fahren (man hat sich was dabei gedacht)[/li][/list]

[marvin78]

Ja natürlich. Da wurde ja nichts geändert. ASC Verhält sich mit Ausnahme der hier besprochenen Fenster/Tür offen schließen und sperren Einstellungen wie sonst auch. Also wenn manuell gefahren wurde wird ASC innerhalb der BlockingAfterManualTime keine weiteren Aktionen durchführen.

BlockingTimerAfterManual steht bei mit auf 1 Sekunde. Das ist es nicht.

[CoolTux]

BlockingTimerAfterManual steht bei mit auf 1 Sekunde. Das ist es nicht.

Also beim Thema Brightness und der Griff stand auf geschlossen hätte das Rollo runter fahren sollen. Hier wurde auch nichts am Code geändert. Ganz andere Sektion.

Beim Brightness und Rollo ist nicht gefahren weil Fenster offen und beim späteren Fenster schließen hätte die Nachtfahrt nachgeholt werden müssen. Auch hier hätte das Rollo fahren sollen da Du ja blockingTime 1s hast. Und wenn nicht durch einen blöden Zufall innerhalb der Sekunde ein manuelles Fahren erkannt wurde hätte das Rollo sich bewegen müssen.

[marvin78]

Also beim Thema Brightness und der Griff stand auf geschlossen hätte das Rollo runter fahren sollen. Hier wurde auch nichts am Code geändert. Ganz andere Sektion.

Das kommt öfter vor. Allerdings bisher nicht bei mehreren. Ich suche noch die Ursache. Ich nehme an Race-Condition. Sicher bin ich nicht. zu wenig Daten.

[CoolTux]

Folgendes:


- Rollladen offen, Griff wird auf offen gesetzt: ASC_LockOut und inibit

Passt

- Rollladen offen, Griff wird auf gekippt gesetzt: Aus meiner Sicht kein LockOut Schutz nötig. Warum auch? Es ist sicher niemand durch diese Tür gegangen.

Passt

- Rollladen zu, Griff wird auf offen oder tiltet gesetzt gesetzt: aus meiner Sicht muss ventilate angefahren werden (aus meiner Sicht sogar egal, ob vorher manual vorlag), wenn gesetzt, KEIN inhbit

Warum sollte ventilate angefahren werden wenn Fenster offen und nicht gekippt? Wir reden ja immer noch von als Terrasse deklariert. Hier sollte also bei offen das Rollo so hoch fahren das man durchgehen kann um auf die Terrasse zu kommen. Und dann sollte auch inhbit gesetzt werden mit on.

- Rollladen manuell über Zentrale runter gefahren, wenn Griff schon auf offen: ASC sollte nicht fahren (man hat sich was dabei gedacht)[/li][/list]

Das verstehe ich nicht. Meines Wissens wird ASC hier auch nichts machen. ASC reagiert ja nur auf Events. Wird also das Rollo geschlossen trotz offenen Griffes so passiert erstmal nichts ausser das ASC bemerkt das das Rollo manuell bewegt wurde.
Wird dann das Fenster geschlossen, wird lediglich inhbit off gesetzt wenn das Rollo ganz geschlossen ist. Ist es auf einer Position welche nicht ClosedPos ist dann fährt ASC allerdings in die ClosedPos.


Wir sollten auch nicht vergessen das wir hier erstmal nur über Verhalten bei Nacht reden. Am Tag bleibt das Rollo eh ganz oben wenn Fenster geschlossen wird und das Rollo auf voll offen stand. Stand es anders wird entsprechend der Konfiguration gefahren. Also entweder ganz auf oder LastPosition.

[loetmeister]

@loetmeister
Ich muss genau wissen was Fenster/Tür offen bei Dir bedeutet? Angeklappt oder wirklich offen. Hast Du twoState oder threeState? Bei threeState muss ControlComfort im ASC auf on stehen. Dann muss ich wissen was welche Positionen bei Euch sind. 100 offen oder geschlossen, 0 offen oder geschlossen. Das reicht mir schon.
Die Rollos fahren bei Fenster öffnen nur wenn die aktuelle Position unterhalb der entsprechenden FensterOffen Position ist. Also je nach Einstellung VentilatePos oder ComfortPos. Egal wie das Rollo muss immer unterhalb dieser Position sein wenn ein Fenster geöffnet wird.

Hi Marko,

meine Testfenster/Terrasse, sieht so aus:
(100% == Rollo oben)

Code Auswählen Erweitern

ASC 2
ASC_BrightnessSensor Aussen_Helligkeit_raw:value 1000:250
ASC_Down brightness
ASC_Drive_Delay 6
ASC_LockOut hard
ASC_LockOut_Cmd inhibit
ASC_Pos_Reading level
ASC_Shutter_IdleDetection working:off
ASC_ShuttersPlace terrace
ASC_WindowRec EG_SC_WZ_Terasse

Sensor ist "twoState" - dann ist ventilatePos == openPos, so wie ich das verstanden hatte. Wenn der Fenterkontakt "offen" meldet müsste doch immer gefahren werden, wenn die aktuelle Position nicht 100% ist?

Wie du geschrieben hast, klappt es nach einer manuellen Fahrt nicht.

PS: inhibit zur Sicherheit zu setzen, auch wenn es schon den richtigen Wert hat ist gar nicht so schlecht... da man den Status von inhibit (bei Homematic) nicht abfragen kann. Also lieber ein mal "zu viel" als zu wenig 

Gruß,
Thomas

[marvin78]

Warum sollte ventilate angefahren werden wenn Fenster offen und nicht gekippt? Wir reden ja immer noch von als Terrasse deklariert. Hier sollte also bei offen das Rollo so hoch fahren das man durchgehen kann um auf die Terrasse zu kommen. Und dann sollte auch inhbit gesetzt werden mit on.

Weil man im Sommer gerne lüftet, in dem man den die TÜr komplett auf macht. Dann braucht man ventilate. Es sollte eben nicht Standard sein, dass der Rollladen hoch fährt, wenn Griff geöffnet. Es sollte minimal konfigurierbar sein. Nicht immer will man raus, wenn man die Terrassentür öffnet. Im Gegenteil. Man will eher selten raus, wenn man sich entschieden hat, dass Nacht ist (Griff schon einnmal geschlossen).[/list]

[CoolTux]

Weil man im Sommer gerne lüftet, in dem man den die TÜr komplett auf macht. Dann braucht man ventilate. Es sollte eben nicht Standard sein, dass der Rollladen hoch fährt, wenn Griff geöffnet. Es sollte minimal konfigurierbar sein. Nicht immer will man raus, wenn man die Terrassentür öffnet. Im Gegenteil. Man will eher selten raus, wenn man sich entschieden hat, dass Nacht ist (Griff schon einnmal geschlossen).[/list]

Das ist aber nicht minimal das ist sehr komplex und Du bist auch ehrlich gesagt der erste mit dieser Anforderung 
Ich überlege.


Und ich habe noch etwas gefunden. Bitte achtet bei Euren Tests nicht nur auf ASC_BlockingTime_afterManual sondern auch auf ASC_BlockingTime_beforeNightClose und ASC_BlockingTime_beforeDayOpen. Beides wird beim schließen des Fensters beachtet.


Ansonsten tendiere ich aktuell in der Tat dazu auch die BlockingTimeAfterManualDrive beim öffnen des Fensters mit zu beachten. Ausserdem finde ich sollte das ganze sperren der Rollos lediglich für gesetzte Terrassen Standorte gelten. Wie seht Ihr das?

[marvin78]

BlockingTimes sind bei mir alle auf 1 Sekunde. Damit kann ich nicht viel anfangen.

[CoolTux]

Ich habe noch mal eine neue Version hoch geladen. Schaut mal bitte. Wer testen kann bitte testen. Ich arbeite noch an der Sache mit dem nicht dauernden setzen von ASC_LockOut_Cmd.

[CoolTux]

Hi Marko,

meine Testfenster/Terrasse, sieht so aus:
(100% == Rollo oben)

Code Auswählen Erweitern

ASC 2
ASC_BrightnessSensor Aussen_Helligkeit_raw:value 1000:250
ASC_Down brightness
ASC_Drive_Delay 6
ASC_LockOut hard
ASC_LockOut_Cmd inhibit
ASC_Pos_Reading level
ASC_Shutter_IdleDetection working:off
ASC_ShuttersPlace terrace
ASC_WindowRec EG_SC_WZ_Terasse

Sensor ist "twoState" - dann ist ventilatePos == openPos, so wie ich das verstanden hatte. Wenn der Fenterkontakt "offen" meldet müsste doch immer gefahren werden, wenn die aktuelle Position nicht 100% ist?

Wie du geschrieben hast, klappt es nach einer manuellen Fahrt nicht.

PS: inhibit zur Sicherheit zu setzen, auch wenn es schon den richtigen Wert hat ist gar nicht so schlecht... da man den Status von inhibit (bei Homematic) nicht abfragen kann. Also lieber ein mal "zu viel" als zu wenig 

Gruß,
Thomas

Hallo Thomas,

Jepp das passt soweit. Wenn twoState gesetzt dann wird die openPos angefahren.
Und in diesem Fall sollte in der Tat immer gefahren werden. Und schon hast Du einen Bug gefunden. Ich habe das mal überprüft und festgestellt das bei diesem Szenario geschaut wird ob das Rollo aktuell unterhalb der VentilatePos steht. Wenn nicht dann wird auch nicht hoch gefahren. Also wieder was gefixt.

[loetmeister]

Ausserdem finde ich sollte das ganze sperren der Rollos lediglich für gesetzte Terrassen Standorte gelten. Wie seht Ihr das?

Hi,

ja, würde ich zustimmen. Es ist ja der Aussperrschutz, das trifft ja nur für Türen zu


In der letzten Testversion fehlen wohl ein paar ";" und Klammern... hab noch nicht alles gefunden. Kannst du noch mal schauen?

Code Auswählen Erweitern

2021.12.08 11:27:17 1: reload: Error:Modul 73_AutoShuttersControl deactivated:
syntax error at lib/FHEM/Automation/ShuttersControl/EventProcessingFunctions.pm line 304, near ");"
Compilation failed in require at lib/FHEM/Automation/ShuttersControl.pm line 80, <$fh> line 2539.
BEGIN failed--compilation aborted at lib/FHEM/Automation/ShuttersControl.pm line 80, <$fh> line 2539.
Compilation failed in require at ./FHEM/73_AutoShuttersControl.pm line 51, <$fh> line 2539.
BEGIN failed--compilation aborted at ./FHEM/73_AutoShuttersControl.pm line 51, <$fh> line 2539.

[CoolTux]

Hi,

ja, würde ich zustimmen. Es ist ja der Aussperrschutz, das trifft ja nur für Türen zu


In der letzten Testversion fehlen wohl ein paar ";" und Klammern... hab noch nicht alles gefunden. Kannst du noch mal schauen?

Code Auswählen Erweitern

2021.12.08 11:27:17 1: reload: Error:Modul 73_AutoShuttersControl deactivated:
syntax error at lib/FHEM/Automation/ShuttersControl/EventProcessingFunctions.pm line 304, near ");"
Compilation failed in require at lib/FHEM/Automation/ShuttersControl.pm line 80, <$fh> line 2539.
BEGIN failed--compilation aborted at lib/FHEM/Automation/ShuttersControl.pm line 80, <$fh> line 2539.
Compilation failed in require at ./FHEM/73_AutoShuttersControl.pm line 51, <$fh> line 2539.
BEGIN failed--compilation aborted at ./FHEM/73_AutoShuttersControl.pm line 51, <$fh> line 2539.

Sorry. Ist gefixt. Kann sein das Du ein rescan der Rollos machen musst und damit leider auch verbunden ein createNewNotifyDev.

[loetmeister]

Hi Marko,

danke. Device ist wieder da 
Ich teste heute Abend (nach "night close") - aktuell, im "day open" Modus wird ASC_LockOut_Cmd nicht gesetzt, egal ob der Rollo bereits oben ist, oder manuell komplett runter gefahren wurde.
"ASC_blockASCDrivesAfterManual" habe ich nicht gesetzt, daher würde ich erwarten der Rollo fährt immer komplett auf und LockOut wird gesetzt. (immer, egal ob gefahren werden muss oder nicht)
Anhand der bisherigen Diskussion bin ich mir aber nicht sicher ob du diesen Punkt schon angegangen bist. (wenn es ein Bug und keiner Layer 8 Problem ist)

Gruß,
Thomas

[CoolTux]

Hi Marko,

danke. Device ist wieder da 
Ich teste heute Abend (nach "night close") - aktuell, im "day open" Modus wird ASC_LockOut_Cmd nicht gesetzt, egal ob der Rollo bereits oben ist, oder manuell komplett runter gefahren wurde.
"ASC_blockASCDrivesAfterManual" habe ich nicht gesetzt, daher würde ich erwarten der Rollo fährt immer komplett auf und LockOut wird gesetzt. (immer, egal ob gefahren werden muss oder nicht)
Anhand der bisherigen Diskussion bin ich mir aber nicht sicher ob du diesen Punkt schon angegangen bist. (wenn es ein Bug und keiner Layer 8 Problem ist)

Gruß,
Thomas

Also LockOut wird bei mir immer gesetzt. Auch am Tag und auch wenn das Rollo oben ist.

[eurofinder]

@CoolTux:
Ich habe hierzu ma leine Frage:

Rollo1 mit Fenster1/Terassentür (0%unten 100%oben)
ASC_ShuttersPlace terrace
ASC_ComfortOpen_Pos 100
ASC_LockOut hard
ASC_LockOut_Cmd inhibit
ASC_WindowRec_subType threestate

Wenn Open = 100, dann darf doch ComfortOpen_pos nicht auch 100 sein - oder doch? War es nicht so, dass alle Werte unterscheidlich sein müssen?

Gruß
eurofinder

[marvin78]

Gelesen habe ich das auch. Logisch ist es in der Praxis, gerade in dem Fall, jedoch nicht wirklich.

[CoolTux]

@CoolTux:
Ich habe hierzu ma leine Frage:
Wenn Open = 100, dann darf doch ComfortOpen_pos nicht auch 100 sein - oder doch? War es nicht so, dass alle Werte unterscheidlich sein müssen?

Gruß
eurofinder

Das trifft in der Tat in den meisten Fällen zu. In diesem besonderen ist es jedoch ausdrücklich nötig. Bei vielen lässt sich die Terrassentür erst öffnen wenn der Rollo vollständig geöffnet ist. Daher wurde hier eine Ausnahme gemacht.

[eurofinder]

@CoolTux:
OK, danke.

Gruß
eurofinder

[loetmeister]

Also LockOut wird bei mir immer gesetzt. Auch am Tag und auch wenn das Rollo oben ist.

ok, war mein Fehler. Magnet war verrutscht.. ist noch nicht der finale Status. 

Mit der aktuellen Testversion sieht es gut aus. Rollo öffnet, egal welche Position er hat und egal ob manuell gefahren wurde. Beim schließen der Tür wird auch (Nachts) der Rollo wieder geschlossen.
Ich beobachte es in den nächsten Tagen weiter.

Bzgl. "threestate" Verhalten kann ich aber nichts sagen...

Gruß,
Thomas

[eurofinder]

Hat zufällig jemand Rollläden von Somfy IO mit Velux KLF200 und ASC in Betrieb?
Funktioniert ASC Lock out damit? Irgendwie verstehe ich die Funktion noch nicht, denn ich schaffe es nicht Hard Lock so einzustellen, dass eine Steuerung über Somfy Smoove IO A/M-Schalter nicht mehr möglich ist.

Gruß
eurofinder

[CoolTux]

Hat zufällig jemand Rollläden von Somfy IO mit Velux KLF200 und ASC in Betrieb?
Funktioniert ASC Lock out damit? Irgendwie verstehe ich die Funktion noch nicht, denn ich schaffe es nicht Hard Lock so einzustellen, dass eine Steuerung über Somfy Smoove IO A/M-Schalter nicht mehr möglich ist.

Gruß
eurofinder

Es werden zum sperren nur die Kommandos unterstützt welche da zur Auswahl stehen. Kann aber gerne versuchen mehr ein zu bauen.

[marvin78]

Ich denke tatsächlich das Sperren wäre ein Bereich, bei dem es generisch gehen sollte. Es gibt unendlich viele Befehle. Bei HMIP und HMIP Wired kann man nur mit einer Kobination von vielen Befehlen sperren. Es gibt kein inhibit. Hier darf es, aus meiner Sicht, keine starren Befehle geben. Das geht viel zu weit auseinder. Perl sollte erlaubt sein.

[CoolTux]

Ich habe den patch nun in den Devel Zweig gemergt. Kommt dann also mit dem nächsten Update

Kann bitte der ersteller des Threads diesen auf gelöst setzen. Danke

[marvin78]

Der Thread dreht sich ja um das korrekte Einrichten des Lock-Out.

Außerdem bin ich mit meinen Tests noch nicht durch. Gelöst setze ich ihn ggfd. wenn das geschehen ist.

[joshi]

Hallo CoolTux,

ich habe ein Innenrollo, dass nur per DayOpen NightClose gefahren wird. "Nachts" funktioniert HardLockOut perfekt und der Homematic Schalter wird bei öffnen der Tür auf inhibit gesetzt.

Wenn ich jedoch Tagsüber die Tür öffne würde ich erwarten, dass das Rollo auch auf "Inhibit" gesetzt wird. Es scheint mir jedoch, dass Tagsüber nicht auf den Fensterkontakt getriggert wird. Ist diese Beobachtung korrekt? Kann ich das beispielsweise durch aktivieren von einem (nie greifenden) Shading beeinflussen?

[CoolTux]

Eigentlich sollte er immer sperren. Welche Version verwendest Du aktuell?

[joshi]

73_AutoShuttersControl.pm:v0.10.19-s25223/2021-11-14

aus dem FHEM SVN

Update:

Es scheint eine Wechselwirkung von dem dokumentierten Problem aus BlockingAfterManuel und einer Wechselwirkug von HMCCU 5 und ASC zu sein. Da dieses im Grund nichts mit LockOut zu tun hat eröffne ich dafür einen neuen Faden https://forum.fhem.de/index.php/topic,125271.0.html.

Update 2:
Damit bei der Kombination aus HMCCU und ASC_LockOut=hard der entsprechende Befehl gesendet wird, habe ich ASC_LockOutCommand=inhibit gesetzt und eine eine EventMap generiert.

Code Auswählen Erweitern


attr mydevice eventMap /datapoint INHIBIT true:inhibit on/datapoint INHIBIT false:inhibit off/


vielleicht hilft das ja jemandem

[marvin78]

Was noch auffällt:

Gibt es ein Delay und man merkt, dass andere Rollladen runter gehen, dreht dann noch schnell den Griff eines Fensters auf open, bei dem der Rollladen nicht runter gehen soll, geht er trotzdem dann nach dem Delay runter. Das sollte so natürlich nicht passieren. Richtig wäre, wenn der Status des Griffs erst in dem Moment geprüft wird, wenn der Delay abgelaufen ist (oder eben nochmal). So hat es mein selbst gebautes Skript immer gemacht. So war ich in der Lage, noch einzugreifen, falls ich vorher vergessen hatte, ein Fahren durch Griff zu verhindern.