Rollladensteuerung: Alternativen zu DOIF

[Beta-User]

OK, und das ganze gibt's dann in der Fülle für jedes Rollo?!?

Auch wenn betateilchen der Ansicht ist, userReadings wären nicht das gelbe vom Ei: Ich würde zum einen versuchen, die zu einem Rollo gehörenden Eigenschaften auch dort abzuspeichern, das, was Du mit Dummies machst, müßte dabei eigentlich auch direkt gehen (?).
Beispielcode (untested) sollte so etwa gehen:

Code Auswählen Erweitern


attr Rollo_Dummy_1 setReading_Werktags_hoch_Zeit setList state:05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:35,06:40,06:45,06:50,06:55,07:00,07:05,07:10,07:15,07:20,07:25,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45

Die Auswertung (DOIF) wäre dann ähnlich wie bisher, aber es muß halt dann halt das jeweilige Reading abgefragt werden, aber ich habe bereits notify's, die mit sowas gut umgehen können, ist eher kein Problem.

Was den eigentlichen Code angeht, tendiere ich mittlerweile dazu, ein (einziges!) notify auf Änderungen der Readings (für alle! Rolläden und ggf. Tür- und Fenstersensoren) zu setzen und dann nur zu prüfen, ob deswegen eine oder mehrere Aktionen unmittelbar erfolgen sollten und/oder wann der nächste (und nur der nächste) Ausführungszeitpunkt für ein at sein muß (nächstgeplante Aktion(en)). Dieses at triggert dann nur das notify.

Dieses notify muß dann "nur" alle Rolläden komplett durchgehen, anstehende Aktionen ausführen und seinen eigenen nächsten Ausführungszeitpunkt festlegen. Sinnvollerweise eine myUtils-Funktion...

Ich sollte dann wohl perl lernen .

Gruß, Beta-User

[lenoxef]

Ich hätte auch gern für jedes Rollo nur einen Dummy, das habe ich aber leider nicht hin bekommen. Vieleicht kann ja jemand mal versuchen meinen Code umzustellen. Mir würde es sicherlich schon reichen, zwei drei Dummys zu einem zusammenzuführen, den Rest sollte ich allein hinbekommen. Ich habe es schon mal mit userReadings versucht, allerdings vergeblich.

[Joker]

Also meine Rolladensteuerung setzt vor allem auf perl-Code, notifys und dummies.
Per notify werden bestimmte Ereignisse mitgeteilt (Helligkeitsschwelle erreicht, Fenster geöffnet/geschlossen etc).
Die notifys springen alle perl-Funktionen in einer separaten myUtils Datei an (ich mag perl-Code direkt am notify nicht, außer eben einen Funktionsaufruf).
Der Perl-Code realisiert die gesamte Logik. Damit habe ich umgesetzt:

- Automatisches Herunter- und Hochfahren der Rollos abhängig vom Sonnenstand
- Öffnen des Rollos bis Schlitz-Stellung, wenn das zugehörige Fenster bei geschlossenem Rollo gekippt wird, komplette Öffnung des Rollos wenn des Fenster geöffnet wird (Lüften)
- Wenn ein Fenster geschlossen wird, fahren des Rollos zurück in die beabsichtigte Position, falls notwendig
- Deaktivierung der Rollo-Automatik für Rollos an Türen, wenn die Tür geöffnet ist (Aussperrschutz)
- Kindersicherung für Rollotaster (diese sind dann ohne Funktion: manuell aktivierbar, oder automatisch z.B. wenn eine Tür geöffnet ist)

[Beta-User]

Ich hätte auch gern für jedes Rollo nur einen Dummy,

Wieso überhaupt einen Dummy neben dem eigentlichen Gerät?

Jedenfalls ich werde nicht versuchen, ein DOIF zu reparieren, das übersteigt meinen Horizont .

Ich habe es schon mal mit userReadings versucht, allerdings vergeblich.

Was war genau das Problem? Das Setzen oder die Auswertung (letzteres sollte mit z.B. "[Rollo_Dummy_1:Werktags_hoch_Zeit]" doch zu lösen sein)?

@TE: Wir sind hier ziemlich off-Topic, oder?

Gruß, Beta-User

[Beta-User]

Also meine Rolladensteuerung setzt vor allem auf perl-Code, notifys und dummies.

Kann man Deine Lösung irgendwo nachlesen?
Das klingt sehr nach einer erstrebenswerten Lösung!

Gruß, Beta-User

[lenoxef]

Was war genau das Problem? Das Setzen oder die Auswertung (letzteres sollte mit z.B. "[Rollo_Dummy_1:Werktags_hoch_Zeit]" doch zu lösen sein)?

ich denke mein Problem ist viel trivialer. Wie bekomme ich das Reading "Werktags_hoch_Zeit" zum "Rollo_Dummy_1"?

[Beta-User]

ich denke mein Problem ist viel trivialer. Wie bekomme ich das Reading "Werktags_hoch_Zeit" zum "Rollo_Dummy_1"?

OK, nach Bemühen der commandref glaube ich, den falschen Begriff gewählt zu haben .
Es geht schlicht darum, dem device weitere readings zu verpassen.

Da ich sowas bei MySensors schon gemacht habe, glaubte ich, das wären userreadings gewesen. Es sollte aber tatsächlich kein Problem sein, weitere readings manuell zu mappen. Der Befehl dabei war

Code Auswählen Erweitern

attr MYSENSOR_99 mapReading_ir_send3 3 ir_send
Das sollte ohne weiteres auch auf andere devices und Typen übertragbar sein, die 3 ist dabei eine MySensors-interne Nummer zur Identifizierung eines bestimmten Sensorwerts (kann also für unsere Zwecke hier vermutlich willkürlich gewählt werden).

Ergo:

Code Auswählen Erweitern

attr Rollo_Dummy_1 mapReading_Werktags_hoch_Zeit 10 Werktags_hoch_Zeit
sollte eigentlich ein entsprechendes Reading anlegen, dem man dann wie unten die setlist verpassen kann...

Kann leider grade nicht selbst testen.

Für dummy gibt es dann noch "readingList".

[Joker]

Kann man Deine Lösung irgendwo nachlesen?
Das klingt sehr nach einer erstrebenswerten Lösung!

Gruß, Beta-User

Aktuell nicht, aber ich kann die Tage mal versuchen das zusammenzuschreiben. Der Kern befindet sich ja prinzipiell in einer Datei.

[Cluni]

Aktuell nicht, aber ich kann die Tage mal versuchen das zusammenzuschreiben. Der Kern befindet sich ja prinzipiell in einer Datei.

Das wäre klasse!

Ich hatte mir auch schon den einen oder anderen Gedanken gemacht, aber ich bin noch nicht ganz bei der Umsetzung.

Erstmal verpasse ich meinen Aktoren ein paar User-Attribute:

Code Auswählen Erweitern

attr Rol.* userattr Auto_Modus:bei_Abwesenheit,immer Auto_hoch:aus,Zeit,Astro Auto_runter:aus,Zeit,Astro Auto_offen_Pos:Auf,Luft Auto_Himmelsrichtung Auto_Abschattung:ja,nein,verspaetet Auto_Zeit_hoch_frueh Auto_Zeit_hoch_spaet Auto_Zeit_hoch_WE_Urlaub Auto_Zeit_runter_frueh Auto_Zeit_runter_spaet

und belege diese dann fürs erste mit ein paar Default-Parametern:

Code Auswählen Erweitern

attr Rol.* Auto_Modus immer
attr Rol.* Auto_hoch aus
attr Rol.* Auto_runter aus
attr Rol.* Auto_offen_Pos Luft
attr Rol.* Auto_Himmelsrichtung 178
attr Rol.* Auto_Abschattung nein
attr Rol.* Auto_Zeit_hoch_frueh 07:30:00
attr Rol.* Auto_Zeit_hoch_spaet 09:00:00 
attr Rol.* Auto_Zeit_hoch_WE_Urlaub 09:30:00
attr Rol.* Auto_Zeit_runter_frueh 16:30:00
attr Rol.* Auto_Zeit_runter_spaet 21:30:00


Dann hatte ich vor mir einige Routinen in der 99_myUtils.pm abzulegen. Eine Funktion soll bei einer Schalt-Aktion des jeweiligen Aktors angestoßen werden. Dort wird dann abhängig von der an dem Tag gültigen Sonnenauf- und -untergangszeit plus der jeweils gesetzten User-Attribute (Auto_Zeit_hoch_frueh Auto_Zeit_hoch_spaet Auto_Zeit_hoch_WE_Urlaub Auto_Zeit_runter_frueh Auto_Zeit_runter_spaet) für den frühesten/spätesten Schalttermin und Berücksichtigung, ob z.B. die Automatik überhaupt eingeschaltet ist, die nächste automatische Schalt-Aktion berechnet. Damit und mit den Parametern für die gewünschte Position wird dann ein at für die nächste Schaltaktion erzeugt. Bei dieser Schalt-Aktion wird das at dann wieder gelöscht und für die nächste Aktion neu berechnet und angelegt. Den dann aktuell berechneten Schaltzeitpunkt und ggf. Position möchte ich in ein bzw. mehreren User-Readings ablegen. Diese sollen aber nur der Übersicht dienen und werden (erstmal) nicht für weitere Aktionen herangezogen.

Die Sache mit dem Sonnenstand und der Abschattung wollte ich davon getrennt erledigen. Dazu würde ich eine Funktion bei Bedarf über ein Notify aufrufen, die den Aktor dann sofort schaltet.

Aber ich über deinen Code würde ich mich sehr freuen. Bin ja noch Anfänger und kann bestimmt noch was lernen!

Gruß, Bernd

[Thorsten Pferdekaemper]

ich denke mein Problem ist viel trivialer. Wie bekomme ich das Reading "Werktags_hoch_Zeit" zum "Rollo_Dummy_1"?

Code Auswählen Erweitern


setreading Rollo_Dummy_1 Werktags_hoch_Zeit 08:15

Meinst Du das?
Gruß,
   Thorsten

[Beta-User]

So, nach einigen Experimenten die vergangenen Tage nachfolgend mal einen Zwischenstand zu einer Lösung auf Basis von notify, perl und userattr, allerdings erst mal ohne Zeitsteuerung und mit nur einer Lüftungsposition (ist für meine Zwecke ausreichend).

Vorab als Hinweis: Ich mußte erst mal rausfinden, wie man manche Dinge mit perl löst, in userattr. abspeichert und sich Zwischenergebnisse und Fehlermeldungen ausgeben läßt . Das ist also WIP, eine Art privater Machbarkeitsstudie, aber (noch) keine Lösung mit Funktionsgarantie .

Ergebnis:
- 2 generalisierte notify, die Reagieren, wenn entweder irgendeine (Außen-) Tür oder ein Fenster geöffnet oder geschlossen wird oder ein beliebiger Rolladen ein stop "meldet" (könnte man evtl. mit etwas perl auch kombinieren)
- eine perl-Funktion in myUtils, die durch diese notifies aufgerufen wird und den entsprechenden Rolladen dann ggf. auf eine andere Position stellt (Lüften, Lüften beenden). Dabei ist es für meine Zwecke ausreichend, eine Lüftungsposition zu definieren (keine 2).
- eine perl-Hilfs-Funktion in myUtils, die mir die entsprechenden userattr erst mal die die jeweils zusammengehörenden Geräte schreibt, also eine Art "peering" macht .

notify für Fensterkontakte:

Code Auswählen Erweitern

defmod n_Rolladen_Window notify .*(closed|open)..to.VCCU. { winOpenShutterTester(AttrVal($NAME,'ShutterAssociated','none'), "Window") }
attr n_Rolladen_Window group Türen und Fenster
attr n_Rolladen_Window icon fts_shutter_automatic


notify für Rolladenstop:

Code Auswählen Erweitern

defmod n_Rolladen_Stop notify .*:motor:.stop.* { winOpenShutterTester($NAME, "Rollo")}
attr n_Rolladen_Stop group Türen und Fenster
attr n_Rolladen_Stop icon fts_shutter_automatic


Die Haupt perl-Funktion in myUtils:

Code Auswählen Erweitern

sub winOpenShutterTester($$) {
    #Als Parameter muss der device-Name übergeben werden
    my ($dev, $event) = @_;
 
    #Erst mal prüfen, ob das übergebene device überhaupt existiert
    if ($defs{$dev}) {
 
        #Als erstes brauchen wir die Info, welcher Rolladen bzw. welcher Fenster- bzw. Türkontakt
        #betroffen sind
        #Also erst mal so tun, als wäre es der Rolladen gewesen, der augeslöst hat:
        my $windowcontact = AttrVal($dev,'WindowContactAssociated',"none");
        my $shutter=$dev;
     
        if (!$shutter) {}
        else {       
          #Wir speichern ein paar Infos, damit das nicht zu unübersichtlich wird
          my $position = ReadingsVal($shutter,'level',0);
          my $winState = Value($windowcontact);
          my $maxPosition = AttrVal($shutter,'WindowContactOpenMaxClosed',100);
          my $onHoldState = AttrVal($shutter,'WindowContactOnHoldState',"none");
         
          #Jetzt können wir nachsehen, ob der Rolladen zu weit unten ist...
          if($position < $maxPosition && $winState ne "closed" && $windowcontact ne "none") {
              fhem("set $shutter $maxPosition");
              fhem("attr $shutter WindowContactOnHoldState $position");
          }
          #...oder ob eine alte Position wegen Schließung des Fensters angefahren werden soll...
          elsif ($event eq "Window" && $winState eq "closed" && $maxPosition ne "none") {
              fhem("set $shutter $onHoldState");
              fhem("attr $shutter WindowContactOnHoldState none");
          }
          #...oder ob die Positionsinfo wegen manueller Änderung gelöscht werden kann.
          elsif ($event eq "Rollo" && $onHoldState ne "none" && $position ne $maxPosition) {
              fhem("attr $shutter WindowContactOnHoldState none");
          }
        }
    }
}

Die "Peering-Hilfsfunktion":

Code Auswählen Erweitern

sub winShutterAssociate($$$) {
    #Als Parameter müssen die Namen vom Fensterkontakt und Rolladen übergeben werden sowie der Maxlevel bei Fensteröffnung
    my ($windowcontact, $shutter, $maxPosition) = @_;
    my ($hash, @param) = @_;
    #Erst mal prüfen, ob die Parameter sinnvoll sind
    if ($defs{$windowcontact} && $defs{$shutter}) {

        if (AttrVal($shutter,'subType', undef) eq "blindActuator" && AttrVal($windowcontact,'subType',undef) eq "threeStateSensor") {
            my $oldAttrWin = AttrVal($windowcontact,'userattr',undef);
            my $oldAttrRollo = AttrVal($shutter,'userattr',undef);
           
            #Jetzt können wir sehen, ob und welche notwendigen userattr vorhanden sind
            #und ggf. Werte zuweisen
            if(index($oldAttrWin,"ShutterAssociated") < 0){
                fhem("attr $windowcontact userattr $oldAttrWin ShutterAssociated");
                  }
            fhem("attr $windowcontact ShutterAssociated $shutter");
              if(index($oldAttrRollo,"WindowContactAssociated") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo WindowContactAssociated");
                  $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
            fhem("attr $shutter WindowContactAssociated $windowcontact");
            if(index($oldAttrRollo,"WindowContactOnHoldState") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo WindowContactOnHoldState");
                  $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
            if(index($oldAttrRollo,"WindowContactOpenMaxClosed") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo WindowContactOpenMaxClosed");
            }
            fhem("attr $shutter WindowContactOpenMaxClosed $maxPosition");
        }
        else { return "One of the devices has wrong subtype";}
    }
    else { return "One of the devices does not exist";}
}

Beispiel-Aufruf für "peering" im Eingabefeld:

Code Auswählen Erweitern

{ winShutterAssociate("Fenster_Wohnzimmer_SSW","Rolladen_WZ_SSW",10) }


Beispiel für die neuen/zusätzlichen Attribute:
- Fensterkontakt:

Code Auswählen Erweitern

attr Fenster_Wohnzimmer_SSW userattr ShutterAssociated
attr Fenster_Wohnzimmer_SSW ShutterAssociated Rolladen_WZ_SSW

- Rolladen

Code Auswählen Erweitern

attr Rolladen_WZ_SSW userattr room_map structexclude WindowContactAssociated WindowContactOnHoldState WindowContactOpenMaxClosed
attr Rolladen_WZ_SSW WindowContactAssociated Fenster_Wohnzimmer_SSW
attr Rolladen_WZ_SSW WindowContactOnHoldState none
attr Rolladen_WZ_SSW WindowContactOpenMaxClosed 10


Hinweise:
- Da scheinbar manche der userattr erst befüllt werden müssen, bevor man sie abfragen kann, klappt es wohl beim allerersten Auslösefall noch nicht wie erwartet, sondern erst ab dem 2. Mal
- Das mit der Unterscheidung für zwei Lüftungspositionen würde wohl noch weitere userattr benötigen, eine Erweiterung der Auswertelogik und ggf. einen bei Öffnung eines Fensters verzögerten Aufruf (wegen des Zwischenereignisses "ganz offen" vor "gekippt"; "defmod <name> at ...").
- Da derzeit nicht abgefragt wird, ob der Motor gerade läuft (denkbar, wenn das Fenster geöffnet wird oder zukünftig bei einem Zeitereignis usw.), kann es wegen der Laufzeit der Rolläden ggf. zu Seiteneffekten kommen. Dazu habe ich noch keine Idee und muß mal sehen, ob das überhaupt ein praxisrelevantes Problem ist.
- Planungen: erst mal um eine Zeitsteuerung erweitern, in einem weiteren Schritt dann ggf. um Beschattung (dachte an eine 360°-Angabe für jeden Rolladen). Das wird aber dauern, wie eingangs erwähnt, bin ich erst mal dabei zu ergründen, wie man mit perl überhaupt "programmiert".
- Was die zukünftige Pflege des ganzen angeht, gab es im Beitrag "Rollosteuerung für große Installationen" eine recht interessante Readingsgroup-Lösung, die man allerdings anpassen müßte (das dürfte aber kein Hexenwerk sein).

Der Dauertest und der "Rollout" für alle meine Rolläden steht noch aus, bisher sieht das aber bei den Rolläden, die ich durch habe, schon ganz ordentlich aus, daher traue ich im das hier auch schon zu posten. Über Anregungen und Hinweise von Leuten, die wirklich wissen, wie man sowas (besser) löst, würde ich mich natürlich freuen .

Gruß, Beta-User

[spi3845]

Wahnsinn, da ist man einige Tage verreist und dann gibt es soviele coole Ideen und Kommentare...

Habe statt DOIFs mal ein paar notifys (ok eigentlich notifications  ) für meinen Test aufgesetzt und muss gestehen, dass es einfacher ist (auch wenn ich ich für jedes Ereignis wie "Tür auf" oder "Tür zu" ein eigenes notify geschrieben habe), als mein ursprüngliches DOIF. Es ist für mich vor allem deutlich einfacher zu verstehen. Danke schon mal für diese Erkenntnis...

Zu meinen Userreadings:
Hatte weniger an hübsche Osteuropäerinnen gedacht , sondern an eine Unterscheidung zwischen WE/Ferien ("7") und unter der Woche ("8"). Gemeint ist also z.B. "früheste Zeit am WE" und "späteste Zeit am WE", dazwischen wird über einen Helligkeitswert entschieden, wann genau der Rollanden hoch soll (bzw. dann wieder runter).
Dabei würden diese Werte nur herangezogen, wenn das "Grundreading" "AutoMode" auf Single steht, ansonsten wäre das analog aus der Gruppenzugehörigkeit abzuleiten.
Die WindowContact-Angaben hätte ich für eine generische Ablösung der obigen notify-Struktur genommen (habe aktuell 2 davon, aber eben nur für die beiden Türen mit Jalousien, nicht für alle Fenster).

Nach dem Testen der notifys (ich bleib jetzt dabei  ) würde mir auch folgender Ansatz gefallen:

• generelle notifys zur Steuerung aller Rollläden (und nicht ein oder mehrere notifys je Rollladen)
  
  
  
  • Abbilden über notify mit regex?
  • oder über perl-Funktionen in myUtils?
• Konfiguration über userreadings je Rollladen
• Parameter zur Konfiguration:
  
  • Automatik an/aus
  • Lüftungsstellungen 1 und 2
  • Aussperrschutz ja /nein (bzw. welche Tür muss zwingend offen bleiben)
  • Zeit frühestes Öffnen
  • Zeit spätestes Öffnen
  • Autom. Öffnen nach Sonnenstand/Wetter (z.B. Horizon-Wert für Twilight-Funktion je Rollladen konfigurieren)
  • Beschatten ? (da fehlt mir noch der intellektuelle Zugang...)

Die HM-Teile sollte man auch entsprechend konfigurieren, die Parameter sind "driveDown", "driveTurn" und "driveUp", dann kann man da auch die %-Öffnung usw. problemlos einstellen (die Parameter werden auf dem Aktor gespeichert). Das Modul bringt also nur dann Vorteile, wenn es darüber hinaus eine Funktionalität hat (?).

Ich hatte auch darüber nachgedacht, das Modul ROLLO zu nutzen, habe dann aber die Zeiten in den Homematic-Aktoren direkt gespeichert (und vorher ewig gemessen). Mein Problem dabei war, dass die Fahrzeiten von den obersten und untersten Positionen bis exakt zur Mitte unterschiedlich sind. Die Mitte des Rollladens ist die Mitte des Fensters und mein Rollladen hat beim Erreichen der unteren Fensterpositionen noch Schlitze offen - um die zu schließen, muss er noch weiter fahren. Um irgendwelche Positionen (z.B. 30%) wiederholt halbwegs exakt von der untersten (Rollladen komplett zu) oder obersten (Rollladen komplett offen) Position anfahren zu können, habe ich unterschiedliche Fahrzeiten konfiguriert. Dabei hat mir http://heinz-otto.blogspot.de/2016_01_01_archive.html geholfen, da die Aktoren erst etwas später abschalten. Zusätzlich habe ich für das Öffnen eine längere Fahrt gespeichert, da das Öffnen ja eigentlich erst beginnt, wenn die Schlitze des Rollladens offen sind und er die unterste Fensterposition erreicht. Damit habe ich mich dann an die unterschiedlichen Fahrzeiten zum Öffnen und Schließen rangetastet.

Für einen 3,6m breiten raumhohen Rolladen sehen die Werte dann bei mir z.B. so aus

Code Auswählen Erweitern

R-driveDown 35.5 s
R-driveTurn 0.5 s
R-driveUp 43 s

Ansonsten hätte ich dann noch über ein Dauer-at (alle 5 Minuten oder so) alle Rolläden durchgegangen und geprüft, ob etwas zu tun ist (Anfangszeit überschritten, Helligkeitswert über- bzw. unterschritten, späteste Zeit erreicht/überschritten).

Interessanter Gedanke, aber warum verlässt Du dich nicht auf Ereignisse? Z.B. zeitlichen trigger durch at/DOIF oder Twilight-Helligkeitswert?

Also meine Rolladensteuerung setzt vor allem auf perl-Code, notifys und dummies.

Da wäre ich auch interessiert zu lernen...

So, nach einigen Experimenten die vergangenen Tage nachfolgend mal einen Zwischenstand zu einer Lösung auf Basis von notify, perl und userattr, allerdings erst mal ohne Zeitsteuerung und mit nur einer Lüftungsposition (ist für meine Zwecke ausreichend).

Respekt. Ich sehe schon, das nächste Wochenende ist versaut mit Nachstellen, Testen und Verstehen. Hoffe, meine Frau ist nicht im Garten...

- Was die zukünftige Pflege des ganzen angeht, gab es im Beitrag "Rollosteuerung für große Installationen" eine recht interessante Readingsgroup-Lösung, die man allerdings anpassen müßte (das dürfte aber kein Hexenwerk sein).

Interessanter Ansatz. Nur so ein Gedanke - einige von uns haben unabhängig voneinander unterschiedlichste Ansätze zur Rollladensteuerung entwickelt. Wäre das nicht etwas für ein eigenes Modul? Ok, ich gebe zu, ich habe keine Ahnung, wie aufwendig und pflegeintensiv das ist. Aber hier sind ein paar echt gute Ideen diskutiert worden.

Ach so, noch was, ich habe mal das Zustandsdiagramm in editierbarer Form dran gehängt, falls jemand Bedarf haben sollte, das für sich zu ändern/ergänzen...

Gruß,
spi

[Beta-User]

Hallo spi,

Danke für die positive Rückmeldung, ich bin auch ganz angetan von der Diskussion hier, die Du angestoßen hast.

Wie man sieht, ist (jedenfalls bei mir) vieles WIP, wobei manche Gedanken und Ansätze schon länger darauf warten, dass sie mal ausgetestet werden. Für ein "Modul" sollte m.E. aber jemand mitwirken, der sowohl programmiertechnisch theoretische wie praktische Kenntnisse hat und auch die internen Mechanismen von FHEM besser kennt (bei mir ist das nur copy/paste, ob der jeweilige Ansatz jetzt clever ist oder nicht geht dann nach Bauchgefühl ).

Ich fänd es auch nicht schlimm, wenn am Ende "nur" eine Art Baukasten steht, aus dem sich jeder bedienen kann (den von mir hier geposteten Code darf jeder bei Gefallen gerne nach Lust und Laune kopieren, verändern oder verfluchen). Denn vermutlich hat jeder etwas andere Geräte und Abhängigkeiten, da finde ich es besser, "verdaubare" Happen für  abgrenzbare Teilaufgaben zu haben, die man dann mit einigen wenigen Eingriffen und Parametern anpassen kann.

Die Kombination notify/at->perl@myUtils ist m.E. sinnvoll, weil die Logik über einen "one-Liner" doch deutlich rausgeht, allerdings war ich dann bemüht, den perl-code wenigstens etwas zu kommentieren, weil ich auch keine Lust hätte, mir code einzupflanzen, dessen Ablauf ich nicht verstehe. So muß man nur wissen, welche Übergabeparameter dass es gibt . Will man eine echte "tri-State-Lösung" ist es m.E. eh zwingend, da man sonst denselben code an zwei Stellen fast identisch hätte und dann doppelt pflegen müßte (z.B. zur Anpassung an andere als HM-Devices).

Für sehr gut halte ich auch den Ansatz, Parametrierungsinformationen usw. beim zu schaltenden Device direkt abzuspeichern. Das hält es einigermaßen übersichtlich; wenn das mit der readingsgroup dann visualisiert (und parametriert) werden kann, ist auch die Vielzahl der Infos gut handhabbar, die bei einem HM-Rolladen liegen.

Was das "at"-Thema angeht, denke ich zwischenzeitlich, dass folgende Vorgehensweise mehr Sinn hätte: einmal am Tag (3:05 Uhr, dann klappt es auch mit der Uhrumstellung bzw. bei Systemstart) alle Rollläden durchgehen, und dann einmalige at für jeden Schaltzeitpunkt und Rollladen anlegen, die sich dann gegenseitig wieder beeinflussen. (Beispiel: at wird für frühestes Hochgehen definiert, das checkt dann, ob es hell genug ist. Wenn nein: neues notify auf Helligkeitswert, wenn ja: erledigt, Löschen des spätesten Hoch-at's. Wenn das notify nicht bis zum spätesten Hoch-Zeitpunkt getriggert hat: hoch auslösen, notify auf Helligkeit löschen).

Das Problem mit den Timern ist, dass jedenfalls Twilight-Funktionen kaum sinnvoll innerhalb einer readingsgroup editierbar sein dürften (ich lasse mich da aber gerne eines besseren belehren). Die Parametrieung mittels userattr sollte aber auch für diese Variante gehen, soweit ich das verstanden habe, wandelt perl jegliche Info halbwegs sinnvoll von Text nach Zahl oder code um...

As always: sollte jemand hier bereits funktionierende Beispiele haben oder ein besseres (Teil-) Konzept, Fragen oder Anregungen: bitte nicht damit hinter dem Berg halten, oft genug sind "einfache" Fragen das, was einen weiterbringt (@lenoxef: Hättest Du nicht die Frage gestellt, wie das jetzt konkret geht, würde ich immer noch überlegen, ob es nicht an der zeit wäre, mal mit perl was zu machen . Und es ist doch etwas verdrehter, als ich erst dachte...).

Gruß, Beta-User

[Joker]

Hi Beta-User,

meine Lösung sieht recht ähnlich aus wie deine, leider bin ich noch nicht dazu gekommen sie hier mal darzulegen. Evtl. am Wochenende.

Die Kombination notify/at->perl@myUtils ist m.E. sinnvoll, weil die Logik über einen "one-Liner" doch deutlich rausgeht

Das finde ich auch. Ich habe das in meiner FHEM-Installation konsequent so durchgezogen, auch wenn es nur one-liner sind: Ein notify ruft bei mir immer eine perl-Funktion auf (teilweise auch mehrere), die folgendem Namensschema folgt:
modulname_onXXX, also z.B. blinds_onWindowClosed

Alle Funktionen die mit demselben Modulnamen beginnen, sind auch in derselben Datei, die obige also z.B. in 99_myUtilsBlinds.pm (sowie alle weiteren Rollofunktionen). Bei jeder Funktion steht dann als Kommentar darüber, wodurch diese Funktion aufgerufen wird, z.B. notify_xxx, at_xxx oder eine andere Funktion. Ich mache das auch bei Funktionen die ein one-liner sind, weil es mir schon öfter passiert ist, dass aus einem one-liner dann doch mehr wird, und es mir dann direkt im notify zu unübersichtlich wurde. Außerdem kann ich so immer die Datei öffnen und sehe alle Funktionen die eine bestimmte Funktionalität erfüllen.

Für sehr gut halte ich auch den Ansatz, Parametrierungsinformationen usw. beim zu schaltenden Device direkt abzuspeichern. Das hält es einigermaßen übersichtlich; wenn das mit der readingsgroup dann visualisiert (und parametriert) werden kann, ist auch die Vielzahl der Infos gut handhabbar, die bei einem HM-Rolladen liegen.

Das ist vermutlich auch keine schlechte Idee. Ich habe das bei meinen Rollo-Funktionen so gelöst, dass in der 99_myUtilsBlinds.pm ein mehrdimensionales Array definiert ist, wo die Parametrierungen stehen, und die Funktionen schauen dort nach. Werde das mal hier posten- ist vermutlich eher nicht so gut, oder vielleicht doch, ich weiß es nicht... Vorteil ist jedenfalls, dass ich es zentral in der perl-Datei umparametrieren kann, allerdings halt nur per Code-Änderung und nicht per Maus- finde ich aber nicht schlimm, denn das soll auch nur jemand tun der weiß was er tut.

[Beta-User]

Hi Joker,

Danke für die Rückmeldung.

Den Ansatz

Ich habe das bei meinen Rollo-Funktionen so gelöst, dass in der 99_myUtilsBlinds.pm ein mehrdimensionales Array definiert ist, wo die Parametrierungen stehen, und die Funktionen schauen dort nach.

habe ich bisher in der Form auch noch nirgendwo gesehen, ist schon interessant, auf was man nicht alles kommt...
Auf den ersten Blick erscheint mir das für Parameter sehr gut geeignet, die man wirklich nie ändern will. Hat man "solche" und "solche", wird das dann aber auch wieder unübersichtlich.

modulname_onXXX, also z.B. blinds_onWindowClosed

Danke für den Denkanstoß zur Namenskonvention, das Thema hatte ich bislang erfolgreich verdrängt.

Anmerkung dazu (auch an @spi): In dem code oben habe ich nur ein notify, das sowohl auf "auf" und "zu" reagiert, die Differenzierung in der auszuführenden Aktion erfolgt dann im perl-Code. Das erscheint mir insbesondere für den Fall zweckmäßig, wenn auch noch eine andere Reaktion (Ziellevel) auf "tilted" erfolgen soll. Dann sollte man m.E. das Absetzten des eigentlichen perl-Aufrufs etwas verzögern (defmod at +2sec ... {funktionsaufruf} dazwischenschalten), weil sonst (mindestens) die falschen Parameter (wo soll der Rolladen nach Schließung hin?) gespeichert werden, wenn sokurz nacheinander abweichende Aufrufe erfolgen; sinnigerweise sollte der defmod dann immer auf dasselbe at zielen, was am einfachsten geht, wenn es derselbe Aufrufcode ist...

Auch das Rolladen-stop-notify ist ein einziges generalisiertes, das auf alle Rollläden reagiert und dann wieder diesselbe perl-routine aufruft wie das Fenster-notify. Weniger Bausteine gehen also kaum . Weiter Zusammenfassen hatte ich erst angedacht und versucht, dann nicht geschafft und jetzt bin ich eigentlich ganz froh, weil der Aufruf eines "defmod at ..." dann auch definitiv eine ganz andere Reaktion ist. So kann es jeder ander leichter anpassen, wenn er mag und ich selbst verstehe hoffentlich in 10 Jahren noch, was ich mir dabei wohl gedacht habe .

Am Rande und off-Topic:
Warum ist es eigentlich so, dass zu dieser Standardaufgabe in praktisch jeder Installation (und dann noch bei einer so weit verbreiteten Hardware) jeder immer wieder das Rad neu erfindet, so von Grund auf? Ich behaupte mal, dass es (jedenfalls bei mir) nicht an ausgiebiger Recherche dazu fehlt. Es gibt zwar auch im Wiki ein paar Musterlösungsansätze, aber nichts, das ich als in jedem Punkt nachahmenswerten Ansatz empfunden habe bzw. als etwas, das einfach auf meine Bedürfnisse anzuwenden. (Danke auch an Wuppi68 für den Schubser, dass sowas wirklich nicht zu exisiteren scheint und schon das Parametrieren und Speichern von Infos ein Thema ist, bei dem es einige Ansätze gibt).
Mutmaßungen:
- Für wirklich Programmiererfahrene ist das zu trivial und hier hat es nur diesen Typ User ( )...
- Die Zahl der zu berücksichtigenden Informationsquellen und Wünsche ist zu groß, um was "von der Stange" anzubieten
- DOIF ist (jedenfalls aus Sicht der "Nichtprogrammierer") zu gut und mit etwas Hilfe im Forum geht es einfach zu parametrieren
- Der Weg ist das Ziel, an sowas hat jeder Spaß und daher soll auch jeder mal müssen?!?
-...?!?

Na ja, jedenfalls Danke an alle, die mit ihren Beispielen (u.a.) hier Denkanstöße und Lösungsansätze geliefert haben. Ein bißchen ist es für mich schon so, dass Punkt 4 greift , und: nachdem ich erste perl-Erfolge hatte, ist perl-scripting für mich zukünftig das Mittel der Wahl .

Gruß, Beta-User