manuelle Steuerung bei DOIF-basierter Rolladenautomatisierung

[StefanD]

Hallo zusammen,

ich habe im Zusammenspiel dem neuen HM Lichtsensor und weiteren Parametern wie Rauminnentemperatur, Außentemperatur, vorhergesagte Temperatur die Rolläden auf der Südseite automatisiert. Funktioniert soweit prima und zuverlässig, gerade der neue Lichtsensor spart die bekannte(n) Bastellösung(n) mit dem Differenztemperatursensor. 
Das DOIF für diese Parameter setzt einen Dummy auf einen Sollwert für die Rolladenposition. Jeder Aktor hat ein eigenes DOIF, welches den Rolladen dann auf den Wert des Dummies fährt. An einigen Fenstern/Türen sind Fenstergriffkontakte, die je nach dessen Stellung ein Schließen verhindern (offen) oder nur bis zu einem bestimmten Wert zulassen (gekippt).

Um die Rolläden im Wohnzimmer auch manuell steuern zu können habe ich auch eine 8-Tastenfernbedienung. Wird diese zum Verfahren verwendet, kann ich das über das Event im Aktorbezogenen DOIF berücksichtigen und damit die Automatik für den jeweiligen Rollo übersteuern, bzw. unberücksichtigt lassen.

Wofür ich jedoch keine Lösung gefunden habe, auch nicht über die Suchfunktion hier noch Google, ist, wie ich mit einem manuellem Eingriff über den HM Aktor (HM-LC-BL1-FM mit Tastern) den gleichen Effekt erreiche. Der Aktor meldet beim Verfahren des Rollos unter der Fahrt auch immer wieder den jeweiligen Öffnungswert. Das tut er beim manuellen Verfahren, wie beim Verfahren über FEHM auf einen Zielwert.
Darin liegt für mich gerade die Herausforderung, wie ich das gelöst bekomme...

Frau und Kinder schaffen das Verfahren über die Fernbedienung, nur die Haushaltshilfe tut sich damit schwer und möchte unbedingt die Bedienung über die Taster/Schalter am Fenster haben.

Lässt sich das in den DOIFs für die jeweiligen Aktoren auch abfangen oder braucht's da andere Mechanismen in FHEM?

Die Haushaltshilfe gegen eine technikafine zu ersetzten, die die FB nutzt, ist naheliegend, aber keine akzeptable Lösung! 

VG Stefan

[Per]

Naheliegend wäre, wenn du dein(e) aktuellen DOIF posten würdest, dann hätten wir eine Diskussionsgrundlage.

[StefanD]

Naheliegend wäre, wenn du dein(e) aktuellen DOIF posten würdest, dann hätten wir eine Diskussionsgrundlage.

Ich war der Ansicht, dass die existierenden DOIFs ehere eine untergeordnete Rolle spielen, da die Frage mehr darauf zielte ob und wie man das manuelle Verfahren über die Aktoren abfangen kann. Wenn's hilft, stelle ich die natürlich gerne zur Verfügung:

Hier das DOIF doif_Beschattung, welches den Wert eines Dummies setzt, der dann von weiteren DOIFs an die Aktoren gesendet wird:

Code Auswählen Erweitern

([{sunset()}-{sunrise()}]) ( set dmy_eg_wz_SetRolloSued off )
DOELSEIF (([18:00-{sunrise()}]) and [os_Lichtsensor:brightness:d] <= 120) ( set dmy_eg_wz_SetRolloSued off )
DOELSEIF ([07:00-20:00] and [eg_wz_Thermostat_Weather:temperature:d] > 24 and [os_Aussenthermometer:temperature:d] >= 23 and ([doif_Beschattung:cmd:d] >= 3 or [doif_Beschattung] eq "initialized")) ( set dmy_eg_wz_SetRolloSued 33 )
DOELSEIF ([07:00-20:00] and [eg_wz_Thermostat_Weather:temperature:d] > 22 and [os_Aussenthermometer:temperature:d] >= 23 and [wtr_PROPLANTA:fc0_tempMax:d] >= 27 and ([doif_Beschattung:cmd:d] >= 3 or [doif_Beschattung] eq "initialized")) ( set dmy_eg_wz_SetRolloSued 50 )
DOELSEIF ([eg_wz_Thermostat_Weather:temperature:d] >= 24 and [os_Lichtsensor:brightness:d] >= 90000 and ([dmy_eg_wz_SetRolloSued:state:d] > 33 or [dmy_eg_wz_SetRolloSued] eq "on") and ([doif_Beschattung:cmd:d] >= 3 or [doif_Beschattung] eq "initialized")) ( set dmy_eg_wz_SetRolloSued 33 )
DOELSEIF ([eg_wz_Thermostat_Weather:temperature:d] >= 23 and [os_Lichtsensor:brightness:d] >= 90000 and ([dmy_eg_wz_SetRolloSued:state:d] > 50 or [dmy_eg_wz_SetRolloSued] eq "on") and ([doif_Beschattung:cmd:d] >= 3 or [doif_Beschattung] eq "initialized")) ( set dmy_eg_wz_SetRolloSued 50 )
DOELSEIF (([06:00-20:00|7] or [07:00-20:00|8]) and [os_Lichtsensor:brightness:d] >= 1000 and [os_Lichtsensor:brightness:d] < 20000 and [os_Aussenthermometer:temperature:d] < [eg_wz_Thermostat_Weather:temperature:d]) ( set dmy_eg_wz_SetRolloSued on )
DOELSEIF (([06:00-09:30|7] or [07:00-09:30|8]) and [os_Lichtsensor:brightness:d] >= 1000) ( set dmy_eg_wz_SetRolloSued on )

Attributes:
   icon       fts_shutter_automatic
   repeatsame 1:1:1:1:1:1:1:1
   room       Rollladen
   wait       0:0:0:300:180:180:600:0

Die beiden Aktoren eg_wz_Rollo_Sofa und eg_wz_Rollo_Balkontuer haben je ein eigenes DOIF, da nur die Balkontür über einen Sensor am Griff verfügt, das Fenster nicht:
doif_eg_wz_Rollo_Balkontuer

Code Auswählen Erweitern

([eg_wz_Balkontuer] eq "open" and [eg_wz_Rollo_Balkontuer:level:d] < 100) ( set eg_wz_Rollo_Balkontuer on )
DOELSEIF ([eg_wz_Balkontuer] eq "tilted" and [eg_wz_Rollo_Balkontuer:level:d] < 25) ( set eg_wz_Rollo_Balkontuer pct 33 )
DOELSEIF ([eg_wz_Balkontuer] eq "closed" and [eg_wz_Rollo_Balkontuer] ne [dmy_eg_wz_SetRolloSued]) ({ fhem("set eg_wz_Rollo_Balkontuer " . (Value("dmy_eg_wz_SetRolloSued"))) })

Attributes:
   do         always
   room       Rollladen,Wohnzimmer
   wait       0:0:[dmy_FBDelay:state:d]

doif_eg_wz_Rollo_Sofa

Code Auswählen Erweitern

([eg_wz_Rollo_Sofa] ne [dmy_eg_wz_SetRolloSued]) ({ fhem("set eg_wz_Rollo_Sofa " . (Value("dmy_eg_wz_SetRolloSued"))) })

Attributes:
   do         always
   room       Rollladen
   wait       [dmy_FBDelay:state:d]

Das Übersteuern durch die Fernbedienung habe ich dadurch gelöst, dass ein DOIF auf die Tastendrücke reagiert und dann den Dummy dmy_FBDelay auf einen Wert setzt, der in den beiden DOIFs für die Aktorenansteuerung das Attribut WAIT beeinflusst:
doif_FBDelay

Code Auswählen Erweitern

(["^eg_wz_FB_Rollo_"]) (set dmy_FBDelay [dmy_FBDelay:FBDelay])

Attributes:
   do         always
   room       Rollladen

dmy_FBDelay

Code Auswählen Erweitern

Internals:
   CFGFN
   NAME       dmy_FBDelay
   NR         8338
   STATE      0
   TYPE       dummy
   Readings:
     2016-06-11 11:35:49   FBDelay         1800
     2016-06-11 12:05:35   d               0
     2016-06-11 11:36:24   defaultDelay    0
     2016-06-11 12:43:20   state           0
Attributes:
   event-on-change-reading state
   event-on-update-reading state
   room       Rollladen

Um die erzwungene Übersteuerung zeitlich zu begrenzen (aktuell 30min) und die Kontrolle wieder voll an die Automatisierung zu übergeben, gibt's noch weiteres DOIF doif_ResetFBDelay:

Code Auswählen Erweitern

([dmy_FBDelay:state:d] != [dmy_FBDelay:defaultDelay:d]) (set dmy_FBDelay [dmy_FBDelay:defaultDelay:d])

Attributes:
   do         always
   room       Rollladen
   wait       1800


Während ich diesen Beitrag zusammengezimmert habe, ist mir ein möglicher Lösungsansatz in den Sinn gekommen: Wenn state des Dummy dmy_eg_wz_SetRolloSued seit >= 20s nicht geändert hat als auch das Reading cmd des DOIFs zum jeweiligen Aktor (jeweils Timestamp), sich jedoch der Level des Aktors ändert, bzw. gerade geändert hat, müsste man dadurch auf ein manuelles Verfahren eines Rollos rückschließen können...
Das würde zwar das Verfahren über die FB, welche direkt gekoppelt ist, mit einschließen, aber letztlich ist das ebenso ein manueller Eingriff.

Oder habe ich hier einen kapitalen Denkfehler?

VG Stefan

[StefanD]

Während ich diesen Beitrag zusammengezimmert habe, ist mir ein möglicher Lösungsansatz in den Sinn gekommen: Wenn state des Dummy dmy_eg_wz_SetRolloSued seit >= 20s nicht geändert hat als auch das Reading cmd des DOIFs zum jeweiligen Aktor (jeweils Timestamp), sich jedoch der Level des Aktors ändert, bzw. gerade geändert hat, müsste man dadurch auf ein manuelles Verfahren eines Rollos rückschließen können...
Das würde zwar das Verfahren über die FB, welche direkt gekoppelt ist, mit einschließen, aber letztlich ist das ebenso ein manueller Eingriff.

Oder habe ich hier einen kapitalen Denkfehler?

Viel Grundlage zu einer Diskussion haben meine DOIFs bis jetzt ja nicht gebracht... 

Hab eben mal testweise ein zus. DOIF zusammengezimmert:

Code Auswählen Erweitern

([eg_wz_Rollo_Sofa] and [doif_eg_wz_Rollo_Sofa:state:sec] > 30) (set dmy_FBDelay [dmy_FBDelay:FBDelay])
DOELSEIF ([eg_wz_Rollo_Balkontuer] and [doif_eg_wz_Rollo_Balkontuer:state:sec] > 30) (set dmy_FBDelay [dmy_FBDelay:FBDelay])
DOELSE ()

Funzt wunderbar. 

Damit wäre mein, bzw. das Problem der Haushaltshilfe gelöst! Nun muss ich nur beim ein oder anderen Device noch den Namenanpassen, damit das ganze stimmig ist, aber damit hat sich die Sache dann auch. Vielleicht führe ich die übersteuernden DOIFs auch in eines zusammen, mal sehen...

VG Stefan

[Per]

Viel Grundlage zu einer Diskussion haben meine DOIFs bis jetzt ja nicht gebracht... 

Ich war leider nur mit dem Handy unterwegs (da kann ich nicht seitlich scrollen, sehe also nicht alle Definitionen) und wenn andere nicht zum Lesen/Antworten animiert werden, kann ich das nicht ändern.

Aber erstmal zur Vereinfachung:
Statt mit den beiden ersten DOIF ein Dummy zu setzen, kannst du direkt den Status des DOIF setzen: attr cmdState ist dafür der Befehl. wait funktionert dabei weiterhin.
Weiterhin kannst du auch im Befehlsteil von DOIF mit set GERAET1 [GERAET2] statt {fhem "set GERAET1 ". Value("GERAET2")} arbeiten. Spart Code, Zeit und ist übersichtlicher. Und gerade Übersicht wird es sein, die hier notwendig ist, um Fehler (oder "Mitdenker") zu finden.

Z.B. Wozu dient

Code Auswählen Erweitern

attr doif_Beschattung repeatsame 1:1:1:1:1:1:1:1
? Müsstest du dazu nicht wenigstens alle DOIF-Zweige mit dem gleichen Ergebnis zusammenfassen?
Oder

Code Auswählen Erweitern

define doif_FBDelay DOIF (["^eg_wz_FB_Rollo_"]) (set dmy_FBDelay [dmy_FBDelay:FBDelay])
define doif_ResetFBDelay DOIF ([dmy_FBDelay:state:d] != [dmy_FBDelay:defaultDelay:d]) (set dmy_FBDelay [dmy_FBDelay:defaultDelay:d])
define dmy_FBDelay dummy
setreading dmy_FBDelay FBDelay 1800
setreading dmy_FBDelay defaultDelay 0
Warum nicht

Code Auswählen Erweitern

define doif_FBDelay DOIF (["^eg_wz_FB_Rollo_"]) ()()
attr doif_FBDelay cmdState 1800|0
attr doif_FBDelay wait 1800
attr doif_FBDelay do resetwait
Dann fragst du [doif_FBDelay:state:d] statt [dmy_FBDelay:state:d] ab.
Da die Zeiten jetzt nur noch an einer Stelle stehen, brauchst du auch keine extra Variable dafür.

Dein neues DOIF müsste dann da mit rein:

Code Auswählen Erweitern

define doif_FBDelay DOIF (["^eg_wz_FB_Rollo_"] or [eg_wz_Rollo_Sofa] and [doif_eg_wz_Rollo_Sofa:state:sec] > 30 or [eg_wz_Rollo_Balkontuer] and [doif_eg_wz_Rollo_Balkontuer:state:sec] > 30) ()()

Die angefragte Übersteuerung bekommst du wahrscheinlich durch ein Fragezeichen hin, allerdings ist mir der Code noch zu verworren, um sagen zu können, wohin genau.

[StefanD]

Ich war leider nur mit dem Handy unterwegs (da kann ich nicht seitlich scrollen, sehe also nicht alle Definitionen) und wenn andere nicht zum Lesen/Antworten animiert werden, kann ich das nicht ändern.

War nicht böse gemeint, deshalb auch der Smiley dahinter.

Aber erstmal zur Vereinfachung:
Statt mit den beiden ersten DOIF ein Dummy zu setzen, kannst du direkt den Status des DOIF setzen: attr cmdState ist dafür der Befehl. wait funktionert dabei weiterhin.
Weiterhin kannst du auch im Befehlsteil von DOIF mit set GERAET1 [GERAET2] statt {fhem "set GERAET1 ". Value("GERAET2")} arbeiten. Spart Code, Zeit und ist übersichtlicher. Und gerade Übersicht wird es sein, die hier notwendig ist, um Fehler (oder "Mitdenker") zu finden.

Das mit dem cmdState ist mir klar, habe ich bei anderen DOIFs, vor allem bei der Heizungssteuerung im Einsatz. Den Dummy könnte man damit im Moment sicherlich ersetzen und hatte ich auch anfangs beim Überlegen wie ich das Ganze angehe schon mal so auf der Uhr. So spontan kann ich gar nicht sagen, warum ich das dann doch über den Dummy gemacht habe. Vermutlich war ich nur zu faul, den Dummy nach den ersten Schritten durch den cmdState abzulösen.

Z.B. Wozu dient

Code Auswählen Erweitern

attr doif_Beschattung repeatsame 1:1:1:1:1:1:1:1
? Müsstest du dazu nicht wenigstens alle DOIF-Zweige mit dem gleichen Ergebnis zusammenfassen?

Durch das do always will ich ein immer währendes wiederholen unterbinden. Korrekterweise müssen die natürlich dann alle auf 0 stehen. Ich hatte wohl noch von was anderem 0 als deaktivieren im Kopf. 
Aaaaaber: Das do always und resetwait kann man sich mit dieser Kombination damit letztlich auch sparen...

Oder

Code Auswählen Erweitern

define doif_FBDelay DOIF (["^eg_wz_FB_Rollo_"]) (set dmy_FBDelay [dmy_FBDelay:FBDelay])
define doif_ResetFBDelay DOIF ([dmy_FBDelay:state:d] != [dmy_FBDelay:defaultDelay:d]) (set dmy_FBDelay [dmy_FBDelay:defaultDelay:d])
define dmy_FBDelay dummy
setreading dmy_FBDelay FBDelay 1800
setreading dmy_FBDelay defaultDelay 0
Warum nicht

Code Auswählen Erweitern

define doif_FBDelay DOIF (["^eg_wz_FB_Rollo_"]) ()()
attr doif_FBDelay cmdState 1800|0
attr doif_FBDelay wait 1800
attr doif_FBDelay do resetwait
Dann fragst du [doif_FBDelay:state:d] statt [dmy_FBDelay:state:d] ab.
Da die Zeiten jetzt nur noch an einer Stelle stehen, brauchst du auch keine extra Variable dafür.

Dein neues DOIF müsste dann da mit rein:

Code Auswählen Erweitern

define doif_FBDelay DOIF (["^eg_wz_FB_Rollo_"] or [eg_wz_Rollo_Sofa] and [doif_eg_wz_Rollo_Sofa:state:sec] > 30 or [eg_wz_Rollo_Balkontuer] and [doif_eg_wz_Rollo_Balkontuer:state:sec] > 30) ()()

Die angefragte Übersteuerung bekommst du wahrscheinlich durch ein Fragezeichen hin, allerdings ist mir der Code noch zu verworren, um sagen zu können, wohin genau.

Die Attribute des DOIF wollte ich zukünftig nicht mehr anfassen müssen, wenn mir der Wert, aus welchen Gründen auch immer, nicht passt. Ich hatte im Hinterkopf, den ggf. über FTUI anpassbar zu machen und da ist der Dummy der bessere Ansatz.

Das mit den Werten in den Dummies kommt wohl davon, dass ich früher sehr oft Entwicklern auf die Fingerklopfen musste, die fast immer Dinge, die man besser in Konfigurationsdateien abgelegt hätte, fest im Code hatten. Waren aus Optimierungsgründen geringfügige Änderungen notwendig, war das immer ein Riesenakt, von den zeitlichen Abständen ganz zu schweigen... Ja ich weiß, Implementierungsrichtlinien, etc., aber grau ist alle Theorie und in der Praxis machen viele was sie wollen, wenn es keine Konsequenzen hat... 

VG Stefan

[Per]

Die Attribute des DOIF wollte ich zukünftig nicht mehr anfassen müssen, wenn mir der Wert, aus welchen Gründen auch immer, nicht passt. Ich hatte im Hinterkopf, den ggf. über FTUI anpassbar zu machen und da ist der Dummy der bessere Ansatz.

Du kannst den state eines DOIF mit setreading doif_xy state wunschstate setzen.

Das mit den Werten in den Dummies kommt wohl davon, dass ich früher sehr oft Entwicklern auf die Fingerklopfen musste, die fast immer Dinge, die man besser in Konfigurationsdateien abgelegt hätte, fest im Code hatten.

Mir schon klar, deshalb mein Verweis darauf, dass es nur an einer Stelle (ok, eineinhalb ) im Code steht. Der Aufwand beim Ändern im Quelltext ist also minimal und in der Oberfläche kleiner als mit Variablen.

[StefanD]

Du kannst den state eines DOIF mit setreading doif_xy state wunschstate setzen.

Sofern der state nur einen Wert hat, bin ich voll bei dir. Da wäre in der Tat vollkommen egal und könnte auch über FTUI geändert werden.

Ich habe den Wert aber auch noch an einer weitern Stelle im Einsatz und da ist es in Summe dann mit einem Dummy etwas einfacher.

VG Stefan