[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

Begonnen von CoolTux, 27 April 2019, 08:04:52

Vorheriges Thema - Nächstes Thema

CoolTux

Nein denn das Modul Rollo sperrt sicherlich nur innerhalb seiner Bedienung.
Bei hard geht es um das sperren der Hardware, also so das die Taster über die direkt gefahren werden kann, gesperrt sind. Somit kann kein versehentliches fahren statt finden (Kinder oder so)
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

Cluni

Zitat von: Uwe S. am 21 Mai 2019, 18:10:43
Ich möchte gerne
ASC_autoShuttersControlMorning
in Abhängigkeit von einem Holiday-device schalten.


Was ich erreichen möchte:
Wenn ich im Urlaub bin, sollen die Rollläden morgens automatisch hochfahren. Wenn nicht, möchte ich die Rollläden manuell hochfahren.

Runterfahren sollen sie abends in beiden Fällen automatisch.

Aktuell habe ich das ohne ASC mit zwei einfachen ATs und entsprechender IF-Bedingung gelöst.

Vielen Dank schon im voraus für die Unterstützung.

Moin!

Mit meinem Skript ist das prinzipiell möglich. Da müsstest du dir nur ein at bauen, welches irgendwann in der Nacht (also vor dem ersten Öffnen) anhand deines Urlaubkalenders die Automatik für morgens ein- bzw. ausschaltet. In meinem Skript ist nur bereits feste verankert, dass man für jeden einzelnen Rollladen jeweils für morgens und abends wählen kann, ob die Automatik aus oder  an sein soll bzw. ob nur bei An- oder bei Abwesenheit gefahren werden soll.

Schaue doch einfach mal in die Funktionsübersicht. Wenn dir das reicht (dieses Modul hier kann in bestimmtem Bereichen bereits mehr), dann probiere das Skript doch einfach mal aus. Ich müsste ggf. noch mal die aktuelle Version hochladen. Da sind noch ein paar Kleinigkeiten geändert worden...

https://forum.fhem.de/index.php/topic,73964.0.html


Beta-User

Zitat von: Uwe S. am 21 Mai 2019, 18:10:43
Ich möchte gerne
ASC_autoShuttersControlMorning
in Abhängigkeit von einem Holiday-device schalten.
Zitat von: Cluni am 22 Mai 2019, 09:55:37
Mit meinem Skript ist das prinzipiell möglich.
Na ja, er wird jetzt wohl kaum "die Pferde wechseln" wollen...

Sollte auch mit ASC gehen, im Moment sehe ich folgenden "Umweg" als möglich an:
ASC_Mode_Up nutzen, einen "Bewohner" dafür definieren, und das betr. ASC_Roommate_Device (bzw. dessen relevantes Reading, das kann auch ein userreading im holiday-Device sein) dann zwischen home und absent schalten lassen.

Aber generell: Vermutlich solltest du (@Uwe S.) mit dem ganzen etwas spielen, evtl. "geht heute schon mehr", als du eigentlich wissen wolltest...



Zitat von: Vorhand am 21 Mai 2019, 22:38:26
Ist denn einer der unterstützten Aktoren das Modul Rollo?
Ähm, geht es um die grundsätzliche Unterstützung durch ASC? Dann: Ja klar! (Nein, wenn es um Sperrung des Aktors an sich geht, wie von CoolTux geschrieben)
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

Cluni

Zitat von: Beta-User am 22 Mai 2019, 10:06:34
Na ja, er wird jetzt wohl kaum "die Pferde wechseln" wollen...

Na anders herum haben das doch auch viele gemacht....  :P

Nein mal im Ernst - Marko hatte vorgeschlagen, dass ich ihm das mal schreiben soll. Ich denke auch, dass das mit ASC schon gehen müsste - ich kann dazu leider nur wenig beitragen, da ich immer noch mein Skript nutze und ASC noch nicht ausprobiert habe.

Vorhand

Zum Verständnis: Also hat das ASC_LockOut_cmd "blocked" nichts mit dem set blocked des Rollo-Moduls zu tun? Ebenso inhibit und protection als ASC_LockOut_cmd, sind spezielle Befehle für z.B. Hardware von Homatic.
Ich verwende Relais von Schalk, die sich vorzüglich mit dem Rollo-Modul steuern lassen. Wenn das ASC_LockOut_Cmd durch käme und z.B. ein dauerhaftes set up (Aufbefehl - einstellbar) auslösen würde, wäre das Zufahren blockiert, weil die Steuereingänge Vorrang vor den Tastereingängen haben.
Du wirst wohl dauernd mit solchen Wünschen bombardiert!?

Trotzdem noch ein Wunsch:
Das Kippen von Lamellen bei Jalousien war schon mal Thema.
Es würde ein zusätzliches attr genügen, welches bewirkt, dass bei Beschattungsfahrt "Zu" zwischen 10 und 90% am Ende der Fahrt ein Aufbefehl von 0,1 bis 1,5 sec gesendet wird default ist 0.
Danke für deine Mühe.
Viele Grüße
Raspi,Homatic,ESP,Fronius,KIA-PHEV,DHW300,Mi,Shelly

CoolTux

Zitat von: Vorhand am 22 Mai 2019, 10:14:32
Zum Verständnis: Also hat das ASC_LockOut_cmd "blocked" nichts mit dem set blocked des Rollo-Moduls zu tun? Ebenso inhibit und protection als ASC_LockOut_cmd, sind spezielle Befehle für z.B. Hardware von Homatic.
Ich verwende Relais von Schalk, die sich vorzüglich mit dem Rollo-Modul steuern lassen. Wenn das ASC_LockOut_Cmd durch käme und z.B. ein dauerhaftes set up (Aufbefehl - einstellbar) auslösen würde, wäre das Zufahren blockiert, weil die Steuereingänge Vorrang vor den Tastereingängen haben.
Du wirst wohl dauernd mit solchen Wünschen bombardiert!?
Ja und Ja und Ja  ;D
Die ASC_LockOut_cmd sind für genau die 2 Aktoren und die Befehle sperren den Aktor vor direkter Nutzung am Aktor selbst.
Wie gesagt es geht nicht darum das der Fahrbefehl aus FHEM heraus blockiert wird sondern an den Tastern/Aktoren selbst. Deine Taster werden vermütlich über FHEM eingebunden sein und sind dann mit dem Rolllo Modul verknüpft. Alle Befehle zum fahren gehen also über FHEM, das ist eher ungewöhnlich daher meine Lösung zum direkten blockieren.
Und das ganze macht in meinen Augen (man kann mich eines besseren Belehren) nur wirklich als Aussperrschutz bei Terrassentüren oder ähnlichen Türen Sinn.


Zitat von: Vorhand am 22 Mai 2019, 10:14:32
Trotzdem noch ein Wunsch:
Das Kippen von Lamellen bei Jalousien war schon mal Thema.
Es würde ein zusätzliches attr genügen, welches bewirkt, dass bei Beschattungsfahrt "Zu" zwischen 10 und 90% am Ende der Fahrt ein Aufbefehl von 0,1 bis 1,5 sec gesendet wird default ist 0.
Danke für deine Mühe.
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: Cluni am 22 Mai 2019, 10:11:02
Na anders herum haben das doch auch viele gemacht....  :P

Nein mal im Ernst - Marko hatte vorgeschlagen, dass ich ihm das mal schreiben soll. Ich denke auch, dass das mit ASC schon gehen müsste - ich kann dazu leider nur wenig beitragen, da ich immer noch mein Skript nutze und ASC noch nicht ausprobiert habe.
;D Wir hätten das script früher "vermodulen" sollen :P

Im Ernst @Uwe S.: Es ist ggf. nicht ganz einfach, in die FHEM-Welt gerade mit diesem Modul einzusteigen (?) und dann gleich "spezielle" Anforderungen realisieren zu wollen.

Ergänzend: Du kannst durchaus ASC einsetzen, und erst mal das "morgens-at" lassen wie es ist und später noch ablösen, wenn du das möchtest. Hat halt den Nachteil, dass ASC nichts von dieser zusätzlichen Logik weiß, was ggf. Nebenwirkungen haben kann.



Zu dem Lamellen-Thema:
Das wäre schön, wenn wir da erst mal die Anforderungen sammeln könnten, damit man das ggf. generischer angehen kann.
Für ROLLO mag ein zusätzlicher Aufbefehl die Lösung sein, passend aber ggf. nur für einen Anwender.
Für ZWave hängt es ggf. vom konkret verwendeten Aktor ab (FGRM-222 (?) hat ein Reading im Hauptdevice, FGRS-223 ist im Moment noch undurchsichtig, FHEM-seitig aber vermutlich ein 2. Device), für CUL_HM (mit Jalousieaktor) gibt es ebenfalls ein eigenes Reading ...

Was ROLLO angeht: evtl. wäre es eine Idee, auf dem Modulautor mal zuzugehen, ob er nicht eine slat-Positionierung einbauen kann (und dafür ein CUL_HM-ähnliches Reading verwenden)?
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

Vorhand

Meine Taster gehen nicht über den Raspi auf das Modul fhem-rollo sondern direkt auf das Relais. Das kann u.a. mit einem Taster Auf/Zu verwalten. Die zusätzlichen Steuereingänge, worauf die fhem Signale wirken, haben Vorrang vor den Tastern. Mein System funktioniert auch noch bei abwesendem Raspi mit fhem.
Aber du hast recht. Harten Aussperrschutz bekomme ich nur, wenn ich den Fensterkontakt AUF direkt auf den Relais-Steuereingang-Auf lege (24VGS). Selbst wenn gleichzeitig ein ZU-Signal von fhem kommt, hat AUF Vorrang.
Danke.
Zur Lamellenverstellung einer Jalousie hatte ich auch schon im Forum 44_Rollo vorgeschlagen, eine solche Funktion einzubauen - zumal ja auch bei Handsteuerung über fhem-Rollo dieser Bedarf besteht. Leider gab es dazu keine Antwort.
Nur die Jalousie bietet die feine Eigenschaft, dass man beschatten kann und trotzdem die Aussicht nicht versperrt. Geht allerdings nur mit ein paar hundert Millisekunden Rücklauf.
Also ganz wichtig.
Viele Grüße
Raspi,Homatic,ESP,Fronius,KIA-PHEV,DHW300,Mi,Shelly

CoolTux

Zitat von: Vorhand am 22 Mai 2019, 12:27:54
Zur Lamellenverstellung einer Jalousie hatte ich auch schon im Forum 44_Rollo vorgeschlagen, eine solche Funktion einzubauen - zumal ja auch bei Handsteuerung über fhem-Rollo dieser Bedarf besteht. Leider gab es dazu keine Antwort.
Nur die Jalousie bietet die feine Eigenschaft, dass man beschatten kann und trotzdem die Aussicht nicht versperrt. Geht allerdings nur mit ein paar hundert Millisekunden Rücklauf.
Also ganz wichtig.

Eine solche Steuerung gehört definitiv in das Rollo Modul und nicht in ASC. Versuch bitte einfach noch mal Dein Anliegen Kund zu tun.



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

Beta-User

ZitatNur die Jalousie bietet die feine Eigenschaft, dass man beschatten kann und trotzdem die Aussicht nicht versperrt. Geht allerdings nur mit ein paar hundert Millisekunden Rücklauf.
Also ganz wichtig.
Finde ich auch gut und wichtig! Habe mir "extra" zu diesem Zweck auch eine ZWave-Aktor geholt, der das können sollte (ist etwas frickelig zum Einrichten, und man muß vor Ort sein...).
Ich fände es daher auch super, wenn ASC das mit der Lamellensteuerung an sich supporten würde. Es wäre aber hinreichend, wenn man neben einem Level noch einen Kippwinkel optional angeben könnte!
Zitat von: Vorhand am 22 Mai 2019, 12:27:54Zur Lamellenverstellung einer Jalousie hatte ich auch schon im Forum 44_Rollo vorgeschlagen, eine solche Funktion einzubauen - zumal ja auch bei Handsteuerung über fhem-Rollo dieser Bedarf besteht. Leider gab es dazu keine Antwort.
FHEM lebt vom mitmachen! Ich bin mir ziemlich sicher, dass sich der Autor über einen funktionierenden Patch freuen würde (der allerdings eher ziemlich tief in den Code eingreifen wird, weil immer zuerst geprüft werden muß, ob die Jalousie-Variante vorliegt, vermute ich mal).
Aber ich halte eher wenig davon, die Timing-Geschichten auch noch in ASC zu doppeln und Richtungszustände usw. hier zu verwalten.

(Es sei angemerkt: ich habe drei weitere Jalousien hinter CUL_HM-Aktoren, die das mit der Lamellensteuerung nicht können; hier würde es mir selbst helfen, wenn ASC das Timing noch mit übernehmen könnte... Aber wer sich intensiver damit beschäftig, wird schnell feststellen, dass das unglaublich komplex ist :P )
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

Typ1er

Ich fahre meine Jalousien nach Temperaturen rauf und runter, beschatten nach bedarf, Schrittweite habe ich 0/33/66/99%, feiner bekommt man es nur von 0 oder 99% Hin. Fahre die Jalousien im Doif vorher oft auf 0% nochmal.

Das kippen wird ja nur über einen Richtungswechsel gesteuert.

Die Befehle unterscheiden sich etwas:

-Der dim Befehl fährt sie auf und ab, wobei beim abfahren sind die Jalousien zu, beim auffahren auf.
-per positionBlind wird sie auf und abgefahren, die alte Position der Lamellen wird wiederhergestellt am Ende
-per positionSlat werden nur die Lamellen verstellt
- Positionen stehen beide in einem Reading wobei ich das aufgesplittet habe

Beta-User

Zitat von: Typ1er am 22 Mai 2019, 16:38:21
Das kippen wird ja nur über einen Richtungswechsel gesteuert.
Wie meinst du das? Hast du den Betriebsmodus auf "Jalousie" umgestellt?

Zumindest der 222-er und der 223-er kennen einen "Venetian Mode", wobei der dann dafür ein "slat-irgendwas"-Reading im Haupdevice verwendet; für den von mir gerade getesteten 223-er habe ich grade zwei FHEM-Devices, eines (.01) ist für die Level-Einstellung, eines für den Drehwinkel (.02). Bei dem 223-er kann man z.B. auch konfigurieren, ob die Lamellenstellung wieder wie vor dem Fahrbefehl eingestellt werden soll oder nicht (bzw. ob das für lokale Schaltungen auch gelten soll). Bin - wie gesagt - noch nicht fertig mit konfigurieren und kenne daher uU. noch nicht alle Optionen.
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

Typ1er

Du hast ja nur 1 Motor für 2 Funtionen, für die Lamellen wird der Motor entgegengesetzt gedreht bei mir macht das 70ms für die 90° grad Bewegung. Gesteuert wird das über positionSlat.

Meine dürften gerne beschatten Tagsüber. Früh steuere ich das auf gerne allein. Ansonsten beobachten mich alle wie ich nackig ins Bad laufe. 😃🙈

Beta-User

Zitat von: Typ1er am 22 Mai 2019, 17:09:04
Gesteuert wird das über positionSlat.
Ok, demnach hast du also den "Venetian Mode" eingestellt.

Bei den CUL_HM-Rollladenaktoren (es gibt die zwischenzeitlich auch in der Jalousie-Variante, aber die habe ich nicht...) kann man
ZitatDas kippen wird ja nur über einen Richtungswechsel gesteuert.
nur so umsetzen, dass man tatsächlich einen prozentualen Fahrbefehl absetzt, der dann den Richtungswechsel initiiert und dadurch indirekt die Lamellen dreht. Dann muß man aber alle Parameter "zu Fuß" überwachen, was ein immenser Aufwand ist...

Bei den Aktoren, die positionSlat kennen, kümmert sich der Aktor darum, und man kann beides gesondert einstellen, insbesondere also (zumindest bei korrekter Parametrierung) gleich (einen zweiten Fahrbefehl) mitgeben, wie sich die Lamellen drehen sollen, wenn die Jalousie denn an der prozentualen Zielposition für hoch/runter angekommen ist. Sowas können mWn. z.B. auch (manche?) KNX-Aktoren.

Mittelfristiger Wunsch an ASC wäre es, diese Varianten (also Level+Drehbefehl direkt zu veranlassen) auch zu unterstützen, oder interpretiere ich das falsch?
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

Typ1er

Ich habe beim rollershutter 2.5 aber immer 2 Befehle. In einem geht es nicht.

-,,set <Device> dim xx" fährt einfach auf und ab, beim abfahren ist die Jalousie zu, beim auffahren auf

-,,set <Device> positionBlind xx"auf und ab normal, die alte Lamellenposition wird am Ende wiederhergestellt

-,,set <Device> positionSlat xx" steuert die Lamellen bei mir sind das die 70ms mit allen Verzögerungen vom Motor. Zu häufiges schwenken verstellt es. Daher fahre zwischendurch oft wieder den Nullpunkt an.