FHEM Forum

Hallo zusammen,

ich arbeite mich in DOIF ein und habe das Waschmaschinen- und Ampel-Beispiel aus https://forum.fhem.de/index.php/topic,49109.0.html (https://forum.fhem.de/index.php/topic,49109.0.html) und https://forum.fhem.de/index.php/topic,49109.30.html (https://forum.fhem.de/index.php/topic,49109.30.html) nachgebaut. Die Ampel mit drei unabhängigen DOIFs ist schon ein Gehirnverzwirner...

Zur Übung habe ich eine Rollladensteuerung mit Dummies nachgestellt. Grundsätzliche Funktionen wie Aussperrschutz funktionieren, aber einiges fehlt noch. Der Code würde dadurch aber immer komplexer. https://wiki.fhem.de/wiki/DOIF/do_always_Alternative_am_Beispiel_einer_Rollladenautomatik (https://wiki.fhem.de/wiki/DOIF/do_always_Alternative_am_Beispiel_einer_Rollladenautomatik) geht mir noch nicht weit genug...

Ich würde gerne hören, wie ihr solch ein Problem angehen würdet? Tatsächlich jede einzelne Bedingungen im DOIF abbilden? Oder mehrere DOIFs wie bei der Ampel?

Oder als Zustandsautomat im Sinne von https://wiki.fhem.de/wiki/DOIF/Mehrfachnutzung_eines_Tasters (https://wiki.fhem.de/wiki/DOIF/Mehrfachnutzung_eines_Tasters)? Wobei auch diese Abbildung in einem DOIF komplex wird, da aus jedem Zustand (z.B. Rollladen unten/cmd=x) mehrere Aktionen zu beliebig anderen Zuständen führen können (z.B. Rollladen oben/cmd=y, Rolladen Lüften wenig/cmd=z, etc.), das wären dann viele Bedingungen in einem DOIF... Es gibt hier auch ein inoffzielles Modul für Zustandsautomaten: https://forum.fhem.de/index.php/topic,51796.0.html (https://forum.fhem.de/index.php/topic,51796.0.html)

Und hier der Beispielcode meiner Rollladensteuerung:
define timer_rollo dummy
attr timer_rollo room Test.Rollladen
attr timer_rollo setList auf zu
attr timer_rollo webCmd auf:zu
define tuer_re dummy
attr tuer_re room Test.Rollladen
attr tuer_re setList gekippt offen verschlossen
attr tuer_re webCmd gekippt:offen:verschlossen
define rollo_li dummy
attr rollo_li room Test.Rollladen
attr rollo_li setList unten oben
attr rollo_li webCmd unten:oben
define rollo_re dummy
attr rollo_re room Test.Rollladen
attr rollo_re setList unten oben irgendwo lueften_wenig lueften_viel stop
attr rollo_re webCmd unten:oben:irgendwo:lueften_wenig:lueften_viel:stop

define di_rolladensteuerung_2 DOIF ## autom. Schließen alle außer Tür-rechts, diese auf Lüften fahren, wenn gekippt\
([timer_rollo] =~ "zu" and [tuer_re] =~ "gekippt") \
(set rollo_li unten)\
(set rollo_re lueften_wenig)\
## autom. Schließen wenn Tür-rechts zu\
DOELSEIF ([timer_rollo] =~ "zu" and [tuer_re] =~ "verschlossen")\
(set rollo_li unten)\
(set rollo_re unten)\
## autom. Schließen wenn Tür-rechts offen\
DOELSEIF ([timer_rollo:"zu"] and [?tuer_re] !~ "verschlossen|gekippt")\
(set rollo_li unten)\
## autom. Lüften wenn Tür-rechts offen\
DOELSEIF ([timer_rollo] =~ "zu" and [tuer_re:"offen"] and [?rollo_re] =~ "lueften_wenig|lueften_viel|unten")\
(set rollo_re lueften_viel)\
## autom. Öffnen alle Rollos, wenn Tür-rechts gekippt oder geschlossen\
DOELSEIF ([timer_rollo:"auf"] and [tuer_re] =~ "gekippt|verschlossen") \
((set rollo_li,rollo_re oben))\
## autom. Öffnen alle Rollos, außer Tür-rechts wenn offen\
## wenn Rollladen rechts tiefer als Lüftern_wenig-Position, dann Öffnen bis Lüften_wenig,\
## sonst Rollladen rechts nicht fahren\
DOELSEIF ([timer_rollo:"auf"] and [tuer_re] !~ "gekippt|verschlossen") \
(set rollo_li oben)\
(IF ([rollo_re] !~ "lueften_wenig|unten") (set rollo_re lueften_wenig))\
## Lüften_wenig-Position\
DOELSEIF ([tuer_re:"gekippt"] and [?rollo_re] =~ "unten")\
(set rollo_re lueften_wenig)\
## Lüften_viel-Position\
DOELSEIF ([tuer_re:"offen"] and [?rollo_re] =~ "unten|lueften_wenig")\
(set rollo_re lueften_viel)\
## Schließen nach Lüften\
DOELSEIF ([tuer_re:"verschlossen"] and [?rollo_re] =~ "lueften_wenig|lueften_viel" and ([$SELF:cmd] == 7 or [$SELF:cmd] == 8))\
(set rollo_re unten)\

attr di_rolladensteuerung_2 checkall event
attr di_rolladensteuerung_2 room Test.Rollladen


Zitat von: spi3845 am 27 März 2017, 13:28:59Ich würde gerne hören, wie ihr solch ein Problem angehen würdet? Tatsächlich jede einzelne Bedingungen im DOIF abbilden? Oder mehrere DOIFs wie bei der Ampel?

Mein Vorgehen (im Laufe der Zeit hat diese sich erst ergeben, es existieren also noch alte Relikte :-[):
- für jeden Aktor existiert max. ein DOIF. Alles, was diesen Aktor betrifft, kommt da hinein.
- für "Zwischenergebnisse" kann es weitere DOIF geben. Entweder, weil sie im DOIF mehrfach gebraucht werden oder weil mehrere DOIF sie brauchen.
- ein DOIF kann auch mehrere Aktoren ansteuern, aber nie umgekehrt!

Nebenbei: außer den reinen Hardware-Devices verwende ich zu ~90% DOIF.

Zitat von: Per am 27 März 2017, 14:10:58
- für jeden Aktor existiert max. ein DOIF. Alles, was diesen Aktor betrifft, kommt da hinein.

Danke - und wie sehen die DOIFs aus (die neuen, nicht die Relikte ;))? Verkettest Du alle Bedingungen einander (so wie in meinem einfachen Beispiel) oder versuchst Du (schöne :) ) Zustandsautomaten abzubilden?

Mein erster Eindruck am Beispiel der Rollladensteuerung ist, dass bei jeder neuen Anforderung ein weiterer DOELSEIF-Zweig mit vielen Bedingungen dazu kommt und das ganze irgendwann nicht mehr pflegbar wird, weil der neue DOELSEIF-Zweig vielleicht noch an der falschen Stelle gelandet ist...

Ich bin quasi auf der Suche nach der Antwort, wie man funktionierenden, übersichtlichen und gut pflegbaren DOIF-Code erstellt.

versuche die ganze Problematik am besten Ereignis anstelle von Zustand gesteuert zu überdenken

Zitat von: spi3845 am 27 März 2017, 14:22:42
Ich bin quasi auf der Suche nach der Antwort, wie man funktionierenden, übersichtlichen und gut pflegbaren DOIF-Code erstellt.

Indem man ihn wegläßt. Macht die Sache sehr übersichtlich.

Zitat von: Wuppi68 am 27 März 2017, 14:30:19
versuche die ganze Problematik am besten Ereignis anstelle von Zustand gesteuert zu überdenken

Genau das war ja mein Ansatz in meinem Beispiel-Code. Nur führt das zu einer langen Verkettung von Bedingungen, da mehrere Ereignisse eintreten können, die abhängig verschiedener Zustände zu unterschiedlichen Ergebnissen führen. Ich hatte gehofft, es gäbe da noch irgend einen Trick, den ich in der Doku nicht gefunden habe...

Zitat von: betateilchen am 27 März 2017, 15:24:38
Indem man ihn wegläßt. Macht die Sache sehr übersichtlich.

:D und statt dessen? Voodoo?

Zitat von: spi3845 am 27 März 2017, 15:34:01
und statt dessen? Voodoo?

nein, die dafür originär implementierten Möglichkeiten wie notify und echtes perl nutzen.

Zitat von: betateilchen am 27 März 2017, 15:43:49
nein, die dafür originär implementierten Möglichkeiten wie notify und echtes perl nutzen.

Warum nicht gleich Assembler oder gar Machinencode? Notify und Perl doch für dich auch nur "Krücken" sein, oder?

Zitat von: betateilchen am 27 März 2017, 15:43:49
nein, die dafür originär implementierten Möglichkeiten wie notify und echtes perl nutzen.

Was kann notify was DOIF nicht kann? Das ginge doch dann in die Richtung mehrerer DOIFs parallel - so wie beim Ampel-Beispiel.

Zitat von: spi3845 am 27 März 2017, 15:56:09
Was kann notify was DOIF nicht kann?

Darum geht es nicht. betateilchen ist bekennender DOIF-Hasser. Und das versucht er gern auch mal an unpassender Stelle loszuwerden. Also lass dich nicht davon beirren.

Deiner Frage nach den Automaten oder Verkettungen: wo ist da die Grenze, ich bin kein gelernter Programmierer (obwohl ich schon den Z8 mit Assembler bearbeitet habe), ich entscheide sowas eher pragmatisch von Fall zu Fall. Wenn du einen Extrem-Fall als Standard definierst, wirst du irgendwann eine Anwendung finden, bei der das andere Extrem einen Zweizeiler, deine Wahl hingegen eine halbe Seite Code erfordert (Übertreibung macht anschaulich ;)).

Oute mich mal auch als bekennender DOIF-Skeptiker...

Zitat von: spi3845 am 27 März 2017, 15:56:09
Was kann notify was DOIF nicht kann? Das ginge doch dann in die Richtung mehrerer DOIFs parallel - so wie beim Ampel-Beispiel.

DOIF ist ein sehr komplexes Werkzeug, das aber eben den Nachteil hat, dass man genau diese Komlexität gerne übersieht. Darauf zielt nach meinem Eindruck auf Wuppie68 ab:

Zitat von: Wuppi68 am 27 März 2017, 14:30:19
versuche die ganze Problematik am besten Ereignis anstelle von Zustand gesteuert zu überdenken

Mit einem notify (das übrigens zusammen mit at vermutlich der älteste und damit "härteste" Bestandteil von FHEM ist), reagiert man eben auf ein Ereignis und kann dann ggf. mit einfachen (perl-) if Abfragen genau die Frage nach dem aktuellen Zustand diverser (nicht-DOIF)-devices klären und daran anknüpfend dann eben genau die Reaktion auf das Ereignis auswählen, die jetzt angezeigt ist.

Sofern man Hilfsinformationen braucht, sind die nach meinen (begrenzten) Verständnis am einfachsten als userReadings bei den devices abzulegen. Das ganze ist dann nicht assembler, sondern kann recht stringenter code sein, der (als perl, klar, aber mindestens) ebenso gut zu verdauen ist als ein DOIF mit einer Vielzahl von attr., bei denen jedenfalls ich niemals verstehen werde, welche Kombination jetzt auf meinen Fall Sinn macht.

m.E. gelungenes Beispiel für perl und userreadings: Bennis globale Tür-offen-Meldung (https://forum.fhem.de/index.php/topic,36504.0.html).

@betateilchen:
Bei Gelegenheit wollte ich mal eine Userreading-basierte Rolladenautomatik angehen, da gibt es leider bislang wohl nur halbgare Ansätze. Kann ich da irgendwo im Forum was finden, was mir hilft, mein (vermutlich (!) nach der commandref gebasteltes) DOIF-Konstrukt loszuwerden?

Nix für ungut,
ein weiterer DOIF-geschädigter Beta-User

PS: Wer so einen Titel wählt, braucht sich über Anworten wie meine und betateilchens nicht wundern und: Laßt das Popcorn auf der Seite, in großen Mengen ist es nicht gesund...

Zitat von: Per am 27 März 2017, 16:12:02
wo ist da die Grenze, ich bin kein gelernter Programmierer (obwohl ich schon den Z8 mit Assembler bearbeitet habe), ich entscheide sowas eher pragmatisch von Fall zu Fall. Wenn du einen Extrem-Fall als Standard definierst, wirst du irgendwann eine Anwendung finden, bei der das andere Extrem einen Zweizeiler, deine Wahl hingegen eine halbe Seite Code erfordert (Übertreibung macht anschaulich ;)).

Den Eindruck einer halben Seite hatte ich nach dem Codieren des (einfachen) Rollladenbeispiels. Daher die Frage nach alternativen Ansätzen.

Zitat von: Beta-User am 27 März 2017, 16:36:05
Mit einem notify (das übrigens zusammen mit at vermutlich der älteste und damit "härteste" Bestandteil von FHEM ist), reagiert man eben auf ein Ereignis und kann dann ggf. mit einfachen (perl-) if Abfragen genau die Frage nach dem aktuellen Zustand diverser (nicht-DOIF)-devices klären und daran anknüpfend dann eben genau die Reaktion auf das Ereignis auswählen, die jetzt angezeigt ist.

Mit einem Notify wird man ja dann bei unterschiedlichen Ereignissen nicht auskommen. Ist die Analogie dazu nicht "mehrere DOIFs"? Mir ist es am Ende egal, ob ich notify oder DOIF nutze, ich will nur die Vor-/Nachteile ausloten...

Zitat von: Beta-User am 27 März 2017, 16:36:05Das ganze ist dann nicht assembler, sondern kann recht stringenter code sein, der (als perl, klar, aber mindestens) ebenso gut zu verdauen ist als ein DOIF mit einer Vielzahl von attr., bei denen jedenfalls ich niemals verstehen werde, welche Kombination jetzt auf meinen Fall Sinn macht.

Urgh, so geht's mir auch nach dem Rollladen-Beispiel...

Zitat von: Beta-User am 27 März 2017, 16:36:05Bei Gelegenheit wollte ich mal eine Userreading-basierte Rolladenautomatik angehen, da gibt es leider bislang wohl nur halbgare Ansätze. Kann ich da irgendwo im Forum was finden, was mir hilft, mein (vermutlich (!) nach der commandref gebasteltes) DOIF-Konstrukt loszuwerden?

Da würde ich gerne mitmachen...

Zitat von: Beta-User am 27 März 2017, 16:36:05PS: Wer so einen Titel wählt, braucht sich über Anworten wie meine und betateilchens nicht wundern

Passt, ich wollte eine Diskussion, jetzt habe ich eine Diskussion.

Zitat von: spi3845 am 27 März 2017, 17:11:37
Mit einem Notify wird man ja dann bei unterschiedlichen Ereignissen nicht auskommen. Ist die Analogie dazu nicht "mehrere DOIFs"? Mir ist es am Ende egal, ob ich notify oder DOIF nutze, ich will nur die Vor-/Nachteile ausloten...

Kommt drauf an. Man kann für dieselbe Reaktion bei beiden Modulen (DOIF und notify) ja auswählen, auf welche Bedingungen reagiert werden soll, bei notify aber halt "nur" im Sinne von "...oder .... oder ... oder" als (alternative) Eingangsbedingungen (bei DOIF geht es auch "weiter hinten" irgendwo in einem else-Zweig). Bei Notify muß man es "hinterher" erledigen, Dinge rauszufiltern, auf die man jetzt halt doch nicht reagieren will.

Zu den Vor und Nachteilen: Mir war es bei meinen FHEM-Anfängen auch mal egal, welches Modul ich nutze, und DOIF war wirklich super-universell. Leider habe ich im Lauf der Zeit zunehmend das Gefühl, dass meine DOIF's entweder komplizierte Varianten von einfacheren Lösungen sind/waren (notify mit einfachem if hintendran, threshold, weekdaytimer) oder irgendwann nicht mehr so reagieren, wie ich das erwartete (und es vermutlich auch mal funktioniert hat). Ich halte es daher für überkomplex und daher für die Zukunft weiterhin fehleranfällig, aber das ist meine persönliche Meinung. Ich habe daher gut die Hälfte meiner DOIF's aus der ersten Phase zwischenzeitlich in andere Lösungen überführt.

notify/at ist erprobt, das wird so schnell nicht ins Wanken geraten. Und ich bin ziemlich sicher, dass daran anknüpfender guter perl-Code auch in 20 Jahren noch zuverlässig seinen Dienst tun wird und nicht das Nachpflegen irgendwelcher attr brauchen wird.

Soviel zu den Vor- und Nachteilen, die ich sehe (aber nochmal: ich kann's eigentlich nicht beurteilen, das ist reinstes Bauchgefühl).

Vermutlich wird man bei einer vernünftigen Rollandensteuerung aber nicht umhin kommen, mehrere Bausteine (notify/at,ggf. weekdaytimer mit perl bzw. alternativ DOIF) zu kombinieren. Die sollten dann aber einen klaren Zweck bzw. Auslöser haben, dann dürfte das nicht zu unübersichtlich werden.

Zitat von: spi3845 am 27 März 2017, 17:11:37
Urgh, so geht's mir auch nach dem Rollladen-Beispiel...

...eine Zeitlang habe ich geglaubt, es läge an mir, warum ich das alles nicht auf die Reihe bekomme :'(, aber dann habe ich einige threads gesehen, bei denen sich die Macher schon nicht einig waren, in welcher Kombination jetzt welche attr Snn machen und ob es eine DOELSE braucht 8). (Nur zur Klarstellung: Der Ansatz ist löblich, aber ich bin kein Programmierer und damit überfordert, und obigen Verdacht werde ich in diesem Leben nicht mehr loswerden, dafür komme ich zwischenzeitlich mit C-Code klar (DOIF goes Arduino 8)), jetzt ist dann halt perl an der Reihe).

Zitat von: spi3845 am 27 März 2017, 17:11:37
Da würde ich gerne mitmachen...

Ich bin kein Programmierer, daher wird das kein Spaß ;).
Es ist Dein Thread. Wenn es kein DOIF mehr sein soll, dann verschiebe den Beitrag und ich bin mit meinen bescheidenen Kenntnissen dabei (oder mache einen neuen auf). Ich habe HM-Hardware (Tri-State Fenstersensoren, UP-Rolladen)...
Bei Interesse kann ich gerne meine Gendanken mal zu Papier bringen, was an Elementen m.E. so zweckmäßig wäre, aber wie gesagt: Eigentlich habe ich keine Ahnung, wie man "sowas" angeht.

Zitat von: spi3845 am 27 März 2017, 17:11:37
Passt, ich wollte eine Diskussion, jetzt habe ich eine Diskussion.

Mach' das nicht zu oft, es macht keinen Sinn, die Leute hier gegeneinander aufzubringen!

Jeder hier tut, was er für gut, zielführend und richtig hält. Es ist open (source...)

Zitat von: Beta-User am 27 März 2017, 17:43:50
Und ich bin ziemlich sicher, dass daran anknüpfender guter perl-Code auch in 20 Jahren noch zuverlässig seinen Dienst tun wird und nicht das Nachpflegen irgendwelcher attr brauchen wird.

Bin schon am Testen von notify statt DOIF...

Zitat von: Beta-User am 27 März 2017, 17:43:50
Ich habe HM-Hardware (Tri-State Fenstersensoren, UP-Rolladen)...
Bei Interesse kann ich gerne meine Gendanken mal zu Papier bringen, was an Elementen m.E. so zweckmäßig wäre, aber wie gesagt: Eigentlich habe ich keine Ahnung, wie man "sowas" angeht.

So geht's mir auch. Und was daraus geworden ist, ist das Code-Beispiel oben...

Zitat von: Beta-User am 27 März 2017, 17:43:50
Mach' das nicht zu oft, es macht keinen Sinn, die Leute hier gegeneinander aufzubringen!

Dar war nicht mein Ziel, Leute gegeneinander aufzubringen. Nur zu verstehen, welche Vor- und Nachteile unterschiedliche Vorgehensweisen haben. Sollte ich jemandem auf die Füße getreten sein - mea culpa. Und danke allen für das Teilen ihrer Ideen...

Zitat von: Beta-User am 27 März 2017, 16:36:05
Bei Gelegenheit wollte ich mal eine Userreading-basierte Rolladenautomatik angehen, da gibt es leider bislang wohl nur halbgare Ansätze. Kann ich da irgendwo im Forum was finden, was mir hilft, mein (vermutlich (!) nach der commandref gebasteltes) DOIF-Konstrukt loszuwerden?

Kennst Du das? https://wiki.fhem.de/wiki/ROLLO

Zitat von: Beta-User am 27 März 2017, 16:36:05
@betateilchen:
Bei Gelegenheit wollte ich mal eine Userreading-basierte Rolladenautomatik angehen,

userreadings kommen in der Grusligkeits-Hitliste bei mir direkt nach DOIF & Consorten.

In meiner FHEM Installation gibt es keine userreadings - mir ist einfach noch keine sinnvolle Anwendungsmöglichkeit (geschweige denn Notwendigkeit) begegnet.

Zitat von: betateilchen am 27 März 2017, 18:45:24
In meiner FHEM Installation gibt es keine userreadings - mir ist einfach noch keine sinnvolle Anwendungsmöglichkeit (geschweige denn Notwendigkeit) begegnet.

Gaszähler liefert Daten in m³, du möchtest jedoch lieber Readings als kWh. Wie machst du das?

Zitat von: vbs am 27 März 2017, 18:53:24
Gaszähler liefert Daten in m³, du möchtest jedoch lieber Readings als kWh. Wie machst du das?

Ich würde die Umrechnung vermutlich bereits in dem Modul vornehmen, von dem die readings erzeugt werden.
Falls das nicht geht, würde ich die Werte genau zu dem Zeitpunkt umrechnen, zu dem ich sie benötige. Mache ich auch bisher schon in verschiedenen Anwendungsszenarien.

Zitat von: betateilchen am 27 März 2017, 18:45:24
In meiner FHEM Installation gibt es keine userreadings - mir ist einfach noch keine sinnvolle Anwendungsmöglichkeit (geschweige denn Notwendigkeit) begegnet.

Hast Du mir ein Stichwort, wie man "sowas" sonst zweckmäßigerweise angeht?
Irgendwie/irgendwo muß ja z.B. stehen, wann ein Rolladen aufzumachen ist. (Ja, at und weekdaytimer kenne ich, aber ich will ja nicht jedesmal das at ändern, wenn ich einen bestimmten Rolladen einer anderen Gruppe zuordnen will. Structure würde dieses Problem m.E. auch nur verlagern). Mit readings ließe sich die grafische Darstellung via readingsgroup (für die wenigen Änderungen, die erfahrungsgemäß halt hin und wieder notwendig sind) recht einfach erledigen. Aber wie bereits mehrfach betont: Ich bin perl-mäßig sowas von unbeleckt...

@spi3845:
ROLLO kenne ich, aber das scheint von einer sehr speziellen HW-Voraussetzung auszugehen und dann schwerpunktmäßig den Umgang damit abzudecken. Aber vielleicht habe ich was übersehen...
Wenn Dein Projekt jetzt eher kein DOIF mehr ist, verschiebe doch bitte den Beitrag unter anderer Bezeichnung (z.B.: Rolladensteuerung: Alternativen zu DOIF) nach Automatisierung.

Was die Userreadings angeht vielleicht noch zur Erläuterung, an was ich auf die Schnelle gedacht hätte (lasse mich aber gerne belehren, wie das alles besser geht):

Reading   Werte   Bemerkungen
AutoMode   Manual, AutoSingle, Group1, Group2, Group3   
AutoSingle7upStart      
AutoSingle8upStart      
AutoSingle7upEnd      
AutoSingle8upEnd      
      
WindowContactAssociated      
WindowContactOpenMaxClosed      
WindowContactOnHoldState   on, off   für notify bei Schließen: automatisch vollends schließen (oder öffnen?)

wir sind hier langsam ziemlich offtopic

Zitat von: Beta-User am 27 März 2017, 19:04:37
Was die Userreadings angeht vielleicht noch zur Erläuterung, an was ich auf die Schnelle gedacht hätte (lasse mich aber gerne belehren, wie das alles besser geht):

Reading   Werte   Bemerkungen
AutoMode   Manual, AutoSingle, Group1, Group2, Group3   
AutoSingle7upStart      
AutoSingle8upStart      
AutoSingle7upEnd      
AutoSingle8upEnd      
      
WindowContactAssociated      
WindowContactOpenMaxClosed      
WindowContactOnHoldState   on, off   für notify bei Schließen: automatisch vollends schließen (oder öffnen?)

Kannst Du kurz erläutern, welche Zustände diese userreadings darstellen sollen? Wenn ich nach AutoSingle7upEnd google, kommt als einziger Fund "Bildhübsche Polinnen". Hm.

Vielleicht ganz kurz zum ROLLO Modul. Dem Teil gibt man die Befehle für hoch/runter und ggf. stop mit. Damit dürfte sich so ziemlich jeder Rollladen steuern lassen. Zusätzlich kann man einen ROLLO blocken - mache ich z.B. wenn Türe offen. Wenn man die Gesamtlaufzeit mitgibt berechnet ROLLO näherungsweise 10% Schritte, ich kann also z.B. auf 30% stellen. Bei mir hängen die ROLLOs in verschiedenen Structures, so kann ich einzelne Zimmer, Himmelsrichtungen oder Etagen gemeinsam schalten.

Auf die schnelle eine kleine Grafik, was ich mir unter einer einfachen Rollladensteuerung vorstelle.

Aus Vereinfachungsgründen habe ich Zustände wie "Rollo fährt runter" weggelassen, genauso an vielen Stellen "manuell hoch/runter" sowie "an irgendeiner Position gestoppt (!=0%|10%|30%|100%).

Bin gespannt, was ihr für Ideen habt, um was das noch ergänz werden könnte (Wärme-/Windschutz etc.). Mein Codebeispiel am Anfang gibt das als DOIF einigermaßen wieder, aber wie gesagt, halte ich das als DOIF auf Dauer für zu komplex.

Wenn man das wiederverwendbar codieren möchte, wird man je Tür/Fenster einige Parameter speichern müssen (z.B. bei offener Tür Rollo hoch-/runterfahren ja/nein, Lüftungspositionen, zugeordnete Fensterkontakte etc.).

Das Bild macht es recht anschaulich, was du erreichen willst... (Ich hab mir deinen DOIF Code nie wirklich genau angesehen)... Die Komplexität liegt darin, dass du einer grundsätzlich anderen Lüft-Philosophie folgst als ich ;-) Bei mir gibt es Lüften - dann ist alles auf und zwar richtig, oder nicht lüften - dann ist alles zu. Aber davon mal abgesehen:

Im Grunde hast du drei Zustände, die du auswerten musst und die bekannt sind:
* der Staus des Rollladens (den sollte der Rollladen kennen)
* den Status der Tür (den kennt die Tür)
* den Status des Timers (den kennt der Timer)

und du hast Events:
* Ein Zeitpunkt ist eingetreten (at oder DOIF)
* Der Rolladen wird manuell geschaltet (notify oder DOIF)
* Der Zustand der Tür wird geändert (notify oder DOIF)

Die Statusübergänge hast du ja schön dargestellt, also kannst du jetzt bei jedem Event deine 3 Zustände ermitteln und den entsprechenden Statusübergang anstoßen. Ob du das per at/notify oder DOIF machst und ob du ein oder viele DOIFs nutzt oder ob du eine Perl-Sub aufrufst oder ein python script, bleibt letztendlich dir überlassen.

Ich persönlich würde:
* die 3 Events getrennt behandeln (beim Event "die Sonne geht unter" willst du vielleicht noch ein Licht anschalten)
* die Verarbeitung in eine perl sub auslagern
Ich bin jetzt nicht der Perl_Profi, aber mit einem multidimensionalem Hash liesse sich dann irgendwie sowas bauen:
my %ctrl ;
$ctrl{"Rollo"}{100}{tilted}{true}{close} = "set $name 30pct";
zu lesen als: Ein event auf "Rollo", Rollo ist auf 100%, Tür ist "tilted", Timer hat die Rolläden schon runtergefahren, aktuelles Kommando ist "close", also setzte Rollo auf 30%.

nur so ein Gedanke...

@spi3845
Zu Deinem Bild: Für Deine Rollandesteuerung könntest Du bei HM auch mein "Lasse die Jalousie oberhalb eines bestimmten Levels, wenn die Tür geöffnet ist/wird" etwas erweitern (weitere Eingangsbedingung, eine weitere Abfrage wg. des Ziellevels).
defmod Automatik_Terrassentuer_Jalousie notify Jalousie_Mitte:leve.*|Terrassentuer_EZ:ope.* IF ( [Jalousie_Mitte:level] < 55) and [Terrassentuer_EZ:state] eq "open") (set Jalousie_Mitte 60)
attr Automatik_Terrassentuer_Jalousie group Türen und Fenster
attr Automatik_Terrassentuer_Jalousie icon fts_shutter_automatic
attr Automatik_Terrassentuer_Jalousie room Esszimmer

Zu meinen Userreadings:
Hatte weniger an hübsche Osteuropäerinnen gedacht 8), 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).

@KernSani
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 (?).
Was das Coding angeht, hatte ich mir das so ähnlich vorgestellt, nur, dass eben der set-Befehl (bzw. die %-Angabe) aus den Userreadings vorher hergeleitet wird. Hoffe, das ist jetzt halbwegs nachvollziehbar dargestellt.

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

Gruß, Beta-User

Ich habe meine Rolloautomatik auch per DOIF geschrieben. Die Automatik greift am Ende auf das ROLLO Modul zu und wird über mehrere Dummies über eine ReadingsGroup mit den entsprechenden Parametern versorgt.

Anbei mal ein Screenshot von der ReadingsGroup. Ich hätte gern noch anstelle der Dropdowns für EIN/AUS bzw. Hand/Auto entsprechende "klickbare" Icons in der ReadingsGroup, hab es aber aktuell noch nicht hin bekommen.

Aktueller Stand: Test über die Dummys... die Reale Hardware ist noch nicht gekoppelt.. das mache ich mal an einem Wochenende.

Bei Fragen bzw. Verbesserungsvorschlägen einfach schreiben.. Danke.

@lenoxef:
Die ReadingsGroup sieht nicht übel aus, mir schwebt was ähnliches vor.

Dabei würde ich die 3 Gruppen, von denen ich oben gesprochen hatte (Group1, Group2, Group3) ggf. noch mit aufnehmen zur Parametrierung. Tendenz wäre jeweils als structure (Problem dabei ist, dass jeder Rollanden ausschließlich in einer der Gruppen sein sollte, muß mal checken, ob ich das (für mich praktikabel) gelöst bekomme).

Ansonsten wäre evtl. interessant, wie das/die DOIF und Dummies im Detail aussehen, und wo (außer der möglicherweise etwas hübscheren Darstellung) der Vorteil z.B. zu weekdaytimer liegt (siehe https://forum.fhem.de/index.php/topic,23655.msg206907.html#msg206907 und https://forum.fhem.de/index.php/topic,27247.0.html)?

...das Ganze sieht so aus.. Wenn jemand eine Idee hat wie das Codesparender gemacht werden kann, immer her damit.

# ToDo: Rollo nicht runter fahren wenn entsprechendes Fenster geöfnet ist (Ein/Ausschaltbar)
# ToDo: Testen Testen Testen
# Todo: Funktion von der SPS nach FHEM verlagern

################################################################################################################################################
####################################################### Rollo 1 ################################################################################
################################################################################################################################################

# Rollo Dummy runter
define Rollo_Dummy_1_runter dummy
attr Rollo_Dummy_1_runter alias Rollo Dummy 1 runter
attr Rollo_Dummy_1_runter event-on-change-reading state
attr Rollo_Dummy_1_runter room Rollo

# Rollo Dummy hoch
define Rollo_Dummy_1_hoch dummy
attr Rollo_Dummy_1_hoch alias Rollo Dummy 1 hoch
attr Rollo_Dummy_1_hoch event-on-change-reading state
attr Rollo_Dummy_1_hoch room Rollo

define Rollo_Dummy_1 ROLLO
attr Rollo_Dummy_1 automatic-enabled on
attr Rollo_Dummy_1 devStateIcon offen:fts_shutter_10:geschlossen geschlossen:fts_shutter_100:offen schlitz:fts_shutter_80:geschlossen drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:offen position-90:fts_shutter_80:geschlossen position-80:fts_shutter_80:geschlossen position-70:fts_shutter_70:geschlossen position-60:fts_shutter_60:geschlossen position-50:fts_shutter_50:geschlossen position-40:fts_shutter_40:offen position-30:fts_shutter_30:offen position-20:fts_shutter_20:offen position-10:fts_shutter_10:offen position-0:fts_shutter_10:geschlossen
attr Rollo_Dummy_1 device 1
attr Rollo_Dummy_1 drive-down-time-to-100 5
attr Rollo_Dummy_1 drive-up-time-to-100 7
attr Rollo_Dummy_1 funktionsweise Typ2
attr Rollo_Dummy_1 genericDeviceType blind
attr Rollo_Dummy_1 homebridgeMapping CurrentPosition=invert=1 TargetPosition=invert=1
attr Rollo_Dummy_1 kanal1 Rollo_Dummy_1_hoch
attr Rollo_Dummy_1 kanal2 Rollo_Dummy_1_runter
attr Rollo_Dummy_1 room Rollo
attr Rollo_Dummy_1 webCmd offen:geschlossen:schlitz:position

# Schalter für die Automatik generell -> Als Bedingung über alles
define Rollo_Dummy_1_Automatik_Schalter dummy
attr Rollo_Dummy_1_Automatik_Schalter alias Rollo 1
attr Rollo_Dummy_1_Automatik_Schalter devStateIcon Auto:fts_shutter_automatic Hand:fts_shutter_manual
attr Rollo_Dummy_1_Automatik_Schalter room Rollo
attr Rollo_Dummy_1_Automatik_Schalter setList state:Auto,Hand
attr Rollo_Dummy_1_Automatik_Schalter webCmd Auto:Hand

# Zeit, wann das Rollo Mo-Fr hoch fahren soll
define Rollo_Dummy_1_Werktags_hoch_Zeit dummy
attr Rollo_Dummy_1_Werktags_hoch_Zeit room Rollo
attr Rollo_Dummy_1_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

# Zeit, wann das Rollo Mo-Fr runter fahren soll -> wenn "Rollo_Dummy_1_Daemmerung_Schalter" eq "off" -> sonst per Dämmerungssensor
define Rollo_Dummy_1_Werktags_runter_Zeit dummy
attr Rollo_Dummy_1_Werktags_runter_Zeit room Rollo
attr Rollo_Dummy_1_Werktags_runter_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

#Position auf die das Rollo Mo-Fr runter fahren soll -> wenn "Rollo_Dummy_1_Daemmerung_Schalter" eq "off" -> sonst auf die Position "Rollo_Dummy_1_Daemmerung_Position"
define Rollo_Dummy_1_Werktags_runter_Position dummy
attr Rollo_Dummy_1_Werktags_runter_Position room Rollo
attr Rollo_Dummy_1_Werktags_runter_Position setList state:0,10,20,30,40,50,60,70,80,90,100

# Zeit, wann das Rollo in Sa+So hoch fahren soll
define Rollo_Dummy_1_Wochenende_hoch_Zeit dummy
attr Rollo_Dummy_1_Wochenende_hoch_Zeit room Rollo
attr Rollo_Dummy_1_Wochenende_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

# Zeit, wann das Rollo in Sa+So runter fahren soll -> wenn "Rollo_Dummy_1_Daemmerung_Schalter" eq "off" -> sonst per Dämmerungssensor
define Rollo_Dummy_1_Wochenende_runter_Zeit dummy
attr Rollo_Dummy_1_Wochenende_runter_Zeit room Rollo
attr Rollo_Dummy_1_Wochenende_runter_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

#Position auf die das Rollo Sa+So runter fahren soll -> wenn "Rollo_Dummy_1_Daemmerung_Schalter" eq "off" -> sonst auf die Position "Rollo_Dummy_1_Daemmerung_Position"
define Rollo_Dummy_1_Wochenende_runter_Position dummy
attr Rollo_Dummy_1_Wochenende_runter_Position room Rollo
attr Rollo_Dummy_1_Wochenende_runter_Position setList state:0,10,20,30,40,50,60,70,80,90,100

# Schalter für die Sonnenschutzfunktion
define Rollo_Dummy_1_Sonnenschutz_Schalter dummy
attr Rollo_Dummy_1_Sonnenschutz_Schalter room Rollo
attr Rollo_Dummy_1_Sonnenschutz_Schalter setList state:Ein,Aus
attr Rollo_Dummy_1_Sonnenschutz_Schalter webCmd Ein:Aus

# Zeit, wann das Rollo wieder hoch fahren soll
define Rollo_Dummy_1_Sonnenschutz_hoch_Zeit dummy
attr Rollo_Dummy_1_Sonnenschutz_hoch_Zeit room Rollo
attr Rollo_Dummy_1_Sonnenschutz_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

# Zeit, wann das Rollo zum Sonnenschutz runterfahren soll
define Rollo_Dummy_1_Sonnenschutz_runter_Zeit dummy
attr Rollo_Dummy_1_Sonnenschutz_runter_Zeit room Rollo
attr Rollo_Dummy_1_Sonnenschutz_runter_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

# Position für Sonnenschutz zB 70%
define Rollo_Dummy_1_Sonnenschutz_Position dummy
attr Rollo_Dummy_1_Sonnenschutz_Position room Rollo
attr Rollo_Dummy_1_Sonnenschutz_Position setList state:0,10,20,30,40,50,60,70,80,90,100

# Schalter legt fest, ob das Rollo anstelle der in "Rollo_Dummy_1_????_runter_Zeit" eingestellten Zeit runterfahren soll wenn der Daemmerungssensor ausloest
define Rollo_Dummy_1_Daemmerung_Schalter dummy
attr Rollo_Dummy_1_Daemmerung_Schalter room Rollo
attr Rollo_Dummy_1_Daemmerung_Schalter setList state:Ein,Aus
attr Rollo_Dummy_1_Daemmerung_Schalter webCmd Ein:Aus

# Zeit, um die nach ausloesen des Daemmerungssensors verzoegert wird um das Rollo runter zu fahren
define Rollo_Dummy_1_Daemmerung_Verzoegerung_Zeit dummy
attr Rollo_Dummy_1_Daemmerung_Verzoegerung_Zeit room Rollo
attr Rollo_Dummy_1_Daemmerung_Verzoegerung_Zeit setList state:0,10,20,30,40,50,60,70,80,90,100,110,120

# Position auf die das Rollo bei Daemmerung fahren soll
define Rollo_Dummy_1_Daemmerung_Position dummy
attr Rollo_Dummy_1_Daemmerung_Position room Rollo
attr Rollo_Dummy_1_Daemmerung_Position setList state:0,10,20,30,40,50,60,70,80,90,100

# Die eigentliche Automatik...(Zeitgesteuertes Hoch und Runterfahren, Daemmerungsautomatik, Beschattungsautomatik,...)

define DOIF_Rollo_Dummy_1 DOIF ([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [([Rollo_Dummy_1_Werktags_hoch_Zeit]+[00:00])-([Rollo_Dummy_1_Werktags_hoch_Zeit]-[00:01])|0123456]) (set Rollo_Dummy_1 position 0)\
DOELSEIF\
([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [([Rollo_Dummy_1_Wochenende_hoch_Zeit]+[00:00])-([Rollo_Dummy_1_Wochenende_hoch_Zeit]-[00:01])|78]) (set Rollo_Dummy_1 position 0)\
DOELSEIF\
([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [Rollo_Dummy_1_Daemmerung_Schalter] eq "Aus" and [([Rollo_Dummy_1_Werktags_runter_Zeit]+[00:00])-([Rollo_Dummy_1_Werktags_runter_Zeit]-[00:01])]) (set Rollo_Dummy_1 position [Rollo_Dummy_1_Werktags_runter_Position])\
DOELSEIF\
([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [Rollo_Dummy_1_Daemmerung_Schalter] eq "Aus" and [([Rollo_Dummy_1_Wochenende_runter_Zeit]+[00:00])-([Rollo_Dummy_1_Wochenende_runter_Zeit]-[00:01])]) (set Rollo_Dummy_1 position [Rollo_Dummy_1_Wochenende_runter_Position])\
DOELSEIF\
([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [Rollo_Dummy_1_Daemmerung_Schalter] eq "Ein" and [Daemmerungssensor] eq "on") (set Rollo_Dummy_1 position [Rollo_Dummy_1_Daemmerung_Position])\
DOELSEIF\
([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [Rollo_Dummy_1_Sonnenschutz_Schalter] eq "Ein" and [([Rollo_Dummy_1_Sonnenschutz_runter_Zeit]+[00:00])-([Rollo_Dummy_1_Sonnenschutz_runter_Zeit]-[00:01])]) (set Rollo_Dummy_1 position [Rollo_Dummy_1_Sonnenschutz_Position])\
DOELSEIF\
([Rollo_Dummy_1_Automatik_Schalter] eq "Auto" and [Rollo_Dummy_1_Sonnenschutz_Schalter] eq "Ein" and [([Rollo_Dummy_1_Sonnenschutz_hoch_Zeit]+[00:00])-([Rollo_Dummy_1_Sonnenschutz_hoch_Zeit]-[00:01])]) (set Rollo_Dummy_1 position 0)\

attr DOIF_Rollo_Dummy_1 room Rollo
attr DOIF_Rollo_Dummy_1 wait 0:0:0:0:[Rollo_Dummy_1_Daemmerung_Verzoegerung_Zeit]:0:0
#Verzoegert den 5. Teil des DOIFs um die Zeit "Rollo_Dummy_1_Daemmerung_Verzoegerung_Zeit"

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:

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

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.

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)

Zitat von: lenoxef am 29 März 2017, 13:15:17
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 ::).

Zitat von: lenoxef am 29 März 2017, 13:15:17
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

Zitat von: Joker am 29 März 2017, 13:24:42
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

ZitatWas 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"?

Zitat von: lenoxef am 29 März 2017, 13:38:05
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 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:
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".

Zitat von: Beta-User am 29 März 2017, 13:30:49
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.

Zitat von: Joker am 29 März 2017, 14:00:06
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:

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:

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

Zitat von: lenoxef am 29 März 2017, 13:38:05
ich denke mein Problem ist viel trivialer. Wie bekomme ich das Reading "Werktags_hoch_Zeit" zum "Rollo_Dummy_1"?


setreading Rollo_Dummy_1 Werktags_hoch_Zeit 08:15

Meinst Du das?
Gruß,
   Thorsten

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:
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:
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:
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":
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:
{ winShutterAssociate("Fenster_Wohnzimmer_SSW","Rolladen_WZ_SSW",10) }


Beispiel für die neuen/zusätzlichen Attribute:
- Fensterkontakt:
attr Fenster_Wohnzimmer_SSW userattr ShutterAssociated
attr Fenster_Wohnzimmer_SSW ShutterAssociated Rolladen_WZ_SSW

- Rolladen
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 (https://forum.fhem.de/index.php/topic,61844.0.html)" 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 :D.

Gruß, Beta-User

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

Zitat von: Beta-User am 28 März 2017, 07:47:18
Zu meinen Userreadings:
Hatte weniger an hübsche Osteuropäerinnen gedacht 8), 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...)

Zitat von: Beta-User am 28 März 2017, 07:47:18
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 (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
R-driveDown 35.5 s
R-driveTurn 0.5 s
R-driveUp 43 s

Zitat von: Beta-User am 28 März 2017, 07:47:18
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?

Zitat von: Joker am 29 März 2017, 13:24:42
Also meine Rolladensteuerung setzt vor allem auf perl-Code, notifys und dummies.

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

Zitat von: Beta-User am 03 April 2017, 11:40:37
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...

Zitat von: Beta-User am 03 April 2017, 11:40:37
- Was die zukünftige Pflege des ganzen angeht, gab es im Beitrag "Rollosteuerung für große Installationen (https://forum.fhem.de/index.php/topic,61844.0.html)" 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

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

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.

Zitat von: Beta-User am 04 April 2017, 08:10:18
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.

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

Hi Joker,

Danke für die Rückmeldung.

Den Ansatz

Zitat von: Joker am 04 April 2017, 12:24:40
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.

Zitatmodulname_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 (https://forum.fhem.de/index.php/topic,67106.msg584822.html#msg584822), dass sowas wirklich nicht zu exisiteren scheint und schon das Parametrieren und Speichern von Infos (https://forum.fhem.de/index.php/topic,68310.msg597944.html#msg597944) 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

Zitat von: Beta-User am 03 April 2017, 11:40:37
- 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 ..."?

Zitat von: Beta-User am 03 April 2017, 11:40:37
- 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
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...

Zitat von: Beta-User am 03 April 2017, 11:40:37
- 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:
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):
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...

Zitat von: Beta-User am 03 April 2017, 11:40:37
- Was die zukünftige Pflege des ganzen angeht, gab es im Beitrag "Rollosteuerung für große Installationen (https://forum.fhem.de/index.php/topic,61844.0.html)" 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.

Zitat von: Beta-User am 04 April 2017, 13:38:27
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

Zitat von: spi3845 am 05 April 2017, 01:06:53
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  :)

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.

Zitat von: spi3845 am 05 April 2017, 01:06:53
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.

Zitat von: spi3845 am 05 April 2017, 01:39:05
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? 8)

Gruß, Beta-User

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

Zitat von: Beta-User am 05 April 2017, 10:28:43
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"):

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

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.

{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 (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!

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

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.

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

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

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

ZitatUserAttribute = 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 (https://github.com/rejoe2/FHEM/tree/master/myShutter) 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

Zitat von: Beta-User am 05 April 2017, 17:45:08
Einen (ungetesteten) update der Bausteine habe ich übrigens auf github (https://github.com/rejoe2/FHEM/tree/master/myShutter) 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]

Zitat von: Beta-User am 03 April 2017, 11:40:37
- 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  :)

Zitat von: spi3845 am 05 April 2017, 17:58:12
[Ä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).

Zitat von: spi3845 am 05 April 2017, 17:58:12
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).

Zitat von: spi3845 am 05 April 2017, 17:58:12
P.S. Nächstes $we versaut, da weitere Tests  :)

...kommt mir bekannt vor 8)...

Gruß, Beta-User

Zitat von: Beta-User am 05 April 2017, 18:23:13
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...

Zitat von: Beta-User am 05 April 2017, 18:23:13
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.

Zitat von: Beta-User am 05 April 2017, 18:23:13
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

Da meine Lösung (https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545 (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

Zitat von: Beta-User am 05 April 2017, 07:56:26
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

Zitat von: hugomckinley am 05 April 2017, 22:10:53
Da meine Lösung (https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545 (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 (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

Zitat von: Beta-User am 05 April 2017, 17:45:08
Einen (ungetesteten) update der Bausteine habe ich übrigens auf github (https://github.com/rejoe2/FHEM/tree/master/myShutter) 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 (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).

sub winShutterAssociate($$$) { muss 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

@spi: Danke für die Code-Analyse, die (alle berechtigten) Anmerkungen sind auf github verarbeitet.

winOpenShutterTester($$) ist tatsächlich im Moment rein ereignisorientiert und wird immer aufgerufen, wenn ein Rolladen hält oder ein Tür-/Fensterkontakt ein Ereignis meldet (tilted@github ist noch nicht getestet). Mit der Zeitsteuerung hat es (noch) nichts zu tun (das macht bei mir noch je Gruppe ein DOIF, deren Parametrierung ich nicht verstehe und die ich daher loswerden will), das wäre dann aber nach meiner bisherigen Idee einfach ein weiterer Aufrufparameter (vielleicht mit dem von einem Timer mitgelieferten Ziellevel, bei dem dann geprüft wird, ob das so "durchgewunken" werden kann oder ein neuer onHoldLevel-Wert geschriebenen wird und der zulässige max-Wert angefahren?).

Erkenntnisse noch:
- setreading (und wohl auch setstate) kann man verwenden, um Werte in den userattr zu setzen. Dann hat man nicht mehr das Problem, dass es als Änderung mit einem roten Fragezeichen interpretiert wird. (EDIT: Danke an Thorsten Pferdekaemper, der darauf schon vor einiger Zeit hier hingewiesen hat.) Das sollte das Setzten der Parameter über readingsgroup deutlich vereinfachen (?).
- Man kann ja auch .5-er Level ansteuern (also 87.5). Da man das über die Oberfläche in der Regel nicht macht und sich solche Zwischenwerte auch nicht bei manuellem Schalten am Taster zu ergeben scheinen, könnte man darüber unterscheiden, ob es sich um einen automatischen Wert handelt (erstmal nur als Merkposten). 

Das mit der userattr-Werteinitialisierung hat sich nach code-Analyse erledigt, nehme ich an? (sonst müßte man auf den HM-Maintainer zugehen, oder? ;))

@Hugo: Danke für dieses wundervollen Codebeispiel! Hat mich sehr ermutigt, das endlich mal anzugehen :).
 
Zu dem Jalousie-Thema:
Zum Drehen nach dem Hochfahren muß man wieder nach unten. Damit wäre man dann wieder unterhalb des Mindestlevels, also: Spiel von vorne => geht so nicht. Ansatz dazu wäre, den weiteren Parameter gleich dazu zu nutzen, erst einen Ticken in Höhe des Parameters zu weit nach oben zu fahren und dann erst wieder (automatisch wegen "stop" ;)) auf den eigentlichen Ziellevel. Dann muß man nur verhindern, dass der onHoldLevel gelöscht wird. Andere Ideen oder Anregungen?

Zu "motor:down" und "set_xx":
motor:down sollte sowohl bei manueller Steuerung über einen Taster wie auch bei FHEM-Kommandos kommen, set_xx nur, wenn FHEM-seitig angestoßen. Wenn wir auch FHEM-seitige Kommandos modifizieren, bleibt die Zwangsöffnung unabhängig von der Zeitsteuerung und man kann nichts falsch machen, wenn man andere als "unsere" Bausteine zur Steuerung verwendet. Daher halte ich es für gut, das gleich auch noch mit abzufangen. Nachvollziehbar oder zu sehr um's Eck gedacht?

Gruß, Beta-User

Zitat von: spi3845 am 06 April 2017, 00:48:28
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).

Kurze Anmerkung dazu: Dass sie auf Utils enden muss stimmt so nicht, scheinbar muss Utils irgendwo im Namen vorkommen (weiß es aber auch nicht näher). Meine Dateien heißen z.B. 99_myUtilsWindows, 99_myUtilsBlinds etc. und die werden auch unter "Edit files" angezeigt.

Zitat von: Beta-User am 06 April 2017, 07:45:11
winOpenShutterTester($$) ist tatsächlich im Moment rein ereignisorientiert und wird immer aufgerufen, wenn ein Rolladen hält oder ein Tür-/Fensterkontakt ein Ereignis meldet (tilted@github ist noch nicht getestet). Mit der Zeitsteuerung hat es (noch) nichts zu tun (das macht bei mir noch je Gruppe ein DOIF, deren Parametrierung ich nicht verstehe und die ich daher loswerden will), das wäre dann aber nach meiner bisherigen Idee einfach ein weiterer Aufrufparameter (vielleicht mit dem von einem Timer mitgelieferten Ziellevel, bei dem dann geprüft wird, ob das so "durchgewunken" werden kann oder ein neuer onHoldLevel-Wert geschriebenen wird und der zulässige max-Wert angefahren?).

Klar, macht Sinn. Willst Du dann das Anfahren der unterschiedlichen Positionen aber nur im Zeitfenster durchführen, wenn die Rollläden per Timer runtergefahren wurden oder auch zu anderen Zeiten (z.B. Rollladen wurde tagsüber komplett runtergefahren und es macht jemand ein Fenster auf --> Rollladen fährt in Lüften-Position)?

Zitat von: Beta-User am 06 April 2017, 07:45:11
Das mit der userattr-Werteinitialisierung hat sich nach code-Analyse erledigt, nehme ich an? (sonst müßte man auf den HM-Maintainer zugehen, oder? ;))

Symbolischer Haken dran...

Zitat von: Beta-User am 06 April 2017, 07:45:11
Zum Drehen nach dem Hochfahren muß man wieder nach unten. Damit wäre man dann wieder unterhalb des Mindestlevels, also: Spiel von vorne => geht so nicht. Ansatz dazu wäre, den weiteren Parameter gleich dazu zu nutzen, erst einen Ticken in Höhe des Parameters zu weit nach oben zu fahren und dann erst wieder (automatisch wegen "stop" ;)) auf den eigentlichen Ziellevel. Dann muß man nur verhindern, dass der onHoldLevel gelöscht wird. Andere Ideen oder Anregungen?

Klingt gut. Etwas höher fahren, dann x Sekunden nach unten, dann erst onHoldLevel ändern.
Oder Jalousie höher fahren, x Sekunden nach unten und weitere Ausführung des Skripts innerhalb von z.B. 3 Sekunden verhindern - damit würde man auch Stottern der Jalousien/Rollläden vermeiden.

Zitat von: Beta-User am 06 April 2017, 07:45:11
Zu "motor:down" und "set_xx":
motor:down sollte sowohl bei manueller Steuerung über einen Taster wie auch bei FHEM-Kommandos kommen, set_xx nur, wenn FHEM-seitig angestoßen. Wenn wir auch FHEM-seitige Kommandos modifizieren, bleibt die Zwangsöffnung unabhängig von der Zeitsteuerung und man kann nichts falsch machen, wenn man andere als "unsere" Bausteine zur Steuerung verwendet. Daher halte ich es für gut, das gleich auch noch mit abzufangen. Nachvollziehbar oder zu sehr um's Eck gedacht?

Ganz klar Bahnhof  ;). Ich versuche mal zu interpretieren:

Zitatset_xx nur, wenn FHEM-seitig angestoßen

Ja, wenn ich auf den Taster direkt drücke, sehe ich beim Aktor kein set_xx

ZitatWenn wir auch FHEM-seitige Kommandos modifizieren

Hm, was meinst Du mit modifizieren?

Warum wollen wir die Bewegung erkennen? Um während der Abwärts-Bewegung eines Rollladens diesen beim Öffnen einer Tür oder eines Fensters anzuhalten? Also Einklemm- und Aussperrschutz? Wäre es dann nicht egal, ob der Rollladen von fhem oder per Taster abwärts gefahren wird? Ich denke da an spielende Kinder, der eine drückt auf den Taster und der andere macht das Fenster auf und hängt den Rüssel raus  ???

Zitat von: Joker am 06 April 2017, 15:31:34
Kurze Anmerkung dazu: Dass sie auf Utils enden muss stimmt so nicht, scheinbar muss Utils irgendwo im Namen vorkommen (weiß es aber auch nicht näher). Meine Dateien heißen z.B. 99_myUtilsWindows, 99_myUtilsBlinds etc. und die werden auch unter "Edit files" angezeigt.

Noch eine kurze Anmerkung dazu: Das ganze kann man sogar (mit ein paar Einschränkungen) über das FHEMWEB-Attribut (https://fhem.de/commandref_DE.html#FHEMWEB) editFileList anpassen. Ansonsten entspricht das zuvor genannte Verhalten aber der Voreinstellung.

Zu dem notify: m.E. sollte das immer und zu jeder Uhrzeit reagieren.
Wer das nicht möchte (z.B. keine automatische Rolladenfahrt in der Nacht), müßte die notif...s ( ::)) halt in dem Zeitraum per attr auf disable-for-... setzen. Ich finde es aber logischer, wenn der Rolladen wirklich immer "auf Linie" gezwungen wird, also auch in dem von Dir genannten Beispiel des manuellen Schließens mit anschließender Fensteröffnung.

Die Jalousiedrehung würde ich nicht blockierend gestalten (geht das überhaupt?), sondern durch einen erneuten Durchlauf des scripts (das ja durch den Zwischen-stop sowieso getriggert wird ;)). Das muß dann nur merken, dass der erreichte stop-Level genau dem "Mach-ein-Wendemanöver"-Level entspricht. Konzept dazu: ein numerisches Jalousie-Attribut kann gesetzt werden (Beispiel: "3"), der Rolladen soll beim ersten Durchlauf auf {WindowContactOpenMaxClosed-3.5} geschickt werden. Stoppt er dann auf genau diesem Wert, darf er wieder auf WindowContactOnHoldState zurück (neuer Fall für das perl-script, nur dass in diesem Fall die onHoldPosition nicht gelöscht werden soll). Durch den Zwischenziellevel (-3.5 statt -3) ist es praktisch ausgeschlossen, dass jemand mittels Taster oder FHEMWEB die Jalousie dahin geschickt hat ;).

Zitat von: spi3845 am 06 April 2017, 15:34:47
Ganz klar Bahnhof  ;). Ich versuche mal zu interpretieren: Ja, wenn ich auf den Taster direkt drücke, sehe ich beim Aktor kein set_xx Hm, was meinst Du mit modifizieren?
Warum wollen wir die Bewegung erkennen? Um während der Abwärts-Bewegung eines Rollladens diesen beim Öffnen einer Tür oder eines Fensters anzuhalten? Also Einklemm- und Aussperrschutz? Wäre es dann nicht egal, ob der Rollladen von fhem oder per Taster abwärts gefahren wird? Ich denke da an spielende Kinder, der eine drückt auf den Taster und der andere macht das Fenster auf und hängt den Rüssel raus  ???

Erklärungsversuch:
Gibt jemand irgendwie das Kommando, dass der Rolladen nach unten soll, soll er an der "richtigen" Stelle anhalten, ist das Fenster offen, also an der offen-Position, aber eben nur wenn diese unterhalb des Ziellevels liegt (oder dieses nicht angegeben wurde=Taster). Allerdings könnte es sein, dass wir z.B. durch unsere zeitgesteuerte Automatikfunktion ja wollen, dass das Fenster am Ende (irgendwann, ausgelöst durch Schließen des Fensters) dann weiterfährt. Dann muß einfach der Ziellevel des trigger-Ereignisses als neue onHoldPosition gesetzt werden...
Die Modifikation des triggernden "motor:down" würde also aus einem "set 20" ein "set 60" machen (bei WindowContactOpenMaxClosed=60) und die onHoldPosition auf 20 setzen.
Jetzt nachvollziehbar?

Zitat von: Beta-User am 05 April 2017, 17:45:08
Einen (ungetesteten) update der Bausteine habe ich übrigens auf github (https://github.com/rejoe2/FHEM/tree/master/myShutter) liegen, da gäbe es dann auch den "Tilted"-Level (wenn es klappt ;)).

Hallo Beta-User,

habe deinen Code mit Dummies nachgebildet und noch folgendes gefunden:

WindowContactOnHoldState muss initial auf none gesetzt werden, sonst fahren die Rollläden bei "Tür zu" immer in Position 100 (also offen).

In der Funktion winOpenShutterTester($$)muss meiner Meinung nach die Zeile
elsif ($event eq "Window" && $winState eq "closed" && $maxPosition ne "none") {
ersetzt werden durch
elsif ($event eq "Window" && $winState eq "closed" && $onHoldState ne "none") {
Ansonsten wird die alte (gemerkte) Position in WindowContactOnHoldState nicht angefahren nach dem Schließen der Tür.

Der Aufruf fhem("setreading $shutter:WindowContactOnHoldState none"); schreibt ein Reading, die Funktion winShutterAssociate($$$$) erstellt aber Attribute (zum Doppelpunkt siehe weiter unten). winOpenShutterTester($$) liest auch Attribute, z.B.
my $onHoldState = AttrVal($shutter,'WindowContactOnHoldState',"none");
Das kollidiert, damit funktionieren die if-Abfragen in winOpenShutterTester($$) nicht, z.B.
if($onHoldState eq "none") { fhem("setreading $shutter:WindowContactOnHoldState $position");}
da die Abfrage auf ein Attribut testet, aber ein reading schreibt... D.h.
my $onHoldState = AttrVal($shutter,'WindowContactOnHoldState',"none");
sollte geändert werden in
my $onHoldState = ReadingsVal($shutter,'WindowContactOnHoldState',"none");

Dann sind noch die Doppelpunkte aus allen setreading Befehlen zu entfernen, statt
fhem("setreading $shutter:WindowContactOnHoldState none");
sollte geschrieben werden
fhem("setreading $shutter WindowContactOnHoldState none");

Hoffe, die Änderungen machen Sinn... Meinen Dummies hat's gefallen  ;)

Eine Frage:
Ich finde Attribute insofern geschickt, als sich diese einfach über die Weboberfläche setzen lassen. Readings nicht, da muss man immer einen Befehl absetzen. Der Vorteil von Readings ist, dass nicht das Fragezeichen neben "Save config" auftaucht. Kann man die Vorteile irgendwie kombinieren? Also einfach editieren ohne das Fragezeichen zu bekommen?

Grüße,
spi

Nachtrag: Es würde reichen, nur WindowContactOnHoldState als Reading zu speichern, da das der einzige Parameter ist, der von dem Skript winOpenShutterTester($$) geschrieben wird. Damit verhindert man das Fragezeichen neben "Save config". Die anderen Parameter kann man als Attribute lassen, damit kann man sie leicht über die Weboberfläche editieren...

Zitat von: Beta-User am 06 April 2017, 16:33:04
Die Jalousiedrehung würde ich nicht blockierend gestalten (geht das überhaupt?)

Bestimmt  :) Rudimentär würde mir ein locked Attribut einfallen (nennt man das Semaphore?), das dann von einem at nach z.B. 3 Sekunden wieder gelöscht würde. Solange es gesetzt ist, würde das Skript sich gleich wieder beenden (oder irgend etwas anderes tun). Das würde in etwa dem entsprechen, 3 Sekunden lang nicht auf Ereignisse motor:stop|up|down zu reagieren (vielleicht kann man auch das anders erreichen). Das Skript wird hier nicht blockiert, reagiert einfach nur auf bestimmte Ereignisse nicht.

Zitat von: Beta-User am 06 April 2017, 16:33:04
Konzept dazu: ein numerisches Jalousie-Attribut kann gesetzt werden (Beispiel: "3"), der Rolladen soll beim ersten Durchlauf auf {WindowContactOpenMaxClosed-3.5} geschickt werden. Stoppt er dann auf genau diesem Wert, darf er wieder auf WindowContactOnHoldState zurück (neuer Fall für das perl-script, nur dass in diesem Fall die onHoldPosition nicht gelöscht werden soll). Durch den Zwischenziellevel (-3.5 statt -3) ist es praktisch ausgeschlossen, dass jemand mittels Taster oder FHEMWEB die Jalousie dahin geschickt hat ;).

Können alle Aktoren Rollläden/Jalousien auf x.5 Werte fahren?

Zitat von: Beta-User am 06 April 2017, 16:33:04
Erklärungsversuch:
Gibt jemand irgendwie das Kommando, dass der Rolladen nach unten soll, soll er an der "richtigen" Stelle anhalten, ist das Fenster offen, also an der offen-Position, aber eben nur wenn diese unterhalb des Ziellevels liegt (oder dieses nicht angegeben wurde=Taster). Allerdings könnte es sein, dass wir z.B. durch unsere zeitgesteuerte Automatikfunktion ja wollen, dass das Fenster am Ende (irgendwann, ausgelöst durch Schließen des Fensters) dann weiterfährt. Dann muß einfach der Ziellevel des trigger-Ereignisses als neue onHoldPosition gesetzt werden...
Die Modifikation des triggernden "motor:down" würde also aus einem "set 20" ein "set 60" machen (bei WindowContactOpenMaxClosed=60) und die onHoldPosition auf 20 setzen.
Jetzt nachvollziehbar?

Hoffentlich verstanden  ???. Das ist dann eine Art Übersteuern des Zielwerts beim Schließen der Rollläden und Öffnen des Fensters. Also so?

• Rollläden per Timer noch offen
• Jemand gibt das Kommando, Rollladen auf Position 20 zu fahren
• Das Fenster wird während der Fahrt geöffnet, Rollladen fährt auf Position 60
• Fenster wird geschlossen, Rollladen fährt auf Position 20
• Timer schlägt zu und schließt Rolladen (Position 0)
• Sollte der Timer zum Schließen der Rollläden zuschlagen, bevor Fenster geschlossen wird (Timer schlägt zu nach dem Schritt 3), würde der Rolladen erst einmal verharren und nicht weiterfahren. Beim Schließen des Fensters fährt er dann zu (Position 0)

Gute Nacht,
spi

Zitat von: spi3845 am 09 April 2017, 00:42:11
Hoffe, die Änderungen machen Sinn... Meinen Dummies hat's gefallen  ;)

...definitiv, Danke für die Code-Analyse! Ich hoffe, mein perl-Verständnis, wird irgendwann besser ::).

Deinen Input und meine zwischenzeitlichen Erkenntnisse sollten in der aktuellen Github-Version soweit verarbeitet sein, dass man das als ganz frühe Beta bezeichnen könnte. Dabei habe ich auch min einen Attribut-Namen teilweise angepasst, das war nicht ganz stimmig.

Die jetzige Version sollte
- beide Level (open/tilted) ansteuern und dabei den onHold-Wert nicht zu sehr durcheinanderbringen (noch nicht ausgiebig getestet, will meine Familie jetzt nicht wecken ::))
- mit Jalousien umgehen können (getestet nur mit open, da aber der code sonst gleich ist, müßte auch tilted passen ;)
- per Automatik immer die Zwischenlevel anfahren (.5), (Aunahme: onHold-State soll angefahren werden). Ich gehe davon aus, dass das alle HM-Aktoren können, für andere Typen wären das zwei kleine Code-Eingriffe...

Was wirklich verwirrend ist, ist das mit ReadingsVal und AttrVal, es scheint aber jetzt so zu funktionieren. Ein paar Mal hatte ich den Effekt, dass die Jalousie ganz nach oben gefahren war, jetzt habe ich die Vermutung, dass das damit zusammenhing, dass das Reading noch nicht gefüllt war. Die Initialisierungsfunktion ist entsprechend angepasst, hoffe das geht jetzt so.

Zu den Jalousien: Der Code ist non-Blocking und triggert sich implizit selbst. Ich fand das charmanter, als irgendwo noch eine Info zwischenzuspeichern oder auf irgendwas zu warten (wie lange?), aber wer bessere Konzepte hat: her damit!

Weitere Neuerungen:
Es gibt eine weitere Sub, um die Jalousie-Eigenschaft festlegen zu können.

Dann habe ich noch eine Readingsgroup gebastelt, mit der man die Maximallevel einfach einstellen kann; ist noch nicht hübsch, aber geht...:
defmod rg_Rolladen_Auto_Oeffnen readingsGroup <Gerät>,<Offen-Pos.>,<Gekippt-Pos.>,<Jalousie>,<On-Hold> (Rolladen_.*|Jalousie_.*)..:level,?WindowContactOpenMaxClosed,?WindowContactTiltedMaxClosed,?JalousieTurnLevel,?WindowContactOnHoldState,
attr rg_Rolladen_Auto_Oeffnen commands { 'WindowContactOpenMaxClosed' => 'WindowContactOpenMaxClosed:10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100','WindowContactTiltedMaxClosed' => 'WindowContactTiltedMaxClosed:10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',}


Zitat von: spi3845 am 09 April 2017, 01:10:06
Hoffentlich verstanden  ???. Das ist dann eine Art Übersteuern des Zielwerts beim Schließen der Rollläden und Öffnen des Fensters. Also so?

Ganz genau. Das wird dann aber wieder eine größerer Aufwand werden (jedenfalls mit meinen bescheidenen Kenntnissen), mal schauen, ob ich da heute Mittag auf der Terrasse ein paar Eingebungen habe ;). Ideen: wie immer willkommen...

Solche Text-Übungen, wie ein "set_off" zu trennen und dann aus "off" ein "0" zu machen, sind sicher nicht schwer. Wenn jemand dazu bereits fertigen code hat, den ich mir erst mühsam erarbeiten muß: Gerne her damit!

Gruß, Beta-User

Beim Testen war leider der Teil mit tilted und Zwischenständen noch nicht ganz so in der Reaktion wie erhofft, neueste Version auf github sollte das jetzt besser können...

Zitat von: Beta-User am 09 April 2017, 11:49:44
Beim Testen war leider der Teil mit tilted und Zwischenständen noch nicht ganz so in der Reaktion wie erhofft, neueste Version auf github sollte das jetzt besser können...

Morgähn,
was hat bei Dir nicht funktioniert? Nach den von mir vorgeschlagenen Änderungen lief tilteld/open mit den Dummies ohne erkennbare Probleme.

Ich hatte mir noch Gedanken zu einer Timersteuerung gemacht. Das wäre eine weitere Abfrage in dem Skript - statt Window oder Rollo z.B. Timer. Wenn der Timer zuschlägt und onHold ist != none, dann müsste onHold auf 0 gesetzt werden. Korrekt?

Grüße,
spi

Er hat die Position nicht sauber angefahren, wenn der onHold-Wert zwischen open und tilted lag (beim Wechsel von open nach tilted).

Da ich zwischenzeitlich den Code auch im Hinblick auf Jalousien umgebaut hatte, waren Deine Anmerkungen nicht mehr 1:1 umsetzbar. Da war vermutlich mit der Jalousiefunktion ein Logikfehler reingekommen. Für Jalousien muß man ein weiteres Attribut setzen (lassen), das dann angibt, um wieviel zuerst zu weit nach oben gefahren werden soll (bei mir scheint 3 ein guter Wert zu sein).

Bastle grade noch an "motor:down", wird noch ein Weilchen dauern, aber die erste Vorverarbeitung der erforderlichen Werte sollte demnächst fertig sein. Das Einbauen in die Gesamtstruktur wird dann der spannende Teil 8).

Zitat von: Beta-User am 09 April 2017, 07:46:17
Solche Text-Übungen, wie ein "set_off" zu trennen und dann aus "off" ein "0" zu machen, sind sicher nicht schwer. Wenn jemand dazu bereits fertigen code hat, den ich mir erst mühsam erarbeiten muß: Gerne her damit!

Mojn!

Ich habe zwar keinen fertigen Code dafür, aber du müsstest relativ einfach Teile vom String ersetzen können. Hab mal gegoogelt:

my $str = "The black cat climbed the green tree";
my $z = substr $str, 14, 7, "jumped from";
say $z;                                                     # climbed
say $str;                  # The black cat jumped from the green tree


Gesendet von iPhone mit Tapatalk

Zitat von: Beta-User am 09 April 2017, 12:54:40
Er hat die Position nicht sauber angefahren, wenn der onHold-Wert zwischen open und tilted lag (beim Wechsel von open nach tilted).

Da ich zwischenzeitlich den Code auch im Hinblick auf Jalousien umgebaut hatte, waren Deine Anmerkungen nicht mehr 1:1 umsetzbar. Da war vermutlich mit der Jalousiefunktion ein Logikfehler reingekommen. Für Jalousien muß man ein weiteres Attribut setzen (lassen), das dann angibt, um wieviel zuerst zu weit nach oben gefahren werden soll (bei mir scheint 3 ein guter Wert zu sein).

Bastle grade noch an "motor:down", wird noch ein Weilchen dauern, aber die erste Vorverarbeitung der erforderlichen Werte sollte demnächst fertig sein. Das Einbauen in die Gesamtstruktur wird dann der spannende Teil 8).

Jalousie kann ich in Ermangelung an Hardware nicht testen. Habe den Code an Rollläden getestet und habe dazu zwei Fragen:

Es gibt folgende Abfrage in winOpenShutterTester
elsif ($event eq "Rollo")
Dieser Codeblock reagiert auf das notify n_Rolladen_Stop.

Der erste Block (für das notify n_Rolladen_Window) wird nicht von einem
if ($event eq "Window")
eingeleitet. In dem letzten elsif vor dem Rollo-Block findet sich eine Abfrage nach dem event "Window". Das ist im Moment nicht schlimm, könnte aber zu Seiteneffekten führen, sollten noch weitere Ereignisse hinzukommen (z.B. Timer). Oder sehe ich das falsch?


Die zweite Frage bezieht sich auf quasi-parallele Ereignisse, wenn mehrere notifys feuern. Wie handhabt fhem die Ausführung dann einer Funktion, die von unterschiedlichen notifys fast zeitgleich aufgerufen wird? Werden die Ereignisse nacheinander abgearbeitet und wartet fhem mit der erneuten Ausführung einer Funktion bis die Funktion zuvor beendet wurde? Oder wird eine Funktion (für das gleiche Device) mehrmals (fast) parallel aufgerufen? Das "fast" bezieht sich auf die Laufzeit, d.h. zur Laufzeit eines Aufrufs wird die Funktion ein weiteres mal aufgerufen...

Sollte eine Funktion tatsächlich mehrmals parallel aufgerufen werden, könnten sich die Kommandos in die Quere kommen. Dann bräuchten wir hier noch irgend etwas, um das zu erkennen und entweder zu unterbinden oder einen kontrollierten Zustand (z.B. eine priorisierte Aktion) herbeizuführen.

Grüße,
spi

Nachtrag:
Beim Testen konnte ich auf die schnelle die Abfrage
elsif ($maxPosTilted < $onHoldState) { $maxPosTilted = $onHoldState; }
nicht zum Feuern bringen. Sind
WindowContactOpenMaxClosed 30
WindowContactTiltedMaxClosed 10
WindowContactOnHoldState 20
dann wird beim Kippen das Rollo auf Position 10 gefahren und nicht 20. Hm.

Ziemlich tricky, das ganze...

Habe zwischenzeitlich eine aktualisierte Version auf Github, ist aber ausdrücklich development, da nicht in allen Belangen funktional, zu den Problemen s.u.

Vorab zu den Fragen und Anmerkungen:
- das elsif ist nur relevant, wenn eine Jalousie an einer Wendeposition hält. Das ist ein Sonderfall, den man im Auge behalten sollte, um keine Seiteneffekte auszulösen, im Moment sehe ich da aber noch keine große Gefahr.
- Was timer und quasi-parallele Ereignisse angeht, sehe ich das so:
-- FHEM sollte alles sequenziell abarbeiten, eine Parallelisierung von threads ist nicht vorgesehen. Bislang habe ich den Eindruck, dass es genau so ist. Damit liegt die eigentliche Schwierigkeit darin, vorab  sinnvolle Eingangsprüfungen zu machen, ob denn überhaupt etwas zu tun ist. Weil: UU. sind bestimmte Werte, von denen man annehmen würde, dass sie zusammen mit dem triggernden Ereignis aktualisiert werden noch nicht auf dem erwarteten Stand (Gerätestatus wird z.B. immer als letztes aktualisiert).
-- Bei der bisherigen Fassung des "testers" war das solange kein Problem, wie genug Zeit war, dass sich die Zustände alle wieder sauber dargestellt haben (während der Rolladenfahrt). Weiteres s.u..
-- interne Timer setzen (wie ginge das überhaupt?), dürfte nach meinem Gefühl eher zu noch mehr Durcheinander führen, im Moment glaube ich, dass bessere Abfragen (ua. nach ReadingsAge()) die meisten Rätsel lösen könnten, über die ich gestern noch gestolpert bin (braucht aber noch Tests).
- Das mit der Tilted-Position ist mir auch aufgefallen, habe da wieder was geändert, ganz gelöst ist es aber noch nicht.

Im Moment hat der dev-Code nämlich (mind.) dieses Problem, was genau damit zusammenzuhängen scheint:
Er triggert sich in bestimmten Positionen/Situationen ständig selbst. Die, bei der mir das aufgefallen ist: Rolladen fährt bei Wechsel des Fensters von "open" zu "tilted" die entsprechende Position an. Dann sieht man im Ereignissmonitor, dass nach Erreichen dieser Position für "level" ständig ein "set_<tiltedPos>" ausgeführt wird. Da aber der Motor nix tut außer ein "stop" zu melden,  geht das im Sekundentakt gerade so weiter, bis man öffnet, schließt oder den Rolladen manuell hochfährt. Vermute, dass "set_xxx" immer kleiner als eine der abgefragten Mindestlevel ist (nämlich als "0" interpretiert wird). Das muß ich mir nochmal genauer ansehen, bin gestern erst spät darauf gekommen, dass manche komischen Effekte, die ich der neuen "MovementCheck"-Funktion zugeschrieben hatte, gar nicht (nur?) aus der Ecke kommen, sondern vom "tester".

Dafür hat die neue Funktion schon ein paar Bausteine drin, die das debuggen und das Ausfiltern der unnötigen "set_xxx" vollends erleichtern sollten:
- Ausgabe div. Infos über Zeile 58. Die deaktiviert die set-Funkionen im Moment mal noch und spuckt nur über einen Dummy die set-Werte aus, zum Testen sollte man das aber bereits auskommentieren können.
- Textfunktionen, um aus "set_xxx" was sinnvolles numerisches machen zu können. (Nächste Aktionen im "Tester", zusammen mir Ausgabe in Dummy)

Wenn das alles funktioniert, sollte eigentlich in der neuen "dynamischen" Version nur noch der Fall nicht abgedeckt sein, dass jemand während der Fahrt nach unten das Fenster aufmacht. Hier könnte uU. ein weiteres Attribut helfen (downTargetPosition (?) gesetzt in der "MovementCheck", falls nicht direkt andere set-Werte angewandt werden, gelöscht dann über den "stop"-Fall im "Tester". Aber eines nach dem anderen 8)...

Gruß, Beta-User

Zitat von: Beta-User am 10 April 2017, 10:27:37
Ziemlich tricky, das ganze...

Ist es.

Ich habe mal folgendes gemacht - vielleicht will ja jemand mittesten:
Die Funktion von github (ohne Jalousienlogik) habe ich reduziert auf die Logik allein, ergänzt um print-Anweisungen.

          #Wir speichern ein paar Infos, damit das nicht zu unübersichtlich wird
          my $event = "Window";
          my $windowcontact = "Fenster1";
          my $position = 5; # Werte 0-100
          my $winState = "open"; # Werte open, tilted oder closed
          my $maxPosOpen = 30; # Lüften-Position bei winstate=open
          my $maxPosTilted = 10;  # Lüften-Position bei winstate=tilted
          my $onHoldState = "none"; # "none" oder alte Position
 
          #Jetzt können wir nachsehen, ob der Rolladen zu weit unten ist (Fenster offen)...
          if($position < $maxPosOpen && $winState eq "open" && $windowcontact ne "none") {
      print "fhem(\"set $shutter $maxPosOpen\")\n";
              if($onHoldState eq "none") { print "fhem(\"setreading $shutter WindowContactOnHoldState $position\")\n"; }
          }
          #...(gekippt)...
          elsif($winState eq "tilted" && $windowcontact ne "none") {
              if($position < $maxPosTilted && $onHoldState eq "none") { print "fhem(\"setreading $shutter WindowContactOnHoldState $position\")\n"; }
  elsif ($maxPosTilted < $onHoldState) { $maxPosTilted = $onHoldState; }
  print "fhem(\"set $shutter $maxPosTilted\")\n";
          }
          #...oder ob eine alte Position wegen Schließung des Fensters angefahren werden soll...
          elsif ($event eq "Window" && $winState eq "closed" && $onHoldState ne "none") {
              print "fhem(\"set $shutter $onHoldState\")\n";
              print "fhem(\"setreading $shutter WindowContactOnHoldState none\")\n"; 
          }
          #...oder ob es sich um einen Stop zum Drehen der Jalousielamellen handelt...
  elsif ($event eq "Rollo") {
  #...oder die Positionsinfo wegen manueller Änderung gelöscht werden kann.
    if ($position != $maxPosOpen && $position != $maxPosTilted && $onHoldState ne "none") {
                        print "fhem(\"setreading $shutter WindowContactOnHoldState none\")\n";
                    }
}


Das ganze kann man z.B. auf https://www.tutorialspoint.com/execute_perl_online.php einkopieren und testen. Dazu die Variablen entsprechend setzen. Möchte man nach einem Lauf aus der Position  in eine andere fahren und testen, ob sich der Rollladen richtig verhält, setzt man die Variablen auf die Ausgabewerte...

So sieht man, ob der Rolladen beim Öffnen des Fensters in die richtigen Positionen fahren würde - ohne einen Rollladen tatsächlich fahren zu lassen.

Grüße,
spi

Zitat von: spi3845 am 10 April 2017, 15:03:34
Ist es.

Habe echt schon einen Knoten im Hirn >:(....

Was "Trockenübungen" angeht, habe ich meine Zweifel, wie weit das trägt, aber einen Versuch wäre es wert. Der Soll-Ablauf an sich ist ja gar nicht sooo schwer... (Aber die Jalousifunktion gefällt mir, sollte eigentlich drin bleiben 8)).

Womit ich mich aber erst nochmal beschäftigen werde, kurz dargestellt:
- Sind die Events für die notifys OK oder kann man das noch besser begrenzen, um eventuelle Mehrfachauslösungen (oder zu frühe) zu vermeiden  (ergo: sind ggf. bereits bestimmte Zustände vorab gesetzt oder nicht)?
- Anders formuliert: Inwiefern spielt die Reihenfolge eine Rolle, in der CUL_HM die EVENTS feuert bzw. wie herum berücksichtigt man das am besten.
- Wäre es nicht insgesamt besser, die Ereignisse ($EVENT) oder Teile davon an die subs zu übergeben statt des Texts? Dann kann man auch dort noch Duplikate aussortieren und hat "Rohevents" für den Fall, dass man das detailierter auswerten muß (für FK wohl egal, aber sonst habe ich die Hoffnung, dass das helfen würde...?).

Aber das muß ich mir in Ruhe nochmal ansehen und eine Event-Übergabe dürfte einige Änderungen am (Eingangs-) code nach sich ziehen...

Ansonsten ist Github mit der Änderungsverfolgung wirklich hilfreich, auch wenn es die Formatierung zerhackt (ist wahrscheinlich eher ein Thema des internen Editors, da sieht das ok aus). Läßt sich sicher besser machen, war aber erst mal nicht prio 1 ;).

Gruß, Beta-User

Zitat von: Beta-User am 10 April 2017, 15:30:24
Habe echt schon einen Knoten im Hirn >:(....

Und ich erst...

Zitat von: Beta-User am 10 April 2017, 15:30:24
Was "Trockenübungen" angeht, habe ich meine Zweifel, wie weit das trägt, aber einen Versuch wäre es wert. Der Soll-Ablauf an sich ist ja gar nicht sooo schwer... (Aber die Jalousifunktion gefällt mir, sollte eigentlich drin bleiben 8)).

Ich sehe vor lauter Ablaufplänen keinen Code mehr vor Augen, daher der Versuch alles zu minimieren...

Zitat von: Beta-User am 10 April 2017, 15:30:24
- Sind die Events für die notifys OK oder kann man das noch besser begrenzen, um eventuelle Mehrfachauslösungen (oder zu frühe) zu vermeiden  (ergo: sind ggf. bereits bestimmte Zustände vorab gesetzt oder nicht)?
- Anders formuliert: Inwiefern spielt die Reihenfolge eine Rolle, in der CUL_HM die EVENTS feuert bzw. wie herum berücksichtigt man das am besten.

Hm, das käme dann auf den Versuch darauf an. Ich glaube, wir könnten mit einer Semaphore etwas abfangen, die zu Beginn des Skripts auf "running" gesetzt und am Ende wieder gelöscht wird. Eine Abfrage ganz zu Beginn des Skripts auf =~ running beendet das Skript gleich wieder, weil es ja bereits läuft. Ggf. muss man die Semaphore aber auf den Namen des Device setzen, da eine mehrfache Ausführung für unterschiedliche Geräte nicht hinderlich ist.

Zitat von: Beta-User am 10 April 2017, 15:30:24
- Wäre es nicht insgesamt besser, die Ereignisse ($EVENT) oder Teile davon an die subs zu übergeben statt des Texts? Dann kann man auch dort noch Duplikate aussortieren und hat "Rohevents" für den Fall, dass man das detailierter auswerten muß (für FK wohl egal, aber sonst habe ich die Hoffnung, dass das helfen würde...?).

Klingt gut. Vermutlich kann man einige Events zusammenfassen und gleich behandeln, aber das kann auch im Skript erfolgen.

Zitat von: Beta-User am 10 April 2017, 15:30:24
Ansonsten ist Github mit der Änderungsverfolgung wirklich hilfreich, auch wenn es die Formatierung zerhackt (ist wahrscheinlich eher ein Thema des internen Editors, da sieht das ok aus).

Urgh, noch 'ne Baustelle. Was muss ich tun?


P.S. Noch ein Gedanke zu dem Testcode, den ich auf Basis deines Entwurfs gepostet hatte: wie wäre folgende Darstellung im Code? Sorry, Jalousien immer noch draußen, weil ich keine habe und das Wenden nicht verstehe...  ::) Mir geht's hier erst einmal um die Darstellung für zukünftige Erweiterung des Codes.


use Switch;


          #Wir speichern ein paar Infos, damit das nicht zu unübersichtlich wird
          my $event = "Window";
          my $windowcontact = "Fenster1";
          my $position = 8; # Werte 0-100
          my $winState = "tilted"; # Werte open, tilted oder closed
          my $maxPosOpen = 30; # Lüften-Position bei winstate=open
          my $maxPosTilted = 10;  # Lüften-Position bei winstate=tilted
          my $onHoldState = "none"; # "none" oder alte Position

if($windowcontact eq "none") { die "Fehler, Türkontakt nicht zugeordnet"; }             # in Subroutine dann return verwenden

switch($event){
   case "Window"           {
                                       switch($winState){
                                            case "open"         {
                                                                        if($position < $maxPosOpen) {
                                                                                print "fhem(\"set $shutter $maxPosOpen\")";
                                                                                if ($onHoldState eq "none") { print "fhem(\"setreading $shutter WindowContactOnHoldState $position\")"; }
                                                                                }
                                                                         }
                                            case "tilted"         {
                                                                        if($position < $maxPosTilted) {
                                                                                print "fhem(\"set $shutter $maxPosTilted\")";
                                                                                if ($onHoldState eq "none") { print "fhem(\"setreading $shutter WindowContactOnHoldState $position\")"; }
                                                                                }
                                                                         }
                                            case "closed"         {
                                                                         if ($onHoldState ne "none") {
                                                                                print "fhem(\"set $shutter $onHoldState\")";
                                                                                print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                                                                }
                                                                         }
                                            else                       { print "Fehler: unbekannter winState $winState\n" }
                                       }
   case "Rollo"           {
                                   if($position != $maxPosOpen && $position != $maxPosTilted && $onHoldState ne "none") {
                                        print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                        }
                                    }

                                       }
   else              { print "Fehler: unbekannter event $event" }
}


Kann man leider nicht mehr unter https://www.tutorialspoint.com/execute_perl_online.php einkopieren, da Switch.pm dort nicht vorhanden ist... Ich habe Padre auf einem Linux-Rechner laufen, F5 zaubert dann die Ergebnisse abhängig der gesetzten Werte, damit muss ich nicht dauernd Rollläden fahren zum Testen.

Für fhem muss Switch.pm installiert werden, auf Debian-Systemen am einfachsten über
sudo apt-get install libswitch-perl

Gruß,
spi

Zitat von: spi3845 am 10 April 2017, 16:22:10
Ich glaube, wir könnten mit einer Semaphore etwas abfangen, die zu Beginn des Skripts auf "running" gesetzt und am Ende wieder gelöscht wird.

Kann ich irgendwo für Dummies nachlesen, was das ist und wie das geht?!?

Was den Ablauf angeht, klappt das an sich "in der wirklichen Welt" (tilted habe ich evtl. kurz vor Ende "verschlimmbessert"). Das Problem scheint jetzt eben zu sein, dass zu oft getriggert wird (und dabei neben dieser ungewollten "Dauer-Schleife" vor allem auch die onHoldPosition fälschlicherweise gelöscht bzw. auf "0" gesetzt wird). Es wirkt aber so, als würde das script nicht - gesehen bei einem Rolladen - mehrfach parallel laufen, sondern eben immer wieder aufgerufen. Würde hier ein Semaphore helfen?

ZitatUrgh, noch 'ne Baustelle. Was muss ich tun?

War nicht als Aufforderung gedacht, an der Stelle nutze ich grade auch nicht den "git commit"-Mechanismus auf der Konsole vom PI, sondern die Web-Schnittstelle. Bei Interesse kannst Du ja einen eigenen Account beantragen (kostet für öffentlich sichtbaren code nichts) und mein Repo "forken". Damit könntest Du mir Änderungswünsche übermitteln.
Aber auch so kannst Du auf der Web-Oberfläche code-Changes sichtbar machen, indem Du die commits (=Änderungen) nachvollziehst. Dabei werden diese farblich dargestellt und haben auch Zeilennummern, was das Suchen vereinfacht.

Das mit dem Wenden ist einfach:
- geht die Jalousie (um einen Mindestwert, den die Lamellen zu drehen brauchen) nach unten, ist die Stellung "normal" (den Mindestwert prüfe ich derzeit nicht, wenn sonst ein Ereignis die Jalousie nach unten schickt).
- geht sie nach oben, wird um den Mindestwert übersteuert und bei Stop auf der Wendeposition wieder um diesen Wert nach unten gefahren. Für die Jalousie ein weiteres Attribut, für das Script drei weitere Werte (incl. dem Attributwert).

Zu Switch und so melde ich mich ggf. später, sieht interessant aus, wobei ich mich schon an die vielen elsif's gewöhnt habe...

Gruß, Beta-User

Zitat von: Beta-User am 10 April 2017, 16:57:15
Zu Switch und so melde ich mich ggf. später, sieht interessant aus, wobei ich mich schon an die vielen elsif's gewöhnt habe...

Ich habe gerade einen kleinen Run auf Switch ;)

Habe das Codebeispiel (aka Logik) erweitert um Timer. Macht das Sinn?

use Switch;


          #Wir speichern ein paar Infos, damit das nicht zu unübersichtlich wird
          my $event = "Timer_up";
          my $windowcontact = "Fenster";
          my $position = 0; # Werte 0-100
          my $winState = "closed"; # Werte open, tilted oder closed
          my $maxPosOpen = 30; # Lüften-Position bei winstate=open
          my $maxPosTilted = 10;  # Lüften-Position bei winstate=tilted
          my $posBlindClosed = 0; # Position, auf die Rollo beim Schließen gefahren werden soll
          my $posBlindOpened = 100; # Position, auf die Rollo beim Öffnen gefahren werden soll
          my $posBlindNotToOpen = 20; # Position, ab der erst ein Rollo bei offener Tür automatisch geöffnet wird, um ein Eindringen zu verhindern
          my $onHoldState = "none"; # "none" oder alte Position

if($windowcontact eq "none") { die "Fehler, Türkontakt nicht zugeordnet"; }             # in Subroutine dann return verwenden

switch($event){
   case "Window"           {
                                       switch($winState){
                                            case "open"         {
                                                                        if($position < $maxPosOpen) {
                                                                                print "fhem(\"set $shutter $maxPosOpen\")";
                                                                                if ($onHoldState eq "none") { print "fhem(\"setreading $shutter WindowContactOnHoldState $position\")"; }
                                                                                }
                                                                         }
                                            case "tilted"         {
                                                                        if($position < $maxPosTilted) {
                                                                                print "fhem(\"set $shutter $maxPosTilted\")";
                                                                                if ($onHoldState eq "none") { print "fhem(\"setreading $shutter WindowContactOnHoldState $position\")"; }
                                                                                }
                                                                         }
                                            case "closed"         {
                                                                         if ($onHoldState ne "none") {
                                                                                print "fhem(\"set $shutter $onHoldState\")";
                                                                                print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                                                                }
                                                                         }
                                            else                       { print "Fehler: unbekannter winState $winState\n" }
                                            }
                                        }
   case "Timer_down"           {
                                       switch($winState){
                                            case "open"         { # Aussperrschutz, nichts tun
                                                                        print "fhem(\"setreading $shutter WindowContactOnHoldState $posBlindClosed\")";
                                                                         }
                                            case "tilted"         { # auf Lüften-Position gekipptes Fenster fahren, als alte Position Schließposition des Rollos speichern
                                                                            print "fhem(\"set $shutter $maxPosTilted\")";
                                                                            print "fhem(\"setreading $shutter WindowContactOnHoldState $posBlindClosed\")";
                                                                         }
                                            case "closed"         {
                                                                           print "fhem(\"set $shutter $posBlindClosed\")";
                                                                           print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                                                         }
                                            else                       { print "Fehler: unbekannter winState $winState\n" }
                                        }
                                        }
   case "Timer_up"           {
                                       switch($winState){
                                            case "open"         { # Eindringen von außen verhindern
                                                                        if($position > $posBlindNotToOpen) {
                                                                                print "fhem(\"set $shutter $posBlindOpened\")";
                                                                                print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                                                                }
                                                                        else { print "fhem(\"setreading $shutter WindowContactOnHoldState $posBlindOpened\")"; }
                                                                         }
                                            case ["tilted","closed"]         { # Rollos eines gekipptes Fenster können geöffnet werden, ansonsten tilted wie open behandeln
                                                                        print "fhem(\"set $shutter $posBlindOpened\")";
                                                                        print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                                                         }
                                            else                       { print "Fehler: unbekannter winState $winState\n" }
                                            }
                                        }
   case "Rollo"           {
                                   if($position != $maxPosOpen && $position != $maxPosTilted && $onHoldState ne "none") {
                                        print "fhem(\"setreading $shutter WindowContactOnHoldState none\")";
                                        }
                                    }
   else              { print "Fehler: unbekannter event $event" }
}


Gruß,
spi

Zitat von: Beta-User am 10 April 2017, 16:57:15
Kann ich irgendwo für Dummies nachlesen, was das ist und wie das geht?!?

Ich würde so etwas vorschlagen...
sub winOpenShutterTester($$) {
    my ($dev, $event) = @_;
    #Erst mal prüfen, ob das übergebene device überhaupt existiert
    if ($defs{$dev}) {
               # Lock-Status lesen
               my $lock = ReadingsVal($shutter,'winOpenShutterTesterLock',0);
               if($lock == 1) { return "Skript für dieses Devices läuft bereits"; }
               # Lock setzen, falls es 0 war
               fhem("setreading $shutter winOpenShutterTesterLock 1");
               # "normale" Skript-Funktionen, Lock ist jetzt 1, sollte das Skript für dieses Device ein weiteres Mal gestartet werden,
               # beendet es sich wieder, bevor irgendwelche Aktionen ausgelöst werden
               ...
               # am Ende Lock wieder löschen
               fhem("setreading $shutter winOpenShutterTesterLock 0");   
}


Ach ja, noch ein Gedanke, wollte man sinnvoll unterbinden, dass nach einer Aktion die nächste Aktion am Aktor erst nach einer Karenzzeit passiert, könnte der Lock z.B. auch erst 5s nach Ende des Skript gelöscht werden (mit einem at).

Der Lock ist nur blöd bei Timern, da die dann verpasst werden könnten, aber das passiert ja nur, wenn der Timer zuschlägt während dem jemand am Rollo rumspielt - und er hat hoffentlich gute Gründe für  :D

Gruß,
spi

Zitat von: spi3845 am 10 April 2017, 16:59:18
Habe das Codebeispiel (aka Logik) erweitert um Timer. Macht das Sinn?

Es sieht vom Aufbau her nachvollziehbar aus, allerdings müßte ich für meine "Abfanglogik" noch einiges mehr berücksichtigen, was ich auf die Schnelle aber von den Auswirkungen her nicht überblicken kann.
"timer" als case gefällt mir irgendwie nicht, das paßt nicht mehr so richtig zu dem dynamischen Konzept, bei der jeder Fahrbefehl wieder analysiert wird unabhängig davon, wo er herkommt. Danach gilt: wer zuletzt kommt, bestimmt die Ziel- und onHold-Positionen, ganz gleich ob über timer, Schalter oder FHEMWEB ausgelöst...

Ganz neu (für meine Betrachtung) ist der Gedanke, trotz geöffnetem Fenster den Rolladen runterzumachen ???. Macht unter Sicherheitsaspekten Sinn, bisher war das gedanklich eher andersrum: ich komme ursprünglich von dem Ansatz zu verhindern, dass ich mich aussperre. Hmmm, sieht so aus, als würde dafür noch ein (einstellbares) Attribut benötigt, um den Aussperrschutz zu übersteuern. Behalte das mal im Hinterkopf, muß aber hintanstehen.

Zitat von: spi3845 am 10 April 2017, 17:21:35
Ich würde so etwas vorschlagen...

OK, Danke für die Info. Das geht in die Richtung wie ReadingsAge(), ohne dass man dafür ein eigenes Attribut bräuchte (?). ReadingsAge() sollte auch für eine sequenzielle Abarbeitung tauglich sein und ist in Zeilen 24 und 28 im Dev-tree für die "Abfangfunktion" schon genutzt, den Umbau im Tester habe ich gestern nicht mehr geschafft, was so schon spät ::).

Zitat von: Beta-User am 10 April 2017, 18:03:01
"timer" als case gefällt mir irgendwie nicht, das paßt nicht mehr so richtig zu dem dynamischen Konzept, bei der jeder Fahrbefehl wieder analysiert wird unabhängig davon, wo er herkommt. Danach gilt: wer zuletzt kommt, bestimmt die Ziel- und onHold-Positionen, ganz gleich ob über timer, Schalter oder FHEMWEB ausgelöst...

Interessanter Gedanke, wie würde Das Konzept aussehen? Kannst Du das skizzieren, dann überlege ich, wie man das abbilden könnte. Aktuell haben wir notifys für FK und motor, bräuchten dann noch Timer, die müssen aber irgend etwas anderes triggern, z.B. Rollopositionen. Timer könnten dann abgebildet werden als "set Rollo 0" und "set Rollo 100".

Zitat von: Beta-User am 10 April 2017, 18:03:01
Ganz neu (für meine Betrachtung) ist der Gedanke, trotz geöffnetem Fenster den Rolladen runterzumachen ???. Macht unter Sicherheitsaspekten Sinn, bisher war das gedanklich eher andersrum: ich komme ursprünglich von dem Ansatz zu verhindern, dass ich mich aussperre. Hmmm, sieht so aus, als würde dafür noch ein (einstellbares) Attribut benötigt, um den Aussperrschutz zu übersteuern.

Geht das in die Richtung "Vergessen, Tür zu schließen und jetzt will ich wenigstens noch Rollladen schließen"? Dann wäre ja ein Aussperrschutz beim Feuern des Timers ok. Danach periodische Erinnerung, dass Balkontür offen steht... Nach 30 Min ohne Reaktion Rollladen zu  :-X

Zitat von: Beta-User am 10 April 2017, 18:03:01
Das geht in die Richtung wie ReadingsAge(), ohne dass man dafür ein eigenes Attribut bräuchte (?).

Was ist denn das nun schon wieder? Muss nicht nur fhem, perl, DOIF lernen, jetzt auch noch ReadingsAge  ::)

Auf den ersten Blick sieht das aus, wie ein Wert, der anzeigt, wann ein spezielles Reading eines Devices das letzte mal geändert wurde. Der Lock-Mechanismus dagegen sorgt dafür, dass die Funktion für das gleiche Device nicht zweimal ausgeführt wird, auch wenn die erste Instanz schon eine Stunde läuft...

Zitat von: Beta-User am 10 April 2017, 18:03:01
ReadingsAge() sollte auch für eine sequenzielle Abarbeitung tauglich sein und ist in Zeilen 24 und 28 im Dev-tree für die "Abfangfunktion" schon genutzt, den Umbau im Tester habe ich gestern nicht mehr geschafft, was so schon spät ::).

Habe Dev erst jetzt gesehen, muss ich mir noch ansehen. Noch mehr Code... Ich keinen Code mehr sehen...  8)

Gruß,
spi

OK, den dev-tree hast Du ja gefunden wg. des Konzepts. Damit bliebe erst mal alles Event-basiert, nur dass eben durch irgendwas (timer usw.) veranlasste settings angepaßt würden.

Zitat von: spi3845 am 10 April 2017, 18:53:33
Geht das in die Richtung "Vergessen, Tür zu schließen und jetzt will ich wenigstens noch Rollladen schließen"?...

Das hatte ich so als Wunsch von Deiner Seite verstanden ;D, ich brauche sowas eher nicht.

Habe mir eben das mit den Events nochmal angesehen. Das wäre m.E. wirklich zielführend, die Events mit zu übergeben, ist aber ein gewisser Umbau. Denn sowohl der "stop" wie der "down"-Event senden die aktuelle Position mit, zu der Zeit ist aber der STATE des Geräts noch nicht geändert, das passiert erst danach. Damit holt Value() einen veralteten Wert, daher m.E. die trigger-loop. Man muß also den Value() überschreiben, (mindestens) wenn ein "stop" auslöst.

Mal sehen, wann ich dazu komme...

Zitat von: Beta-User am 10 April 2017, 19:54:07
OK, den dev-tree hast Du ja gefunden wg. des Konzepts. Damit bliebe erst mal alles Event-basiert, nur dass eben durch irgendwas (timer usw.) veranlasste settings angepaßt würden.Das hatte ich so als Wunsch von Deiner Seite verstanden ;D, ich brauche sowas eher nicht.

Ne, ich brauche nur Aussperrschutz. Sonst sitzt meine Familie draußen, wenn ich mal nicht da bin  :)

Zitat von: Beta-User am 10 April 2017, 19:54:07
Habe mir eben das mit den Events nochmal angesehen. Das wäre m.E. wirklich zielführend, die Events mit zu übergeben, ist aber ein gewisser Umbau.

Ich glaube mit Switch geht das einfacher, denn die case-Befehle könnten die Events direkt aufnehmen.

Zitat von: Beta-User am 10 April 2017, 19:54:07
Denn sowohl der "stop" wie der "down"-Event senden die aktuelle Position mit, zu der Zeit ist aber der STATE des Geräts noch nicht geändert, das passiert erst danach. Damit holt Value() einen veralteten Wert, daher m.E. die trigger-loop. Man muß also den Value() überschreiben, (mindestens) wenn ein "stop" auslöst.

Auf den Motor zu triggern führt zu einer Verzögerung. Denn erst gibt es irgendein Ereignis (Taste wird gedrückt oder Timer feuert), das wird verarbeitet und dann triggert der Aktor den Motor. Da die Aktoren die Position aus der Laufzeit bestimmen, dauert deren Bestimmung entsprechend. Deshalb habe ich versucht, den Timer gleich in die Funktion mit einzubauen - weiß noch nicht, wie gut das funktioniert. Der Timer ist im endlichen Automaten ein Ereignis wie "Tür auf", "Tür zu" oder "Schalter gedrückt" und führt zu einem Ergebnis wie Rolladen auf oder zu.

Zitat von: Beta-User am 10 April 2017, 19:54:07
Mal sehen, wann ich dazu komme...

Kenne ich  8)

Habe Beta-Users Code mit Switch-Anweisungen umgeschrieben und an Dummys zum Testen angepasst. Wer möchte, kann das so in fhem einkopieren. Das landet alles in einem Raum namens Test.Rollladen.sp.

Der Rolladen wird entsprechend bewegt je nachdem, ob die Tür geöffnet, geschlossen oder gekippt ist. Timer-Logik ist eingebaut und kann über die fhem Befehlszeile getestet werden. Hier gibt es unterschiedliche Reaktionen, je nachdem, ob die Tür offen (Aussperr- und Eindringschutz), gekippt (Lüften) oder geschlossen ist.

Timer_down testen mittels
{ WinShutterTester(AttrVal("t.r.sp.tuerkontakt_re",'ShutterAssociated','none'), "Timer_down") }
Timer_up:
{ WinShutterTester(AttrVal("t.r.sp.tuerkontakt_re",'ShutterAssociated','none'), "Timer_up") }

Die Funktionen für die 99_*Utils.pm (umbenannt, damit sie nicht mit Beta-Users-Funktionen kollidieren):

# am Anfang nach anderen use-Statements einfügen
use Switch;
# ...
# Enter you functions below _this_ line.

sub WinShutterTester($$) {
    #Als Parameter muss der device-Name übergeben werden
    #notify-Definitionen:
    #defmod n_Rolladen_Window notify .*(closed|open|tilted)..to.VCCU. { WinShutterTester(AttrVal($NAME,'ShutterAssociated','none'), "Window") }
    #defmod n_Rolladen_Stop notify .*:motor:.stop.* { WinShutterTester($NAME, "Rollo")}
    #Hint for window contacts: make sure to modify settings of device wrt. some delay in sending state changes to avoid unnecessary triggers
    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
        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 $maxClosedIfOpen = AttrVal($shutter,'ShutterMaxClosedIfOpen',30);
          my $maxClosedIfTilted = AttrVal($shutter,'ShutterMaxClosedIfTilted',10);
  my $onHoldState = ReadingsVal($shutter,'ShutterOnHoldState',"none");
  my $maxClosed = AttrVal($shutter,'ShutterMaxClosed',0);
  my $maxOpened = AttrVal($shutter,'ShutterMaxOpened',100);
  my $notOpenIfBelow = AttrVal($shutter,'ShutterNotOpenIfBelow',20);
 
  # wenn kein $windowcontact, so tun als wäre Fenster immer zu (=closed)
  if($windowcontact eq "none") { $winState = "closed"; }

  switch($event){
  case "Window"{
switch($winState){
case "open"{
if($position < $maxClosedIfOpen) {
                        fhem("set $shutter $maxClosedIfOpen");
                            if ($onHoldState eq "none") { fhem("setreading $shutter ShutterOnHoldState $position"); }
                            }
                    }
case "tilted"{
if($position < $maxClosedIfTilted) {
fhem("set $shutter $maxClosedIfTilted");
if ($onHoldState eq "none") { fhem("setreading $shutter ShutterOnHoldState $position"); }
}
}
case "closed"{
if ($onHoldState ne "none") {
fhem("set $shutter $onHoldState");
fhem("setreading $shutter ShutterOnHoldState none");
}
}
else { return "Fehler: unbekannter winState $winState"; }
}
}
case "Timer_down"{
switch($winState){
case "open"{ # Aussperrschutz, nichts tun
fhem("setreading $shutter ShutterOnHoldState $maxClosed");
}
case "tilted"{ # gekipptes Fenster auf Lüften-Position fahren,
# als alte Position Schließposition des Rollos speichern
fhem("set $shutter $maxClosedIfTilted");
fhem("setreading $shutter ShutterOnHoldState $maxClosed");
}
case "closed"{
fhem("set $shutter $maxClosed");
fhem("setreading $shutter ShutterOnHoldState none");
}
else { return "Fehler: unbekannter winState $winState"; }
}
}
case "Timer_up"{
switch($winState){
case "open"{ # Eindringen von außen verhindern
if($position > $notOpenIfBelow) {
fhem("set $shutter $maxOpened");
fhem("setreading $shutter ShutterOnHoldState none");
}
else {
fhem("set $shutter $notOpenIfBelow");
fhem("setreading $shutter ShutterOnHoldState $maxOpened");
}
}
case ["tilted","closed"]{ # Rollos eines gekippten Fensters können geöffnet werden,
# ansonsten müsste tilted wie open behandelt werden
fhem("set $shutter $maxOpened");
fhem("setreading $shutter ShutterOnHoldState none");
}
else { return "Fehler: unbekannter winState $winState"; }
}
}
case "Rollo"{ # noch nicht fertig, testen
if($position != $maxClosedIfOpen && $position != $maxClosedIfTilted && $onHoldState ne "none") {
fhem("setreading $shutter ShutterOnHoldState none");
}
}
else { return "Fehler: unbekannter event $event"; }
}
  }
}
}


sub WinShutterLink($$$$$$$) {
    #Als Parameter müssen die Namen vom Fensterkontakt und Rolladen übergeben werden sowie der Maxlevel bei Fensteröffnung und tilted
    #Call in FHEMWEB e.g.: { WinShutterLink("Fenster_Wohnzimmer_SSW","Rolladen_WZ_SSW",30,10,0,100,20) }
    my ($windowcontact, $shutter, $maxClosedIfOpen, $maxClosedIfTilted, $maxClosed, $maxOpened, $notOpenIfBelow) = @_;
    my ($hash, @param) = @_;
    #Erst mal prüfen, ob die Parameter sinnvoll sind
    if($defs{$windowcontact} && $defs{$shutter}) {

if(AttrVal($shutter,'subType', undef) =~ "blindActuator|dummy|" && AttrVal($windowcontact,'subType',undef) =~ "threeStateSensor|dummy|") {
            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,"ShutterOnHoldState") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo ShutterOnHoldState");
                $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
fhem("setreading $shutter ShutterOnHoldState none");
            if(index($oldAttrRollo,"ShutterMaxClosed") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo ShutterMaxClosed");
                $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
            fhem("attr $shutter ShutterMaxClosed $maxClosed");
            if(index($oldAttrRollo,"ShutterMaxOpened") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo ShutterMaxOpened");
                $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
            fhem("attr $shutter ShutterMaxOpened $maxOpened");
            if(index($oldAttrRollo,"ShutterMaxClosedIfOpen") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo ShutterMaxClosedIfOpen");
                $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
            fhem("attr $shutter ShutterMaxClosedIfOpen $maxClosedIfOpen");
            if(index($oldAttrRollo,"ShutterMaxClosedIfTilted") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo ShutterMaxClosedIfTilted");
                $oldAttrRollo = AttrVal($shutter,'userattr',undef);
            }
            fhem("attr $shutter ShutterMaxClosedIfTilted $maxClosedIfTilted");
            if(index($oldAttrRollo,"ShutterNotOpenIfBelow") < 0) {
                fhem("attr $shutter userattr $oldAttrRollo ShutterNotOpenIfBelow");
            }
            fhem("attr $shutter ShutterNotOpenIfBelow $notOpenIfBelow");
        }
        else { return "One of the devices has wrong subtype"; }
    }
    else { return "One of the devices does not exist"; }
}


Und hier die Dummys zum Testen:
define t.r.sp.rollo_re dummy
attr t.r.sp.rollo_re userattr WindowContactAssociated ShutterOnHoldState ShutterNotOpenIfBelow
attr t.r.sp.rollo_re ShutterMaxClosed 0
attr t.r.sp.rollo_re ShutterMaxClosedIfOpen 30
attr t.r.sp.rollo_re ShutterMaxClosedIfTilted 10
attr t.r.sp.rollo_re ShutterMaxOpened 100
attr t.r.sp.rollo_re ShutterNotOpenIfBelow 20
attr t.r.sp.rollo_re WindowContactAssociated t.r.sp.tuerkontakt_re
attr t.r.sp.rollo_re room Test.Rollladen.sp
attr t.r.sp.rollo_re userReadings level { ReadingsVal("t.r.sp.rollo_re","state",0);;;; }
attr t.r.sp.rollo_re webCmd 0:5:10:20:30:50:70:100
define t.r.sp.tuerkontakt_re dummy
attr t.r.sp.tuerkontakt_re userattr ShutterAssociated
attr t.r.sp.tuerkontakt_re ShutterAssociated t.r.sp.rollo_re
attr t.r.sp.tuerkontakt_re room Test.Rollladen.sp
attr t.r.sp.tuerkontakt_re setList tilted open closed
attr t.r.sp.tuerkontakt_re webCmd tilted:open:closed
define t.r.sp.n_Rolladen_Window notify t.r.sp.tuerkontakt_.*(closed|open|tilted) { WinShutterTester(AttrVal($NAME,'ShutterAssociated','none'), "Window") }
attr t.r.sp.n_Rolladen_Window group Türen und Fenster
attr t.r.sp.n_Rolladen_Window icon fts_shutter_automatic
attr t.r.sp.n_Rolladen_Window room Test.Rollladen.sp


Zum Konfigurieren von Türkontakt und Rollladen initial ausführen (in fhem Befehlszeile einkopieren):
{ WinShutterLink("t.r.sp.tuerkontakt_re","t.r.sp.rollo_re",30,10,0,100,20) }
Dabei sind die Parameter:

t.r.sp.tuerkontakt_re	Device Türkontakt
t.r.sp.rollo_re	Device Rollo
30	Lüften-Position des Rollos, wenn Tür offen ist
10	Lüften-Position des Rollos, wenn Tür gekippt ist
0	Soll-Position des Rollos nach autom. Schließen
100	Soll-Position des Rollos nach autom. Öffnen
20	Schwellwert des Rollos, ab der es autom. geöffnet wird, sollte die Tür offen sein (Schutz vor Eindringen) Ist das Rollo darunter, wird es bis zu dieser Position geöffnet, wenn die Tür beim autom. Öffnen offen steht.

ToDos:

• Testen :-\ in Reallife mit "echten" Rollläden, bisher teste ich nur mit Dummies
• Seiteneffekte abfangen
• Auf Motorbewegungen reagieren
• Timer erstellen mit min/max/Sonnenstandzeiten (dazu auch ein userattr je Rollladen mit Horizon-/Light-/Weather-Wert o.ä. aus twilight hinterlegen)
• GUI
• Beschattung

Grüße,
spi

Nachtrag: WinShutterLink habe ich angepasst (die Reihenfolge der userattr-Einträge geändert), damit auch alle angelegt werden, die gleich beginnen. Also erst die kürzeren und dann die längeren userattr (z.B. zuerst ShutterMaxClosed, dann erst ShutterMaxClosedIfOpen).

Zitat von: spi3845 am 10 April 2017, 22:03:44
Auf den Motor zu triggern führt zu einer Verzögerung. Denn erst gibt es irgendein Ereignis (Taste wird gedrückt oder Timer feuert), das wird verarbeitet und dann triggert der Aktor den Motor.

Im realen Leben stimmen diese Annahmen m.E. leider nicht immer. Auf "motor: down" und "motor: stop" habe ich nur deswegen ein notify gelegt, weil bei einem Tastendruck am Aktor selbst (also am eingebauten Schalter) eben nur diese beiden (bzw. noch "up") kommen. "stop" braucht man auch, weil die Alternative wäre, Änderungen im Device-STATE auszuwerten. Diese kommen während des Fahrens uU aber zum einen sehr schnell, können andererseits jedoch erst sinnvoll ausgewertet werden, wenn eine gewisse Zeit keine Änderung mehr kommt. Sonst wäre manches einfacher ;), weil man dann nicht nochmal prüfen müßte, ob alle Parameter bereits geprüft und richtig gesetzt sind.

Zitat von: spi3845 am 10 April 2017, 22:03:44...Der Timer ist im endlichen Automaten ein Ereignis wie "Tür auf"...

Achtung: Die Begrifflichkeit ist etwas anders als das, was ich bisher gedacht habe. Ich verstehe das so und habe das bisher auch in den Beiträgen entsprechend verwendet:
- Ein Ereignis ist irgendetwas, was mit einem "notify" ausgewertet werden kann. Dieses kann dann der perl-Funktion Informationen übergeben, die erst durch das Ereignis näher konkretisiert werden, insbesondere $NAME und $EVENT (oder Teile davon). Wenn ich von "Event" spreche, meine ich also, ein notify wird getriggert werden (oder könnte es werden, wenn es eines gäbe) und der Übergabewert (verkürzt zu das "Event") sollte dann zukünftig auch $EVENT (oder uU. Teile davon) sein.
- Ein Timer ist etwas, was rein zeitbasiert geschieht, klassischerweise ein "at". Dieses kann natürlich auch Ereignisse auslösen.

Meine Idee zur Aussperrschutz- und Lüftungsfunktion (nicht aber Eindringschutz) bisher war, in diesem Sinne rein Event-basiert vorzugehen, damit jeder diese Funktion nutzen kann, unabhängig davon, ob er die anderen Teile, die noch zu entwickeln wären (1. Morgens auf/abends zu bzw. 2. Beschattung) ebenfalls nutzen will.

Zitat von: Beta-User am 11 April 2017, 09:11:01
Achtung: Die Begrifflichkeit ist etwas anders als das, was ich bisher gedacht habe. Ich verstehe das so und habe das bisher auch in den Beiträgen entsprechend verwendet:
- Ein Ereignis ist irgendetwas, was mit einem "notify" ausgewertet werden kann. Dieses kann dann der perl-Funktion Informationen übergeben, die erst durch das Ereignis näher konkretisiert werden, insbesondere $NAME und $EVENT (oder Teile davon). Wenn ich von "Event" spreche, meine ich also, ein notify wird getriggert werden (oder könnte es werden, wenn es eines gäbe) und der Übergabewert (verkürzt zu das "Event") sollte dann zukünftig auch $EVENT (oder uU. Teile davon) sein.
- Ein Timer ist etwas, was rein zeitbasiert geschieht, klassischerweise ein "at". Dieses kann natürlich auch Ereignisse auslösen.

Meine Idee zur Aussperrschutz- und Lüftungsfunktion (nicht aber Eindringschutz) bisher war, in diesem Sinne rein Event-basiert vorzugehen, damit jeder diese Funktion nutzen kann, unabhängig davon, ob er die anderen Teile, die noch zu entwickeln wären (1. Morgens auf/abends zu bzw. 2. Beschattung) ebenfalls nutzen will.

Ich meine zu verstehen, vielleicht aber auch nicht  ???
Ereignisse beziehst Du rein auf durch notify auswertbar, z.B. "Tür auf" oder "Tür zu", aber auch "motor:down" weil jemand zuvor eine (physische) Taste gedrückt hat.

Ein Fahrkommando aus der fhem GUI wäre auch ein Ereignis - könnte ja z.B. ein Dummy aka virtuelle Taste sein, der durch ein notify registriert wird.

Die ursprüngliche Version deiner Funktion reagierte auf die Events "Tür auf/zu/gekippt" und "motor:.*".

Das Fahren des Rollladen über die GUI (oder auch Timer oder sonst irgendeiner Aktionen in fhem) könnte jetzt auf zweierlei Weise erfolgen:

• zu den ursprünglichen Events in deiner Funktion kämen noch Events "auf" und "zu" hinzu und das Fahren des Rollladens wäre ein Aufruf der Funktion mit den Parametern Rollladen-Device und "auf" oder "zu"
• der Rollladen wird direkt getriggert (z.B. "set Rollladen 0" und das Fahren wird dann über den Event "motor:.*" (in diesem Fall "motor:down") erkannt

Ich habe Weg 1 abgebildet (auch wenn ich die Events "Timer_down" und "Timer_up" genannt habe, sind sie generelle Events für "zu" und "auf"). Wenn ich dich richtig verstehe, bildest Du die Steuerung über Weg 2 ab? Oder stehe ich immer noch auf dem Schlauch? Was auch gut möglich (und wahrscheinlich) ist  :D

Wenn das Szenario tatsächlich so wie beschrieben ist, was sind aus deiner Erfahrung Vor-/Nachteile der einen gegenüber der anderen Lösung? Ich lerne immer noch fhem und die Lernkurve der letzten Tage war so etwas von steil - echt danke dafür!

Grüße,
spi

Zitat von: spi3845 am 11 April 2017, 21:33:36
Ich meine zu verstehen, vielleicht aber auch nicht  ???

Das haut in etwa so hin, wie Du das jetzt beschreibst.

ZitatEin Fahrkommando aus der fhem GUI wäre auch ein Ereignis - könnte ja z.B. ein Dummy aka virtuelle Taste sein, der durch ein notify registriert wird.

Es braucht nicht mal einen Dummy, die Gerätedarstellung eines Rolladenaktors in FHEMWEB tut es auch (oder ein Set-Kommando, das von einem at, weekdaytimer usw., aus aufgerufen wird...)

ZitatDie ursprüngliche Version deiner Funktion reagierte auf die Events "Tür auf/zu/gekippt" und "motor:.*".

Korrekterweise neben den Fenster-Kontakt-Events nur auf "motor:.stop", wenn also der Rolladen - warum auch immer - angehalten hat.
In der dev-Version ist im Moment noch ein weiteres notify vorgesehen, dass auch auf "level:.set.*" und "motor:.down.*" reagiert. Ersteres ist unglücklich, weil es eigentlich besser wäre, direkt das Geräte-"set" abzufangen, so konnte ich zwar doppelte Events vermeiden, es wäre aber m.E. besser, die level-sets schlicht in der Auswertefunktion zu verwerfen. Dann wird mit der zweiten Funktion geprüft, ob ein neuer "onHold"-Wert gesetzt werden muß und der Rolladen zwischendurch anhalten soll (neuer set-Befehl).
Das Problem dabei ist "nur", dass es zwei Events gibt, die kurz nacheinander kommen und man aber den 2. (motor:.down) ignorieren kann/muß, wenn man bereits kurz vorher ein "set" hatte. Daher der Versuch mit  ReadingsAge().

So richtig kann ich nicht erkennen, was mit den unterschiedlichen Wegen gemeint ist. Im Kern geht es ja nur darum, abhängig vom Fensterzustand bzw. dessen Änderung zu erkennen, was jetzt mit dem Rolladen geschehen soll bzw. optimalerweise schon zu verhindern, dass der Aktor "falsche" Befehle überhaupt erhält. Das geht jedenfalls dann nicht, wenn jemand direkt eine Taste drückt, für den Rest könnte es sein, dass man durch ein noch früheres Abfangen des Set-Kommandos aus FHEM sogar verhindern könnte, dass "level:.set.*" überhaupt geschieht. Keine Ahnung, muß erst mal coden. 

ZitatWenn das Szenario tatsächlich so wie beschrieben ist, was sind aus deiner Erfahrung Vor-/Nachteile der einen gegenüber der anderen Lösung? Ich lerne immer noch fhem und die Lernkurve der letzten Tage war so etwas von steil - echt danke dafür!

Danke zurück!
Meine "Programmier-Erfahrung" ist kaum größer als Deine, zu Vor- und Nachteilen kann ich daher wenig sagen (zumal ich keine signifikanten Unterscheiden feststellen kann. Bislang habe ich nur etwas mit C (Arduinos) rumgespielt, das war's aber. Diese textorientierte Denkweise von perl ist auch für mich ganz neu, habe die vergangenen Tage auch recht viel dazugelernt (mußte aber auch viel experimentieren, insbesondere der erste Ansatz, nur vereinfachte Infos vom notify an perl zu übergeben war vermutlich nicht hilfreich). Die "neue" Funktion zum Neusetzen von Zielwerten ist da deutlich besser. Sogar an den "Modulgedanken" habe ich mich gewöhnt, allerdings keinen Plan, was das für Vorteile hätte ("softpeering" erleichtern, andere Initialisierungsfunktionen für die Attr aufrufen? Notifys als interne Funktion nutzen? Vielleicht kann mir da ja jemand mal auf die Sprünge helfen?

Gruß, Beta-User   

Hier nun die ordentlich kommentierte Version meines Scripts in der 99_myUtils.pm https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545 (https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545)
Bei weiteren Fragen einfach melden.

Und die gewünschten Überlegungen:

• Was ist das Ziel der Lösung?
  Rolladenautomatisierung für eine große Anzahl von Rollos (Verdunkelung und Beschattung). Einfache Parametrisierung über eine GUI. Möglichst wenige Komponenten (dummys, doifs, at, usw.), leichte Erweiterbarkeit (Rollos, Funktionen), vollautomatischer Betrieb (möglichst keine Benutzereingriffe nötig), Mehrbenutzerfähigkeit (3 Wohneinheiten), "objektorientiertes Design" (keine dummys für Parameter/Readings der Rollos, sondern alles beim "Objekt"). Mittelfristig sollen Parameter von Nicht-Experten per Floorplan auf einem  Touchdisplay einstellbar sein. Anwesenheitssimulation in Kombination mit dieser Automatik. 
  
• Was ist bereits umgesetzt?
  Verdunkelung, Beschattung, GUI, automatisches Parametrieren von neuen Rollos, vollautomatischer Betrieb (Sommer/Winter, kühle/heiße Tage), unabhängige Wohneinheiten
  
• Was fehlt noch?
  Bedienung über Floorplan (z.B. setzen der gewünschten Beschattungsposition per Touchscreen --> Zitat: "genau wo das Rollo jetzt steht soll es immer sein beim Beschatten"). Einbinden der Anwesenheitssimulation in die Rollosteuerung.
  
• Was sind die Voraussetzungen (HW/SW) für diese Lösung?
  Rollladen-Aktoren, welche die Position melden, Helligkeitssensoren für jede (gewünschte) Hausseite, Temperatursensor(Außentemperatur), Fensterkontakte für Terrassentüren. (Bei mir alles Homematic)
  
• Warum wurde die Lösung so implementiert?
  Übersichtlichkeit. Ich möchte, dass meine Lösungen auch von anderen (möglichst) einfach übernommen werden kann. (z.B. Konfiguration der Rollos)
  
• Was würde ich heute anders machen?
  Kann ich so nicht sagen. Optimierungspotential ist genug vorhanden. Trotz der guten Vorsätze ist es trotzdem viel "Zeug" geworden (doifs, weekdaytimers, dummy, notify usw.) --> weitere "Monolithisierung" und wenn das nicht möglich ist, ein "Installationsscript"(vgl. mit dem Parametrisieren der Rollos)
  

Hugo

Zitat von: hugomckinley am 12 April 2017, 20:14:30
Hier nun die ordentlich kommentierte Version meines Scripts in der 99_myUtils.pm https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545 (https://forum.fhem.de/index.php/topic,61844.msg532545.html#msg532545)
Bei weiteren Fragen einfach melden.

Hugo

Danke! Die nächsten freien Tage sind versaut mit dem Lesen von Code 8)

Hallo zusammen,

habe derweil auch meine Gedanken in Code gegossen, scheint zu funktionieren, ist aber noch nicht umfassen getestet.

Achtung: Bitte die notifys prüfen.
Es gibt jetzt 2 Stück:
Eins für die Basisfunktionalität, die auf das stop wartet und sich jetzt nur noch einmal selbst unnötig triggert.
Das Andere fängt Set-Befehle ab.

Code ist wieder auf github (https://github.com/rejoe2/FHEM/blob/master/myShutter/99_myShutterUtils.pm), wobei ich den Dev-tree geschlossen habe, es ist alles also wieder in Master zu finden.

Über Rückmeldungen (und ggf. Testergebnisse) würde ich mich freuen. Wenn es alles zufriedenstellend läuft, mach' ich vielleicht auch eine schöne Doku ;).

@Hugo:  nochmals Danke für dieses sehr anspruchsvolle Beispiel, Deine neuen Kommentare schaue ich mir vermutlich über die Feiertage mal an, jetzt schnaufe ich erst mal durch, bevor es an's Erstellen einer eventuellen Timer-Funktionalität geht.

@spi: Interessanter Ansatz, die weekdaytimer-Funktionalität zu generalisieren!

Gruß, Beta-User

Noch ein update nach etwas testen und weiterüberlegen:

Auch das Unterbrechen von Fahrten scheint jetzt gut zu funktionieren, ohne dass sich das ununterbrochen selbst triggert.

Code liegt wieder im dev-tree auf Github (https://github.com/rejoe2/FHEM/tree/dev-module).

Wesentlicher Unterschied: Es gibt jetzt nur noch ein notify! Die Idee dahinter ist, das tatsächlich in Richtung eines Moduls auszubauen. Vorläufiger Name: HM-Shuttertools?

So ganz habe ich allerdings die Dokumente zur Modulentwicklung noch nicht verstanden, wenn da also jemand Hilfestellung leisten möchte: GERNE!!!

Was soll das Modul können:
1. (Version 0.1) Die Fenster-auf/gekippt-Lüftungs-/Aussperrschutzfunktion durch Überwachung aller HM-Rolladenaktoren übernehmen
2. (Später, Version 0.5): Zeitgrenzen + Bedingung (optional) für Öffnen und Schließen (je Rolladen individuell per Attribute einstellbar)
3. (evtl., Version 0.9): Beschattungsteuerung über Attribute je Rolladen

Da die sehr speziellen Readings der HM-Devices ausgewertet werden, ist die Einsatzmöglichkeit - jedenfalls was die Rolladensteuerung angeht - bis auf weiteres auf diese Geräteart beschränkt.

Das HM-Shuttertools-Device soll dabei dazu dienen, die zu überwachenden Rolladen und Tür/Fensterkontakte miteinander bekannt zu machen und die notwendigen Attribute zu generieren, dafür default-Werte vorzuhalten und dann bei Erweiterung der Funktionalität auf einfachem Weg die Ersteinrichtung erleichtern.

Die weitere Einstellung für die einzelnen Rolläden könnte man dann z.B. per Readingsgroup recht komfortabel vornehmen.

Zu Version 0.1 (Aussperrschutz etc.) dürfte eigentlich mit Unterstützung eines erfahrenen Modulentwicklers nicht mehr so viel fehlen?

Was Version 0.5 angeht, soll im Prinzip einmal am Tag (bzw. bei Änderung der Attribute) eine Berechnung der Werte erfolgen, wobei es eigentlich möglich sein sollte, auch perl-code (sunrise, sunset) als Attribut zu hinterlegen und $we zu verwenden (zwei "Zeitzonen"); schön wäre es, wenn man das optional über eine "Gruppen"zugehörigkeit regeln könnte (und darüber ggf. auch ausschalten, also "Manuell"=keine Automatik, "SingleMode"=die beim Rolladen eingstellten Werte, "Gruppe1" (-3)=Gruppenwerte nehmen). Zum frühesten Schaltzeitpunkt wäre dann eine optionale Bedingung zu prüfen (hell genug?) und ggf. ein notify zu definieren, das das dann bis zum spätesten Zeitpunkt überwacht usw..

Zu Beschattung: noch keine konkrete Vorstellung, das darf wachsen...

Über Rückmeldung (und Hilfe beim "Modulieren") würde ich mich freuen!

Gruß, Beta-User

Hallo Zusammen,

ihr scheint ja ganz schön Gas zu geben hier!  :o
Ich war bis heute im Urlaub und schaue erst jetzt wieder richtig rein. Ich muss gestehen, dass ich in euer Projekt noch nicht hineingeschaut habe. Die Zeitsteuerung ist bei mir während des Urlaubs gut gelaufen. Ich habe bis jetzt aber nur die Zeitsteuerung fertig. Abschattung und die Automatik beim Öffnen eines Fensters wollte ich aber auch noch einbauen.
Bis jetzt habe ich meine Rolllanden mit einigen User-Attributen versehen. Für jeden Rollladen wird nach Aufruf der Perl-Routine "Auto_Rol_calc_at" in meiner 99_myUtils.pm mehrere ats angelegt. Für 00:05Uhr wird auf jeden Fall ein tägliches at angelegt, welches diese Perl-Routine für diesen Rollladen ausführt und die aktuellen ats für Öffnen und Schließen anlegt. Dabei werden die Vorgaben direkt aus den User-Attributen des Rollladen gelesen und verwendet. Ist dort kein automatisches Öffnen und/oder Schließen ausgewählt, dann wird auch kein at dafür erzeugt.

Eventuell könnt ihr den Code ja für das Modul brauchen - Ich kann die aktuelle Routine (da wird sich aber bestimmt noch was dran ändern) gerne nochmal posten, wenn ihr Interesse habt!?

Für die Abschattung habe ich mir überlegt, dass man dafür entweder ein doif oder irgendwie ein Notify an Twilight oder ähnliches heften könnte (welches dann auch über die Perl-Routine automatisch generiert werden könnte). Damit könnte man dann die Abschaltung triggern...

Gruß, Bernd

Hier mal ein Screenshot-Ausschnitt der erzeugten Timer...

Zitat von: Beta-User am 15 April 2017, 14:47:27
Wesentlicher Unterschied: Es gibt jetzt nur noch ein notify! Die Idee dahinter ist, das tatsächlich in Richtung eines Moduls auszubauen. Vorläufiger Name: HM-Shuttertools?

Wow, hätte nicht gedacht, dass sich das so rasant entwickelt! Perfekt!

Wenn ich das recht sehe, gibt es einige in diesem Thread, die sich an Rollladensteuerungen versuchen oder versucht haben. Können wir unsere gemeinsamen Ansätze irgendwie organisieren? Hinsichtlich eines Moduls wäre die Entwicklung neuer Funktionen, Doku, Test, Support dann einfacher.

Persönlich ist mein Problem aktuell, dass ich versuche, mehrere Code-Versionen, darunter meine eigene und die von Beta-User, zu testen und abzubilden und gleichzeitig die von anderen (z.B. hugomckinley) zu verstehen. Das kostet nicht nur viel Zeit, es ist auch extrem schwierig, die Ideen und Ansätze dahinter zu greifen. Einiges erschließt sich mir auch nicht auf den ersten oder zweiten Blick... 8)

Das Codieren einer Rollladensteuerung ist das eine, das andere ist der grundlegende Ablauf dahinter im Sinne eines Zustandsautomaten, also welcher neue Zustand tritt ein, wenn ein Rollladen ganz offen ist und Ereignis x oder y tritt ein. Das ist erst einmal Aufwand für die Erzeugung der Darstellung, ich glaube aber, dass es für ein Modul extrem hilfreich ist, um die unterschiedlichen Zustände und Ereignisse abzubilden. Es hilft dann später bei der Codierung und auch beim Verstehen des Codes, ganz zu schweigen vom Testen...

Ein Beispiel einer wirklich simplen Rollladensteuerung hatte ich zuvor schon mal gepostet, anbei nochmal die Datei. Erstellt mit LibreOffice Draw, das ich hierfür nicht wirklich gut finde.

• Was haltet ihr von der Idee, wenn wir eine generelle Rollladensteuerung grafisch als Zustandsautomat abbilden (dabei den Zuständen Kurznamen geben, um sie im Code wiederzufinden)?
• Wenn Zustimmung, habt ihr einen Vorschlag, wie man mit wenig Aufwand die grafische Darstellung erreichen kann? Wie gesagt, halte ich LibreOffice Draw für zu aufwendig. Ich denke da an irgendetwas textbasiertes, das über git verteilt werden kann.

Grüße,
spi

https://www.draw.io (https://www.draw.io)

Zitat von: Cluni am 16 April 2017, 01:24:46
https://www.draw.io (https://www.draw.io)

Cool, gefällt mir. Wie ist deine Erfahrung in der Zusammenarbeit mit mehreren bzgl. Änderungen nachverfolgen?

Habe parallel GraphViz getestet (http://www.graphviz.org/ (http://www.graphviz.org/)). Könnte als Textdatei über git verteilt werden (mit Nachverfolgen der Änderungen). Beispiel anbei - ist noch nicht schön, aber schnell und einfach :)

ea_rollo_001.gv

digraph finite_state_machine {
        rankdir=TB; /* LR für von links nach rechts */
        size="8,5"
        node [shape=box,style="rounded,bold"];
        ro [color=black,label="Rollo oben\n[ro]",labelloc=b];
        lv [color=blue,label="Lüften viel\n[lv]",labelloc=b];
        lw [color=blue,label="Lüften wenig\n[lw]",labelloc=b];
        ru [color=black,label="Rollo unten\n[ru]",labelloc=b];
        ro -> ru [ label = "Rollo zu" ];
        ru -> ro [ label = "Rollo auf && Tür!=offen" ];
        ro -> lw [ label = "Rollo zu && Tür=gekippt" ];
        lv -> lw [ label = "Tür kippen" ];
        lw -> ru [ label = "Tür zu" ];
        lv -> ru [ label = "Tür zu" ];
        ru -> lw [ label = "Tür kippen" ];
        ru -> lv [ label = "Tür öffnen" ];
        lw -> lv [ label = "Tür öffnen" ];
        lw -> ro [ label = "Rollo auf && Tür!=offen" ];
}


Png erstellen durch:
dot -T png ea_rollo_001.gv -o ea_rollo.png

Grüße,
spi

digraph finite_state_machine {
rankdir=TB; /* LR für von links nach rechts */
node [shape=box,style="rounded,bold"];
ro [color=black,label="Rollo steht oben\n[ro]",labelloc=b];
rülo [color=blue,label="Rollo steht oberhalb Position\n'Lüften bei offener Tür'\n[rülo]",labelloc=b];
rfülo [color=red,label="Rollo fährt oberhalb Position\n'Lüften bei offener Tür'\n[rfülo]",labelloc=b];
rfalo [color=red,label="Rollo fährt an Position\n'Lüften bei offener Tür'\n[rfalo]",labelloc=b];
lo [color=green,label="Rollo steht in Position\n'Lüften bei offener Tür'\n[lo]",labelloc=b];
rülg [color=blue,label="Rollo steht oberhalb Position\n'Lüften bei gekippter Tür'\n[rülg]",labelloc=b];
rfülg [color=red,label="Rollo fährt oberhalb Position\n'Lüften bei gekippter Tür'\n[rfülg]",labelloc=b];
rfalg [color=red,label="Rollo fährt an Position\n'Lüften bei gekippter Tür'\n[rfalg]",labelloc=b];
lg [color=green,label="Rollo steht in Position\n'Lüften bei gekippter Tür'\n[lg]",labelloc=b];
rulg [color=blue,label="Rollo steht unterhalb Position\n'Lüften bei gekippter Tür'\n[rulg]",labelloc=b];
rfulg [color=red,label="Rollo fährt unterhalb Position\n'Lüften bei gekippter Tür'\n[rfulg]",labelloc=b];
ru [color=black,label="Rollo steht unten\n[ru]",labelloc=b];
ro -> ru [ label = "Rollo zu" ];
ru -> ro [ label = "Rollo auf && Tür!=offen (Einbruchschutz)" ];
ro -> ro [ label = "Rollo auf && Tür=offen (Aussperrschutz)" ];
ro -> lg [ label = "Rollo zu && Tür=gekippt" ];
lo -> lg [ color=green,fontcolor=green,label = "Tür kippen" ];
lg -> ru [ label = "Tür zu" ];
lo -> ru [ label = "Tür zu" ];
ru -> lg [ color=green,fontcolor=green,label = "Tür kippen" ];
ru -> lo [ color=green,fontcolor=green,label = "Tür öffnen" ];
lg -> lo [ color=green,fontcolor=green,label = "Tür öffnen" ];
lg -> ro [ label = "Rollo auf && Tür!=offen" ];

ro -> rfülo [ label = "Rollo zu" ];
rfülo -> rülo [ color=red,fontcolor=red,label = "Stopp gedrückt" ];
rfülo -> rfalo [ color=orange,fontcolor=orange,label = "weiter 'Rollo zu'" ];
rfalo -> rfülg [ color=orange,fontcolor=orange,label = "weiter 'Rollo zu'" ];
rfülg -> rülg [ color=red,fontcolor=red,label = "Stopp gedrückt" ];
rfülg -> rfalg [ color=orange,fontcolor=orange,label = "weiter 'Rollo zu'" ];
rfalg -> rfulg [ color=orange,fontcolor=orange,label = "weiter 'Rollo zu'" ];
rfalo -> lo [ color=red,fontcolor=red,label = "Stopp gedrückt" ];
rfalg -> lg [ color=red,fontcolor=red,label = "Stopp gedrückt" ];
rfulg -> rulg [ color=red,fontcolor=red,label = "Stopp gedrückt" ];
rülo -> rfülo [ label = "Rollo auf/zu" ];
rfülo -> ro [ color=orange,fontcolor=orange,label = "weiter 'Rollo auf'" ];
rülg -> rfülg [ label = "Rollo auf/zu" ];
rfülg -> rfalo [ color=orange,fontcolor=orange,label = "weiter 'Rollo auf'" ];
rulg -> rfulg [ label = "Rollo auf/zu" ];
rfulg -> rfalg [ color=orange,fontcolor=orange,label = "weiter 'Rollo auf'" ];
{ rülo,rülg,rulg -> lo [ color=purple,fontcolor=purple, label = "Tür öffnen" ] };
{ rülo,rülg,rulg -> lg [ color=purple,fontcolor=purple, label = "Tür kippen" ] };
{ rfülo,rfalo,rfülg,rfalg,rfulg -> lo [ color=purple,fontcolor=purple, label = "Tür öffnen" ] };
{ rfülo,rfalo,rfülg,rfalg,rfulg -> lg [ color=purple,fontcolor=purple, label = "Tür kippen" ] };

}

@Beta-User: ein quick&dirty-Versuch, die Zustände deiner Funktion abzubilden (Ereignisse zu prüfen, insbesondere die in lila Farbe).

Zustände:
Schwarz = Rollo im Anschlag ober oder unten
Grün = Rollo bei geöffneter/gekippter Tür
Blau = Rollo in anderen Positionen
Rot = Rollo in Bewegung

Ist das ein gangbarer Weg, eine Rollladensteuerung abzubilden? Oder über https://www.draw.io (https://www.draw.io)? Was meint ihr?
Auf jeden Fall gilt es, das Modell zu vereinfachen - nicht alle Zustände werden gebraucht...

Grüße,
spi

Moin zusammen,

Danke für den Versuch eine Visualisierung! Es erinnert an die HM-Statemachine-Beschreibung im Einsteigerdokument, die wirklich hilfreich war, um zu verstehen, wie so ein Gerät "denkt" (und das dann ggf. auch mit einem Arduino etc. für andere Bereiche abzubilden).

Was ich in der Abbildung so nicht gefunden habe, ist die "Mitnahme" der "Soll-Position" beim Schließen des Fensters (wenn unterhalb des aktuellen Levels). Ansonsten bleiben ja auch alle Zwischenaktionen zulässig, also bei offenem Fenster ein "set 50" zu machen, wenn "40" der Offen-Level ist. Ansonsten ist meine Feststellung in der Praxis, dass jeder Versuch der Vereinfachung der Zustände zu unerwünschten Ergebnissen führt... Nichts schlimmes, aber eben auch nicht intuitiv. Dazu kommt, dass es manchmal nicht so einfach ist, bis man die "richtigen" Ereignisse und Informationen abgreift (bzw. alle); das führt dann zu solchen "Hä, warum denn jetzt auf einmal dieser Parameter hier?!?.." - ??? -Erlebnissen und Knoten im Hirn. Habe aber den Eindruck, dass der code so langsam aber sicher alle Varianten abbildet.

Auch gut wäre eine einheitliche Namenskonvention. (Bisher habe ich aus dem Grund nur 4 "verattributiert", 2 Jalousien und 2 Rolläden). Das ist auch mit ein Grund für die Modul-Idee, dann geht es nämlich relativ einfach, die Attribute einheitlich setzen zu lassen und die erforderlichen notifys intern zu verwalten (?).

"Mein" Code und Hugos Lösung sind auch nicht grundsätzlich unterschiedlich, sondern lösen jeweils andere Teilaspekte, wobei meine Motivation erst mal die war, perl zu verstehen, um die Grundlage dafür zu haben, das in die Richtung zu lösen, wie @cluni das mit den Timern schon geschafft hat. Damit könnte ich weitere 6 DOIF's aus der Konfiguration werfen, die nicht immer so reagieren, wie ich das nach dem code vermuten würde ;). Damit wäre dann nur noch die Urlaubssimulation in Teilen (Licht) nach weekdaytimer zu überführen und ich dann DOIF-los 8).

@cluni: Für Code-Beispiele wäre ich also dankbar, wobei es m.E. in der "Modulvariante" so sein sollte, dass diese Timer nicht als eigene Geräte aufgeführt werden, sondern als interne Timer beim "HM-ShutterTools-Gerät". Das würde dann auch die zeitgesteuerte Neugenerierung übernehmen (den regelmäßigen Timer beim starten selbst setzen).

Der Ansatz, das gemeinsam weiterzuentwickeln, gefüllt mir sehr gut! Hätte nur 2 Bedingungen: Möglichst keine weiteren Abhängigkeiten (perl-Module) und (zwingend!) in der Doku keine DOIF. (Wer mag, kann das verwenden, es schließt sich nicht aus. Aber es geht sicher auch ohne...).

Zu Hugos code noch:
- Er hat m.E. den "Nachteil", dass es recht schwierig zu verstehen ist, welcher Parameter was bewirkt und er mit seiner großen Lösung eben auch viele Parameter braucht. Es wäre für ein Modul m.E. besser, wenn es mit dem Verständnis des Benutzers wachsen könnte (neue Teilfunktionen nur bei Bedarf, zusätzliche Gruppen für Beschattung usw.).
- Dann braucht es eben noch relativ viele einzelne Geräte (Timer, DOIF, ...) die konfiguriert werden wollen. Das geht ohne Modul wohl nur so (?), macht es aber nicht eben intuitiv vom Verständnis.
- Ansonsten sind mir bei der Durchsicht nur 2 Dinge aufgefallen, die eventuell "eleganter" gelöst werden können:
-- devspec2array statt alle Geräte zur Konfiguration zu durchlaufen und
-- (zu den ReadingsGroups): ob die Readings in den userattr nicht teilweise direkter gesetzt werden könnten (?)

Es wäre jedenfalls klasse, wenn wir da was miteinander hinbekämen, das es allen einfacher macht, zu einer (halbwegs) intuitiven und gut skalier- und konfigurierbaren Lösung zu kommen.

Frohe Ostern allseits,

Beta-User

Hallo zusammen und frohe Ostern!

Bin momentan nicht zu Hause, daher kann ich grade den Code nicht posten. Grundsätzlich könnte man (wenn sie denn stören) die Timer auch verstecken. Das hatte ich auch schon überlegt, aber finde es momentan zum Fehler suchen einfacher, wenn sie sichtbar sind.
Mit einem Durchlauf für alle Geräte wollte ich auch noch einbauen. Dürfte auch eigentlich nicht zu schwierig sein - man müsste nur die Geräte mit dem entsprechenden Namen auslesen und alle in einer for- oder while-Schleife durchlaufen. Die einzelnen Timer für hoch und runter wurden natürlich bleiben, aber das ist ja logisch. Vielleicht baue ich das nachher noch schnell um, bevor ich den Code poste....


Gesendet von iPhone mit Tapatalk

Zitat von: Beta-User am 16 April 2017, 08:02:22
Danke für den Versuch eine Visualisierung! Es erinnert an die HM-Statemachine-Beschreibung im Einsteigerdokument, die wirklich hilfreich war, um zu verstehen, wie so ein Gerät "denkt" (und das dann ggf. auch mit einem Arduino etc. für andere Bereiche abzubilden).

Was ich in der Abbildung so nicht gefunden habe, ist die "Mitnahme" der "Soll-Position" beim Schließen des Fensters (wenn unterhalb des aktuellen Levels).

Ich kann die Mitnahme "Soll-Position" mit einzeichnen, würde aber gerne erst einmal diskutieren, ob wir die Darstellung fortführen wollen. Sie ist jetzt schon ziemlich umfangreich. Habe geute etwas mit GraphViz rumgespielt und es ist zwar einfach, neue Zustände und Übergänge aufzunehmen, auf die Darstellung selbst hat man aber wenig Einfluss. Das Ergebnis kann dann etwas überwältigend sein 8) Anbei eine aktualisierte Grafik. Wenn gewünscht, kann ich die pflegen, würde dann aber vorschlagen, dass wir

• sie auf github ablegen (wg. Änderungen verfolgen)
• im Code die Zustände aus der Grafik in den Kommentaren kenntlich machen (ich kann gerne andere Kürzel einbauen)
• die Zustandsgrafik prüfen auf redundante Zustände und Ereignisse, um sie zu vereinfachen

Zitat von: Beta-User am 16 April 2017, 08:02:22
Der Ansatz, das gemeinsam weiterzuentwickeln, gefüllt mir sehr gut! Hätte nur 2 Bedingungen: Möglichst keine weiteren Abhängigkeiten (perl-Module) und (zwingend!) in der Doku keine DOIF. (Wer mag, kann das verwenden, es schließt sich nicht aus. Aber es geht sicher auch ohne...).

Also doch keine DOIFs? Damit ist meine allererste Frage beantwortet  :D
Im Ernst, pflichte dem bei, keine Abhängigkeiten und Einfachheit/Schlichtheit, damit das ganze pflegbar bleibt.

Zitat von: Beta-User am 16 April 2017, 08:02:22
- Ansonsten sind mir bei der Durchsicht nur 2 Dinge aufgefallen, die eventuell "eleganter" gelöst werden können:
-- devspec2array statt alle Geräte zur Konfiguration zu durchlaufen und
-- (zu den ReadingsGroups): ob die Readings in den userattr nicht teilweise direkter gesetzt werden könnten (?)

devspec2array klingt interessant, würde dann aber auch Rollläden erwischen, für die wir keine Automatik wollen (wer kann so etwas wollen?). Wie würden dann die entsprechenden Fensterkontakte zugeordnet werden? Über Namenskonvention (z.B. Name FK = Name des Rollos mit angehängtem FK?) oder standardmässig none zuweisen und dann manuell in den userattr setzen? Oder eine zweispaltige Liste, die wir über die GUI zuordnen... Geht so etwas überhaupt?

Was meinst Du mit Readings in den userattr direkter setzen?

Zitat von: Beta-User am 16 April 2017, 08:02:22
Frohe Ostern allseits,

Ebenso!

Grüße,
spi

Zitat von: spi3845 am 16 April 2017, 18:26:24
Ich kann die Mitnahme "Soll-Position" mit einzeichnen, würde aber gerne erst einmal diskutieren, ob wir die Darstellung fortführen wollen. Sie ist jetzt schon ziemlich umfangreich.

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)...
M.E. ist eine graphische Darstellung hilfreich, um das erst mal zu verstehen, aber wenn es mal funktioniert, sollte es intuitiv sein, so dass man das eher als Referenz für Fragen sehen sollte, wenn es welche gibt.
Kann das bei Bedarf gerne auf Github einpflegen.

Zitatdevspec2array klingt interessant, würde dann aber auch Rollläden erwischen, für die wir keine Automatik wollen (wer kann so etwas wollen?).

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

ZitatWie würden dann die entsprechenden Fensterkontakte zugeordnet werden?

Die Zuordnung soll über eine "set"-Funktion des Moduls erfolgen, was man 1x pro Paar für diesen Teil der Funktionalität machen müßte. Dafür ist man in der Wahl der Namen frei, kann also nehmen, was da ist, man braucht kein "Name FK = Name des Rollos mit angehängtem FK?".
Über eine GUI wäre schön, aber ich denke, wenn man z.B. sowas wie set RolloTools softpair Rolladen_WZ_SSO Fenster_Wohnzimmer_1 <offenWert><tiltedWert> einmalig eingeben muß und die letzten beiden Werte auch als Default nehmen bzw. später einfach über eine Readingsgroup ändern kann, ist das ok.

ZitatWas meinst Du mit Readings in den userattr direkter setzen?

Hugo verwendet in der ReadingsGroup noch eine command-definition, um darüber dann ein "attr ..." auszuführen. M.E. braucht es das nicht, habe das aber - außer für die max-Level - noch nicht weiter ausprobiert.

Ein bißchen "moduliert" habe ich schon, bin aber nicht recht weitergekommen, weil trotz "copy/paste" nicht mal ein "define" klappen wollte. Werde das mal bei Gelegenheit auf github legen, vielleicht hat ja jemand einen Tip dazu.

Gruß, Beta-User

Moin zusammen!

Soooo, ich habe noch ein wenig herumgespielt und möchte mal meinen aktuellen Stand posten. Es wird nun nur noch ein Timer für die Nacht erzeugt, worüber alle Rollladen abgearbeitet werden. (siehe Anhang)
Momentan ist nur die Zeitsteuerung fertig. Abschattung und Reaktionen auf z.B. Fenster-Öffnen fehlen noch gänzlich.

Damit alles so funktioniert, wie ich es mir gedacht habe, gibt es ein paar Vorbedingungen:

1. Meine Rollladen haben den Namen "Rol.xxx", wobei "xxx" für das Zimmer steht (Bsp: "Rol.Bad" oder "Rol.WZ.Seitentuer")

2. Allen Rollladen werden neue User-Attribute zugeordnet (die aber momentan noch nicht alle in Benutzung sind):
attr Rol\..* userattr Auto_Modus:bei_Abwesenheit,immer Auto_hoch:aus,Zeit,Astro Auto_runter:aus,Zeit,Astro Auto_offen_Pos:on,Luft,10,20,30,40,50,60,70,80,90 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 Auto_Fensterkontakt Auto_Luft_Fenster_offen:ja,nein Auto_Sperre_Fenster_offen:ja,nein
Initialisiert habe ich ein paar der Attribute wie folgt:
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
attr Rol\..* Auto_Luft_Fenster_offen ja
attr Rol\..* Auto_Sperre_Fenster_offen nein


3. Um die komplette Automatik auf einen Schlag ein- bzw auszuschalten habe ich mir zwei Dummies angelegt, die ich auch über Apple Home ändern kann:
Internals:
   NAME       Rolllanden.Automatik.morgens
   NR         273
   STATE      on
   TYPE       dummy
   Readings:
     2017-04-17 09:49:46   state           on
Attributes:
   alias      Automatik morgens
   genericDeviceType switch
   group      Rollladen_Automatik
   icon       weather_sun
   room       Haus,Homekit,Rollladen
   setList    on off
   sortby     2
   webCmd     on:off
Internals:
   NAME       Rolllanden.Automatik.abends
   NR         274
   STATE      on
   TYPE       dummy
   Readings:
     2017-04-17 09:49:42   state           on
Attributes:
   alias      Automatik abends
   genericDeviceType switch
   group      Rollladen_Automatik
   icon       weather_moon_phases_8
   room       Haus,Homekit,Rollladen
   setList    on off
   sortby     3
   webCmd     on:off

Hier der Code, der in der 99_myUtils.pm einzufügen ist (für Neulinge: nach dem Abspeichern nicht das "reload 99_myUtils.pm" vergessen!):
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_group_at($)
{
    #Als Parameter muss der Anfang der device-Namen übergeben werden, der bei allen Rollladen gleich ist
    my $group_name=shift(@_);
my @monitored=devspec2array("($group_name\..*)");

foreach my $dev (@monitored) {
    #Erst mal prüfen, ob das übergebene device überhaupt existiert und ob es ein Rollladen ist
    if (($defs{$dev}) and (AttrVal($dev,'subType','nv') eq 'blindActuator')) {

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

my $Ferien=ReadingsVal('Ferientag','state',-1);
my $Feiertag=ReadingsVal('Feiertag','state',-1);


        #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='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});


if ($A_Modus eq 'immer') {fhem("setreading $dev Auto_Modus Automatik auch bei Anwesenheit");}
elsif ($A_Modus eq 'bei_Abwesenheit') {fhem("setreading $dev Auto_Modus Automatik nur, wenn niemand zu Hause ist");}
fhem("setreading $dev Auto_hoch_Zeit --:--:--");
fhem("setreading $dev Auto_hoch_Pos ---");
fhem("setreading $dev Auto_hoch_Zeit --:--:--");

$Hoch_Zeit = randomtime_with_realtime("$A_Zeit_hoch_WE_Urlaub","$A_Zufall_Minuten","+"); # Zeit zum Hochfahren mit der Wochenend- bzw. Urlaubs-Zeit vorbesetzen

if ($A_hoch eq 'aus') {goto CHECK_SET_DOWN_TIME;} # Automatik für morgens (für diesen Rollladen) ausgeschaltet? ==> dann Sprung!
if (($wday > 5) or ($wday == 0) or ($Ferien == 1) or ($Feiertag == 1)) {goto ABWESENHEITSCHECK;} # Wochenende, Urlaub oder Feiertag? ==> dann Sprung

elsif ($A_hoch eq 'Astro'){ # Automatik (für diesen Rollladen) 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 (für diesen Rollladen) auf normalem Zeitprogramm?
$Hoch_Zeit = randomtime_with_realtime("$A_Zeit_hoch_frueh","$A_Zufall_Minuten","+");
}

ABWESENHEITSCHECK:
if ($A_Modus eq 'immer') {$hoch_at = "define $Rol_hoch_Timername at $Hoch_Zeit { if (ReadingsVal(\"Rolllanden.Automatik.morgens\",\"state\",\"nv\") eq \"on\" ) { fhem(\"set $dev $A_offen_Pos\") }}";}
elsif ($A_Modus eq 'bei_Abwesenheit') {$hoch_at = "define $Rol_hoch_Timername at $Hoch_Zeit { if ((ReadingsVal(\"jemand_zu_Hause\",\"state\",\"\") eq \"absent\" ) and (ReadingsVal(\"Rolllanden.Automatik.morgens\",\"state\",\"nv\") eq \"on\" )) { fhem(\"set $dev $A_offen_Pos\") }}";}

fhem("$hoch_at");
fhem("attr $Rol_hoch_Timername room Timer");
fhem("attr $Rol_hoch_Timername icon fts_shutter_automatic\@yellow");
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 diesen Rollladen) für abends ausgeschaltet? ==> dann Sprung!
elsif ($A_runter eq 'Astro'){ # Automatik (für diesen Rollladen) 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 (für diesen Rollladen) auf normalem Zeitprogramm?
$Runter_Zeit = randomtime_with_realtime("$A_Zeit_runter_spaet","$A_Zufall_Minuten","-");
}

if ($A_Modus eq 'immer') {$runter_at = "define $Rol_runter_Timername at $Runter_Zeit { if (ReadingsVal(\"Rolllanden.Automatik.abends\",\"state\",\"nv\") eq \"on\" ) { fhem(\"set $dev off\") }}";}
elsif ($A_Modus eq 'bei_Abwesenheit') {$runter_at = "define $Rol_runter_Timername at $Runter_Zeit { if ((ReadingsVal(\"jemand_zu_Hause\",\"state\",\"\") eq \"absent\" ) and (ReadingsVal(\"Rolllanden.Automatik.abends\",\"state\",\"nv\") eq \"on\" )) { fhem(\"set $dev off\") }}";}


fhem("$runter_at");
fhem("attr $Rol_runter_Timername room Timer");
fhem("attr $Rol_runter_Timername icon fts_shutter_automatic\@green");
fhem("setreading $dev Auto_runter_Zeit $Runter_Zeit");


ENDE:
}
}

my $TimerErzeugerName='TimerErzeuger_'.$group_name;
fhem("define $TimerErzeugerName at *00:05:00 {Auto_Rol_group_at(\"$group_name\")}") if (!($defs{$TimerErzeugerName}));  # Timer zum Starten dieser Funktion erzeugen, falls noch nicht vorhanden
fhem("attr $TimerErzeugerName room Timer");
fhem("attr $TimerErzeugerName icon clock\@blue");
fhem("attr $TimerErzeugerName webCmd execNow"); # Webcmd zur einfachen Neuberechnung anlegen


# nun noch ein Notify erzeugen, damit bei einem Neustart von Fhem die temporaeren Timer berechnet werden (die sind sonst naemlich weg)
fhem("define TimerSystemStart.ntfy notify global:INITIALIZED {fhem(\"set $TimerErzeugerName execNow\")}") if (!($defs{"TimerSystemStart.ntfy"}));  # Notify erzeugen, falls noch nicht vorhanden
fhem("attr TimerSystemStart.ntfy room Timer");
fhem("attr TimerSystemStart.ntfy icon system_fhem_reboot\@orange");

} 


Mit einem einmaligen Aufruf der Routine für meine Rollladen mit dem Befehl:
{Auto_Rol_group_at("Rol")}

...wird ein nächtlicher Timer um 00:05:00Uhr mit dem Namen "TimerErzeuger_Rol" angelegt. Dieser ist permanent und wird jede Nacht ausgeführt, damit die at (Timer) für die einzelnen Rollladen täglich neu berechnet werden. Da hierbei eine permanente Sache generiert wird, muss die Konfiguration einmal gespeichert werden (rotes ?). Dies ist aber nur beim allerersten Aufruf der Fall. Die automatisch angelegten Timer für die einzelnen Rollladen sind einmalige Timer, die sich nach Ausführung selber löschen und dann in der Nacht neu angelegt werden.

Möchte man die Timer manuell neu berechnen lassen (z.B., weil irgendwelche User-Attribute geändert wurden), dann kann man das mit einem der beiden folgenden Befehle machen:
{Auto_Rol_group_at("Rol")}

oder

set TimerErzeuger_Rol execNow

Es kann nun auch das webCmd "execNow" am Timer gedrückt werden, damit eine Neuberechnung angestoßen wird.

So - ich hoffe, dass ich nichts vergessen habe. Bei Rückfragen und/oder Unstimmigkeiten gerne her damit. ;)

Gruß Bernd

Oh, ich sehe grade, dass ich den Ferien- und Feiertagskalender vergessen habe zu erwähnen. Diesen habe ich wie an diversen Stellen beschrieben angelegt. Damit ich den aktuellen Status auswerten kann, lege ich mir im Falle von Ferien bzw Feiertagen den Wert "1" auf das jeweilige Dummy (mit dem Namen "Ferien" bzw. "Feiertag")...

Ich habe meine Routine in der 99_myUtils.pm oben noch etwas ergänzt. Am Ende lege ich nun noch ein Notify an, welches beim Systemstart getriggert wird. Daraufhin werden die Timer einmal neu generiert. Dies ist notwendig, wenn man nach 00:05:00Uhr einen Neustart von Fhem macht (aus welchem Grund auch immer). Bei einem Neustart werden die temporären ats gelöscht, was wiederum zur Folge hat, dass die vorher berechneten Rollladenfahrten nicht mehr ausgeführt würden. Dies ist nun behoben.

Zitat von: Beta-User am 16 April 2017, 19:47:32
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.

Zitat von: Beta-User am 16 April 2017, 19:47:32
"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

Zitat von: spi3845 am 17 April 2017, 20:58:58
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.

ZitatWie 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

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

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 (https://github.com/rejoe2/FHEM/blob/dev-module/myShutter/98_HMshutterUtils.pm). 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 (https://forum.fhem.de/index.php/topic,70146.msg617312.html#msg617312) ist ein weiteres Beispiel, das sogar noch eine Filterfunktion verwendet: @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

Zitat'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

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

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

ZitatHallo,
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

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 (https://forum.fhem.de/index.php/topic,57729.msg491242.html#msg491242).

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

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

Bitte gerne
LG

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:
([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
([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:
([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

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

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

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 (https://forum.fhem.de/index.php/topic,72497.msg641159.html#msg641159) 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

Zitat von: Beta-User am 06 April 2017, 07:45:11

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 (https://github.com/rejoe2/FHEM/blob/development/myShutter/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

@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 (https://github.com/rejoe2/FHEM/blob/dev-module-experimental/myShutter/99_myShutterUtils.pm). 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 (https://forum.fhem.de/index.php/topic,69704.msg620946.html#msg620946)). 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...

Zitat von: kjmEjfu am 23 Mai 2017, 10:50:57
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

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

Hi zusammen,

ich habe mir gedacht, dass ich unseren Stand auch nochmal mitteilen könnte. Wir (Matthias und ich) feilen zwar noch an ein paar Ecken, aber langsam aber sicher nimmt die Sache Gestalt an.

Was schon geht:

• ats werden für jeden Rollladen erzeugt. Diese werden automatisch jede Nacht um 0:05Uhr erzeugt. In den Attributen jedes Rollladen sind dafür diverse Einstellmöglichkeiten vorgesehen (siehe Textdatei im Anhang)
• Bei vorhanden Fenster- bzw Drehgriffkontakt werden abhängig vom Kontakt Öffnen/Lüften/Schießen Notifies angelegt. Diese sind verriegelt und lösen nicht aus, wenn der Rollladen bereits in Bewegung ist (Beispiel: Ich drücke den Taster zum Öffnen des Rollladen und öffne eine Sekunde später das Fenster. Der Rollladen wird dann weiter geöffnet.)
• Bei vorhandenen Hellikeitssensor(en) kann eine Abschattung in den Attributen jedes Rollladen definiert werden. Diese ist ziemlich variabel nach Schwellen einstellbar und richtet sich zusätzlich nach dem aktuellem Sonnenstand und definierbaren Mindessperrzeiten zwischen den einzelnen Fahrten. Außerdem kann eingestellt werden, dass x Minuten vor dem automatischen, abendlichen Schließen der Rollladen nicht mehr geöffnet werden und einfach in der Abschattungsposition belassen werden soll.

Momentan muss ich noch die Sperre nach einer manuellen Fahrt implementieren (ist schon zum Großteil auskommentiert im Code vorhanden). Ich möchte ja nicht, dass ich den Rollladen per Hand öffne und ein paar Minuten später durch die Abschattung wieder geschlossen wird. Die Abschattung soll dann für x Minuten gesperrt werden. ==> Implementierung sollte bald fertig sein.
Gegebenenfalls werden wir die Öffnen/Lüften/Schließen-Notify-Geschichte noch in eine eigene Routine packen um damit dann die ganzen Notifies einsparen und es etwas übersichtlicher machen zu können. Damit gäbe es dann nur noch ein Notify für alle Kontakte und alle Seitenbedingungen werden dann in der Routine überprüft und entsprechend abgearbeitet. Aber nochmal schauen. Kommt zeit kommt Fahrrad...

### ACHTUNG !!! ###
So gut wie alle Parameter sind am jeweiligen Rollladenaktor einstellbar. Die berechneten Dinge werden in eigenen Readings abgespeichert. Sollte jemand die Funktionen ausprobieren, so gibt es ab sofort einige zusätzliche Readings, die mit "Automatik_" beginnen. Die zusätzlichen Userattribute beginnen mit "Auto_". Bei der Ausführung der Hauptroutine, die ja automatisch nachts ausgeführt wird, führe ich am Ende ein automatisches "save" durch - dies habe ich gemacht, weil während der Ausführung diverse at/notify/ReadingsGroup falls vorher vorhanden gelöscht und ja auch angelegt werden. Das hat dann natürlich ein rotes Fragezeichen wegen der geänderten Konfiguration zu Folge. Deshalb habe ich den save-Befehl angehängt. Wer die automatische Speicherung nicht haben möchte, muss den save-Befehl halt auskommentieren.

Sollte man meine Routinen nachher doch nicht mehr nutzen wollen, dann bleiben die Readings und Attribute natürlich und müssen (wenn sie denn stören) in Eigenregie von Hand per deletereading/deleteattr gelöscht werden. Tut man dies nicht, dann hat das aber auch keinen negativen Einfluss auf die Aktoren. Um spätere Fehlermeldungen im Log nach Entfernen der Routinen in der 99_myUtil.pm zu vermeiden, müssen die verbleibenden at und die ReadingsGroup im Raum "Timer" und die Notifies im Raum "Notify" gelöscht werden. Es ist außerdem zu beachten, dass ich (und auch Matthias) dies alles nur mit Homematic-Komponenten genutzt haben. Inwiefern sich eine Anpassung an andere Aktoren/Sensoren machen lässt und mit wie viel Aufwand dies verbunden ist, müsste dann mal ein anderer prüfen und testen...


Bei mir läuft es schon ziemlich verlässlich und stabil. Es sind nur noch einige Sachen, die noch nicht gemacht sind. Bald beginnt die Arbeit an den WAF-Faktoren. Das heißt, dass die möglichen Einstellungen gruppiert in einer bzw. mehreren ReadingsGroups erfolgen soll, damit später zentral an einer Stelle die Einstellungen gemacht werden können. Aber wie gesagt, dass kommt erst, wenn die anderen Dinge alle wie gewünscht funktionieren.

Bevor ihr euch jetzt auf den Code stürzt und das alles ausprobiert - denkt an folgendes: Ihr macht das auf eigene Gefahr - ich garantiere für nichts! Legt also VORHER ein Backup an und schaut euch vielleicht auch den Code an - wir haben uns die Mühe gemacht und versucht so gut wie ALLES mit Erklärungen zu versehen!

Soooo, ich hoffe ich habe nichts vergessen und wünsche euch viel Spaß beim Spielen!

Ich würde mich sehr freuen, wenn Rückmeldungen dazu kommen würden. ;)

Liebe Grüße Bernd

PS: Wenn ich denke, dass alles fertig ist, dann werde ich dies auch nochmal in dieser Form in einem eigenen Thread veröffentlichen.

EDIT: Anhang geändert

Hallo,

da bin ich sehr gespannt! :-)

Das Thema brennt mir - als Bewohner einer Dachgeschosswohnung - quasi auf den Nägeln.
Und meine Doifs tun nicht immer das was sie sollen....

Toll, dass ihr euch des Themas annehmt!

Viele Grüße
Christian

Da ich keine Testumgebung habe, werde ich erst mit Beta-Status in die Tests einsteigen können. 1x Terassentüre mit Drehgriffkontakt und einen Lichtsensor   kann ich zum testen nutzen.

Hallo Christian, willkommen im Club - ich habe auch keine Testumgebung. Ich operiere quasi am lebenden Objekt.... [emoji12] Ostersonntag ist es dann auch passiert - die Rollladen gingen alle hintereinander um kurz nach 7Uhr wegen eines kleinen Fehlers im Programm hoch.... [emoji23]


Gesendet von iPhone mit Tapatalk

Hallo,

ich wäre des Todes...07:00 Uhr und die Teenager würden über mich herfallen.

Trotzdem würde ich gerne testen.
Da meine Rollos alle mit "Rollo.." anfangen, würde ich das TestRolle umbenennen in "Test....".
Wenn ich nun die Installation mit {Auto_Rol_group_at("Test")} durchführe sollte das ja laufen. Richtig?
Bekomme ich das später auch nochmal umgebogen wenn ich dann auf "Rollo" schwenken möchte?

Danke und Gruß
Christian

Hi Christian,

das kannst du so machen. Ich habe jetzt in der aktuellen Version umgestellt auf eine eigene Datei "99_myUtils_Shutter.pm". Damit ist es dann einfacher und du kannst den kompletten Inhalt direkt kopieren und einfügen. Du musst die Datei im Fhem-Editor dann halt nur unter diesem Namen abspeichern und dann ein "reload 99_myUtils_Shutter.pm" oben in der Zeile machen. Ich hänge diese Datei plus eine Textdatei mit den Vorbedingungen (hoffe ich habe alles drin), wie z.B. Ferienkalender, Feiertagskalender, nötige Dummies, ... an.

Hoffe, dass alles einigermaßen verständlich und umsetzbar ist.

Grüße, Bernd

EDIT: Ich sehe gerade, dass ich in der Textdatei noch nicht beschrieben habe, wie man Twilight, die Dummies für Sonnenposition, Höhe, Temperatur,... anlegt. Bekommst du das selber hin, oder brauchst du da Hilfe?

Hi,
ich habe mal angefangen....

Mein Rollo umbenannt in "TestRollo...".
Anleitung abgearbeitet.
Aktivierung per {Auto_Rol_group_at("TestRol")}
Die Anlage der UserAttr wollte er nicht...also händisch, da ja eh nur 1 Rollo.
Belegung der UserAttr per Hand ebenfalls okay (auch wenn ich nicht alle vorhandenen verstehe).

Timer-> ATs -> neu berechnet sieht erst einmal gut aus.

Offen ist noch:
Wie gebe ich meinen Lichtsensor an? Das Device "Wetterstation" hat ein Reading namens "Luminosity2". Der Wert wird also nicht im State dargestellt.

Helfen könntest du mir noch mit dem korrekten notify für die Twilight-Parameter.

Was m.E.nicht korrekt ist:
In der Ansicht Timer -> Rolladenstatus zeigt er eine Übersicht aller meiner Rollos an (die beginnen alle mit "Rollo", aber nicht mein TestRollo. Da scheint er die Definition nicht übernommen zu haben.

So als weitere Idee noch: Ich hätte gerne einen "Button" zum Abschalten der Beschattungsautomatik...zB wenn der Fensterputzer da ist...der erschrickt immer so :-)

Ansonsten teste ich jetzt mal....

VG
Christian

PS: im Attr Auto_Zeit_hoch_WE_Urlaub habe ich 09:00:00, der Timer für morgen steht trotzdem auf 08:00 Uhr. Richtig?

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44
Die Anlage der UserAttr wollte er nicht...also händisch, da ja eh nur 1 Rollo.

Öhm, warum nicht? Den Namen "Rol\..*" musst du natürlich ändern in "TestRol.*" (der \ bei mir ist nur da, weil nach meinem "Rol" bei allen Rollladen im Namen ein "." kommt - und mit dem ".*" wird daraus dann "\..*".

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44Belegung der UserAttr per Hand ebenfalls okay (auch wenn ich nicht alle vorhandenen verstehe).

Sind welche nicht in der Textdatei beschrieben?  ???

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44Offen ist noch:
Wie gebe ich meinen Lichtsensor an? Das Device "Wetterstation" hat ein Reading namens "Luminosity2". Der Wert wird also nicht im State dargestellt.

Dazu machst du dir am besten einen Dummy "Helligkeit", dem du über ein Notify per
define ntfy.Helligkeit notify (Wetterstation: Luminosity2.*)  {fhem("setreading Helligkeit brightness $EVTPART1")}
den Wert auf das Reading "brightness" schreibst (nagel mich bitte nicht auf das Notify fest - habe es nicht ausprobiert). Und als Helligkeitssensor trägst du dann "Helligkeit" ein.

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44Helfen könntest du mir noch mit dem korrekten notify für die Twilight-Parameter.

define ntfy.sunpos (T_N_Wetter:azimuth.*) set Sonnenposition $EVTPART1  ==> auf Dummy "Sonnenposition"

define ntfy.sunheight (T_N_Wetter:elevation.*) set Sonnenhoehe $EVTPART1 ==> auf Dummy "Sonnenhoehe"

define ntfy.Temp (Klima.Terrasse:temperature.*) set Aussentemperatur $EVTPART1 ==> auf Dummy "Aussentemperatur"

T_N_Wetter bzw. Klima.Terrasse musst du natürlich auf deine Gegebenheiten anpassen.

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44
Was m.E.nicht korrekt ist:
In der Ansicht Timer -> Rolladenstatus zeigt er eine Übersicht aller meiner Rollos an (die beginnen alle mit "Rollo", aber nicht mein TestRollo. Da scheint er die Definition nicht übernommen zu haben.

Das muss ich mir ansehen. Da scheinen wir den Namen hardcodiert drin zu haben... Danke für den Hinweis!

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44
So als weitere Idee noch: Ich hätte gerne einen "Button" zum Abschalten der Beschattungsautomatik...zB wenn der Fensterputzer da ist...der erschrickt immer so :-)

Ist notiert ;)

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44
PS: im Attr Auto_Zeit_hoch_WE_Urlaub habe ich 09:00:00, der Timer für morgen steht trotzdem auf 08:00 Uhr. Richtig?

Doch, das ist korrekt - deshalb ist das at zur Berechnung ja nach Mitternacht. Dann werden die korrekten Werte für diesen Tag berechnet. Lass dich überraschen... :P

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44
Was m.E.nicht korrekt ist:
In der Ansicht Timer -> Rolladenstatus zeigt er eine Übersicht aller meiner Rollos an (die beginnen alle mit "Rollo", aber nicht mein TestRollo. Da scheint er die Definition nicht übernommen zu haben.

In Zeile 425 das "Rol" durch "$group_name" ersetzen... ;)

Zitat von: Chris8888 am 02 Juni 2017, 21:09:44
PS: im Attr Auto_Zeit_hoch_WE_Urlaub habe ich 09:00:00, der Timer für morgen steht trotzdem auf 08:00 Uhr. Richtig?

Und, hat es funktioniert oder sind jetzt alle sauer auf dich? :P

Zitat von: Cluni am 03 Juni 2017, 09:27:44
Und, hat es funktioniert oder sind jetzt alle sauer auf dich? :P

2017.06.03 09:00:00 3: CUL_HM set TestRolloTerassenTuerWZ 100

Alles Top. :-)

Den Rest schaue ich mir später an und melde mich. ;-)

Zitat von: Cluni am 03 Juni 2017, 00:11:00
Öhm, warum nicht? Den Namen "Rol\..*" musst du natürlich ändern in "TestRol.*" (der \ bei mir ist nur da, weil nach meinem "Rol" bei allen Rollladen im Namen ein "." kommt - und mit dem ".*" wird daraus dann "\..*".

Okay, mein Fehler. Das kannte ich nicht.

Zitat von: Cluni am 03 Juni 2017, 00:11:00
Sind welche nicht in der Textdatei beschrieben?  ???

Beschrieben schon. Ich verstehe zB das hier nicht:
attr Rol\..* Auto_Offset_Minuten_morgens 0            # Offset Rollladen morgens
attr Rol\..* Auto_Offset_Minuten_abends 0            # Offset Rollladen abends
Was bewirkt das? Eine Verschiebung um X Min?

Zitat von: Cluni am 03 Juni 2017, 00:11:00
Dazu machst du dir am besten einen Dummy "Helligkeit", dem du über ein Notify per

Code Auswählen Erweitern

define ntfy.Helligkeit notify (Wetterstation: Luminosity2.*)  {fhem("setreading Helligkeit brightness $EVTPART1")}
den Wert auf das Reading "brightness" schreibst (nagel mich bitte nicht auf das Notify fest - habe es nicht ausprobiert). Und als Helligkeitssensor trägst du dann "Helligkeit" ein.

Code Auswählen Erweitern

define ntfy.sunpos (T_N_Wetter:azimuth.*) set Sonnenposition $EVTPART1  ==> auf Dummy "Sonnenposition"

Code Auswählen Erweitern

define ntfy.sunheight (T_N_Wetter:elevation.*) set Sonnenhoehe $EVTPART1 ==> auf Dummy "Sonnenhoehe"

Code Auswählen Erweitern

define ntfy.Temp (Klima.Terrasse:temperature.*) set Aussentemperatur $EVTPART1 ==> auf Dummy "Aussentemperatur"

T_N_Wetter bzw. Klima.Terrasse musst du natürlich auf deine Gegebenheiten anpassen.

erledigt. Klappt! (für die Nachahmer in den defines oben fehlt noch der Modulname notify.)

Zitat
In Zeile 425 das "Rol" durch "$group_name" ersetzen...

gemacht inkl Reload. Die Ansicht ändert sich aber nicht. Könnte das an dem DEF liegen? "Rol..*:pct,Automatik_Modus_...."? Muss ich den auch noch anpassen?

Update 4.6.: Anzeige ist jetzt korrekt. Selbstheilung über Nacht? :-)
Nee, im Ernst: Anpassung des DEFs in "TestRollo..*:pct,Autom..." hat geklappt.

In der Anleitung steht:
10.) Dummies f¸r Aussentemperatur, Sonnenhoehe und SonnenPosition, die per Notify mit Daten vom Twilight-Modul versorgt werden:
Sonnenposition muss aber mit kleinem "p" geschrieben werden.

Noch ein Verbesserungsvorschlag:
Ich würde 2 getrennte Attr für "attr Rol\..* Auto_Abschattung_Wartezeit 20" vorschlagen. Ich fahre bisher recht schnell runter bei Sonne 5 Min, aber erst später wieder hoch bei Wolken 20 Min.

Frage/Verbesserungsvorschlag:
Bei Level < 100 und die Türe wird geöffnet, fährt das Rollo nicht hoch bzw. wenn wieder geschlossen wird, nicht wieder in die alte Position zurück.
Ist das richtig? Wenn ja -> Verbesserungsvorschlag :-)
(Die Abschaltung des Tasters funktioniert soweit)
Oder ist dafür das "Lüften" gedacht per Pos 100? Dann aber nur mit Drehgriffsensor "tilted", oder?

Den Nachrichtendienst nutze ich nicht...
set teleBot message
Kann man diese Funktion abschalten?

zB der Notify für die Abschattung wird in 2 Räumen angelegt: Notify und Wetterdaten
Ziemlich viele neue Räume die ich bisher nicht hatte. Da würde ich mir etwas "Passform" für meine Installation wünschen.

Sorry für die vielen Fragen und Anmerkungen..... :-[

Viele Grüße
Christian

Hi Christian,
Wir sind grade mir der Family unterwegs. Versuche es per Handy mal zu beantworten.

Hast du an der Türe, die sich ganz öffnen soll einen Fenster oder einen Drehgriff Kontakt. Das geht nur beim Drehgriff kontakt. Es müsste aber auch funktionieren, wenn du den Fensterkontakt als Drehgriff Kontakt einträgst (aber nur dort, nicht bei beiden). Versuche das mal. Natürlich fährt der Rollladen dann immer komplett auf - egal, ob du die Tür kippst oder ganz öffnest.

Die offset Minuten kommen auf die berechnete Zeit drauf. Wenn du überall die gleichen Bedingungen (also zum Beispiel Astro, gleiche Zufallszeit) einstellst, dann ereichst du so, dass alle Rollladen zwar wie gewollt in einem gewissen Maße jeden Tag zu unterschiedlichen und auch in unterschiedlicher Reihenfolge fahren. Aber wenn du beispielsweise bei der Terrasse Tür den offset größer/gleich der Zufallszeit machst, dann ist sichergestellt, dass dieser Rollladen als letztes herunter fährt.

Das at für die Berechnung der Timer musst du bitte einmal von Hand löschen, da dieses nicht neu angelegt wird, wenn es einmal vorhanden ist. Da muss ich das evtl. mal mit devmod ran und nur immer das dev ändern. Natürlich musst du dann einmal die Routine wie bei der Erstinstallation per Hand starrten. Oder halt wie du sagtest das Def per Hand änderen.

Der Vorschlag mit den unterschiedlichen Wartezeiten ist gut. Werde ich mal reinmachen, wenn ich wieder daheim bin.

Das mit dem Telegram Messenger ist noch für mich selber drin, damit ich genau mitbekomme, wenn was schief läuft. Ich werde da mal in die Routine einen Schalter zum ein-/ausschalten reinmachen, den man dann nur auf 0 setzen muss (analog zur Ausgabe ins logfile).

Das mit den Räumen ist halt an meine Gegebenheiten angepasst. Ich muss mal schauen. Das müsste mal eventuell durch einen eigenen dummy für die komplette Rollladen Automatik mit ein paar Userattributen in den Griff bekommen können. Ich werde mal scharf drüber nachdenken, wie man das machen kann.

Die Sache ist halt, dass ich das anfangs ja nur für mich programmiert habe und deshalb noch einige Dinge da sind, die noch nicht so "beweglich" sind, dass da jeder mit zufrieden ist. Da wäre ein eigenes Modul für diesen Zweck wahrscheinlich zielführender. Damit kenne ich mich aber leider (noch) nicht mit aus und mir fehlt da etwas die Zeit dazu. Es war ja auch der Anstoß für mich, was eigenes zu machen. Die Vorschläge, die hier in verschiedenen threads schon vorgestellt wurden, passten mir aus irgendwelchen Gründen nicht und waren mir zu starr. Bei meiner Version gebe ich aber auch zu, dass man dabei einiges an Vorarbeit leisten muss, damit alles so funktioniert, wie gedacht (Kalender, verschiedene dummies,...). Das ist für Anfänger sehr erschlagend und schwer umsetzbar. Aber langsam aber sicher bin ich sehr zufrieden mit der Funktionsweise. Wir sind auf der Zielgeraden... [emoji6]


Gesendet von iPhone mit Tapatalk

Hallo Bernd,

Zitat von: Cluni am 04 Juni 2017, 14:08:17
Hast du an der Türe, die sich ganz öffnen soll einen Fenster oder einen Drehgriff Kontakt. Das geht nur beim Drehgriff kontakt. Es müsste aber auch funktionieren, wenn du den Fensterkontakt als Drehgriff Kontakt einträgst (aber nur dort, nicht bei beiden). Versuche das mal. Natürlich fährt der Rollladen dann immer komplett auf - egal, ob du die Tür kippst oder ganz öffnest.

Ja, genau. In der aktuellen Testtüre habe ich nur einen Fensterkontakt. Deinen Tip schnell getestet und läuft! Prima! WAF = 10 :-)

Zitat von: Cluni am 04 Juni 2017, 14:08:17
Die offset Minuten kommen auf die berechnete Zeit drauf. Wenn du überall die gleichen Bedingungen (also zum Beispiel Astro, gleiche Zufallszeit) einstellst, dann ereichst du so, dass alle Rollladen zwar wie gewollt in einem gewissen Maße jeden Tag zu unterschiedlichen und auch in unterschiedlicher Reihenfolge fahren. Aber wenn du beispielsweise bei der Terrasse Tür den offset größer/gleich der Zufallszeit machst, dann ist sichergestellt, dass dieser Rollladen als letztes herunter fährt.

Ah, dafür also. Das macht bestimmt bei einigen Szenarien Sinn. Danke für die Erklärung.

Zitat von: Cluni am 04 Juni 2017, 14:08:17
Das mit den Räumen ist halt an meine Gegebenheiten angepasst. Ich muss mal schauen. Das müsste mal eventuell durch einen eigenen dummy für die komplette Rollladen Automatik mit ein paar Userattributen in den Griff bekommen können. Ich werde mal scharf drüber nachdenken, wie man das machen kann.

Die Sache ist halt, dass ich das anfangs ja nur für mich programmiert habe und deshalb noch einige Dinge da sind, die noch nicht so "beweglich" sind, dass da jeder mit zufrieden ist. Da wäre ein eigenes Modul für diesen Zweck wahrscheinlich zielführender. Damit kenne ich mich aber leider (noch) nicht mit aus und mir fehlt da etwas die Zeit dazu. Es war ja auch der Anstoß für mich, was eigenes zu machen. Die Vorschläge, die hier in verschiedenen threads schon vorgestellt wurden, passten mir aus irgendwelchen Gründen nicht und waren mir zu starr. Bei meiner Version gebe ich aber auch zu, dass man dabei einiges an Vorarbeit leisten muss, damit alles so funktioniert, wie gedacht (Kalender, verschiedene dummies,...). Das ist für Anfänger sehr erschlagend und schwer umsetzbar. Aber langsam aber sicher bin ich sehr zufrieden mit der Funktionsweise. Wir sind auf der Zielgeraden... [emoji6]

Absolut! Und besten Dank für die Entwicklung! Das ist ja alles freiwillig und Hobby!

Schöne Pfingsten
Christian

Zitat von: Chris8888 am 03 Juni 2017, 14:55:20
In der Anleitung steht:
10.) Dummies f¸r Aussentemperatur, Sonnenhoehe und SonnenPosition, die per Notify mit Daten vom Twilight-Modul versorgt werden:
Sonnenposition muss aber mit kleinem "p" geschrieben werden.

==> korrigiert! ;)

Zitat von: Chris8888 am 03 Juni 2017, 14:55:20
Noch ein Verbesserungsvorschlag:
Ich würde 2 getrennte Attr für "attr Rol\..* Auto_Abschattung_Wartezeit 20" vorschlagen. Ich fahre bisher recht schnell runter bei Sonne 5 Min, aber erst später wieder hoch bei Wolken 20 Min.

Ich habe das mal im Code überflogen. Ist leider nicht so einfach, wie ich anfangs dachte. Die Wartezeit frage ich ziemlich zur Anfang der Routine ab und entscheide sofort, ob der Rollladen schon dran ist, oder noch warten muss. Die Prüfung zu sonnig/schattig kommt erst viel weiter unten. So wie es aussieht müsste ich dafür den kompletten Code umstellen, was natürlich auch wieder eine gewisse Fehleranfälligkeit mit sich bringt. Das muss ich mir nochmal irgendwann in Ruhe ganz genau durch den Kopf gehen lassen und möchte ich nicht zwischen Tür und Angel mit der heißen Nadel stricken. Da darfst den Code natürlich für dich nach deinem Bedarf gerne verändern (ich weiß nicht, wie firm du in Perl bist). Wenn du Änderungen machst, dann mache bitte auch wie wir für die jeweiligen Zeilen am besten direkt einen Kommentar, was der Code da genau macht beziehungsweise machen soll. So könnte ich auch später überlegen, ob ich das in meinen Code übernehme, wenn ich es dann noch nicht selber eingefügt habe.

Zitat von: Chris8888 am 03 Juni 2017, 14:55:20
Den Nachrichtendienst nutze ich nicht...
set teleBot message
Kann man diese Funktion abschalten?

Habe ich bei mir jetzt aktuell schon eingepflegt. Ganz oben in der Routine gibt es dann eine Variable "my $Telebot_debug_info = 2;. Wenn diese auf 0 initialisiert wird, bekommt man gar keine Nachrichten mehr auf den Telegram Messenger. Bei 1 wird nur gemeldet, wenn geöffnet oder geschlossen wird und bei 2 bekommt man z.B. auch die Abbrüche einer Vormerkung geschickt. Wenn du das im Code geändert hat bitte aber den Reload der Datei nicht vergessen. Erst dann ist die neue Datei aktiv.

Zitat von: Chris8888 am 03 Juni 2017, 14:55:20
zB der Notify für die Abschattung wird in 2 Räumen angelegt: Notify und Wetterdaten
Ziemlich viele neue Räume die ich bisher nicht hatte. Da würde ich mir etwas "Passform" für meine Installation wünschen.

Das werde ich auch auf die ToDo-Liste setzen, aber ist momentan noch hinten angestellt.

Im Moment habe ich noch einen Tageszähler jeweils für die hoch und runter Fahrten in die Readings eingebaut, die dann nachts wieder auf 0 gesetzt werden sollen. Das wollte ich haben, damit man einen schnellen Überblick bekommt, wie oft die Rollladen am Tag wegen der Abschattung hoch und runter fahren. Eventuell kopiere ich die dann nachts noch auf ein anderes Reading für den Vortag. Mal sehen...

Deinen Wunsch zur einfachen Abschaltung der Abschattung werde ich jetzt noch einbauen. Das sollte schnell erledigt sein. Ein Dummy mit Web-Schaltern für on/off und ein notify, welches das notify für die Abschattung entsprechend dis- bzw. enabled. Fertig...

Sobald ich den Code fertig habe, werde ich hier die neue Version posten. Dann gehe ich erst eine Runde Laufen und dann geht es wieder ins Schwimmbad und in die Sauna.  8)

So hier der Dummy-Schalter für die Abschattung:

define Rolllanden.Automatik.Abschattung dummy
attr Rolllanden.Automatik.Abschattung alias Automatik Abschattung
attr Rolllanden.Automatik.Abschattung group Rollladen_Automatik
attr Rolllanden.Automatik.Abschattung icon weather_cloudy_light
attr Rolllanden.Automatik.Abschattung setList on off
attr Rolllanden.Automatik.Abschattung webCmd on:off

Das frage ich in der Routine ab, weil es unter Umständen ja mehrere Notify für verschiede Helligkeitssensoren geben könnte und die dann alle erstens gefunden und zweitens inaktiv geschaltet werden müssten...

Hallo Bernd,

werde ich zeitnah mal einspielen und weiter testen.
Bis läuft es weiterhin sehr stabil und zuverlässig. Klasse!

Hast du eine Idee woher das hier kommt?

2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x95fd928)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x54fcc38)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0xa633d88)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x98c8cd0)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x547c080)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x54f5a50)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0xa26b088)
2017.06.06 08:01:22 3: Ferien.notify return value: SCALAR(0x5a8a030)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x9677ac0)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x54908a8)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x5c866c0)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x5c8eff0)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0xa07bbe0)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x5505690)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0xa5cf6f8)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x9defa28)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x99b11a8)

Ich konnte auf Anhieb nichts dazu finden....Danke vorab!

VG
Christian

Das habe ich auch. Scheint an der Rückgabe vom Kalender zu liegen. Weiß ich auch noch nicht, wie man das weg bekommt....


Gesendet von iPhone mit Tapatalk

Hallo,

@ Cluni
ist die Rollladensteuerung nur für HomeMatic Aktoren?

Ich habe leider nur das ROLLO Modul.
Man könnte viel mit DOIF oder notify machen aber das ist viel gerade für so eine Komplexe Steuerung und bei vielen Rollläden (ein Haus).

Ich weis auch das das ROLLO Modul auch schon viel kann.

Könnte man so eine Steuerung für das ROLLO Modul entwickeln und alles über ein Modul steuern lassen, wo man nur noch die anderen Aktoren bzw Sensoren einfügt und dessen Schwellenwerte eingeben muss?

Ihr alle habt schon super Ideen eines fällt mir noch ein was ist mit Unwetter, Sturm, Hagel, usw. oder die Windgeschwindigkeit? 

Grüße
Markus

Hallo Bernd,

neue Version ist eingespielt. :-)

Ein paar kurze Anmerkungen:
Im Code taucht öfter der Befehl auf: ELSIF ....das soll sicherlich ELSEIF lauten

Und noch 2 kleine Vertipper:
define Rolllanden.Automatik.Abschattung dummy -> Im Dummy ist ein "n" zuviel...aber im Code ist es auch so, von daher funktioniert es ja

In der Doku Punkt 10 fehlt ein "notify".

Danke für die neuen Features! Sehr cool! :-)

Test läuft!

VG
Christian

Kann man die Dummys eventuell durch Verweise auf andere Geräte überschreiben?
Ich finde es immer unschön, wenn ich mir ein Dummy für einen Wert erstellen muss, den ich schon als Reading an einem Device habe, also z.B. die Werte vom Twilight-Device.
Eventuell könnte man ja eine Variable mit dem Namen des Twilights-Gerätes anlegen und wenn die leer ist, wird stattdessen ein Dummy abgefragt?

Zitat von: Chris8888 am 08 Juni 2017, 10:36:51
Ein paar kurze Anmerkungen:
Im Code taucht öfter der Befehl auf: ELSIF ....das soll sicherlich ELSEIF lauten

Nein, das passt schon - bei Perl heißt das so... ;)

Zitat von: Chris8888 am 08 Juni 2017, 10:36:51
Und noch 2 kleine Vertipper:
define Rolllanden.Automatik.Abschattung dummy -> Im Dummy ist ein "n" zuviel...aber im Code ist es auch so, von daher funktioniert es ja

Oh - das passiert durch das ganze copy&pase... Danke - korrigiert!
Wer den Dummy bereits hat:
1. rename Rolllanden.Automatik.Abschattung Rollladen.Automatik.Abschattung
2. in der Routine das 'n' löschen, abscheichern und Routine neu laden

Zitat von: Chris8888 am 08 Juni 2017, 10:36:51
In der Doku Punkt 10 fehlt ein "notify".

Behoben... ;)

Zitat von: Chris8888 am 08 Juni 2017, 10:36:51
Danke für die neuen Features! Sehr cool! :-)
Test läuft!

Freut mich/uns, wenn es dir gefällt und es gut funktioniert!  :)

Zitat von: MarkusHiba am 07 Juni 2017, 00:22:24
@ Cluni
ist die Rollladensteuerung nur für HomeMatic Aktoren?

Ich habe leider nur das ROLLO Modul.
Man könnte viel mit DOIF oder notify machen aber das ist viel gerade für so eine Komplexe Steuerung und bei vielen Rollläden (ein Haus).

Ich weis auch das das ROLLO Modul auch schon viel kann.

Könnte man so eine Steuerung für das ROLLO Modul entwickeln und alles über ein Modul steuern lassen, wo man nur noch die anderen Aktoren bzw Sensoren einfügt und dessen Schwellenwerte eingeben muss?

Da ich die Routinen nach meinen eigenen Bedürfnissen und Wünschen programmiert habe, ist diese natürlich auf meine Geräte zugeschnitten. Du darfst dir natürlich gerne den Code schnappen und ihn an deine Gegebenheiten anpassen.

Zitat von: MarkusHiba am 07 Juni 2017, 00:22:24
Ihr alle habt schon super Ideen eines fällt mir noch ein was ist mit Unwetter, Sturm, Hagel, usw. oder die Windgeschwindigkeit? 

Da habe ich auch bereits dran gedacht, aber hatte bis jetzt noch nicht die Muße mich da dran zu setzen. Kommt aber höchstwahrscheilich noch (vor dem Herbst.... :P )

Zitat von: kjmEjfu am 08 Juni 2017, 10:42:59
Kann man die Dummys eventuell durch Verweise auf andere Geräte überschreiben?
Ich finde es immer unschön, wenn ich mir ein Dummy für einen Wert erstellen muss, den ich schon als Reading an einem Device habe, also z.B. die Werte vom Twilight-Device.
Eventuell könnte man ja eine Variable mit dem Namen des Twilights-Gerätes anlegen und wenn die leer ist, wird stattdessen ein Dummy abgefragt?

Die Sache mit den Dummies für jeweilige Werte habe gewählt, damit bei der Weitergabe die Routine nicht starr an die Namen des jeweiligen Device (der Name für das Twilight Device ist ja frei wählbar) geheftet ist. Und wenn ich schon einen Dummy für die Namen generiere, dann kann ich auch direkt dort den Wert ablegen. Zusätzlich hat das den Vorteil, dass ich diese Dummies in einer Gruppe ablegen kann und auf einen Blick alle Werte (egal wo her sie kommen) in den States habe.

EDIT: Ich sehe grade, dass du den Namen (in der Routine?) in einer Variablen speichern möchtest, richtig?! Das wäre natürlich prinzipiell möglich. Aber dadurch wird jeder Aufruf der Routine eine stärkere Belastung für den Controller. Es muss die Variable ausgelesen werden und immer die Fallunterscheidung für das abzufragende Device gemacht werden. Finde ich nicht schön.

Wenn du das gerne anders hättest, dann darfst du dir natürlich gerne die Routine auf die direkte Abfrage umbauen. Ich gebe dir recht, dass dies für fhem weniger Overhead bedeutet, aber dadurch wird die Sache halt steifer. Man könnte natürlich auch alle benötigten Readings in einem Dummy vereinen, aber dadurch würde der Overhead auch nicht kleiner...

Grüße, Bernd

Ach so, noch die aktuelle Version anhängen....

Das meinte ich übrigens:

Zitat von: Cluni am 08 Juni 2017, 11:09:42
Nein, das passt schon - bei Perl heißt das so... ;)

Das sieht FHEM aber anders: lt LOG:
Unknown command elsif, try help.
Unknown command elsif, try help.

:-)

Das kommt aber sicherlich nicht von meiner Routine?!

ich denke schon...die hatte ich vorher nicht....

Wann genau kommt das denn und was steht unmittelbar davor/dahinter? Kannst du mal einen Auszug posten?

Zitat von: Chris8888 am 06 Juni 2017, 16:36:08
Hast du eine Idee woher das hier kommt?

Code Auswählen Erweitern

2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x95fd928)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x54fcc38)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0xa633d88)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x98c8cd0)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x547c080)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0x54f5a50)
2017.06.06 08:01:21 3: Ferien.notify return value: SCALAR(0xa26b088)
2017.06.06 08:01:22 3: Ferien.notify return value: SCALAR(0x5a8a030)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x9677ac0)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x54908a8)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x5c866c0)
2017.06.06 08:02:54 3: Feiertag.notify return value: SCALAR(0x5c8eff0)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0xa07bbe0)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x5505690)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0xa5cf6f8)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x9defa28)
2017.06.06 08:02:55 3: Feiertag.notify return value: SCALAR(0x99b11a8)

Ich konnte auf Anhieb nichts dazu finden....Danke vorab!

Das liegt an dem Vergleich im Notify, wenn der Kalender gelesen wird. Ich habe das def von:

NRW_Feiertage { \ fhem "set Feiertag " . (ReadingsVal("NRW_Feiertage", "modeStart", "") =~ "schulferieneu" ? 1: 0) }

zu

NRW_Feiertage { my $Rueckgabe = ReadingsVal("NRW_Feiertage", "modeStart", ""); my $setval = 0; if (index($Rueckgabe,"schulferieneu") > 0) {$setval = 1;}; fhem ("set Feiertag $setval")}

umgebaut. Seit dem keinen Fehler mehr im log gehabt...

Zitat von: Chris8888 am 03 Juni 2017, 14:55:20
Noch ein Verbesserungsvorschlag:
Ich würde 2 getrennte Attr für "attr Rol\..* Auto_Abschattung_Wartezeit 20" vorschlagen. Ich fahre bisher recht schnell runter bei Sonne 5 Min, aber erst später wieder hoch bei Wolken 20 Min.

Hi, es ist zwar nicht ganz das, was du wolltest, aber es sollte dem Wunsch etwas entgegen kommen:
Ich habe zwei neue Attribute eingefügt: Auto_Abschattung_schnell_oeffnen und Auto_Abschattung_schnell_schliessen

Um die Funktion zu verstehen, muss man folgendes wissen: Die Wartezeit, die im Attribut Auto_Abschattung_Wartezeit steht, halbiere ich erstmal in der Routine. Dies mache ich, weil vor einer Fahrt der Rollladen erstmal zur Fahrt vorgemerkt wird. Dies geschieht frühestens nach der halben Wartezeit. Eine Vormerkung zu einer Aktion wird durch Überschreitung der jeweils anderen Schwelle wieder gelöscht (ansonsten könnte ich mir die Sache mit der Vormerkung ja auch sparen). Danach wird der Rollladen frühestens nach der weiteren halben Wartezeit gefahren, wenn die Bedingungen stimmen.
Wenn ich einen Rollladen zum Schließen/Öffnen vormerke oder auch wenn ich ihn schließe/öffne, dann speichere ich mir die aktuelle Zeit auf dem Reading "Automatik_Abschattung_letzte_Uhrzeit". Bei der nächtlichen Aktualisierung der ganzen Timer und sonstigen Dinge initialisiere ich dieses Reading mit 00:00:00.

Was mache ich also logischerweise, wenn ich die Wartezeit z.B. vor dem erneuten Schließen halbieren möchte? Dann schreibe ich nach dem Öffnen des Rollladen einfach statt der aktuellen Zeit die Zeit 00:00:00 in das Reading Automatik_Abschattung_letzte_Uhrzeit. Die nächste Vormerkung zum Schließen erfolgt dann direkt bei Überschreitung der Schwelle (weil die Wartezeit ja für den Vergleich bereits abgelaufen ist) und es muss nur noch die halbe Wartezeit gewartet werden, bis zum Schließen.

Bitte ausprobieren, ob das so klappt, wie ich mir das ausgedacht habe. Ist das so ok für dich?

Grüße Bernd

PS: Die neue Routine enthält auch noch ein paar weitere Bugfixes

Hallo Bernd,

die Meldung kommt beim Start des Systems:


.....
2017.06.08 09:05:38 3: bridge_HUEDevice1: I/O device is bridge
2017.06.08 09:05:38 3: bridge_HUEGroup0: I/O device is bridge
2017.06.08 09:05:38 3: bridge_HUEGroup1: I/O device is bridge
2017.06.08 09:05:40 1: HMCCURPC: Device ccu_rpc. Initialized version 0.95 beta
2017.06.08 09:05:40 3: TelegramBot_Define Telegram: called
2017.06.08 09:05:40 3: eq3: Defined with URL http://www.eq-3.de/service/downloads.html and interval 86400
2017.06.08 09:05:40 3: eq3: added hint :text,reading,internal,expression,delete to attr readingMaxAgeReplacementMode in userattr list
2017.06.08 09:05:41 1: Including ./log/fhem.save
2017.06.08 09:05:44 1: ./log/fhem.save: Unknown command if, try help.
Unknown command elsif, try help.
Unknown command elsif, try help.

2017.06.08 09:05:44 3: Device Aussenthermometer added to ActionDetector with 000:10 time
2017.06.08 09:05:44 3: Device BewegungsmelderFlur added to ActionDetector with 000:20 time
2017.06.08 09:05:44 3: Device BewegungsmelderGWC added to ActionDetector with 000:20 time
2017.06.08 09:05:44 3: Device BewegungsmelderKueche added to ActionDetector with 000:20 time
...

In älteren Logs sieht es genauso aus....nur ohne den 09:05:44 1:

Den angepassten Notifier teste ich sofort...
Update: Sieht top aus. Keine FM mehr. Hast du das auch für den Ferien-Notifier gemacht?

Die Halbierung der Wartezeit ist Top! Damit komme ich locker zu recht! Klasse!

Neue Version wird gleich eingespielt....
Update:Im Log taucht nach dem Reload folgende Fm auf:
2017.06.09 19:50:43 1: PERL WARNING: "my" variable $Tempvar masks earlier declaration in same scope at ./FHEM/99_myUtils_Shutter.pm line 169.

VG
Christian

PS: Und noch eine Frage zu einem Anwendungsszenario. Die Teenager schlafen immer seeeehr lange. D.h. ich würde hier als Hochfahrzeit am WE zB 16:00 Uhr eintragen. Was passiert wenn die Beschattungsregeln vorher eintreten? Bleibt das Rollo unten oder fährt es auf das Beschattungslevel.
-> An der Antwort hängt mein Haussegen ;-)

Also deine Meldungen sagen mir nichts. Ich glaube auch nicht, dass die von der Routine kommen.

Mir ist wohl eingefallen, dass ich eine oder zwei Stellen vergessen habe, wo ich noch was anpassen muss. Werde heute oder morgen nochmal eine neue Version posten. Die jetzige sollte aber funktionieren. Nur wenn eine Abschattung vorgemerkt, aber wegen wolkig wieder abgeblasen wird, ist die Wartezeit noch normal.


Gesendet von iPhone mit Tapatalk

Alles klar...dann suche ich mal weiter nach der Ursache...nichts für Ungut!

Schönes Wochenende!

Hallo

ich habe mich mal an den Code gesetzt um ihn für das Rollo Modul  anzupassen.
Hier ist er nun bitte testen ob es geht.

Anhang was ich geändert habe
überall wo Rolllanden stand in Rollladen geändert
Beim modul ROLLO Modul habe ich attr <Name> type normal um dieses auch in Ultis als SubType geändert.
pct in position geändert
motor in state geändert und drive-down drive-up wenn Motor fährt.
Wo geschalten werden soll position hinzugefügt  ( z.B. set $dev position $A_Pos_vor_Lueften)
bei ROLLO Modul attr <Name> blockmode force-open
in Ultis set <Name> reset open hinzugefügt und  set $dev inhibit on in set $dev blocked geändert  (Aussperrschutz)

ich habe es noch etwas geändert größer als kleiner als umgedreht
Fensterstatus Funktioniert
Aussperrschutz müsste auch funktionieren wird nur durch Taster wieder freigeben gerade für Winter wenn man raus geht
mit der Abschattung muss ich noch testen

Hallo Bernd,

heute war es etwas seltsam...
Das Rollo ist wie geplant um 22:30 runter gefahren...aber:
1. Die Türe war noch offen.
2. Das Rollo ist bis 10% - also nicht zu - gefahren.

Anbei mal ein Screenshot der Readings....

Im Log: 2017.06.11 22:29:59 3: CUL_HM set TestRolloTerassenTuerWZ 10

Hast du eine Idee wieso? Und woher kommt die 10?

Ich hätte gedacht, dass bei offener Türe das Rollo auch zum Schaltzeitpunkt nicht zufährt.

Einzige Besonderheit: Ich hatte gestern die Beschattungsautomatik und die normale Steuerung (Abend/Morgen) deaktiviert (da wir ne Party hatten) und heute erst wieder eingeschaltet.

VG
Christian

Mojn!

Zitat von: Chris8888 am 11 Juni 2017, 22:37:10
Hast du eine Idee wieso? Und woher kommt die 10?

Miss dieser Sache momentan bitte mal nicht zu viel Bedeutung zu. Matthias und ich haben uns grade drauf verständigt, dass wir einige Sachen umbauen wollen, damit u.A. das automatische Speichern in der Nacht entfällt (was mir seit Anfang an ein Dorn im Auge war). Da dies ein ziemlich grundlegender Umbau sein wird, werden wir eh alles nochmal umkramen müssen und uns dementsprechend auch bei den einzelnen Fallunterscheidungen alles nochmal genausten anschauen. Der Umbau könnte jedoch ein paar Tage in Anspruch nehmen, da wir ja auch noch andere Dinge tun. Ich bzw. wir melden uns mit einer aktuellen Version, sobald der Umbau fertig ist! ;)

Grüße Bernd

Hallo Bernd und Matthias,

Wie wäre es daraus ein Modul zu bauen?

Grüße
Markus

Hi Markus,

prinzipiell wäre das eine coole Sache - hatte ich auch bereits drüber nachgedacht. Aber die Sache hat mehrere Haken:

1. Ich habe keine Ahnung, wie man ein Modul baut und müsste mich deshalb erstmal tief einarbeiten ==> die Zeit ist aber bei meinen ganzen momentanen Baustellen (und dabei meine ich nicht nur Fhem) schon das Problem
2. habe ich deshalb keine Ahnung, wieviel Aufwand dann noch durch den reinen Umbau (Punkt 1 ist ja nur die Einarbeitung)hinzu kommt und wieviel zeit das wieder beansprucht
3. müsste das Modul ja sehr flexibel werden - es gibt ja nicht nur das ROLLO-Modul bzw. die Homematik-Aktoren. Es müsste ja komplett an andere Befehle/Strukturen anpassbar sein und ggf. gehen auch einige Dinge mit fremden Aktoren gar nicht.
4. möchte ich meine Routine erstmal so lauffähig haben, dass alles so funktioniert, wie ich mir das ursprünglich gedacht habe. Vorher macht es meiner Meinung nach keinen Sinn, dass man das in eine "Modul-Hülle" verpackt (kann sein, dass ich mich da irre und mein Weg der komplett falsche ist). Du siehst ja an meinem vorherigen Post, wie schnell man das aktuelle Konzept fast komplett über den Haufen wirft und es dann doch wieder anders aufzieht. Aber das ist meiner Meinung nach momentan nur noch der Feinschliff. Bin schon recht zufrieden und mehr oder weniger sind das nun nur noch Aufräumarbeiten - auch wenn das, was ich grade vorhabe eher einem Komplettabriss mit Wiederaufbau gleich kommt...  ;D

EDIT:Ich überlege grade, ob ich den Rollläden einfach ein paar weitere Attribute (sind ja noch nicht genug... :P ) spendieren soll, wo man die Dinge, die du geändert hast damit es mit dem Rollo-Modul funktioniert, definieren kann (z.B. Auto_Befehl_Prozent wäre dann standardmäßig auf 'pct', man könnte den Befehl dann aber einfach durch einen eigenen Befehl wie 'position' ersetzen) damit wären dann sogar gemischte Installationen möglich. Werde mal drüber nachdenken...

Hallo

Ich werde mich mal belesen wie das mit dem Modul Bau funktioniert. Naja man müsste das mit dem attr <Name> Helligkeitssensor so lösen das  man jeden sensor einfügen könnte also <name>:<sensorreading>
usw. Wenn du umbaust könntest du gleich Windstärke mit dazu nehmen.
Ich habe auch ein paar Tage gebraucht um deinen code zuverstehen und viel probiert bis es mit dem Rollo Modul lief.
Hast du es schon mal getestet?


Gesendet von meinem E6653 mit Tapatalk

Hattest du schon mein EDIT meines Post gelesen? :P

Wie kann es denn sein, dass du so lange zum Verstehen brauchtest? Da ist doch wirklich so gut wie jeder Schritt kommentiert? :D

Nein, deine Routine habe ich nicht getestet, weil ich mir dazu erst eine Testumgebung schaffen müsste mit dem ROLLO-Modul. Lies mal oben meinen Punkt 1... :P

Ja
Immer abends daran gesessen für 2 Stunden da wird nicht viel.
Ich bin noch ein Neuling. Ich wollte auch jeden befehl verstehen.

Ich finde finde deine Routine klasse.
Habe es auch erstmal auf einer Testumgebung laufen.

Also mein Vorschlag: Wir machen hier an dieser Stelle jetzt erstmal einen Cut, weil ich den Code eh massiv umschreiben möchte und er damit hoffentlich noch um einiges vereinfacht wird. Dabei werde ich auch direkt darüber nachdenken, ob und wie ich die Möglichkeit hineinbringen werde, dies alles auf andere Installationen anzupassen. Ok!?

Das mit der Windstärke stelle ich mir vorerst wie folgt vor:
- Attribut für Name/reading des Windsensors
- Attribut für Wind-Schwellwert (das werde ich aber erstmal recht einfach gestalten: Wert überschritten, dann wird sofort die komplette Automatik abgeschaltet und muss manuell wieder aktiviert werden)
- Aktion bei Schwellwert-Überschreitung (aus, hoch, runter)

Ich bin mir aber noch nicht sicher, wann ich das mit dem Wind machen werde. Komplizierter und aufwendiger kann es immer noch irgendwann werden. Aber so, wie ich das oben geschrieben habe, wäre es recht leicht zu implementieren...

@Cluni: Schön, dass Ihr da weiter vorangekommen seid!

Btw.: Zwischenzeitlich weiß ich auch, warum meine set-Funktion nicht so wollte, bin aber noch nicht weitergekommen, das %set-Array (das ich versehentlich gebaut habe) wieder in einen normalen $-String bzw. ein flaches Array zu verwandeln. Alles sehr ungewohnt...

Zitat von: MarkusHiba am 12 Juni 2017, 13:28:52
Ich bin noch ein Neuling. Ich wollte auch jeden befehl verstehen.

Nur als Tip von jemandem, der auch keine wirkliche Ahnung von perl hat, aber den "Vorteil", sich mal mit der Modul-Thematik beschäftigt zu haben (siehe einige Posts weiter oben):

Das ist kein Hexenwerk, erfordert aber ein gewisses Mindestmaß an Perl-Kenntnissen, das über "ein bißschen if - elsif" rausgeht. Vor allem muß man dann intern die ganze Syntax nochmal überarbeiten, selbst wenn code an sich funktioniert, schlicht, weil man z.B. auch definieren kann, wann der code auszuführen ist usw.

Ich habe dabei zwischenzeitlich mal den Überblick verloren vor lauter copy-paste (und auch gewissen Erfolgen) folgende Empfehlung: Wenn Du jemanden hast, der Dich da an die Hand nehmen kann und mag: Tu es. Ansonsten kannst Du Dich gerne in die Dev-Module-Intro einlesen, aber ohne perl-Vorkenntnisse ist das m.E. sehr mühsam (s.o.).

@MarkusHiba: Du kannst den Code auf Github gerne zum Testen (und als Anschauungsmaterial, was notify-perl vs. modul angeht) nehmen, fang vielleicht mit der dev-module-Version an (danach habe ich einiges - vermutlich unnötigerweise - verbogen).

Gruß, Beta-User

Das mit der Windstärke dein Vorschlag klingt gut. Mein Vorschlag wäre:
Das wenn der Wind zugenommen hat und der Schwellenwert überschritten ist Rollo auf/zu, Automatik deaktivieren dann warten bis Wind abgenommen hat aber dort auch warten nicht das zufällig ein Windstoß kommt danach wieder alles auf Automatik.


Gesendet von meinem E6653 mit Tapatalk

Danke Beta-User
Werde mich mal damit beschäftigen naja ich kann schon etwas programieren sowas wie Webseiten oder ähnliches aber Perl ist neu und interessant.
Welchen code meinst du auf github? Ist das der  https://github.com/rejoe2/FHEM/tree/dev-module/myShutter  (https://github.com/rejoe2/FHEM/tree/dev-module/myShutter)

Gesendet von meinem E6653 mit Tapatalk

Zitat von: MarkusHiba am 12 Juni 2017, 14:02:30
... dann warten bis Wind abgenommen hat aber dort auch warten nicht das zufällig ein Windstoß kommt danach wieder alles auf Automatik.

Das meinte ich mit "Komplizierter und aufwendiger kann es immer noch irgendwann werden."
So eben ist das ja nicht implementiert mit dem wieder einschalten. Da muss man dann wieder Schwellwerte und Wartezeiten berücksichtigen. Ist ja dann fast ähnlich aufwendig, wie bei der Abschattung. Deshalb erstmal wenn es stürmisch wird in den sicheren Zustand und da wird geblieben. Ist dann so ähnlich wie beim auslösen einer Sicherung bei einem Kurzschluss - die geht ja auch nicht automatisch wieder rein, wenn der Kurzschluss wieder weg ist. Nein Spaß - alles der Reihe nach und nicht auf einmal. Mein Vorschlag ist schnell und einfach integriert. Alles andere kommt später! ;)

Ok ja kompliziert kann man es machen aber ich kenne es so auf Arbeit haben wir auch sowas wenn Wind ist geht Rollo hoch und ist gesperrt wenn Wind weg ist ist es wieder freigegeben sowas wie beim Aussperrschutz könnte man machen für Wind.

Gesendet von meinem E6653 mit Tapatalk

Zitat von: MarkusHiba am 12 Juni 2017, 14:29:18
Ok ja kompliziert kann man es machen aber ich kenne es so auf Arbeit haben wir auch sowas wenn Wind ist geht Rollo hoch und ist gesperrt wenn Wind weg ist ist es wieder freigegeben sowas wie beim Aussperrschutz könnte man machen für Wind.

Das ist nicht das Problem, aber: Es muß zum Rest des Codes passen bzw. der andere Teil des Codes muß damit umgehen können...

Zitat von: MarkusHiba am 12 Juni 2017, 14:17:03
Welchen code meinst du auf github? Ist das der  https://github.com/rejoe2/FHEM/tree/dev-module/myShutter  (https://github.com/rejoe2/FHEM/tree/dev-module/myShutter)

Genau der; aber Achtung, ich habe eigentlich seit mehreren Wochen nichts mehr an diesem Teil des codes rumgeschraubt (außer einem Typo), kenne also den wirklichen Stand der Funktionalität nicht, zumal da nur HM abgebildet ist...
Wie gesagt, es geht dabei eher darum zu zeigen, welche Unterschiede hinsichtlich der Syntax exisiteren (es ist auch die "alte" Perl-Routine noch als 99- drin). Hat auch praktisch (noch) nichts/wenig Überschneidungen mit dem Code von Cluni u.a..

Zitat von: MarkusHiba am 12 Juni 2017, 14:29:18
Ok ja kompliziert kann man es machen aber ich kenne es so auf Arbeit haben wir auch sowas wenn Wind ist geht Rollo hoch und ist gesperrt wenn Wind weg ist ist es wieder freigegeben sowas wie beim Aussperrschutz könnte man machen für Wind.

das betrifft aber primär Jalousien. Rollos kann man ja durchaus bei Sturm runterfahren. Da wäre dann die Option eher die komplett runterzufahren und keine Lüftungsschlitze zu lassen. Nach dem Sturm müssten sie auf eine vorher eventuell vorhandene Lüftungsposition fahren.
Ist also gar nicht so einfach ...

Zitat von: Beta-User am 12 Juni 2017, 14:41:38
Das ist nicht das Problem, aber: Es muß zum Rest des Codes passen bzw. der andere Teil des Codes muß damit umgehen können...

Das ist auch nicht das Problem - der andere Code wird wenn gesperrt ja gar nicht ausgeführt. Aber es muss durchdacht, programmiert und getestet werden. Wann genau verlasse ich wieder den sicheren Modus und entsperre wieder alles? Da kommen einige Dinge zusammen, die sich AUSSERHALB der Routine gemerkt werden müssen und sehr viele Dinge/Überlegungen, die beachtet werden müssen. Deshalb erstmal der Ansatz: wenn windiger als Schwelle ==> sicher Zustand und warten auf manuelle Freigabe. ALLES ANDERE WIRD DANN SPÄTER NOCH DAZU KOMMEN!
Wer meint, dass er es schneller haben muss, der muss es dann auch selber programmieren... :D

Zitat von: kjmEjfu am 12 Juni 2017, 14:48:33
das betrifft aber primär Jalousien. Rollos kann man ja durchaus bei Sturm runterfahren. Da wäre dann die Option eher die komplett runterzufahren und keine Lüftungsschlitze zu lassen. Nach dem Sturm müssten sie auf eine vorher eventuell vorhandene Lüftungsposition fahren.
Ist also gar nicht so einfach ...

Aus diesem Grund mein obiger Vorschlag zu dem Attribut "Aktion bei Schwellwert-Überschreitung (aus, hoch, runter)"

Zitat von: Cluni am 12 Juni 2017, 09:51:19
Mojn!

Miss dieser Sache momentan bitte mal nicht zu viel Bedeutung zu. Matthias und ich haben uns grade drauf verständigt, dass wir einige Sachen umbauen wollen, damit u.A. das automatische Speichern in der Nacht entfällt (was mir seit Anfang an ein Dorn im Auge war). Da dies ein ziemlich grundlegender Umbau sein wird, werden wir eh alles nochmal umkramen müssen und uns dementsprechend auch bei den einzelnen Fallunterscheidungen alles nochmal genausten anschauen. Der Umbau könnte jedoch ein paar Tage in Anspruch nehmen, da wir ja auch noch andere Dinge tun. Ich bzw. wir melden uns mit einer aktuellen Version, sobald der Umbau fertig ist! ;)

Grüße Bernd

Hallo Bernd,

alles klar. Ich gedulde mich einfach. :-)
Wenn ich testen kann...sag Bescheid.

VG
Christian

Hallo
Sorry erst mal. hab den ganzen Thread nicht gelesen ....
Wie die meisten hier habe ich auch Rolladenaktoren ( HM )
Wie die meisten hier möchte ich die auch smart schalten.
Es gab da mal einen Versuch ein Modul zu entwickeln, leider ging es nicht weiter.
so in der Art verschiedener Attribute, Aussperrschutz ein aus, Kopplung Türsensor etc.

kann kein Modul programmieren, aber wäre es nicht sinnvoller ein Rolladen Smart Modul zu entwickeln ?
Wenn man sich die doifs so anschaut wie lange der Code ist und das für jede Rollade ?

Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
Sorry erst mal. hab den ganzen Thread nicht gelesen ....
Wie die meisten hier habe ich auch Rolladenaktoren ( HM )
Wie die meisten hier möchte ich die auch smart schalten.

Grade dann solltest du dir schon die Mühe machen und wenigstens die letzten paar Seiten lesen...  ::)

Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
so in der Art verschiedener Attribute, Aussperrschutz ein aus, Kopplung Türsensor etc.

Das alles kann unser Code bereits (von Frini und mir):
- fahren morgens/abends: (versch Modi: aus, immer oder nur bei Abwesenheit)
  * nach fester Zeit
  * Sonnenauf- bzw -untergang
  * +/- Zufallszeit (damit die Rollladen 1. nicht alle gleichzeitig und 2. an unterschiedlichen Tagen auch in unterschiedlicher Reihenfolge fahren)
  * + bzw. - Offset (damit ich einen Rollladen z.B. abends gezielt als letztes fahren kann trotz Zufallszeiten und Astrofunktion
  * vordefinierbare Position fürs Öffnen
  * Feiertags-/Wochenend-Modus
- zuschaltbarer Aussperrschutz
- automatisch Lüften auf vordefinierbare Position aktivierbar
- automatisches Öffnen auf vordefinierbare Position bei Drehgriffkontakt aktivierbar
- Automatische Abschattung (Möglichkeiten: ja, nein, verspätet, bei Anwesenheit, bei Abwesenheit)
  * frei pro Aktor definierbare Schwellen
  * frei definierbare Wartezeit (man will ja nicht, dass direkt gefahren wird, wenn die jeweilige Schwelle unter/überschritten wird)
  * einstellbarer Winkel, auf dem das Fenster liegt (es werden nur die Seiten abgeschattet, die in der Sonne sind)
  * frei definierbarer Vor- und Nachlaufwinkel (d.h. die Abschattung geschieht um die Fensterposition +/- den Winkeln (nützlich, wenn ein Baum schon Schatten wirft)
  * Höhe der Sonne (Elevation) einstellbar, ab bzw. bis zu der abgeschattet wird (wenn z.B. Gebäude Schatten werfen, wird die Abschattung früher beendet)
  * Helligkeitssensoren können jedem Aktor separat zugeordnet werden
  * Sperrzeit vor Nacht einstellbar (ich will ja nicht, dass der Rollladen wegen Abschattungsende öffnet und z.B. 2min später regulär schließt - dann bleibt er, wo er grade ist)

Ich bin grade aber dabei den kompletten Code umzustrukturieren - das dauert aber noch ein wenig. Aber im Grunde läuft das so alles bei mir zu Hause schon seit Wochen in der aktuellen Version schon recht sicher und zuverlässig...

Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
kann kein Modul programmieren, aber wäre es nicht sinnvoller ein Rolladen Smart Modul zu entwickeln ?
Wenn man sich die doifs so anschaut wie lange der Code ist und das für jede Rollade ?

Bei uns werkeln nur Notifies und ats. Die ats werden auch bleiben (weil sich die Zeiten ja täglich ändern). Momentan sind es aber noch viele Notifies, die auf ein Minimum reduziert werden sollen. Außerdem packt unsere Routine die ganzen Abfragen und Befehle in das jeweilige def des Notify/at - das soll sich bald auch ändern und somit viel übersichtlicher werden. Ein Modul werde ich aber nach momentanen Stand nicht daraus bauen. Aber vielleicht mache ich das ja mal, wenn alles so weit läuft, wie ich es gerne hätte...

Was genau meinst du ansonsten mit einem "Rollladen Smart Modul"?

PS: Rolladen sind zum essen da... :P

Zitat von: Franz Tenbrock am 13 Juni 2017, 10:47:01
Sorry erst mal. hab den ganzen Thread nicht gelesen ....
..
...
..
kann kein Modul programmieren, aber wäre es nicht sinnvoller ein Rolladen Smart Modul zu entwickeln ?
Wenn man sich die doifs so anschaut wie lange der Code ist und das für jede Rollade ?

Zitat von: Cluni am 13 Juni 2017, 11:23:42
Was genau meinst du ansonsten mit einem "Rollladen Smart Modul"?

@Franz Tenbrock: Also ehrlich gesagt bin ich gerade ein wenig angepisst. Du stellst eine Frage hier im Thread und sagst dazu, dass du nicht alles gelesen hast. Ich mache mir daraufhin die Arbeit und schreibe dir nochmal haarklein und Schritt für Schritt alles hin, wonach du gefragt hast und stelle dir noch eine Gegenfrage, ob du vielleicht etwas anderes gemeint hast. Aber du findest in über einer Woche noch nicht mal die 2 Minuten Zeit für eine kurze Antwort??!!??!! Echt unglaublich! Ja, ich bin angepisst....  >:(

Sorry -Asche auf mein Haupt

bin gerade in der knappen Zeit dabei mich in doorpi einzuarbeiten
war nicht Absicht
hab auch im Forum noch mal gesucht
es gab vor ca 1 Jahr mal einen Versuch von einem Forumsteilnehmer die Automatisierung der Rolladen für nicht Programmierer einfacher zu gestalten
ich hab dann nach dem Thread einige Zeit gesucht aber leider nicht gefunden
Es geht darum das nach Definition der HM Rolaldenaktoren eben einige Bedingungen wie nicht runterfahren wenn Tür offen bei sehr vielen Usern vorkommen aber recht schwierig sind zu definieren, oder Rolladen automatisch schließen wenn Sonnenuntergang etc
FHEM bietet zwar extrem viele Möglichkeiten man muss aber schon bei einfachen Dingen immer recht viel wissen.

Bin gerade wieder an einem Bewegungsmelder und an einer Foscam c!

@Franz Tenbrock: Also wenn ich eines im Zusammenhang mit FHEM gelernt habe ist, dass man eins nach dem anderen machen sollte.
Zuviele offene Projekte bringen zu viele Variablen.
Also ich wüsste aktuell nicht, wie wir ein Modul umsetzen sollten. Wir feilen noch an den Kinderkrankheiten und versuchen den aktuellen Code Fehlerfrei zu bekommen. Cluni investiert wirklich viel freie Zeit.

FHEM ist nunmal kein KlickiBunti, es erfordert viel Einarbeit, ist dafür aber wirklich mächtig  ???

muss doch auch nicht sein
bewundere viele hier wie viel Zeit in die Projekte gesteckt wird
aber es wird auch sehr viel Zeit investiert um Fragen zu beantworten wegen fehlender Doku ( kann ich hier nicht beurteilen ) oder eben weil es recht kompliziert ist
es sind halt hier auch viele die eben nicht tagtäglich programmieren

Also ein zwei Posts vor deinem hat Cluni recht detalliert aufgelistet, was zu tun ist um mit dieser Steuerung zu arbeiten.

Zitat von: Franz Tenbrock am 21 Juni 2017, 22:25:07
es sind halt hier auch viele die eben nicht tagtäglich programmieren

Aus diesem Grund habe ich mehrere Dinge getan. Es gibt zwei Dateien. In Fhem wird ein neues, eigenes Modul mit dem Namen "99_myUtils_Shutter.pm" erzeugt. Dort hinein kommt der Inhalt der gleichnamigen Datei in meinem Anhang am obigen Post. Alle anderen Voraussetzungen sind denke ich ziemlich gut Schritt-für-Schritt in der Textdatei erklärt. Für das alles braucht man kein Ass im Programmieren sein - mehr an die Hand genommen werden kann man ja schon kaum. Und ich denke, dass alles, was ggf. noch offen bleibt, auch entweder selber recht schnell und einfach hier im Forum herausgefunden werden kann und wenn man sich dazu auch noch nicht im Stande sieht, dann kann man ja auch immer noch hier fragen. Aber grundsätzlich ohne genauer hinzusehen einfach sagen, das ist zu kompliziert - na, dann musst du halt weiterhin Knöpfchen drücken, wenn es dir zu hell ist. Man muss ja wenigstens mal die Zeit investieren und das lesen, was andere mühsam zusammen geschrieben haben als Erklärung für Außenstehende (mal von der Programmierung bzw dem Testen ganz abgesehen)...

ich will euch doch gar nichts, eher das Gegenteil
.
Auch hier sind mittlerweile 180 Posts, da braucht es schon recht viel Zeit um alles zu lesen.

Ich habe eine funktionierende Steuerung, die aber nicht optimal ist ...

Du verwaist auf eine Post mit erin pm und Erklärungen, der ist aber auch shcon wieder aufgrund unserer Diskussion einiges weiter oben.

Der Übersichtlichkeit  halber wäre doch vielleicht folgendes sinnvoll.
macht einen neuen Thread auf für euer pm Modul, im ersten Post der aktuell gehalten wird die wichtigsten Infos, so dass man sich schnell zurecht findet und schauen kann ob das Modul für einen selber geeignet ist.
Die Updatereihenfolge, die ja in der TXT drin ist, im 1. Post im Klartext dann kann man schnell sehen was läuft  Hilfe und Erweiterungen im Thread, hier dann ein Link damit es alle finden.

Einige machen das doch so und das kommt sicher gut an.
FHEM hat einfach verdient noch besser zu werden,einfach genial was hier geht.

PS : ohen Hilfe hier aus dem Forum hätte ich sicher ncoh gar nichts. Danke an alle

Zitat von: Franz Tenbrock am 22 Juni 2017, 11:34:28
Du verwaist auf eine Post mit erin pm und Erklärungen, der ist aber auch shcon wieder aufgrund unserer Diskussion einiges weiter oben.

Die letzten 5 bis 10 Post sollte man aber schon anschauen, wenn man sich mit der Thematik beschäftigt... (die von mir gemeinte Antwort war #170 und nun sind wir bei #178 - ist sogar auf der gleichen Seite)

Zitat von: Franz Tenbrock am 22 Juni 2017, 11:34:28
Der Übersichtlichkeit  halber wäre doch vielleicht folgendes sinnvoll.
macht einen neuen Thread auf für euer pm Modul, im ersten Post der aktuell gehalten wird die wichtigsten Infos, so dass man sich schnell zurecht findet und schauen kann ob das Modul für einen selber geeignet ist.
Die Updatereihenfolge, die ja in der TXT drin ist, im 1. Post im Klartext dann kann man schnell sehen was läuft  Hilfe und Erweiterungen im Thread, hier dann ein Link damit es alle finden.

Hättest du dir die Mühe gemacht die letzten paar (!) Seiten (ich rede nicht von allen Seiten) zu lesen, dann wüsstest du auch bereits, was ich dazu gesagt habe...
siehe hier (ganz unten im Post im PS): https://forum.fhem.de/index.php/topic,69704.msg642383.html#msg642383

@Cluni: ich habe dein Script erfolgreich bei mir im System eingebaut und soweit funktioniert es perfekt. Ich habe lediglich noch den Civil Sonnenauf- bzw Untergang mit eingebaut.

P.S. in der txt war der Fehler mit Rollanden noch drin.

Hallo,

ich habe den Code für das Rollo Modul angepasst nach erfolgreichen Tests funktioniert es,
nun kommen die richtigen Rollos dran zum Test.

Civil habe ich noch nicht drinnen, wird aber noch nachgereicht.

userattr erweitert um paar 0.

userattr Auto_Modus_hoch:bei_Abwesenheit,immer,aus Auto_Modus_runter:bei_Abwesenheit,immer,aus Auto_hoch:Zeit,Astro,Civil Auto_runter:Zeit,Astro,Civil Auto_Abschattung_Pos:0,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 Auto_Abschattung_Pos_nach_Abschattung:-1,0,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 Auto_Lueften_Pos:0,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 Auto_offen_Pos:0,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 Auto_Himmelsrichtung Auto_Abschattung:ja,nein,verspaetet,bei_Abwesenheit,bei_Anwesenheit Auto_Zeit_hoch_frueh Auto_Zeit_hoch_spaet Auto_Zeit_hoch_WE_Urlaub Auto_Zeit_runter_frueh Auto_Zeit_runter_spaet Auto_Zufall_Minuten Auto_Drehgriffkontakt Auto_Fensterkontakt Auto_Luft_Fenster_offen:ja,nein Auto_Aussperrschutz:ja,nein Auto_Geoeffnet_Pos:0,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 Auto_Abschattung_Winkel_links:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 Auto_Abschattung_Winkel_rechts:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 Auto_Abschattung_Helligkeitssensor Auto_Abschattung_Schwelle_sonnig Auto_Abschattung_Schwelle_wolkig Auto_Abschattung_Wartezeit Auto_Abschattung_min_elevation Auto_Abschattung_min_Temp_aussen Auto_Abschattung_Sperrzeit_nach_manuell Auto_Offset_Minuten_morgens Auto_Offset_Minuten_abends Auto_Abschattung_Sperrzeit_vor_Nacht Auto_Abschattung_schnell_oeffnen:nein,ja Auto_Abschattung_schnell_schliessen:nein,ja


die Textdatei befindet sich unter diesem Link:
https://forum.fhem.de/index.php/topic,69704.msg651290.html#msg651290 (https://forum.fhem.de/index.php/topic,69704.msg651290.html#msg651290)

ich halte denn Post immer  Aktuell.

Leg da bitte nicht zu viel Herz Blut hinein. Es kommt bald eine neuere Version wie bereits mehrmals angekündigt.


Gesendet von iPhone mit Tapatalk

Hab ich schon gelesen ich bin froh das das erstmal funktioniert  wie sieht ungefähr die neue Version aus? Ich bin gespannt.

Gesendet von meinem E6653 mit Tapatalk

So, erstmal sorry, dass es nun doch etwas länger gedauert hat - war einiges zu tun privat...

Ich habe nun alles soweit überarbeitet und die aktuelle Version in einen eigenen, neuen Thread gepackt: https://forum.fhem.de/index.php/topic,73964.0.html (https://forum.fhem.de/index.php/topic,73964.0.html)
Die vielen Notifies für die Fensterkontakte und für den Aussperrschutz sind nun alle zusammen in einem einzigen Notify vereint.

Solltet ihr bereits eine ältere Version am laufen haben, dann müsst ihr ggf. die eine oder andere Stelle anpassen. Geht bitte nochmal die Attribute und Dummies durch und aktualisiert auf jeden Fall das Attribut "userattr" der Rollläden!

Schaut es euch an - viel Spaß beim Ausprobieren! ;)

Grüße
Cluni