Rollladensteuerung: Alternativen zu DOIF

[spi3845]

Fehlt da nicht noch die Unterscheidung beim Fahren, ob eine Zielposition gegeben ist (FHEM-veranlaßt) oder nicht (Tastendruck). Im ersteren Fall muß man m.E. noch unterscheiden, ob die Zielposition oberhalb der aktuellen ist (dann reagieren wir erst wieder bei "stop") oder unterhalb (dann generieren wir daraus eine neue on-Hold-Position)...

Vorschlag: schaut euch die Grafik an, malt drin rum (gerne mit Stift, dann Einscannen und mir schicken) - ich baue das wieder ein. Dann haben wir eine Art "Lastenheft", in dem wir die verschiedenen Funktionen abbilden.

"Mein"  notify reagiert schon heute auf alle Rolläden und Tür-/Fensterkontakte im Haus und prüft, ob was getan werden soll. Das ist im Moment eben nur bei 4 Rolläden und 2 Drehkontakten sowie 2 "Auf/Zu"-Kontakten der Fall. Damit etwas passiert, braucht es die entsprechenden Attribute.

Klar, das macht ja die entsprechende Associate-Funktion. Meine Frage bezog sich darauf, wie devspec2array helfen soll. In der Associate-Funktion doch nur, wenn auf einen Schlag für alle entsprechenden Devices default-Werte eingetragen würden, da ansonsten eine 1:1-Zuordnung Fenster-Fensterkontakt definiert werden muss (und hier hilft doch devspec2array nicht oder verstehe ich die Funktion falsch?). Automatisch könnte das dann nur geschehen, wenn aus dem einen Device-Namen der andere abgeleitet werden könnte (Namenskonvention).

Eine generelle Frage zum Entwurf:
Wie wollen wir Vorschläge und Wünsche abbilden? Bsp. Rollladen fährt aus der ganz offen-Position nach unten und befindet sich über der "Tür offen"-Lüftenposition. Die Tür wird geöffnet. Wohin soll der Rollladen dann fahren? Der eine mag vielleicht, dass der Rolladen sofort stehen bleibt, oder eine obere Aussperrposition anfährt (z.B. nur 30% geschlossen), der dritte mag vielleicht, dass der Rollladen auf die "Tür offen"-Lüftenposition fährt.

M. M. gibt es hier zwei Möglichkeiten, die eine ist, dass wir so etwas erkennen, besprechen und flexibel im Code (aka späteren Modul   ) abbilden. Dazu werden wir entsprechende zusätzliche userattr brauchen und eine Darstellung, die jeder versteht. Daher die Zustandsgrafik...

Die andere Möglichkeit ist, dass ein bestimmtes Verhalten fest im Code abgebildet wird.

Die erste Möglichkeit gefällt mir gut, die zweite nicht, da der Code dann kein flexibles Modul mehr wäre. Was meint ihr?

Grüße,
spi

[Beta-User]

wie devspec2array helfen soll.

Beim Thema Rolladen-Lüftenpositionen dürfte das gar nicht helfen, eher bei der timer-Generierung bzw- -prüfung. Das war darauf bezogen, dass Hugo in seinen Funktionen quasi eine eigene Funktion geschreiben hat, die (wie ich das verstanden habe) was verglichbares bezweckt.

Wie wollen wir Vorschläge und Wünsche abbilden? Bsp. Rollladen fährt aus der ganz offen-Position nach unten und befindet sich über der "Tür offen"-Lüftenposition. Die Tür wird geöffnet. Wohin soll der Rollladen dann fahren? Der eine mag vielleicht, dass der Rolladen sofort stehen bleibt, oder eine obere Aussperrposition anfährt (z.B. nur 30% geschlossen), der dritte mag vielleicht, dass der Rollladen auf die "Tür offen"-Lüftenposition fährt.

M. M. gibt es hier zwei Möglichkeiten, die eine ist, dass wir so etwas erkennen, besprechen und flexibel im Code (aka späteren Modul   ) abbilden. Dazu werden wir entsprechende zusätzliche userattr brauchen und eine Darstellung, die jeder versteht.

M.M. wird der Versuch eher schwierig, alle Wünsche und Möglichkeiten abzubilden. Bereits der Versuch, 2 Zwischenzustände zu definieren machte es schwierig, den fahrenden Rolladen abzugreifen erwies sich dann als ausgesprochen tricky.

Gelöst ist (?) es im Moment so, dass es darauf ankommt, ob es eine Zielposition gibt (also ein "set_"). Ist diese vorhanden, fährt der Rolladen entweder dahin (so die Position nach den aktuellen Gegebenheiten zulässig ist) oder hält unterwegs an und merkt sich, dass er weiterfahren soll, sobald das Fenster (weiter) geschlossen wird. Gibt es keine (nur bei Fahrt nach unten), geht die Funktion erst mal davon aus, dass komplett geschlossen werden soll. Ein "stop" überschreibt das ggf. später ja wieder bei einem "rechtzeitigen" Benutzereingriff, also vor Erreichen der (modifizierten) Zwischenzielposition.

Ansonsten ist mir in der Grafik auch noch nicht klar, wie Zwischenpositionen behandelt werden sollen, die nicht Läfungsbedingt angefahren wurden. Hier wäre meine Logik: solange zulässig, darf der Rolladen da stehen bleiben, wo er ist, begrenzt wird immer nur "nach unten".

Nachvollziehbar?

Gruß, Beta-User

[hugomckinley]

Guten Abend,

Da ja mein Code hier einige Denkanstöße liefert möchte ich noch etwas Unterstützung bieten soweit ich eure Fragen verstehe.

devspec2array: habe ich soweit ich mich erinnern kann nicht verwendet, da ich es nicht geschafft habe auf Attribute (hier den subType) zu prüfen (und nur dort steht, dass es ein blindActuator ist). Bei mir und bei vielen anderen (hinsichtlich Modularisierung) folgen die Rollos nicht unbedingt einer einheitlichen Namensstruktur, aber Rollos sind sie alle

command in readingsGroup: Ich wollte Dropdowns mit den möglichen Werten (z.B. Zeitzone(EG1, EG2, OG1, OG2, usw.)) und Toggle-Funktionen. Das war die einzige Möglichkeit wie ich das geschafft habe.

DOIFs, Timer, dummy, usw: waren leider (stört mich wirklich sehr, wegen der mangelnden Übersichtlichkeit) nötig, da ich kein Modul schreiben wollte (konnte)

Komplexität: Ja es ist schon ziemlich länglich und meine Lösung deckt ja nicht einmal Raffstores ab oder Lüftungsfunktionen. Die Geschichte ist die, dass hier viele Abhängigkeiten entstanden sind die sich im Laufe des ersten Entwicklungsjahres ergeben haben und "abgefangen" werden mussten. Wenn man ein für die meisten Fälle "gültiges" Modul entwickeln will, wird dieses sicher sehr komplex (intern. nach außen kann und soll man das natürlich so gut wie möglich verstecken -->nur notwendige Parameter anzeigen usw.)


Die Idee mit dem Modul finde ich sehr gut, denn da hat man dann alle Möglichkeiten die man braucht, um das Ding so gut wie möglich zu kapseln. Ein neues Modul zu schreiben übersteigt meine Fähigkeiten leider, aber bestehenden Code zu erweitern kann ich und da würde ich mich auch sehr gerne Beteiligen, wenn es ein Rohgerüst des Moduls gibt.

Grüße
Hugo

[Beta-User]

Hallo zusammen,

nachdem das $we u.a. auch dazu da war, das eine oder andere im Hinblick auf ein "Modul" auszutesten usw. mal ein kurzer Zwischenbericht. Vorab: das ist richtig mühsam , und es stellt sich die Frage, ob das nur daran liegt, dass ich an sich wenig Programmierkenntnisse habe oder auch daran, dass viele Funktionen, die u.a. fhem.pl bietet, nur durch Analyse von Quelltext und (Anwendungs-) Beispielen verwendet werden können.

Im Ergebnis geht es jedoch etwas voran, wenn auch bei weitem nicht so zügig wie erhofft .

Wer Tipps geben mag und Spaß daran hat, pre-alpha-code zu testen, findet die "Modul"-Version auf github. Aber Achtung: manche meiner "Umbauten" im Code hatten als (behobenes) Zwischenergebnis, dass FHEMWEB nicht mehr erreichbar war, also: Auf eigenes Risiko!

Was funktioniert:

• Man kann ein Gerät "HMshutterUtils" definieren.
• Es "reagiert" auch auf Events von Rolläden und Tür/Fensterkontakten, ABER: Die Reaktionen sind leider weit von der Konsistenz der myUtils-Fassung entfernt (so sie überhaupt erfolgen)
• Man kann die internen Variablenwerte im Gerät sehen (State wird derzeit vorrangig zur Debuggingausgabe genutzt, ist aber naturgemäß immer auf den letzten Event beschränkt).

Was geht (noch) nicht:

• Attributvergabe über "set" (softpeering, Jalousie-Wert)
• Konsistentes Anfahren sinnvoller Positionen (klappt nur hin und wieder)

Offene Punkte/Fragen:

• Ist es erforderlich, Doppelevents zu erkennen und zu vermeiden?
• Welche Rolle spielt in dem Zusammenhang ggf. {NotifyOrderPrefix}?
• Warum wird der onHoldState gelegentlich gelöscht? Doppelevent oder
• funktionieren manche nummerischen Vergleiche nicht?
• Wie müssen die Set-Funktionen aussehen?
• Coding allg.: Irgendwie sieht das deutlich weniger elegant aus als bei anderen Modulen . Anregungen zur Verbesserung sind daher willkommen, insbesondere: kann/sollte man direkter auf die Readings zugreifen mit $hash->{wasauchimmer}?

Nächste Schritte daher:

• Code für "Fenster/Tür-Offen/tilted" wieder in Modulform zum Funktionieren bringen.
• Set-Funktionalität für Attributvergabe usw. implementieren

Dann kann es erst Richtung Timerdefinition aus Attributen gehen.
@all: Wer helfen kann und mag: feel free!
Die meiste Zeit habe ich dafür aufgewendet, den Code von "klassischem" FHEM-perl-code hin zu "internem" FHEM-perl-code zu modifizieren, an sich ist das aber - abgesehen von der anderen Form der Funktionsaufrufe selbst - nicht wirklich ganz was anderes.

@cluni: Danke für den Code, das sieht nach einer guten Basis aus! Was mir nicht so gefällt, ist die Einschränkung der Namensgebung, aber das mit der Namenskonvention verfolgte Ziel sollte auch auf anderem Wege zu erreichen sein (Attribute/Inhalt, s.u.).

@Hugo:
- devspec2array hatte ich so verstanden, dass man im Prinzip jeden regulären Ausdruck nehmen kann, um das Array zu generieren. @cluni hat das auch so gemacht, hier ist ein weiteres Beispiel, das sogar noch eine Filterfunktion verwendet:

Code Auswählen Erweitern

@list = devspec2array("subType=threeStateSensor:FILTER=winOpenMsg=1");
Habe das so verstanden: Was ein "list" mit der devspec liefert, landet mit devspec2array im Array. Sollte also für die Generierung von Öffnen- und Schließen-ats passen.
- Das mit "command" ist klar, es ging mir nur darum, ob das "attr $DEVICE" in

'automatic.on' => 'attr $DEVICE automatic off', 'automatic.off' => 'attr $DEVICE automatic on',

erforderlich ist. Ist aber eher ein völlig unbedeutendes Detail...

Wie dem auch sei, das wird noch ein langer Weg, wenn niemand (Modul-)Kompetentes hilft .

Gruß, Beta-User

[Frini]

Hallo,
ich betreibe meine Rolladensteuerung bereits mit mehreren DOIFs. Die intelligenten Rolläden, also jene wo die Fenster mit Drehgriffsensoren ausgestattet sind, besitzen zwei DOIFs. Eins für die normalen Fahrzeiten und eins für die Türöffnung.
Dieses prozedere für jedes Rollo.
Ich verfolge diesen Thread also sehr interessiert. Die Anzahl der gesteuerten Rolladen nimmt so langsam zu, und ich würd das gerne etwas übersichtlicher gestalten.

Bin auch bereit zu testen, bin allerdings ziemlicher Perl Anfänger und kann bis Dato nur einigermaßen mit DOIFs steuern

Grüße
Matthias

[Cluni]

Meine Perl Funktion läuft mittlerweile recht gut und erzeugt jeweils AT für hoch und runter und notify für die Fensterkontakte. Die Lüftungsfunktion über die notify läuft noch nicht ganz zufriedenstellend und da muss ich nochmal bei gehen. Was noch komplett fehlt sind die automatisch erzeugten notify für Aussperrschutz und für die Beschattung. Könnte später nochmal den aktuellen Stand posten oder dir eine Anleitung per Email schicken mit allen Voraussetzungen, wenn du das mal testen möchtest. Kannst mir dann deine Email ja per PN schicken.


Gesendet von iPhone mit Tapatalk

[mrfloppy]

Hallo,
ich betreibe meine Rolladensteuerung bereits mit mehreren DOIFs. Die intelligenten Rolläden, also jene wo die Fenster mit Drehgriffsensoren ausgestattet sind, besitzen zwei DOIFs. Eins für die normalen Fahrzeiten und eins für die Türöffnung.

Würdest du deine DOIF´s ev. mal posten.

Danke

[Frini]

Klar kein Thema.
Hier findet man einen Zwischenschritt. Bin nicht zu Hause kann den aktuellen Code momentan nicht liefern https://forum.fhem.de/index.php/topic,57729.msg491242.html#msg491242.

Bei Interesse liefer ich den aber nach. Ist aber nen DOIF

[mrfloppy]

Bei Interesse liefer ich den aber nach. Ist aber nen DOIF

Bitte gerne
LG

[Frini]

Hallo,
nun mal meine Steuerung am Beispiel von unserer Terassentür welche mit einem Drehgriffsensor und einem Rolladenaktor von Homematic ausgestattet ist.
Folgende devices sind involviert:
rol.eg.wz.RolladeGartenRechts --> Rolladenaktor
sen.eg.wz.TerrassentuerRechts --> Drehgriffsensor
dum.RolloZustand --> wird benötigt im Zusammenhang mit der Beschattungsfunktion
dum.eg.wz.RolladeGartenRechtsPos --> wird benötigt um zu verifizieren ob ich noch im Automatikmodus bin oder nicht. Dies musste ich einbauen, falls meine Frau bei geöffneter Tür manuell das Rollo verfährt. Damit umgehe ich quasi das anfahren der vor dem Tür öffnen gespeicherte Position
dum.eg.wz.RolloAutomatik --> Das entsprechende Dummy

DOIF für das automatische Fahren des Rollos abhängig vom Wochentag:

Code Auswählen Erweitern

([06:00|8])
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="up" up, set dum.RolloZustand:FILTER=STATE!="Tag" Tag, set dum.eg.wz.RolladeGartenRechtsPos up)
DOELSEIF
([{sunset("REAL",+900,"18:00","21:00")}|8] and [sen.eg.wz.TerrassentuerRechts:state] eq "closed")
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="down" down, set dum.RolloZustand:FILTER=STATE!="Nacht" Nacht, set dum.eg.wz.RolladeGartenRechtsPos down)
DOELSEIF
([{sunset("REAL",+900,"18:00","21:00")}|8] and [sen.eg.wz.TerrassentuerRechts:state] eq "tilted")
(set rol.eg.wz.RolladeGartenRechts 70, setreading rol.eg.wz.RolladeGartenRechts speicher down, set dum.RolloZustand:FILTER=STATE!="Nacht" Nacht, set dum.eg.wz.RolladeGartenRechtsPos 70)
DOELSEIF
([{sunset("REAL",+900,"18:00","21:00")}|8] and [sen.eg.wz.TerrassentuerRechts:state] eq "open")
(setreading rol.eg.wz.RolladeGartenRechts speicher down, set dum.RolloZustand:FILTER=STATE!="Nacht" Nacht)
DOELSEIF
([{sunrise("CIVIL",0,"07:00","08:00")}|7])
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="up" up, set dum.RolloZustand:FILTER=STATE!="Tag" Tag, set dum.eg.wz.RolladeGartenRechtsPos up)
DOELSEIF
([{sunset("REAL",+4500,"18:00","22:00")}|7] and [sen.eg.wz.TerrassentuerRechts:state] eq "closed")
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="down" down, set dum.RolloZustand:FILTER=STATE!="Nacht" Nacht, set dum.eg.wz.RolladeGartenRechtsPos down)
DOELSEIF
([{sunset("REAL",+4500,"18:00","22:00")}|7] and [sen.eg.wz.TerrassentuerRechts:state] eq "tilted")
(set rol.eg.wz.RolladeGartenRechts 70, setreading rol.eg.wz.RolladeGartenRechts speicher down, set dum.RolloZustand:FILTER=STATE!="Nacht" Nacht, set dum.eg.wz.RolladeGartenRechtsPos 70)
DOELSEIF
([{sunset("REAL",+4500,"18:00","22:00")}|7] and [sen.eg.wz.TerrassentuerRechts:state] eq "open")
(setreading rol.eg.wz.RolladeGartenRechts speicher down, set dum.RolloZustand:FILTER=STATE!="Nacht" Nacht)
attr do allways ist gesetzt

Dieses DOIF steuert die Komfortfunktion der Rollade, also Rollo hochfahren bei Öffnen der Tür und fahren des Rollos auf Lüftungsposition bei Kippen der Tür. Des Weiteren verhindert dieses DOIF auch das schließen der Rollade bei geöffneter Tür und fährt das Rollo dann anschließend zu, sofern der Sonnenuntergang aus vorrigem DOIF schon gewesen ist. Die Positionen des Rollos speichere ich in einem Userreading im Rolladen device genannt speicher

Code Auswählen Erweitern

([sen.eg.wz.TerrassentuerRechts] eq "open" and ([?rol.eg.wz.RolladeGartenRechts] eq "up" or [?rol.eg.wz.RolladeGartenRechts] > 80))
(setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts])
DOELSEIF
([sen.eg.wz.TerrassentuerRechts] eq "open" and ([?rol.eg.wz.RolladeGartenRechts] eq "down" or [?rol.eg.wz.RolladeGartenRechts] <= 80))
(setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts], set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="up" up, set dum.eg.wz.RolladeGartenRechtsPos up)
DOELSEIF
([sen.eg.wz.TerrassentuerRechts] eq "tilted" and ([?rol.eg.wz.RolladeGartenRechts] eq "up" or [?rol.eg.wz.RolladeGartenRechts] > 30))
(setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts])
DOELSEIF
([sen.eg.wz.TerrassentuerRechts] eq "tilted" and ([?rol.eg.wz.RolladeGartenRechts] eq "down" or [?rol.eg.wz.RolladeGartenRechts] <= 30))
(setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts], set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="30" 30, set dum.eg.wz.RolladeGartenRechtsPos 30)
DOELSEIF
([sen.eg.wz.TerrassentuerRechts] eq "closed" and ([?rol.eg.wz.RolladeGartenRechts] eq "up" or [?rol.eg.wz.RolladeGartenRechts] eq "100" or [?rol.eg.wz.RolladeGartenRechts] eq "30" or [?rol.eg.wz.RolladeGartenRechts] eq "80") and [?rol.eg.wz.RolladeGartenRechts:speicher] ne "up")
(set rol.eg.wz.RolladeGartenRechts [rol.eg.wz.RolladeGartenRechts:speicher], set dum.eg.wz.RolladeGartenRechtsPos [rol.eg.wz.RolladeGartenRechts:speicher])
DOELSEIF
([sen.eg.wz.TerrassentuerRechts] eq "closed" and ([?rol.eg.wz.RolladeGartenRechts] ne "up" or [?rol.eg.wz.RolladeGartenRechts] ne "100" or [?rol.eg.wz.RolladeGartenRechts] ne "30" or [?rol.eg.wz.RolladeGartenRechts] ne "80") and ([?rol.eg.wz.RolladeGartenRechts:speicher] eq "up" or [?rol.eg.wz.RolladeGartenRechts:speicher] eq "100"))
(setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts])
attr do always gesetzt

Und hier das DOIF welches den Sonnenschutz steuert:

Code Auswählen Erweitern

([MeinWetter:temp_c] > 19 and [?myTwilight:azimuth] > 220 and [?myTwilight:azimuth] < 290 and [?sen.eg.wz.TerrassentuerRechts] eq "closed" and [?dum.eg.wz.RolloAutomatik] eq "Automatik" and ([?rol.eg.wz.RolladeGartenRechts] eq "up" or [?rol.eg.wz.RolladeGartenRechts] < 71))
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="70" 70, set dum.eg.wz.RolladeGartenRechtsPos 70, set rol.eg.wz.RolladeGartenLinks:FILTER=STATE!="70" 70)

DOELSEIF
([MeinWetter:temp_c] > 19 and [?myTwilight:azimuth] > 220 and [?myTwilight:azimuth] < 290 and [?sen.eg.wz.TerrassentuerRechts] eq "tilted" and [?dum.eg.wz.RolloAutomatik] eq "Automatik" and ([?rol.eg.wz.RolladeGartenRechts] eq "up" or [?rol.eg.wz.RolladeGartenRechts] < 71))
(setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts], set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="70" 70, set dum.eg.wz.RolladeGartenRechtsPos 70, set rol.eg.wz.RolladeGartenLinks:FILTER=STATE!="70" 70)

DOELSEIF
([MeinWetter:temp_c] > 19 and [?myTwilight:azimuth] > 220 and [?myTwilight:azimuth] < 290 and [?sen.eg.wz.TerrassentuerRechts] eq "open" and [?dum.eg.wz.RolloAutomatik] eq "Automatik" and ([?rol.eg.wz.RolladeGartenRechts] eq "up" or [?rol.eg.wz.RolladeGartenRechts] > 91))
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="90" 90, setreading rol.eg.wz.RolladeGartenRechts speicher [rol.eg.wz.RolladeGartenRechts], set dum.eg.wz.RolladeGartenRechtsPos 90, set rol.eg.wz.RolladeGartenLinks:FILTER=STATE!="70" 70)

DOELSEIF
([MeinWetter:temp_c] < 19 and ([?myTwilight:azimuth] > 220 or [?myTwilight:azimuth] < 290) and [?sen.eg.wz.TerrassentuerRechts] ne "aa" and [?dum.eg.wz.RolloAutomatik] eq "Automatik" and [?dum.RolloZustand] eq "Tag")
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="up" up, set dum.eg.wz.RolladeGartenRechtsPos up, set rol.eg.wz.RolladeGartenLinks:FILTER=STATE!="up" up)

DOELSEIF
([MeinWetter:temp_c] < 19 and [?sen.eg.wz.TerrassentuerRechts] ne "aa" and [?rol.eg.wz.RolladeGartenRechts] > 69 and d[?dum.RolloZustand] eq "Tag" and [?dum.eg.wz.RolloAutomatik] eq "Automatik")
(set rol.eg.wz.RolladeGartenRechts:FILTER=STATE!="up" up, set dum.eg.wz.RolladeGartenRechtsPos up, set rol.eg.wz.RolladeGartenLinks:FILTER=STATE!="up" up)

Und das HilfsDOIF für die Automatik

Code Auswählen Erweitern


([rol.eg.wz.RolladeGartenRechts:STATE] ne [?dum.eg.wz.RolladeGartenRechtsPos:STATE])
(set dum.eg.wz.RolloAutomatik Manuell)
DOELSE
(set dum.eg.wz.RolloAutomatik Automatik)

Ich denke, dass es auch einfacher geht. Aber diese Version läuft schon seit geraumer Zeit stabil und ist mit der Zeit gewachsen.

[kjmEjfu]

Es wäre cool, wenn auch der Status eines zugeordneten Residents mit berücksichtigt werden könnte.
Also z.B. Rollo X automatisch runterfahren, sobald der Status des zugeordneten Residents auf "go to sleep" wechselt, spätestens aber automatisch um xx Uhr.
Oder Rollo Y automatisch hochfahren um xx Uhr, aber nicht wenn ein zugeordneter Resident (Guest) anwesend ist (z.B. fürs Gästezimmer).

[Beta-User]

Hallo zusammen,

kurze Zwischeninfo zu dem Modul-Thema:

Die "Absturzursache" habe ich zwischenzeitlich gefunden und behoben, aber am eigentlichen Code bin ich nicht wirklich weitergekommen, da ich dafür schlicht keine Zeit hatte.

Dafür habe ich versucht, das mit der Set-Funktionalität mal auf einen Stand zu bringen, der ggf. auch anderen das Testen ermöglicht, war aber leider nicht erfolgreich und habe daher zu der speziellen Frage hier einen Thread aufgemacht.
Vielleicht mag jemand mit einem Testsystem mal ausprobieren, ob das uU. nur an Altlasten meiner lokalen Maschine liegt oder ob es sich um eine reproduzierbares Problem handelt (wobei ich von letzterem ausgehe).

Wenn ich dazu kommen, konsolidiere ich die diversen Fassungen des notify mal und melde mich dann wieder.

Gruß, Beta-User

[Jorge3711]

winOpenShutterTester($$) ist tatsächlich im Moment rein ereignisorientiert ...

Bin gerade, ganz ähnlich wie bei Dir, mich in Perl einzudenken und evtl. DOIF in Teilen zu entsorgen. Ich sitzen schon seit längerem vor Deiner 99_myShutterUtils.pm. Grundsätzlich verstehe ich den Code, das meiste sind ja doch nur if Abfragen (nicht abwertend gemeint!).

Was ich aber nicht verstehe ist der Unterschied zwischen myShutterUtils_MovementCheck() und winOpenShutterTester(). Sind das einfach 2 Ansätze das gleiche umzusetzen, oder ergänzen die sich irgendwie (oder kommen die sich evtl. gar in die Queere)? Kurze Erläuterung dazu fände ich knorke.

Ansonsten sind da interessante Ideen und Ansätze dahinter, welche sich für mich aber teilweise nicht 1:1 umsetzen lassen, bzw. unnötig sind (bsp.: Wenn gelüftet wird, dann Fenster ganz auf, gekippt kommt quasi nicht vor. Wenn, dann eher Raumabhängig. Das ist aber eine individualisierungs Geschichte).

Danke und Gruß
Jorge

[Beta-User]

@Jorge:
Uff, ist schon eine Weile her, seit ich mich mit der notify-Version beschäftigt habe, daher nach bestem Wissen und Gewissen:

Die aktuellste Version auch der notify-myUtils-Version ist diese in dev-module-experimental. Soweit ich das im Kopf habe, sollte die auch - mit den korrekten attr-Namen - problemlos funktionieren. Eigentlich steht bei jeder Version dabei, wie das bzw. die notify aussehen müssen (als Kommentar oberhalb der jeweiligen Funktion; die heißt in der genannten Fassung wieder anders, Grund s.u.). Ich sollte evtl. das Repo bei Gelegenheit mal aufräumen, damit wieder alles zueinander paßt .

In der Version mit den 2 Funktionen kommen die sich an sich nicht in die Quere, weil man 2 notify braucht, die auf unterschiedliche Ereignisse derselben Devices reagieren, und dann - gut beobachtet - eigentlich fast dasselbe machen. Daher dann auch die Weiterentwicklung, das in eine Funktion zu packen und dann "modulkompatibel" umzubenennen (s.o., mehr Info hier). Hinweis: Es kann sein, dass die Attribute etwas anders/sprechender benannt sind, wären ggf. umzubenennen.

Im Prinzip sollte das auch so universell sein, dass Dein Ziel "Fenster auf -> Rolladen ganz auf" sich ohne weiteres damit umsetzen läßt, Du mußt ja nur den Fenster-offen-Level auf 100 setzen . Es ist damit sogar nicht nur auf Raum-Level individualisiert, sondern pro Fenster/Rolladen; das ganze ist sehr einfach einzustellen via Readingsgroup (code dafür ist auch irgendwo hier im Tread).

Ansonsten hast Du recht, das mit dem perl ist kein Hexenwerk, man muß "nur" wissen, auf welche Infos man sinnvollerweise zugreifen muß (und in welcher Reihenfolge die Dinge innerhalb FHEM abgearbeitet werden). Es ist wirklich überraschend, wie weit man ohne wirkliche Programmeirkenntnisse kommt...

Es wäre cool, wenn auch der Status eines zugeordneten Residents mit berücksichtigt werden könnte.
Also z.B. Rollo X automatisch runterfahren, sobald der Status des zugeordneten Residents auf "go to sleep" wechselt, spätestens aber automatisch um xx Uhr.
Oder Rollo Y automatisch hochfahren um xx Uhr, aber nicht wenn ein zugeordneter Resident (Guest) anwesend ist (z.B. fürs Gästezimmer).

Das mit dem "ich gehe ins Bett, mach den Rolladen zu" würde ich außerhalb dieser Art der Automatik lösen (egal, ob man das wie Frini löst oder über scripte). Den 2. Punkt - Gast ist da - würde ich irgendwann dann gerne so lösen, dass ich die "Automatik-Gruppe" des Rolladens dann auf "Manual" (oder eine andere Gruppe, wenn doch später "zwangsgeöffnet" werden soll) setze (per notify auf "Gast kommt/geht" oder manuell über eine weitere Readingsgroup).

Gruß, Beta-User

[Beta-User]

Die myUtils-Fassung mit dem einen notify habe ich heute morgen nochmal kurz getestet:

Das funktioniert soweit ersichtlich ganz ordentlich, ein "Problem" ist mir dabei aber noch aufgefallen: Macht man das Fenster zu, während der Rolladen wegen eines Tastendrucks (am Schalter) nach oben fährt, ging der Rolladen nicht weiter hoch, sondern nach unten auf "onHoldPostition". Daher habe ich noch ein paar diesbezügliche Abfragen reingebastelt um das zu verhindern. In der Hoffnung, auch diese Fälle noch in den Griff bekommen zu haben, ist das Ergebnis auf github daher jetzt im "master"-Zweig zu finden.

Selbst Testen kann ich das Ganze aber erst wieder heute abend, Mutige vor .

Gruß, Beta-User