ASC - Feststellung der Griffstellung vor Fahrt, nicht vor Wartezeit

Begonnen von marvin78, 05 Januar 2024, 06:46:06

Vorheriges Thema - Nächstes Thema

marvin78

@CoolTux: Ich hatte das Thema schon einmal angesprochen. Aus meiner Sicht ist es sehr wichtig, dass die Griffstellung und die damit verbundene Entscheidung, ob ein Rollladen fährt, nicht nur vor der Verzögerungszeit, sondern dann nochmal unmittelbar vor der Fahrt festgestellt wird. Es kommt viel zu oft vor, dass man den Griff benutzt um eine Fahrt zu verhindern und der Rollladen dann trotzdem fährt, weil vor der individuellen Verzögerung der Fahrt für den speziellen Rollladen die Griffstellung anders war.

Dann darf natürlich kein inhibit gesetzt werden (oder es muss konfigurierbar sein), wenn der Rollladen unten ist und der Griff auf Offen gestellt wird. Hochfahren muss dann möglich sein (Fluchtweg). Auch das hatte ich vor langer Zeit schon angesprochen (falls das konfigurierbar ist, ist es zu schwer zu finden - wie vieles). Danke.

CoolTux

Hallo Marvin,

Ich wünsche Dir ein gesundes neues Jahr. Was ich mich frage ist woher Du weißt wann genau der Rolladen fährt so das Du genau vor diesem Moment des Drehgriff betätigst? Wenn das Rollo erstmal fährt kann ASC es nicht mehr unterbrechen. Die groß ist Deine höchste Verzögerungszeit bei ASC?


Grüße
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

marvin78

#2
Danke für die guten Wünsche. Ebenso :)

Ich weiß es, weil es ständig passiert.

Es geht nicht darum, dass es bereits fährt.

Folgendes Szenario (ich hatte das schon einmal woanders genauer ausgeführt): Terrasse-Hauptausgang. Rollladen soll nicht fahren, es fällt einem aber erst ein, wenn es schon fast dunkel ist, stellt den Griff auf offen, damit er nicht fährt. Man weiß nicht, dass für ASC eigentlich schon Dunkelheit getriggert wurde, weil man das nicht ständig verfolgt. Der Rollladen hat ein Delay von 130 Sekunden. ASC hat schon nachgeschaut, ob der Griff auf geöffnet steht, stand er zum Zeitpunkt des Beginns des Delays nicht. Rollladen fährt also, unabhängig vom Drehgriffzustand zum Zeitpunkt der Fahrt, trotzdem. Das kommt nicht so selten vor, wie man zunächst denkt und sollte so nicht sein und es sollte sogar durch schnelles öffnen des Griffs eine Fahrt abbrechbar sein, der Rollladen dann wieder hoch fahren (so hatte ich es in mein altes Skript gebaut und so ist es auch sinnvoll). Tatsächlich muss zwingend unmittelbar vor der Fahrt der Status es Drehgriffs (ggf. noch einmal oder überhaupt) überprüft werden.




CoolTux

Also wir können gerne mal schauen wie es sich verhält wenn ich kurz vor der Fahrt abfrage ob das Fenster geöffnet ist. Ich frage nichts weiter ab, dazu würde auch die Terrassentür zählen ohne irgendwelche zusätzlichen Bedingungen. Einfach nur ob es offen ist oder nicht. Aber nur öffen, keine Angekippt. Würde Dir das vorerst reichen?
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

marvin78

Naja. Es geht ja NUR um die Offenstellung. Es geht darum, dass man mit dem Griff, als "Schalter" verhindert, dass die Fahrt nach unten (und nur nach unten) stattfindet. Die Griffstellung zum Zeitpunkt des Triggers "dunkel" oder was auch immer als Trigger herangenommen wird, um runter zu fahren, ist dabei unerheblich. Die Griffstellung zum Zeitpunkt unmittelbar VOR der Fahrt ist aber interessant. Dazwischen sind bei mir "nur" 130 Sekunden. Das könnten aber woanders deutlich mehr sein.

Folgendes passiert bei uns in dem Zusammenhang auch ziemlich oft: Besuch betritt das Haus durch die besagte Terrassentür. Weil das eben so war, stehen die Schuhe des Besuchs vor der Terrassentür. Er wird also das Haus auch dort wieder verlassen. Griffstellung bleibt also bewusst auf "offen", damit der Rollladen nicht herunter fährt. Leider haben manche der Besucher andere Terrassentüren oder aber auch manchmal das Hirn zu Hause gelassen und bewegen den Griff vor dem Verlassen in "geschlossen"-Stellung, weil sie offenbar denken, sie haben es mit einer normalen Haustür zu tun. Da helfen dann auch die 3 Sekunden Wartezeit, die ich in die HM-Aktoren eingebaut habe, nicht, der Rollladen fährt runter. Leider ist dann aber, da der Griff natürlich nach dem Anfahren der Rollladen erneut betätigt wird (der Gast bekommt dann Zuckungen ;)) und auf "Offen" gestellt wird, es nicht möglich, die Fahrt aufzuhalten (inhibit wird durch die erneute Offenstellung gesetzt). Man muss erst wieder auf geschlossen stellen, damit die Fahrt aufgehalten und der Rollladen erneut hochgefahren werden kann. Es wäre also gut, wenn man eine gewisse Verzögerung der Fahrt nach unten einstellen könnte, bevor der Rollladen dann wirklich fährt. Auch hier sollte natürlich dann erst unmittelbar vor der Fahrt die Griffstellung kontrolliert und dementsprechend dann auch nicht gefahren werden, wenn der Griff wieder auf offen steht. Klingt komplex, ist aber eigentlich ganz einfach und gewöhnlich.

CoolTux

Das muss ich mir in Ruhe durch den Kopf gehen lassen. Es sind jetzt schon viele komplexe Zusammenhänge enthalten. Mal schauen was ich da noch 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

CoolTux

Ich habe mir die Nacht Gedanken gemacht. Ich kann versuchen bei irgendeiner Form von öffnen des Fensters einen emergency Stop oder sogar Drive Up ein zu bauen. Voraussetzung dafür wäre aber das das Rollo sich in Fahrt befindet. Es muss also zwingend das Attribut zum erkennen einer Fahrt dafür gesetzt sein.

Was wäre besser? Halt oder Drive Up?
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

Beta-User

Zitat von: CoolTux am 06 Januar 2024, 08:52:31Was wäre besser? Halt oder Drive Up?
MAn.: default stop, aber bitte konfigurierbar...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

marvin78


CoolTux

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

marvin78

Gut, dass es angegangen wird. Das Problem, um das es eigentlich hier im Thread gehen sollte, ist damit aber noch nicht erfasst oder?

CoolTux

Zitat von: marvin78 am 08 Januar 2024, 08:33:51Gut, dass es angegangen wird. Das Problem, um das es eigentlich hier im Thread gehen sollte, ist damit aber noch nicht erfasst oder?

Doch ich denke schon. Denn ich werde die Abfrage wie gewünscht direkt vor der abschließenden Fahrt machen.
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

loetmeister

Hi,

Warum wird eine so lange Verzögerung gesetzt?

Bzgl. dem überraschenden schließen... wäre eine Idee ASC_PrivacyDownValue_beforeNightClose mit ein paar wenigen Prozent zu konfigurieren, das man sieht das der Rollo sich bald schließt?

Ich hab auch ein Rollo an der Terrassentür, mit hard Lockout, da wäre eine direkte Reaktion auf SC open/close während der Fahrt nicht schlecht. Meine präferierte Konfigurationsoptionen wäre in die gegengesetze Richtung zu fahren.  ;D

Gruß
Thomas

marvin78

Na weil eben oft vorkommt, dass man das Fenster noch frei lassen möchte, aber man erst dran denkt, wenn schon Rollläden geschlossen werden. Man sieht, dass andere Rollläden runter gehen, geht schnell zu dem, der offen bleiben soll und stellt den Griff entsprechend. Leider ist der Nutzen aber nicht vorhanden, wenn der Status zur falschen Zeit geprüft wird. Es ist nicht nur ein Aussperrschutz. Es ist ein Schalter.


marvin78

Hat sich hier eigentlich was getan? Ich habe nicht aufgepasst aber auch keine Änderung am Verhalten festgestellt.