ASC - Feststellung der Griffstellung vor Fahrt, nicht vor Wartezeit

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

Vorheriges Thema - Nächstes Thema

marvin78

Zitat von: CoolTux am 08 Januar 2024, 09:26:28
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.

Hey CoolTux. Ist das eigentlich mal passiert? Ich habe das nicht verfolgt. Meine Rollläden verhalten sich noch immer nicht korrekt und ich halte das, was ich beschrieben habe, eigentlich für ein essentielles Verhalten eines solchen Moduls.

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

Ich hatte gerade wieder den Fall, dass ich den Griff erst umgelegt hatte, nachdem die Prüfung stattgefunden hat. Der Rollladen ist dann auf der Fliegentür gelandet, weil ASC "dachte", die Tür und die Fliegentür wären zu und dann den Rollladen geschlossen hat. Die Prüfung muss eben unmittelbar vor der Fahrt stattfinden und nicht oder nicht nur, wenn das Ereignis eintritt, welches zum Schließen führt. Es reicht, wenn dazwischen Sekunden liegen, um in einer Katastrophe zu enden. Kannst du mir einen kleinen Horizont geben, wann und ob  du hier mit der Umsetzung rechnest? Falls es keine Hoffnung auf Änderung gibt, muss ich auf ein paar Vorteile von ASC verzichten und wieder auf die alte Skriptlösung bauen.

Danke.

CoolTux

Ich empfehle dann die alte Script Lösung. Du bist aktuell alleine mit Deiner Anforderung. Sorry
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 09 Januar 2025, 10:08:29Ich empfehle dann die alte Script Lösung. Du bist aktuell alleine mit Deiner Anforderung. Sorry

Die Anforderung ist doch sachlich voll nachvollziehbar - bisher hatte ich keinen Anlass, mich hier dazu ausdrücklich zu positionieren.

Prinzipiell sollten vor einer getimerten Fahrt immer alle Bedingungen nochmal geprüft werden.

Meine 2ct.
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

Naja. Du hattest geschrieben, dass du dich der Sache annimmst (weil es eine sehr logische und für die sichere Funktion des Moduls notwendige Maßnahme ist - man sollte nicht (sehr sinnvolle) Verzögerungen anbieten und dann das ganze für die sichere Funktion nicht an allen Stellen logisch durchziehen - das kann viel kaputt machen und ein User, der nicht weiß, was der da tut, kann damit sogar die Rollladen/Jalousien zerstören ). Deshalb habe ich darauf gewartet, dass du Zeit dafür aufbringen kannst (sehr lange und geduldig). Tatsächlich bin ich weit davon entfernt, einem Entwickler eines Moduls zu sagen, was er zu tun hat. ABER: Wenn man etwas zusagt, dann hält man sich dran oder sagt Bescheid, wenn man keine Lust dazu hat. Dafür habe ich dann Verständnis, hierfür jedoch nicht.

Hat ASC eine Art API, mit der ich eine geplante Fahrt eines Rollladen aufhalten kann?

Beta-User

Zitat von: Beta-User am 09 Januar 2025, 10:11:31
Zitat von: CoolTux am 09 Januar 2025, 10:08:29Ich empfehle dann die alte Script Lösung. Du bist aktuell alleine mit Deiner Anforderung. Sorry

Die Anforderung ist doch sachlich voll nachvollziehbar
... weswegen sich hier auch bereits andere gemeldet hatten...
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

CoolTux

Ich habe keine Zeit dafür. Jeder weiß aber das ich Patches gerne annehme und einbauen.
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

#23
Ich verstehe den Aufbau des Moduls in keiner Weise und gehe davon aus, dass du sowas deutlich schneller eingebaut hast, als ich es könnte. Da es auch Sicherheit bieten muss, wage ich mich an eine solche Sache nicht gerne ran. Aber gut, ich habe verstanden. Tatsächlich halte ich das Modul so für weitgehend unbrauchbar, da man damit Rollladen nicht annähernd sicher steuern kann.

Ich schaue mir an, ob ich einen Patch liefern könnte, gehe aber davon aus, dass ich meine alten Skript schneller wieder auf Vordermann habe...wie gesagt, hatte ich bisher auf deine Umsetzung gewartet, die du ja bereits zugesagt hattest.

CoolTux

Bitte einmal diese Datei oder besser den Inhalt der Datei bei Dir ins System einpflegen

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/patch-marvin78/lib/FHEM/Automation/ShuttersControl.pm


Es ist nicht so einfach genau das um zu setzen was Du wolltest. Ich habe eine "Lösung" gefunden. Einfach so zu sagen er soll nicht fahren weil der Fenster/Tür Sensor offen ist geht nicht. Er soll ja fahren wenn das Fenster geöffnet wird. Er soll fahren wenn die Tür auf ist aber SelfDefense aktiv und so weiter.



Die "Lösung" funktioniert sofern folgendes vorausgesetzt ist.

- das Rollo muss in der Position Open stehen
- der Sensor muss auf open stehen / gestellt werden
- Attribut ASC_ShuttersPlace muss auf terrace gesetzt sein
- Attribut ASC_Self_Defense_Mode muss auf off gesetzt sein


Bitte teste einmal ob es mit den Änderungen funktioniert.
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

Hey. Danke. Ich teste das, wenn ich dazu komme, heute noch. Sonst morgen. Wenn es funktioniert, wie du sagst, ist es völlig ausreichend.

marvin78

So. Erster Test war erfolgreich. Ich konnte die Fahrt an einer Terrassentür aufhalten, während andere schon fuhren oder gefahren waren. Ich teste das weiter. Danke!

marvin78

Das sieht gut aus. Es hat nun mehrfach so geklappt so sollte es auch sein. Aus meiner Sicht könntest du das so einchecken.

Ich verstehe die Einschränkungen bezüglich Defense Mode. Dafür hätte ich allerdings ohnehin den Vorschlag, dass dafür noch zusätzliche Parameter geprüft werden können. Ein Rollladen darf bspw. dann NIEMALS fahren (auch nicht bei Defense), wenn noch eine Fliegentür geöffnet ist, die sich hinter dem Rollladen befindet). In dem Fall müsste ein weiterer Sensor unmittelbar vor der Fahrt abgefragt werden.

CoolTux

Kann denn die Fliegentür offen und im Weg sein auch wenn die Terrassentür geschlossen ist?
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 21 Januar 2025, 17:07:21Kann denn die Fliegentür offen und im Weg sein auch wenn die Terrassentür geschlossen ist?
Wieso denn nicht?
Gibt nach meinem Eindruck alle möglichen Kombinationen und kaum Regeln für sowas....
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