[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