Rollladensteuerung: Alternativen zu DOIF

[spi3845]

- 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 ...").

Verständnisfrage: meine Türkontakte habe ich so konfiguriert, dass sie 3 Sekunden verzögert senden, um sauber den Zustand von "offen" nach "gekippt" zu erkennen. Dein "n_Rolladen_Window" würde dann auf open oder closed sauber triggern. Ein "defmod ... at" wäre damit hinfällig? Übrigens - ist das nicht ein "define n_Rolladen_Window notify ..." statt "defmod n_Rolladen_Window notify ..."?

- 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.

Da dein "n_Rolladen_Window" auch auf open triggert, müsste m. M. nach die Routine winOpenShutterTester ergänzt werden um eine Abfrage etwa der Art

Code Auswählen Erweitern

elsif ($event eq "Window" && $shutterMotorState eq "down" && $emergencyStop eq "yes"){
fhem("set $shutter stop");
}

"$shutterMotorState" ist dabei der Zustand des Motors: auf, stop oder ab
"$emergencyStop" wäre ein Attribut, das bei den Türen auf yes zu setzen wäre, deren Rollläden während des Schließens bei Öffnen der Tür anzuhalten sind (Nothalt). Vielleicht auch bei Fenstern interessant, damit Kids ihre Köpfe und sonstige Extremitäten nicht einklemmen...

- 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".

Gedanke:

Code Auswählen Erweitern

define wdt WeekdayTimer timer_rollo_n !$we|{sunrise_abs("HORIZON=0.0",0,"6:00","8:00")}|auf $we|{sunrise_abs("HORIZON=0.0",0,"7:00","9:00")}|auf {sunset_abs("HORIZON=0.0",0,"17:00","22:00")}|zu
"timer_rollo_n" ist in meiner Testumgebung ein Dummy, der die Zustände auf oder zu annehmen kann und auf den meine notifys zum Öffnen oder Schließen der Rollläden triggern (also z.B. triggern auf (timer_rollo_n:zu)).

Diesen WeekdayTimer würde ich gerne noch generalisieren, damit die Zeiten nicht direkt drin stehen, sondern aus den userattr der entsprechenden Rollläden (die alle irgendwie heißen wie eg_Rollo_WoZi_li) ausgelesen werden. Geht so etwas überhaupt? Ich denke da an (der Übersichtlichkeit wegen auf mehrere Zeilen verteilt):

Code Auswählen Erweitern

define wdt WeekdayTimer .*_Rollo_.*  \
   Mo|AttrVal($NAME,'mo_auf','none')|auf    Mo|AttrVal($NAME,'mo_zu','none')|zu \
   Di|AttrVal($NAME,'di_auf','none')|auf    Di|AttrVal($NAME,'di_zu','none')|zu \
   ...
   So|AttrVal($NAME,'so_auf','none')|auf    So|AttrVal($NAME,'so_zu','none')|zu \

Damit könnte man auch unterschiedliche (feste oder nach Sonnenstand) Zeiten je Wochentag hinterlegen, ohne dass die WeekdayTimer-Definition unlesbar wird. Urlaubsprogramm? Später...

- 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).

Harter Stoff. Muss ich erst durchdringen. Würde das gerne aber irgendwie vereinfachen, da auf Dauer vermutlich schwer pflegbar.

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.
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 .

Interessante Gedanken. Ich würde noch einen hinzufügen - fhem ist eine OpenSource-Lösung geboren aus der Not (oder Interesse) eines Einzelnen, der am Anfang alles selbst codiert und dokumentiert hat. Eine Rollladensteuerung ist dann einfach nur noch banal  . Viele proprietäre (Closed-Source) Lösungen zielen darauf, schnell sichtbare Ergebnisse zu liefern, Kompromissbereitschaft vorausgesetzt. Standard-Use-Cases nicht mitzuliefern wäre dann verkaufshemmend... Und selber basteln macht halt auch wirklich Spaß, ich bin bei Punkt 4 dabei...

Gruß,
spi

[spi3845]

Diesen WeekdayTimer würde ich gerne noch generalisieren, damit die Zeiten nicht direkt drin stehen, sondern aus den userattr der entsprechenden Rollläden (die alle irgendwie heißen wie eg_Rollo_WoZi_li) ausgelesen werden. Geht so etwas überhaupt? Ich denke da an (der Übersichtlichkeit wegen auf mehrere Zeilen verteilt):

Code Auswählen Erweitern

define wdt WeekdayTimer .*_Rollo_.*  \
   Mo|AttrVal($NAME,'mo_auf','none')|auf    Mo|AttrVal($NAME,'mo_zu','none')|zu \
   Di|AttrVal($NAME,'di_auf','none')|auf    Di|AttrVal($NAME,'di_zu','none')|zu \
   ...
   So|AttrVal($NAME,'so_auf','none')|auf    So|AttrVal($NAME,'so_zu','none')|zu \


Der Gedanke hierzu kam mir erst später, muss ich noch prüfen: DOIF statt WeekdayTimer? Hier schließt sich der Kreis 

[Beta-User]

Hallo zusammen,

echt spannend, was rauskommt, wenn man sowas diskutiert! Super Sache!

Die FK's entsprechend zu konfigurieren ist natürlich das Mittel der Wahl! Damit läßt sich vermutlich dann auch Wuppi68's Wunsch nach 2 Positionen (tilted/open) vermutlich realisieren (weiteres userattr). Problem dabei vielleicht: alte Position bei späterem Wechsel zwischen diesen Zuständen (sollte aber über oldstate des FK's unterscheidbar sein).

Das defmod ist eine Sonderform von define, kommt so raus, wenn man sich die raw-Definition von devices anzeigen läßt. Bedeutung frei übersetzt: define or modify...

Danke auch für den Hinweis, dass man ja auch den Trigger auf Motor down setzen kann. Damit könnte man früher reagieren, bräuchte aber eine Art Hysterese, um bei Jalousien das Drehen der Lamellen zu ermöglichen (das mit dem Drehen kam erst jüngst so richtig in mein Gesichtsfeld.

Zu den timer-Sachen schreib ich später was, da muß ich mich wirklich erst auch mal mit weekdaytimer usw. beschäftigen.

Harter Stoff. Muss ich erst durchdringen. Würde das gerne aber irgendwie vereinfachen, da auf Dauer vermutlich schwer pflegbar.

Harter Stoff, ja, aber mein Eindruck ist gerade andersrum: Wenn man das mal hat, ist es super-einfach, einzelne Parameter anzupassen. Aber ich habe da auch erst mal nur Bahnhof, Abfahrt... verstanden, muß mich da auch erst eindenken.

Der Gedanke hierzu kam mir erst später, muss ich noch prüfen: DOIF statt WeekdayTimer? Hier schließt sich der Kreis 

Dazu erwartest Du keinen ernsthaften Kommentar, oder?

Gruß, Beta-User

[Cluni]

Soooo, ich schreib nochmal was...

Eigentlich wollte ich mir ein Eigengewächs ersparen und habe deshalb am Wochenende versucht, die Steuerung meiner Rollladen in ein WeekDayTimer zu verstauen. Dabei hatte ich aber dann doch das eine oder andere Problem, weshalb ich diesen Thread aufgemacht hatte: https://forum.fhem.de/index.php/topic,70023.0.html

Ich bin dann doch auf eine eigene Perl-Funktion umgeschwenkt, die die UserAttribute meines Rollladen ausliest und dementsprechende at-Befehle erzeugt. Da Beta-User mich in dem o.g. Thread mitgelesen hat und mich darauf angesprochen hat, will ich nun hier mit der Diskussion fortfahren...

Hi Bernd,

sorry, hatte den Quervergleich nicht gemacht .
Ist aber erst mal schön zu hören, dass das Konzept mit dem Auslesen der userattr an sich zu funktionieren scheint.

Anmerkung noch zu der notify-Sache:
Es dürfte einfacher sein, wenn man das in 2 Subfunktionen teilt, nämlich einen "Rahmenpart", der alle Rolläden dann einzeln an die eigentliche "Mache mir at's"-Funktion (für den einzelnen Rolladen) schickt. Dann sollte man diese Teilfunktion nämlich einfacher vom notify aus direkt mit Angabe des betreffenden Rolladens aufrufen können. Aber wie gesagt: bin auch nur am Experimentieren...

Meine Funktion ist bereits auf einen Rollladen ausgerichtet und berechnet für das übergebene Gerät die at und setzt auch einige UserReadings an diesem Gerät.

Es ist zwar noch nicht fertig, aber ich will dann doch schon mal meine UserAttribute und die Funktion posten (zur Info: meine Rollladen heißen z.B. "Rol.Bad"):

Code Auswählen Erweitern

attr Rol.* userReadings 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 Auto_Zufall_Minuten

Code Auswählen Erweitern

sub randomtime_with_realtime($;$;$)
{
  my $ZtA;
  my ($MeH,$MeM,$MeS)=split(':',shift(@_));
  my $MeB=shift(@_);
  my $MeD=shift(@_);
  if ($MeD eq '+') {$ZtA = int($MeH*3600 + $MeM*60 + rand($MeB*60) + $MeS);} # Minuten addieren
  else {$ZtA = int($MeH*3600 + $MeM*60 - rand($MeB*60) + $MeS);} # Minuten subtrahiern

  my $ZtH = int($ZtA/3600);
  my $ZtM = int(($ZtA-$ZtH*3600)/60);
  my $ZtS = int($ZtA-($ZtH*3600+$ZtM*60));
  return sprintf("%2.2d:%2.2d:%2.2d",$ZtH,$ZtM,$ZtS);
} 


sub Auto_Rol_calc_at($)
{
    #Als Parameter muss der device-Name übergeben werden
    my $dev=shift(@_);

    #Erst mal prüfen, ob das übergebene device überhaupt existiert
    if ($defs{$dev}) {

my $Hoch_Zeit;
my $Runter_Zeit;
my $hoch_at;
my $runter_at;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time());

        #Aus dem device werden nun, sofern vorhanden, die ganzen Attribut ausgelesen.
        #Wenn das Attribut nicht vorhanden ist, bekommt es einen Standardwert (z.B. 'nv' für nicht vorhanden)
        my $A_Modus=AttrVal($dev,'Auto_Modus ','immer');
        my $A_hoch=AttrVal($dev,'Auto_hoch','aus');
        my $A_runter=AttrVal($dev,'Auto_runter','aus');
        my $A_offen_Pos=AttrVal($dev,'Auto_offen_Pos','Luft');
        #my $A_Himmelsrichtung=AttrVal($dev,'Auto_Himmelsrichtung',0);
        #my $A_Abschattung=AttrVal($dev,'Auto_Abschattung','nein');
        my $A_Zeit_hoch_frueh=AttrVal($dev,'Auto_Zeit_hoch_frueh','07:30:00');
        my $A_Zeit_hoch_spaet=AttrVal($dev,'Auto_Zeit_hoch_spaet','09:00:00');
        my $A_Zeit_hoch_WE_Urlaub=AttrVal($dev,'Auto_Zeit_hoch_WE_Urlaub','09:30:00');
        my $A_Zeit_runter_frueh=AttrVal($dev,'Auto_Zeit_runter_frueh','16:30:00');
        my $A_Zeit_runter_spaet=AttrVal($dev,'Auto_Zeit_runter_spaet','21:30:00');
my $A_Zufall_Minuten=AttrVal($dev,'Auto_Zufall_Minuten','30');
my $A_Zufall_Sekunden=$A_Zufall_Minuten*60;
my $Raeume=AttrVal($dev,'room','');

        #Festlegen des Namens für die Timer, die angelegt werden um den Rollladen zu gewünschter
        #Zeit zu fahren.
        #my $Rol_hoch_Timername=$dev.'_hochTimer';
        #my $Rol_runter_Timername=$dev.'_runterTimer';
        my $Rol_hoch_Timername='Rol_Timer_hoch_'.$dev;
        my $Rol_runter_Timername='Rol_Timer_runter_'.$dev;
my $Rol_at='Timer_build_at_'.$dev;
        # #Sollten diese Timer bereits existieren, so werden sie zunächst gelöscht.
        Log 1,"delete $Rol_hoch_Timername" if ($defs{$Rol_hoch_Timername});
        fhem("delete $Rol_hoch_Timername") if ($defs{$Rol_hoch_Timername});
        Log 1,"delete $Rol_runter_Timername" if ($defs{$Rol_runter_Timername});
        fhem("delete $Rol_runter_Timername") if ($defs{$Rol_runter_Timername});
        Log 1,"delete Timer_build_at_$dev" if ($defs{$Rol_at});
fhem("delete Timer_build_at_$dev") if ($defs{$Rol_at});

fhem("setreading $dev Auto_hoch_Zeit --:--:--");
fhem("setreading $dev Auto_hoch_Pos ---");
fhem("setreading $dev Auto_hoch_Zeit --:--:--");

$Hoch_Zeit = $A_Zeit_hoch_WE_Urlaub; # Zeit zum Hochfahren mit der Wochenend- bzw. Urlaubs-Zeit vorbesetzen
if ($wday > 5) {goto ABWESENHEITSCHECK;} # Wochenende oder Urlaub? ==> dann Sprung (Urlaub noch nicht vorgesehen)

if ($A_hoch eq 'aus') {goto CHECK_SET_DOWN_TIME;} # Automatik für morgens ausgeschaltet? ==> dann Sprung!
elsif ($A_hoch eq 'Astro'){ # Automatik auf Astro-Programm?
$Hoch_Zeit = sunrise_abs("REAL",$A_Zufall_Sekunden-rand($A_Zufall_Sekunden*2),randomtime_with_realtime("$A_Zeit_hoch_frueh","$A_Zufall_Minuten","+"),randomtime_with_realtime("$A_Zeit_hoch_spaet","$A_Zufall_Minuten","-"));
}
elsif ($A_hoch eq 'Zeit'){ # Automatik auf normalem Zeitprogramm?
$Hoch_Zeit = randomtime_with_realtime("$A_Zeit_hoch_frueh","$A_Zufall_Minuten","+");
}

ABWESENHEITSCHECK:
$hoch_at = "define $Rol_hoch_Timername at $Hoch_Zeit set $dev $A_offen_Pos";
fhem("$hoch_at");
fhem("attr $Rol_hoch_Timername room $Raeume");
fhem("setreading $dev Auto_hoch_Zeit $Hoch_Zeit");
fhem("setreading $dev Auto_hoch_Pos $A_offen_Pos");


CHECK_SET_DOWN_TIME:
if ($A_runter eq 'aus') {goto ENDE;} # Automatik für abends ausgeschaltet? ==> dann Sprung!
elsif ($A_runter eq 'Astro'){ # Automatik auf Astro-Programm?
$Runter_Zeit = sunset_abs("REAL",$A_Zufall_Sekunden-rand($A_Zufall_Sekunden*2),randomtime_with_realtime("$A_Zeit_runter_frueh","$A_Zufall_Minuten","+"),randomtime_with_realtime("$A_Zeit_runter_spaet","$A_Zufall_Minuten","-"));
}
elsif ($A_runter eq 'Zeit'){ # Automatik auf normalem Zeitprogramm?
$Runter_Zeit = randomtime_with_realtime("$A_Zeit_runter_spaet","$A_Zufall_Minuten","-");
}

$runter_at = "define $Rol_runter_Timername at $Runter_Zeit set $dev off";
fhem("$runter_at");
fhem("attr $Rol_runter_Timername room $Raeume");
fhem("setreading $dev Auto_runter_Zeit $Runter_Zeit");


ENDE:
my $TimerErzeugerName='TimerErzeuger_'.$dev;
fhem("define $TimerErzeugerName at *00:05:00 {Auto_Rol_calc_at(\"$dev\")}") if (!($defs{$TimerErzeugerName}));  # Timer zum Starten dieser Funktion erzeugen, falls noch nicht vorhanden
fhem("attr $TimerErzeugerName room $Raeume");
}
}

Für jeden Rollladen muss einmal manuell der Befehl z.B.

Code Auswählen Erweitern

{Auto_Rol_calc_at("Rol.Bad")}

in die Codezeile von Fhem eingegeben werden, nachdem alle Einstellungen für diesen Rollladen gemacht wurden.

Hoffe, dass es schon dem ein oder anderen etwas weiter hilft.

Gruß, Bernd

EDIT: Heute Abend könnte ich bei Interesse auch einen Programmablaufplan (stimmt aber nicht mehr ganz mit dem aktuellen Code überein) posten, den ich mir vor der Programmierung erstellt habe.
EDIT2: Bevor ich mich hier mit fremden Federn schmücke - die Funktion "randomtime_with_realtime" ist eine von mir abgeänderte Version der Funktion "randomtime" von depe1999 aus diesem Thread: https://forum.fhem.de/index.php/topic,29438.msg222082.html#msg222082. Die abgeänderte Funktion erlaubt es mir direkt die komplette Zeit aus meinen Attributen zu übergeben und ich kann sagen, ob der Zufallswert addiert oder subtrahiert werden soll. Danke an depe1999 für das Gerüst!

[Cluni]

Was noch fehlt ist zum Beispiel die Sache mit der Anwesenheit. Dies muss aber im at verarbeitet werden, da dies ja genau zum Ausführungszeitpunkt geprüft werden muss. Außerdem hätte ich gerne eine automatische Neuberechnung, sobald eines der UserAttribute geändert wird. Aber da sehe ich momentan noch keine Lösung, weil die Änderung eines Attributs meines Wissens kein notify auslösen kann. Lasse mich aber gerne eines besseren belehren!
Des weitern muss ich noch eine Funktion schreiben, die zum Beispiel alle 10 Minuten das Modul Twilight checkt und bei Bedarf den entsprechenden Rollladen in Abhängigkeit von z.B. Außentemperatur, Helligkeit, Sonnenstand,... zur Verdunkelung absenkt bzw. wieder öffnet. Mal schauen, wann ich dazu komme.

[Cluni]

Kann mir eigentlich jemand sagen, wie man (mit Wildcard für mehrere Geräte gleichzeitig) weitere UserAttribute hinzufügt, ohne dass bereits vorhandene UserAttribute überschrieben bzw. gelöscht werden? Ich würde gerne noch einen Sensor (z.B. Fenster- oder Türsensor) angeben können, der vor dem Zufahren eines Rollladen abgefragt werden soll und die Aktion abbricht.

[Beta-User]

Für mehrere Geräte auf einmal kann ich es nicht beantworten, aber meine "Peering"-Hilfsfunktion funktioniert in die gewünschte Richtung (beim Rolladen: UserAttribute nur anlegen, wenn sie nicht schon definiert sind.

Müßtest Du halt anpassen, dafür könntest Du aber das "peering" der Geräte gleich mit machen .
https://forum.fhem.de/index.php/topic,69704.msg615465.html#msg615465

[Cluni]

Ich glaube du hast mich falsch verstanden - ich möchte in Fhem allen meinen Rollladen-Aktoren "Rol.*" ein oder mehrere zusätzliche UserAttribute hinzufügen, ohne, dass die bereits konfigurierten UserAttribute überschrieben werden. Sozusagen ein UserAttribute = UserAttribute + <weitere UserAttribute>. Zur Not muss ich die halt bei jedem Gerät einzeln eintragen. Aber wäre lästig....

[Beta-User]

Hi Cluni,

ich habe das schon richtig verstanden und habe tatsächlich (noch) keine Ahnung, wie man das "Array-mäßig" löst bzw. mit Wildcard.

Der code oben macht wie gewünscht

UserAttribute = UserAttribute + <weitere UserAttribute>

(wenn noch nicht vorhanden), aber eben Rolladen für Rolladen und mit Schreiben der Attribute, auch wenn sie bereits belegt sein sollten.
Der Vorteil ist aber der: man kann gleich die Wechselbeziehung z.B. zwischen Rolladen und Fensterkontakt direkt als Parameter eingeben (und die Öffnung, die bei "Fenster wird geöffnet" min. sein soll). M.E. ist es einfacher, das einmalig manuell pro Rolladen zu mappen, als die attr. auf einmal vorzubereiten und dann wieder commandozeilenmäßig zu befüllen (diesen Weg habe ich als sehr fummelig empfunden, daher überhaupt die Hilfs-Funktion).

Und mehrere Kontakte auf einmal in einem attr. geht auch nicht (Zimmer mit Tür und 2 Fenstern; da müßten bei der Tür ja mehrere Rolladen gespeichert werden und entsprechend ausgewertet, wenn man sowas will).

Einen (ungetesteten) update der Bausteine habe ich übrigens auf github liegen, da gäbe es dann auch den "Tilted"-Level (wenn es klappt ). Wer meint, Fehler gefunden zu haben oder sinnvolle Ergänzungen, kann gerne die github-Funktionalität nutzen (schon wieder was, in das ich mich etwas einarbeiten sollte, hoffe, das klappt ggf. so einfach ). Wer Vorschläge hat für eine bessere, ggf. einheitliche Benennung der Attribute und Funktionen: her damit, jetzt ist es (jedenfalls für mich) noch recht einfach, das zu ändern.

Gruß, Beta-User

[spi3845]

Einen (ungetesteten) update der Bausteine habe ich übrigens auf github liegen, da gäbe es dann auch den "Tilted"-Level (wenn es klappt ). Wer meint, Fehler gefunden zu haben oder sinnvolle Ergänzungen, kann gerne die github-Funktionalität nutzen (schon wieder was, in das ich mich etwas einarbeiten sollte, hoffe, das klappt ggf. so einfach ). Wer Vorschläge hat für eine bessere, ggf. einheitliche Benennung der Attribute und Funktionen: her damit, jetzt ist es (jedenfalls für mich) noch recht einfach, das zu ändern.

[Ähem] wenn ich mir was wünschen dürfte - eine Funktion, die alle Rollos mit userattr initial belegt [/Ähem]

- 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.

Ist Dir beim Testen irgend etwas aufgefallen bzgl. der Seiteneffekte?

Gruß,
spi

P.S. Nächstes $we versaut, da weitere Tests 

[Beta-User]

[Ähem] wenn ich mir was wünschen dürfte - eine Funktion, die alle Rollos mit userattr initial belegt [/Ähem]

Hm, da muß ich erst nachdenken, was Du mir mitteilen willst... Die Rolläden, die ich bisher angefaßt habe, hatten schon ein userattr gesetzt, aber die FK's eher nicht (?). Ergo wage ich zu behaupten, dass die Hilfsfunktion ein "attr userattr" anlegt, wenn es nicht vorhanden ist. War das gemeint? Oder bräuchtest Du ein weiteres userattr mit dem Namen "initial"?
Die Vorbelegung aller neuen userattr (und auch der bereits vorhandenen mit den "richtigen" Namen) macht die github-Version jetzt auch (dürfte der Grund gewesen sein, warum das in der ersten Version beim allerersten Mal nicht gleich funktioniert hat, wenn man das "peering" erledigt hatte; es mußte wohl erst mal ein Wert geschrieben worden sein, vorher war das "onHoldState" nicht lesbar).

Ist Dir beim Testen irgend etwas aufgefallen bzgl. der Seiteneffekte?

Bisher nicht, aber der Gedanke "notify auch für motor:down" gefällt mir sehr gut und sollte ebenso weiterhelfen wie der Stups zur Erkenntnis, dass "in Bewegung" wohl ein schlichtes "!=stop" sein dürfte. Muß nur rausfinden, wie man ggf. ein "Taste runter gedrückt" von einem "set_90" unterscheidet und das letztere dann nicht versehentlich in ein "set_80" umwandelt (Ziellevel höher als Mindestlevel bei Öffnung).
Eventuell bräuchte es noch eine Unterscheidung zwischen Rolladen (bei "down" sofort anhalten, ggf. wieder nach oben) und einer Jalousie (Drehbewegung der Lamellen zulassen bzw. alternativ die Lamellen nach Zwangsöffnung gleich wieder "nach unten" drehen, das ist aber vermutlich etwas komplizierter).

P.S. Nächstes $we versaut, da weitere Tests 

...kommt mir bekannt vor ...

Gruß, Beta-User

[spi3845]

Hm, da muß ich erst nachdenken, was Du mir mitteilen willst... Die Rolläden, die ich bisher angefaßt habe, hatten schon ein userattr gesetzt, aber die FK's eher nicht (?). Ergo wage ich zu behaupten, dass die Hilfsfunktion ein "attr userattr" anlegt, wenn es nicht vorhanden ist. War das gemeint?

Si. Das war gemeint - für alle Rollläden, Fenster, Fensterkontakte und was sonst noch alles beim ersten Anlegen die entsprechenden userattr gleich mit anlegen und mit default-Werten belegen. Habe deine Funktion noch nicht im Detail angeschaut, daher der Wunsch...

Bisher nicht, aber der Gedanke "notify auch für motor:down" gefällt mir sehr gut und sollte ebenso weiterhelfen wie der Stups zur Erkenntnis, dass "in Bewegung" wohl ein schlichtes "!=stop" sein dürfte. Muß nur rausfinden, wie man ggf. ein "Taste runter gedrückt" von einem "set_90" unterscheidet und das letztere dann nicht versehentlich in ein "set_80" umwandelt (Ziellevel höher als Mindestlevel bei Öffnung).

Das ich das richtig verstehe - set_xx wird doch nur gesetzt, wenn der Rollladen-Level von fhem aus gesetzt wird. Bei einem Tastendruck direkt auf dem Aktor wird doch kein set_xx gesetzt oder irre ich mich da? Dann hätten wir doch eine Unterscheidung: motor!=stop und set_xx ==> per fhem getriggert, ansonsten per Taster.

Eventuell bräuchte es noch eine Unterscheidung zwischen Rolladen (bei "down" sofort anhalten, ggf. wieder nach oben) und einer Jalousie (Drehbewegung der Lamellen zulassen bzw. alternativ die Lamellen nach Zwangsöffnung gleich wieder "nach unten" drehen, das ist aber vermutlich etwas komplizierter)

Ein weiteres userattr das angibt, ob Lamellen zu berücksichtigen sind oder nicht. In dem Fall von Jalousien in Endstellung für einige Sekunden dann in andere Richtung fahren.

Gruß,
spi

[hugomckinley]

Da meine Lösung (https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545) anscheinend von einigen als interessant gesehen wird, kann ich gerne anbieten meinen (zugegebenermaßen) nicht ganz offensichtlichen Code besser zu kommentieren, um euch das Lesen zu erleichtern.

Gebt mir ein paar Tage dann kann ich das nachreichen.

Genau das war auch der Grund für diese Entwicklung --> 1x Arbeit aber es ist leicht zu bedienen/erweitern

Harter Stoff, ja, aber mein Eindruck ist gerade andersrum: Wenn man das mal hat, ist es super-einfach, einzelne Parameter anzupassen. Aber ich habe da auch erst mal nur Bahnhof, Abfahrt... verstanden, muß mich da auch erst eindenken.

Dieses System läuft seit fast 2 Jahren sehr zufriedenstellend und mit den diversen Optimierungen wirklich vollautomatisch. Sollte außer dem Perlcode noch etwas unklar sein, bitte Bescheid geben, damit ich auch das ausführlicher beschreiben kann.

lg
Hugo

[spi3845]

Da meine Lösung (https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545) anscheinend von einigen als interessant gesehen wird, kann ich gerne anbieten meinen (zugegebenermaßen) nicht ganz offensichtlichen Code besser zu kommentieren, um euch das Lesen zu erleichtern.

Das wäre prima! Danke!

So ein Gedanke und eine Bitte - ich will nicht stumpf Code kopieren, sondern ihn und auch die Ziele, die jeder mit seiner Lösung verfolgt, verstehen. Was sie oder er erreicht hat, was noch offen ist, etc. Würdet ihr kurz die folgenden Fragen mit beantworten, wenn ihr eure Lösungen vorstellt? Feel free to add Fragen Ich weiß, vieles ergibt sich aus euren Posts, aber die interessanten Dinge sind über viele Stellen verstreut...

• Was ist das Ziel der Lösung?
  ...
• Was ist bereits umgesetzt?
  ...
• Was fehlt noch?
  ...
• Was sind die Voraussetzungen (HW/SW) für diese Lösung?
  ...
• Warum wurde die Lösung so implementiert?
  ...
• Was würde ich heute anders machen?
  ...

Für meine im ersten Post (https://forum.fhem.de/index.php/topic,69704.msg612152.html#msg612152) vorgestellte sehr rudimentäre DOIF-Routine meine Antworten:

• Was ist das Ziel der Lösung?
  Rollladensteuerung in einem mehrgeschossigen Haus. Dabei bei einer Tür Aussperrschutz und Lüftungsfunktion. Und fhem verstehen lernen... Da kam die Rollladensteuerung gerade recht...
• Was ist bereits umgesetzt?
  Aussperrschutz und Lüftungsfunktion funktionieren
• Was fehlt noch?
  
  
  
  • Beschattungsfunktion
  • einfacher Code und damit Nachvollziehbarkeit auch noch in Monaten
  • eine Funktion für alle Rollläden - aktuell muss der Code mehrfach kopiert und damit gepflegt werden
  • einfache Konfiguration einzelner Rollläden
  • übersichtliche Darstellung und Auswahl der Parameter in einer GUI
  • sonstige Komfortfunktionen
• Was sind die Voraussetzungen (HW/SW) für diese Lösung?
  Homematic-Rollladen-Aktoren, sollte aber auch mit anderen Aktoren funktionieren.
• Warum wurde die Lösung so implementiert?
  Ich bin erst vor wenigen Wochen in fhem eingestiegen und schnell bei DOIF gelandet. Wollte mit einer Funktion alles abdecken. DOIF erschien mir passend.
• Was würde ich heute anders machen?
  Habe ich bereits, weil mein DOIF-Ansatz (für mich) schwer verständlich ist: habe das ganze mit notifys und WeekdayTimer abgebildet. Damit ist es für mich einfacher zu verstehen, aber noch nicht genau das, was ich mir vorstelle.

Gruß,
spi

[spi3845]

Einen (ungetesteten) update der Bausteine habe ich übrigens auf github liegen, da gäbe es dann auch den "Tilted"-Level (wenn es klappt ).

Auf die Schnelle ist mir folgendes aufgefallen (ok, so schnell war's auch nicht, musste erst Doku unter https://wiki.fhem.de/wiki/99_myUtils_anlegen lesen ).

Damit die auf github liegende "99_myShutter.pm" in fhem unter "Edit files" angezeigt wird, muss sie "99_myShutterUtils.pm" heißen. Alles was auf Utils endet, wird angezeigt... Die initialize-Funktion muss "myShutterUtils_Initialize($$)" heißen (und damit dem Dateinamen entsprechen).

Code Auswählen Erweitern

sub winShutterAssociate($$$) { muss

Code Auswählen Erweitern

sub winShutterAssociate($$$$) { heißen, ein $ fehlt.

Zum Verständnis:
winOpenShutterTester($$) wird bei entsprechenden Ereignissen immer ausgeführt und fährt dann die Rollläden entsprechend. Die Ausführung ist nicht beschränkt auf die "Nacht-Zeit", zu der die Rollläden automatisch geschlossen werden sollen? Ich habe das mit dummys nachgestellt zum Testen und bin nicht sicher, ob ich einen Fehler gemacht habe oder das auch das Ziel von winOpenShutterTester($$) ist.

Weitere Tests später...

Gute Nacht,
spi