FHEM > Automatisierung

[ASC] Lock out korrekt einrichten

(1/13) > >>

marvin78:
Hallo,

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


--- Code: ---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

--- Ende Code ---

(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: ---set ASC hardLockOut on
--- Ende Code ---

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: ---set ASC-Device lockOut soft
--- Ende Code ---

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)?

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln