Betatester für neues Modul AutoShuttersControl gesucht!

[Prof. Dr. Peter Henning]

Was speziell ist, hängt individuell an der Installation;  jemand, der in USA, Frankreich, Polen oder Indien seine Devices benennt, findet evtl. "Roll.*" sehr speziell

Warum nicht allen Rollläden, die gesteuert werden sollen, ein globales Attribut geben ? So habe ich das im Alarm-Modul ebenso wie bei Babble gelöst.

LG

pah

[Beta-User]

Thx, meine Jalousien sind jetzt auch da, wenn auch wieder mit den "falschen" defaults !

Hatte dann auch gestern noch an der Automatik "CIVIL" eingestellt (so war das bei meiner bisherigen Steuerung auch, allerdings mit anderen Zeitgrenzen).

Rechte am Modul stehen seit eben auf 644 (wie bei allen anderen Modulen; das scheint auch zu reichen, jedenfalls ist das Device auch nach einem Neustart da ).

Mit den Roommates und ihrer Steuerung muß ich mich erst noch etwas beschäftigen, wie gesagt, das war bisher nicht da, da müssen jetzt (ausnahmsweise) dummy-Devices herhalten, und die wollen ja auch ihren Status ändern .

Kann man eigentlich mehrere Roommates pro Raum definieren bzw. hätte das Auswirkungen?

Was die RG angeht: Gemach, gemach... Mach' ich notfalls schon selbst . Ziel sollte sein, damit die Geräte direkt bedienen und ggf. die hin und wieder veränderlichen Attribute und  Zeiten einstellen zu können. War nur die Frage, ob jemand da schon was hat. V.a. das mit den Zeiten wäre interessant, aber da gibt es auch Beispiele im Wiki und ggf. im "Urvater-Thread" von HugoMcKinnley. Muss mal suchen.

Aber keine Hektik, das ist eine Riesen-Sache und muß nicht in einer Woche stehen .

Warum nicht allen Rollläden, die gesteuert werden sollen, ein globales Attribut geben ?

Kann ich nicht beurteilen, aber an Attributen an den Rolläden mangel es nicht; das Array mit den Devicen steht ja auch im zentralen Gerät. Aber eine Möglichkeit, Rolladen-Devices einzeln dazu- bzw. herauszunehmen wäre m.E. nicht schlecht.
Nach meinem (subjektiven) Eindruck wird mit der "auto"-Angabe gleich beim "define" zu viel auf einmal verursacht. Das wird bei vielen Einsteigern ein Gefühl der Überforderung geben. Aber wie gesagt: Just my2ct.
Vielleicht komme ich dazu, mir den Code mal anzusehen, dann gibt es ggf. einen Vorschlag für "set ... addDevices" usw.. Die Routinen im Hintergrund scheinen ja vorhanden zu sein.

Gruß, Beta-User

[CoolTux]

Guten Morgen

Thx, meine Jalousien sind jetzt auch da, wenn auch wieder mit den "falschen" defaults !

Kannst Du mir das mit den "falschen" defaults versuchen Näher zu bringen? Sind sie für Dich falsch und ist der ganze default Unsinn? Meinst Du die Attribute für up und down fahrten? Also 0 und 100?
Darüber können wir gerne reden. Was denkst Du/Ihr welche Werte eher vertreten sind in der Anzahl. Hoch 0 und runter 100 oder umgekehrt. Wir können das gerne an passen.

Kann man eigentlich mehrere Roommates pro Raum definieren bzw. hätte das Auswirkungen?

Aktuell noch nicht, wird aber kommen, war in der Planung einer der Voraussetzungen für mich, da ich 2 Kinder im selben Raum habe und natürlich das Schlafzimmer auch von 2 benutzt wird.

Nach meinem (subjektiven) Eindruck wird mit der "auto"-Angabe gleich beim "define" zu viel auf einmal verursacht. Das wird bei vielen Einsteigern ein Gefühl der Überforderung geben. Aber wie gesagt: Just my2ct.

Oft sind es genau diese Just my2ct.welche gute Ideen ein bringen.
Kannst Du mir dieses "gefühlte zu viel" etwas genauer erklären? Zu viel zum einstellen?

Warum nicht allen Rollläden, die gesteuert werden sollen, ein globales Attribut geben ? So habe ich das im Alarm-Modul ebenso wie bei Babble gelöst.

LG

pah

Ich fand die Idee gut, für genau 20 Sekunden. Bis ich kurz nachgedacht habe und der Meinung war/bin das es egal ist ob ich ein globales Attribut an alle Rolläden verteile oder alle Rolläden zur Not in meiner define mit angebe. Der Aufwand wird wohl identisch sein. Was denkt Ihr?

[DS_Starter]

Bis ich kurz nachgedacht habe und der Meinung war/bin das es egal ist ob ich ein globales Attribut an alle Rolläden verteile oder alle Rolläden zur Not in meiner define mit angebe. Der Aufwand wird wohl identisch sein. Was denkt Ihr?

Die Attribut-Lösung halte ich für besser. Weniger wegen des Aufwands, sondern wegen der Flexibilität.
Idee - hat man ein Attribut (ich habe bei mir sogar ein Reading "Rollo_Automatic" verwendet), kann man es z.B. durch programmtechnische Maßnahmen "von außen", z.B. durch Schalter mit notifies oder MyUtils-Routinen usw. in den Automatic/Manuell-Mode schalten. Ich mache das z.B. mit einem Command-Icon in der Readingsgroup für die Rollos.

LG
Heiko

[CoolTux]

Die Attribut-Lösung halte ich für besser. Weniger wegen des Aufwands, sondern wegen der Flexibilität.
Idee - hat man ein Attribut (ich habe bei mir sogar ein Reading "Rollo_Automatic" verwendet), kann man es z.B. durch programmtechnische Maßnahmen "von außen", z.B. durch Schalter mit notifies oder MyUtils-Routinen usw. in den Automatic/Manuell-Mode schalten. Ich mache das z.B. mit einem Command-Icon in der Readingsgroup für die Rollos.

LG
Heiko

Bitte nicht vergessen, es geht hier in erster Linie um das finden aller relevanten Rolladen Devices beim define einer Modulinstanz.


ansonsten!
Mann sollte also mal drüber nachdenken ob man

Desweiteren Beachtung der Attribute AutoShuttersControl_Mode_Down und AutoShuttersControl_Mode_Up

nicht lieber als Reading pro Rollo macht? Das Reading müsste aber wenn dann im Modul Device stehen, für Jedes einzelne Rollo. Ich will nicht mehr wie nötig in fremde Devices schreiben.
Idee finde ich erstmal nicht verkehrt.

[DS_Starter]

Bitte nicht vergessen, es geht hier in erster Linie um das finden aller relevanten Rolladen Devices beim define einer Modulinstanz.

Achso.... wenn es darum geht schlage ich im auto-define die Verwendung von devspec mit einem Filter auf den TYPE bzw. bei HM auf den Subtype vor. So mache ich es bei mir (habe allerdings nur HM) und dadurch ist automatisch jedes neu definierte Device mit den Filterkriterien mit in der Steuerung, es sei denn man schaltet es in den manuellen mode wie vorhin geschrieben.

Lg
Heiko

[CoolTux]

Achso.... wenn es darum geht schlage ich im auto-define die Verwendung von devspec mit einem Filter auf den TYPE bzw. bei HM auf den Subtype vor. So mache ich es bei mir (habe allerdings nur HM) und dadurch ist automatisch jedes neu definierte Device mit den Filterkriterien mit in der Steuerung, es sei denn man schaltet es in den manuellen mode wie vorhin geschrieben.

Lg
Heiko

Siehe dazu.

Das ist mir viel zu speziell. Meine Rollo Devices haben zum Beispiel keines Deiner Filter (weder Type noch Subtype). Vielleicht hat auch einer nur Dummys und steuert damit GPIOs an. Jalou baue ich gerne noch ein.
Man sieht ja in den Readings wunderbar welche Devices erwischt wurden. Sollten noch Feinheiten nötig sein so kann man das später ohne Probleme noch machen.

Es gibt eine interne ARRAY List aller Rollos. Wir haben versucht weitestgehend flexibel zu entwickeln.

[FunkOdyssey]

Ich hoffe, dass ich das hier alles richtig verstanden habe.
Es geht einmal um die individuelle Konfiguration der Jalousien in deren Attributen.
Und weiterhin um das Finden der Jalousien in FHEM, oder?

Kann man dann nicht per devspec einfach nach den Jalousien suchen?
Also sobald ein Attribut namens AutoShuttersControl.* gesetzt ist, dann ist es ein zu steuerndes Device?

[Beta-User]

Kannst Du mir das mit den "falschen" defaults versuchen Näher zu bringen?

Es dürfte auch mit den Vorgaben, die das Modul derzeit macht funktionieren, allerdings eben "levelInverse", also morgens gingen die Rolläden zu, abends auf .
Wie bereits geschrieben, kann man das wie folgt drehen:

Code Auswählen Erweitern


attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Closed_Pos 0
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Open_Pos 100Dasselbe gilt für die Shading-Position usw.. Ob insgesamt ein Drehen der defaults die Lösung ist? Ich fände es nach wie vor besser, wenn man die Presets vorab auswählen könnte, dann muß man nicht nacharbeiten.

Ergänzend eine Frage. Wenn ihr (für was auch immer) mal wissen wollt, ob eine aktuelle Position z.B. offener oder geschlossener ist als ein neues "Soll": Woher weiß das die Steuerung? (Früher gab es zu diesem Zweck (vermutlich) das Attribut LevelInverse.)

Aktuell noch nicht, wird aber kommen, war in der Planung einer der Voraussetzungen für mich, da ich 2 Kinder im selben Raum habe und natürlich das Schlafzimmer auch von 2 benutzt wird.

Kein Ding, dann gibt es eben (ggf. übergangsweise) eine structrure.

Kannst Du mir dieses "gefühlte zu viel" etwas genauer erklären? Zu viel zum einstellen?

Also mal "Otto Normaluser" als gedanklicher Ausgangspunkt. Der versucht erfahrungsgemäß, es sich erst mal einfach zu machen. "auto" klingt so, als wäre damit die meiste Arbeit schnell zu erledigen.
Gedacht, getan. Dann muß ich in meiner Installation "ganz schnell" >10 Rolläden konfigurieren, dabei eine ganze Anzahl von Parametern richtig setzen (mind. 6 pro Rolladen, oder?) und diverse Abhängigkeiten beachten, deren Auswirkungen ich noch nicht kenne.
Klar, man kann das umgehen, indem man das define nach und nach erweitert, aber die Vermutung liegt nahe, dass das in der Regel eben nicht so gemacht werden wird.

Bitte nicht vergessen, es geht hier in erster Linie um das finden aller relevanten Rolladen Devices beim define einer Modulinstanz.

Genau diesen Ansatz würde ich aus diesem Grund auch (nochmal) in Frage stellen: Wieso muß das über das "define" laufen?

Stelle daher nochmal folgenden Ablauf aus Usersicht zur Diskussion:
1. Zunächst definiert man das Steuerungsdevice _ohne_ irgendwelche Rolläden zu benennen, die gesteuert werden sollen:

Code Auswählen Erweitern

define Rolladensteuerung AutoShuttersControl

2. Dann stellt man defaults für diverse Dinge ein, sofern gewünscht.
3. Dann erweitert "Normaluser" die Steuerung, indem er einzelne oder mehrere Rolladendevices mit sowas in der Art hier

Code Auswählen Erweitern

set <AutoShutterControl> addShutter <Shuttername> [<Fensterkontakt>] [<ClosedPosition:0,100>] hinzufügt. Dann kann das Modul gleich sinnvolle Presets für die diversen Positionen ableiten und kennt auch die logische Fahrtrichtung.
Der User kann Raum für Raum vorgehen und sich erst mal mit einem oder zwei Rolläden einarbeiten, ohne erst durch "auto" in die falsche Richtung geschickt worden zu sein...

(4. Nach updates wäre ggf. zu prüfen, ob alle Devices auch alle Attribute haben => "set ... updateCheck")
(5. Die umgekehrte Richtung für Devices, die - aus welchen Gründen auch immer - nicht mehr gesteuert werden sollen würde dann auch benötigt. Anektdote dazu: Mein versehentlich noch vorhandener Rolladendummy war im Array gespeichert; ob er durch einen simplen Neustart wieder verschwunden wäre: keine Ahnung).

Man sollte also mal drüber nachdenken ob man [...] Beachtung der Attribute AutoShuttersControl_Mode_Down und AutoShuttersControl_Mode_Up nicht lieber als Reading pro Rollo macht

Fände ich eigentlich auch - jedenfalls auf den ersten Blick - ganz gut; allerdings sind die Rolladendevices jetzt schon unübersichtlich.

Achso.... wenn es darum geht schlage ich im auto-define die Verwendung von devspec mit einem Filter auf den TYPE bzw. bei HM auf den Subtype vor. So mache ich es bei mir (habe allerdings nur HM) und dadurch ist automatisch jedes neu definierte Device mit den Filterkriterien mit in der Steuerung, es sei denn man schaltet es in den manuellen mode wie vorhin geschrieben.

So dachte ich auch erst, aber ich habe wie gesagt auch meine Leinwand an so einem Aktor. Den jedes Mal wieder rauszuwerfen, wenn FHEM gestartet wird, ist mühsam. Das einmalig zu machen, nachdem man mit "addDevice" die Devspec verwendet hat, ist dagegen easy...

Und wie gesagt: Nur mein Eindruck...

EIDT: Formatierung.

[CoolTux]

Ich war schon dran mit Subtype und Type zu arbeiten bis Du das mit dem Leinwandmotor geschrieben hast. Ist also wieder ein Argument dagegen.

Deine Argumente bezüglich über Set den Rolladen hinzu zu fügen und dann auch die Vorgaben für Attribute im Modul Device zu machen sind einleuchtend und gut. ABER! Es ist ein großer Aufwand für den Entwickler.
Was ich aber gut finde und womit ich leben könnte ist, ein globales Attribut AutoShuttersControl mit Wert 1 welcher nach dem anlegen des Moduldevices und vor dem set autoScanShutters an alle Rolläden eingestellt werden muss.
Was sagt Ihr dazu?

Dennoch wird es für den User Pflicht sein jeden Rolladen noch mal an zu fassen um die für ihn passenden Attribute mit korrekten Werten zu setzen. Das kann man ja in einem Reading im Moduldevice noch mal explizit mit geben und auch vom User bestätigen lassen, sonst läuft gar nichts.


Von einem Smart Home Kollegen habe ich auch geade eine super tolle Logikidee bekommen

Self Defence, wenn beim Verlassen des letzten Bewohners noch ein Fenster gekippt ist, wird der Rolladen an diesem Fenster automatisch geschlossen.

Ich finde das ist eine super tolle Idee.

[Beta-User]

ABER! Es ist ein großer Aufwand für den Entwickler.

Vielleicht komme ich dazu, mir den Code mal anzusehen, dann gibt es ggf. einen Vorschlag für "set ... addDevices" usw.. Die Routinen im Hintergrund scheinen ja vorhanden zu sein.

Auch wenn meine Perl-Kenntnisse nicht besonders sind: Du mußt ggf. nicht alles alleine machen; Und: es gibt sicher noch andere, die sich gerne einbringen, die das besser können als ich. In dem Zusammenhang finde ich es nur wichtig, dass man sich über das Ziel einig ist und jetzt nichts baut, was den Umbau noch komlexer macht...

Was ich aber gut finde und womit ich leben könnte ist, ein globales Attribut AutoShuttersControl mit Wert 1 welcher nach dem anlegen des Moduldevices und vor dem set autoScanShutters an alle Rolläden eingestellt werden muss.
Was sagt Ihr dazu?

Wäre auch eine Lösung für das Problem. Wie wäre es mit Werten 0,1,2? Dann könnte man über die weitere Unterscheidung 1-2 gleich die Defaults definieren, also (1 => pct 100=closed), (2 => pct 0=closed) und könnte das nachfolgend im Bedarfsfall auch verwenden, um die richtige Vergleichsrichtung zu haben (siehe mein letzter Post).

Ergo meine 2ct: sehr guter Kompromiss!

[Wunschmodus ein]Super wäre eine Art Assistent/Dialogbox, in dem man gleich alle passenden Optionen pro Device durchgehen könnte....
[Wunschmodus aus]

Von einem Smart Home Kollegen habe ich auch geade eine super tolle Logikidee bekommen

Finde ich als Option nicht schlecht, einzustellen im Zentalen Device.

[CoolTux]

Auch wenn meine Perl-Kenntnisse nicht besonders sind: Du mußt ggf. nicht alles alleine machen; Und: es gibt sicher noch andere, die sich gerne einbringen, die das besser können als ich. In dem Zusammenhang finde ich es nur wichtig, dass man sich über das Ziel einig ist und jetzt nichts baut, was den Umbau noch komlexer macht...Wäre auch eine Lösung für das Problem. Wie wäre es mit Werten 0,1,2? Dann könnte man über die weitere Unterscheidung 1-2 gleich die Defaults definieren, also (1 => pct 100=closed), (2 => pct 0=closed) und könnte das nachfolgend im Bedarfsfall auch verwenden, um die richtige Vergleichsrichtung zu haben (siehe mein letzter Post).

Ergo meine 2ct: sehr guter Kompromiss!

[Wunschmodus ein]Super wäre eine Art Assistent/Dialogbox, in dem man gleich alle passenden Optionen pro Device durchgehen könnte....
[Wunschmodus aus]Finde ich als Option nicht schlecht, einzustellen im Zentalen Device.

Das mit dem Attribut default Values auf Basis des erkannten Rolladen verteilen ist leider nicht ganz so trivial wenn man nicht doppelt programmieren will. habe da aber eine kleine Idee die ich später mal verfolgen werde.
Die Tage werde ich erstmal die Logik beim anlegen ändern.

[Beta-User]

Eventuell könnte es helfen, hinten in die Zuweisung ein Array zu schreiben, damit wären zwei oder mehr Werte möglich und man müßte nur den Index zutreffend auswählen.
Aber soooo dramatisch wichtig ist es nicht (mehr) die Änderung weg von den defaults durchzuführen, wenn man die Rolläden nacheinander per Attribut dazunehmen kann... Der Punkt ist m.E. ungleich wichtiger.

Danke!

[CoolTux]

Eventuell könnte es helfen, hinten in die Zuweisung ein Array zu schreiben, damit wären zwei oder mehr Werte möglich und man müßte nur den Index zutreffend auswählen.
Aber soooo dramatisch wichtig ist es nicht (mehr) die Änderung weg von den defaults durchzuführen, wenn man die Rolläden nacheinander per Attribut dazunehmen kann... Der Punkt ist m.E. ungleich wichtiger.

Danke!

Manchmal fehlen einfach nur Ideen. Danke. Das schaue ich mir genauer an.


Ich habe soeben den Umbau abschließen können, hat etwas gedauert. Aber nun wird nach dem define der state entsprechend gesetzt mit dem Hinweis ein set Befehl auszuführen nachdem in allen Rolläden das Attribut AutoShuttersControl auf 1 gesetzt wurde.
Das mit 2 machen wir dann später.



Grüße

[Prof. Dr. Peter Henning]

Lustig wäre aus meiner Sicht ein Modell für das Mapping auf den tatsächlichen Stand des Rollladen. Auf welchen (fiktiven) Prozentwert muss man den Rollladenaktor stellen, um den Rollladen tatsächlich auf 50% zu bekommen ? Ich habe ein solches Modell für meine motorisierte TV-Wandhalterung geschrieben - ist auf +/- 3% genau im Bereich zwischen 0° und 90°.

Außerdem hier noch eine Idee:

Rollladen ist oben, aber Haus ist im Zustand gesichert. Bewegungsmelder registriert Bewegung vor dem Rollladen => Rollladen wird 10% herunter gefahren. Wenn danach für 10 Minuten keine Bewegung mehr, wird der Rollladen wieder hoch gefahren. Wenn die Bewegung nicht aufhört, wird der Rollladen ganz herunter gefahren und eine Warnungsmeldung abgesetzt. Ich bin gerade dabei, solche Bedingungen in das Alarm-Modul einzubauen - es ist sinnvoller, diese Alarmfunktionalität nicht auch noch in das Rollladenmodul einzubauen. Nützlich wäre aber eine Funktion, die einen Rollladenfür eine definierte Zeit um ein Stück weiter herunter fährt.

LG

pah