[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[CoolTux]

Wir legen es erstmal auf den To-Do Stapel

[hexenmeister]

Ich würde wahrscheinlich nicht so kompliziert mit dem Comfort/Verntilate etc. gestallten.
Recht nicht ein kombiniertes Attrubut für alles?
So was in der Art:

Code Auswählen Erweitern

attr ASC ASC_windowRec_Action open:100 tilted:80 close:last

Also Key-Value-Paare mit <event>:<action> Action wäre dann der Wert für Position mit Sonderwerten wie 'last' für 'vorherige Position wiederherstellen'.

Damit könnte man Anzahl der Attribute im Allgemeinen drastisch reduzieren.

[CoolTux]

Key Value Paare wurden nur beim Auslesen von Attributen gehen, wir haben aber auch welche wo die Werte der Attribute in die NOTIFYDEV kommen zum triggern, da geht es dann nicht mehr. Das auseinander zu halten ist mir zu viel unnötiger Aufwand.

Aktuell habe ich das ASC_Pos_after_ComfortOpen etwas besser (meiner Meinung nach) benannt ASC_ComfortOpen_Pos.
Sicherlich findet sich in naher Zukunft diesbezüglich noch mehr Einsatzmöglichkeiten.


Grüße

[Tomy]

Hi Cooltux,

also mein Helligkeitssensor ist die Photovoltaikanlage auf dem Dach -> je höher die Leistung, desto stärker scheint die Sonne
von daher, bitte die "brightness" aufnehmen!

Danke & Grüße Matthias

Was denkt Ihr sollte eine Mindestanforderung an Daten sein für eine Beschattung

Aktuell denke ich
brightness (Hellikeitssensor)
azimuth (Sonnenwinkel, Twilight oder Astro)
elevation (Sonnenhöhe, Twilight oder Astro)
temperature (Aussentemperatur)


Kleiner Logauszug

Code Auswählen Erweitern


2018.11.14 11:52:05.071 3: AutoShuttersControl (ASControl) - Shading Processing, Rollladen: RolloKinZimSteven_F2
2018.11.14 11:52:05.071 3: AutoShuttersControl (ASControl) - Shading Processing, Variablen - Azimuth: 180.1 Elevation: 19.4 Brightness: 598 Aussentemp: 100 Rollladenausrichtung: 178 Eintritswinkel Links: 85 Ausstrittswinkel Rechts: 85


[Tomy]

Hi Cooltux,

konntest du schon mal über die Jalousien (Type KNX) nachdenken, bei der die Position der Jalousie und die Neigung der Lamelle über getrennte set Befehle (0-100) gesteuert werden könnte?
Könntest das ja mal auf die "Wunschliste" aufnehmen.

Danke & Grüße
Matthias

Ok also Lamellenunterstützung wäre dann bei Dir nicht möglich, das normale fahren aber schon. Ist nur doof wenn die Lamellen waagerecht sind und das Modul sagt schließe und der Rolladen fährt komplett runter aber die Lamellen bleiben waagerecht. Da müsste man dann noch einen Befehl für die Lamellen nachlegen.
Ich denke mal drüber nach 

[CoolTux]

Hi Cooltux,

konntest du schon mal über die Jalousien (Type KNX) nachdenken, bei der die Position der Jalousie und die Neigung der Lamelle über getrennte set Befehle (0-100) gesteuert werden könnte?
Könntest das ja mal auf die "Wunschliste" aufnehmen.

Danke & Grüße
Matthias

Hallo Matthias,

Jepp habe ich mehrere Tage drüber nachgedacht und ich denke es wird kommen. Aber so langsam müssen wir erstmal priorisieren, Rollladensteuerung ist ein umfangreiches Projekt und jeder hat so seine Wünsche und Vorstellungen. Daher habe ich ja auch von Anfang an gesagt es wird mindestens ein Jahr dauern bis alle zufrieden läuft und integriert ist. Aber ich kann Dir sagen das ich vorhabe Lamellensteuerung mit auf zu nehmen. Und das wir vom Zeitplan her sehr gut aufgestellt sind, Beschattung zum Beispiel wollte ich erst im neuen Jahr machen und bin jetzt schon zu gekommen. Mal schauen wie gut es weiterhin läuft. Wichtig sind die Tester und die Rückmeldungen.


Grüße
Leon

[enno]

Moin CoolTux,

ich habe jetzt fast alle meine bisher in DOIF, AT, Notify verteilten Aufgaben für ein Rollo mit deinem Modul ersetzt. Und es läuft. Meine Frau ist zufrieden Am Wochenende kommt das Nächste an die Reihe.... da muss ich mir aber noch ein "Workaround" für den Fernseher einfallen lassen, weil wenn das nicht geht ich hier kein Essen mehr bekomme...

Hilfreich war die Diskussion um die Lüftung und Comfortfunktion. Ich nutze "twostate" simuliert mit 1-Wire Reedkontakt im Fensterrahmen in diesem Fall nur für Lüften. 

Gruss
  Enno

[CoolTux]

Moin CoolTux,

ich habe jetzt fast alle meine bisher in DOIF, AT, Notify verteilten Aufgaben für ein Rollo mit deinem Modul ersetzt. Und es läuft. Meine Frau ist zufrieden Am Wochenende kommt das Nächste an die Reihe.... da muss ich mir aber noch ein "Workaround" für den Fernseher einfallen lassen, weil wenn das nicht geht ich hier kein Essen mehr bekomme...

Hilfreich war die Diskussion um die Lüftung und Comfortfunktion. Ich nutze "twostate" simuliert mit 1-Wire Reedkontakt im Fensterrahmen in diesem Fall nur für Lüften. 

Gruss
  Enno

Hallo Enno,

Vielen Dank für das Feedback. Sowas wird immer gebraucht. Das mit dem Fernsehr bekommen wir später auch noch hin, bis dahin musst Du leider ein Provisorium schaffen.
Was genau soll denn passieren mit dem Fernsehr und dem Rollladen? Wenn Fernsehr an und ein bestimmter Helligkeitswert unterschritten soll gefahren werden?



Grüße

[enno]

Was genau soll denn passieren mit dem Fernsehr und dem Rollladen? Wenn Fernsehr an und ein bestimmter Helligkeitswert unterschritten soll gefahren werden?

Wenn Fernseher an abhängig von brightness (Hellikeitssensor), azimuth (Sonnenwinkel, Twilight oder Astro), elevation (Sonnenhöhe, Twilight oder Astro) fährt an einem Fenster das Rollo auf definierte Position. Wenn Fernseher aus greifen wieder die Standardeinstellungen.

Ich denke ich werde an dem Fenster erst einmal die Lüftenfunktion "missbrauchen".

Gruss
  Enno

[FunkOdyssey]

Vermutlich hat doch jeder Wünsche dieser Art - nur halt stark unterschiedliche.
Kann man für solche Dinge nicht irgendwelche Trigger einbauen?
Oder ein SET, welches nur die Ausführung durchführt?
Dann kann man den Rest in individuelle DOIFs packen.

[pc1246]

Wenn Fernseher an abhängig von brightness (Hellikeitssensor), azimuth (Sonnenwinkel, Twilight oder Astro), elevation (Sonnenhöhe, Twilight oder Astro) fährt an einem Fenster das Rollo auf definierte Position. Wenn Fernseher aus greifen wieder die Standardeinstellungen.

Ich denke ich werde an dem Fenster erst einmal die Lüftenfunktion "missbrauchen".

Gruss
  Enno

Hallo Enno
Das Problem wird sein, dass Du das Rollo runter haben moechtest und nicht hoch. Und Lueften geht davon aus, dass es hoch soll!
Aber einen Workaround wirst du finden, oder Du laesst es erstma so wie es ist! (Workaround koennte sein: ASC off und fahren auf Position, wenn Fernseher an)
Gruss Christoph

[hexenmeister]

Für solche komplexen benutzerspezifische Szenarien sollte man, mMn, eine Möglichkeit schaffen, die gezielt bestimmte Aktionen triggern kann. Man kann im Modul sonst nicht alles vorsehen.
Ich stelle mir so etwas vor wie ein paar attribute für device/reading paar (analog zu brightness, temperature etc)
Wenn diese reading dann aktualisiert wird und drin eine Aktion steht (ggf. parametrisiert), dann soll diese ausgeführt werden.

attr ASC cmdTriggerDevice ascTrigger
attr ASC cmdTriggerReading cmd

Befehle z. B.
'setposition 100'
'trigger comfortOpen'
'trigger NightClose'
'trigger Shading'
etc.

Oder gar
'setposition {myCalculation()}'

So als Idee...

[Sascha_F]

Hallo Sascha,

Das was Du beschrieben hast ist bereits möglich. Du kannst pro Rolladen bestimmen ob er bei Civil oder REAL fahren soll. Und das auch noch getrennt für Morgens und Abends. Attribut ASC_AutoAstroModeMorning und ASC_AutoAstroModeEvening.

Zum Thema Comfort Attribut. Hier bin ich mir noch nicht ganz schlüssig wie ich das weiter verwende. Ich hatte es mal so übernommen ohne zu verstehen für was das genau war. Aktuell ist es so verarbeitet das es lediglich bei Rollläden mit threestate Sensoren Verwendung findet in dem beim open Event der Rolladen auf den Wert von ASC_Pos_after_ComfortOpen gefahren wird. Hier dachte ich an eine Position fast offen. So um Abends mal die Spinne rauswerfen zu können oder kurz das Kissen auf zu schütteln.


Grüße

Hi Leon,

das stimmt --> aktuell fährt bei mir alles mit CIVIL (CIVIL aktuell so 17:10 h, REAL aktuell so 16:30 h) --> mit dem Timeshift meinte ich, dass ich z.B. mit CIVIL ein Timeshift -25 Minuten oder mit REAL ein Timeshift + 15 Minuten einrichten kann, sodass die Rollläden so gegen 16:45 h runterfahren.

Ich bin ein Fan von Ventilate und Comfort, da ich ausschließlich threestate im Einsatz habe (und das Modul damit vollständig mein DOIF ersetzt). Bei Ventilate fahre ich die Rollläden so weit hoch, dass die "Lüftungsschlitze" offen sind und bei Comfort öffne ich auch ca. 80 %, um noch mal auf die Terrasse / den Balkon gehen zu können --> oder in der Küche die Fenster, wenn's beim Kochen mal ungewollte Situationen gab :-D

Ich wäre für: bei threestate so belassen, wie es ist, bei twostate entweder immer nur Ventilate (oder Comfort) - oder noch ein Attribut am Device, welches bei twostate die Auswahl <Ventilate/Comfort> bietet. Wobei letzteres eigentlich unnötig ist, denke ich. Wenn ich einen twostate habe, muss ich halt wissen, welches Attribut ich pflegen muss. Noch mal drüber nachgedacht: Beim Einsatz von twostate möchten die User bestimmt auch an unterschiedlichen Devices Ventilate oder Comfort nutzen. Von daher ggf. doch ein weiteres Attribut.

Vielleicht können die twostate-User ja mal kurz mitteilen, welche Funktion sie eher benutzen wollen (ventilate oder comfort).

Grundsätzlich haben wir durch ASC ja schon echt viele Attribute in den Devices --> aber ganz ehrlich: Tut mir nicht weh - wenn alles konfiguriert ist, könnten da auch 500 Attribute am Device sein und es würd mich nicht stören. Danach gucke ich vermutlich eh nie wieder ins Device (außer bei Fehlern o.ä.).

Viele Grüße
Sascha

[Beta-User]

Möglichst nicht noch ein Attribut. Lieber die Auswahl ermöglichen "twostate:<Variante>
Kann bzw. will damit aber kein Votum für oder gegen das feature abgeben...

[CoolTux]

Hi Leon,

das stimmt --> aktuell fährt bei mir alles mit CIVIL (CIVIL aktuell so 17:10 h, REAL aktuell so 16:30 h) --> mit dem Timeshift meinte ich, dass ich z.B. mit CIVIL ein Timeshift -25 Minuten oder mit REAL ein Timeshift + 15 Minuten einrichten kann, sodass die Rollläden so gegen 16:45 h runterfahren.

Ich bin ein Fan von Ventilate und Comfort, da ich ausschließlich threestate im Einsatz habe (und das Modul damit vollständig mein DOIF ersetzt). Bei Ventilate fahre ich die Rollläden so weit hoch, dass die "Lüftungsschlitze" offen sind und bei Comfort öffne ich auch ca. 80 %, um noch mal auf die Terrasse / den Balkon gehen zu können --> oder in der Küche die Fenster, wenn's beim Kochen mal ungewollte Situationen gab :-D

Ich wäre für: bei threestate so belassen, wie es ist, bei twostate entweder immer nur Ventilate (oder Comfort) - oder noch ein Attribut am Device, welches bei twostate die Auswahl <Ventilate/Comfort> bietet. Wobei letzteres eigentlich unnötig ist, denke ich. Wenn ich einen twostate habe, muss ich halt wissen, welches Attribut ich pflegen muss. Noch mal drüber nachgedacht: Beim Einsatz von twostate möchten die User bestimmt auch an unterschiedlichen Devices Ventilate oder Comfort nutzen. Von daher ggf. doch ein weiteres Attribut.

Vielleicht können die twostate-User ja mal kurz mitteilen, welche Funktion sie eher benutzen wollen (ventilate oder comfort).

Grundsätzlich haben wir durch ASC ja schon echt viele Attribute in den Devices --> aber ganz ehrlich: Tut mir nicht weh - wenn alles konfiguriert ist, könnten da auch 500 Attribute am Device sein und es würd mich nicht stören. Danach gucke ich vermutlich eh nie wieder ins Device (außer bei Fehlern o.ä.).

Viele Grüße
Sascha

Hallo Sascha,

Schau Dir mal die Möglichkeiten von Horizon und den dafür gedachten Attribut ASC_autoAstroModeMorningHorizon -9 bis + 9 an.
Da kannst Du dann auch Zeiten zwischen CIVIL und REAL fahren. Mache ich auch so. Eventuell ist es ja schon das was Du möchtest.