DOIF & Twilight & Motion zur Steuerung von Außenlicht

Begonnen von Morgennebel, 01 November 2015, 18:17:17

Vorheriges Thema - Nächstes Thema

Morgennebel

Guten Abend,


ich komme mit meiner Lichtsteuerung nicht weiter und möchte gerne um Hilfe und Ratschläge bitten.

Szenario:

  • structure Aussenbeleuchtung sind alle Lampen im Außenbereich
  • EG.Scheune.MotionDetect ein Bewegungsmelder

Das Twilight-Modul ist eingebunden. Ich möchte erreichen:


  • Außenbeleuchtung an an Werktagen ab 05:30 bis zur Dämmerung
  • Außenbeleuchtung an an Wochenenden und Schuleferien (über die holiday2we-Funktion) ab 06:30 bis zur Dämmerung
  • Außenbeleuchtung an ab Dämmerung bis 22:30
  • Außenbeleuchtung an für 4 Minuten bei erkannter Bewegung bei Dämmerung - sofern die Lampen nicht schon an sind

Mein Ansatz war über DOIF:


define AussenlichtONOFF DOIF ([05:30-{ReadingsVal('MyTwilight','sr_civil','')}|8]) (set Aussenlicht on) \
    DOELSEIF ([06:30-{ReadingsVal('MyTwilight','sr_civil','')}|7]) (set Aussenlicht on) \
    DOELSEIF ([{ReadingsVal('MyTwilight','ss_civil','')}-22:00]) (set Aussenlicht on) \
    DOELSEIF ([EG.Scheune.MotionDetect:motion] and [22:00-05:30]) (set Aussenlicht on-for-time 240) \
    DOELSE (set Aussenlicht off)
attr AussenlichtONOFF do always


Leider funktioniert dies nicht - die Lampen bleiben abends aus und der Bewegungsmelder reagiert auch nicht richtig. Die Logfiles sind leer.

Eine andere DOIF-Anweisung in derselben .cfg-Datei funktioniert tadellos - dies ist aber auch viel einfacher.

Was mache ich falsch?

Danke, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Yil

Hi Morgennebel,

ich habe ein ähnlich gelagertes Problem, verwende jedoch statt des Twilight-Moduls Berechnungen aus den sunrise() und sunset()-Funktionen. Auch bei mir macht die Schaltung in Verbindung mit den Wochentagen nicht das, was sie soll. Bist Du hier irgendwie weiter gekommen?

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

Morgennebel

Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Yil

Ok danke - ist dann doch nicht ganz mein Problem. Bei mir ist es so, dass DOIF viel öfter triggert als es soll und die Lampen mehrfach ein- bzw. ausgeschaltet werden. Ich werde nun mal versuchen, die auslösenden $DEVICE und $EVENTS ins Log zu schreiben und mehr über diesen Trigger-Wildwuchs herauszufinden.

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

Morgennebel

Hi Yil,


DOIF entspricht nicht einer verschachtelte if-elseif-elseif-else-then Anweisung einer höheren Programmiersprache, in der Du ein Ereignis in das if-Konstrukt oben reinwirfst und das Ereignis dann nett die ganzen if-elseif-Anweisungen durchputzelt bis eines zuschlägt.

DOIF reagiert auf Statusänderungen eines Readings eines Devices und macht dann was. In Deiner Lösung löst z.B. der motion-Sensor aus und macht das Licht für 240 Sekunden an - egal, ob es vorher an oder aus war. Nach Ablauf der 240 Sekunden geht das Licht aus. Dann triggert Deine Twilight-/Zeit-Kombination und macht das Licht wieder an. usw. und so fort.

Außerdem löscht Du den motion-Zustand im Bewegungsmelder nicht. Der triggert also eigentlich ständig.

Die Lösung im Wiki entspricht genau Deinen Anforderungen und funktioniert prima. Du mußt nur die Zeiten anpassen und sunrise/sunset durch Twilight ersetzen.

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Yil

Hi Morgennebel,

danke für die Erläuterung, das hilft weiter. Ich bin - immerhin durch eigenes Nachdenken  ;) - noch die Erklärung gekommen, warum die Ausführungszeiten nicht mit den berechneten Zeiten des DOIF Statements übereinstimmen: ich habe zu den Zeit, die die Funktionen sunrise() und sunset() ergeben, Zufallswerte hinzuaddiert bzw. abgezogen und dabei nicht im Hinterkopf behalten, dass ich diesen Wert ja nicht vorneweg in einer Variablen speichere und dann mehrfach diesen gleichbleibenden Wert verwende, sondern ich lasse ihn JEDESMAL neu durch die Zufallsfunktion laufen, auch bei der eigentlichen Ausführung. So habe ich JEDESMAL einen neuen Wert und JEDESMAL damit auch eine andere Ausführunsgzeit als mir die unterschiedlichen Timer des DOIF Statements anzeigen (die ja zu einem früheren Zeitpunkt als dem Ausführunsgzeitpunkt berechnet werden).

So habe ich - ohne es zu wollen - eine fast vollkommene Abwesenheitssimulation geschaffen ;-)

Immerhin hab ich es jetzt geschafft, alles zu verstehen, was mich wieder etwas zufriedener macht. Ich schau mir nochmal das Wiki an und insbesonderen die Twilight-Funktion, mit der ich bisher nicht gearbeitet habe.

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

Yil

Hi Morgennebel,

noch eine Nachfrage habe ich allerdings zu:

ZitatIn Deiner Lösung löst z.B. der motion-Sensor aus und macht das Licht für 240 Sekunden an - egal, ob es vorher an oder aus war.

ich hab keinen Motion-Sensor, sondern ich prüfe alleine die Zeit. Was ich nicht prüfe ist der Schaltzustand. So macht es natürlich nur Sinn den Device anzuschalten, wenn er nicht vorher schon an war (resp. umgekehrt). Ich hatte mit vorgestellt, dies so zu lösen:

DOIF (..) (set <device> on if ($EVENT ne 'on'))

Leider funktioniert das nicht, er meldet, dass "on" keine Parameter braucht und führt das Statement nicht aus.

Hat jemand einen Tipp, wie ich das korrekt abfragen kann?

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

turo

Nur kurz im Vorbeischauen: Du mischst da Perl und FHEM zusammen. Also entweder muss das reines FHEM werden (mit "IF" etwa) oder reines Perl (so {fhem("set tralala") if $irgendwas}).

Aber: Wenn Du eine zusätzliche Bedingung hast - ist die nicht besser im Bedingungsteil des DOIF aufgehoben?

Gruss,
turo
3xRaspberry PI, Homematic, SELVE Rollos, 1-wire, Logitech Harmony, Alexa, Fussbodenheizung (ESP8266), Netatmo

Morgennebel

Hi Yil,


jetzt habe ich Deine und meine Frage verwechselt.

Was spricht denn gegen:


define DI_AussenlichtTimer DOIF (([15:00-23:00|8] or [05:30-08:00]) and ([MyTwilight:twilight_weather] < 40)
   (set Aussenlicht on)
DOELSE
   (set Aussenlicht off)
attr DI_AussenlichtTimer do always


Das macht das an Werktagen zwischen 15 und 23 Uhr sowie jeden Morgen zwischen 05:30 und 8 Uhr das Licht an, sofern es dunkel genug ist. Ist es um 15 Uhr noch hell, wird das Licht entsprechend spaeter angemacht...

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Yil

Hi Turo,

ja, das habe ich befürchtet, dass da etwas durcheinander geht. Wie gesagt: Anfänger  :o

Danke für den Tipp, eine weitere Bedingung mit in die DOIF Abfrage einzubauen. Bei DOELSE geht das aber nicht.

Könntest Du mir ein Syntax-korrektes Beispiel geben, wie ich verhindere, dass in einem DOELSE-Fall ein Device ausgeschaltet wird, wenn er zum Triggerzeitpunkt sowieso schon ausgeschaltet ist?

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

Yil

Hi Morgennebel,

das spricht gar nichts dagegen. Mein Problem liegt ehrr dort, dass die Abfragen zu oft ausgeführt werden und ein Anschalten dort erfolgt, wo der Device schon angeschaltet ist (so mein Log). Das würde ich gerne abfangen - vgl. auch meine Fragestellung an Turo.

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

turo

Hi Yil,

aber gerne! Ich wähle die Perl-Lösung (weil ich das besser kann). Als Beispiel für "mydevice", wobei ich annehme, dass der Status von "mydevice" dann "on" oder "off" ist.

DOELSE ( {fhem("set mydevice off") if [mydevice] ne "off"} )
oder (gefällt mir besser, weil man das dann schön als "mach das außer wenn dies" lesen kann):
DOELSE ( {fhem("set mydevice off") unless [mydevice] eq "off"} )

Gruss,
turo
3xRaspberry PI, Homematic, SELVE Rollos, 1-wire, Logitech Harmony, Alexa, Fussbodenheizung (ESP8266), Netatmo

Yil

Hi Turo,

das ist ja sehr cool - ich hab das elegantere der beiden eingebaut und bin sehr gespannt, wie's läuft! Danke!

VG Yil
HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

Yil

Hallo Turo,

zu schnell gefreut: es kommt folgender Fehler, den ich noch nicht hatte:

{fhem("set Garten.Beleuchtung off") unless off eq 'off'}: Bareword "off" not allowed while "strict subs" in use at (eval 19259) line 1.

Was könnte das sein?

VG Yil

HM CCU3 und HCU mit ca. 50 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth,
HUE, UniFi

turo

hinter dem unless muss dann bei Dir [Garten.Beleuchtung] stehen - mit den "[]" - nicht ein off (Das meckert auch die Fehlermeldung an) - so hatte ich das gemeint.

Zur Sicherheit komplett:
{fhem("set Garten.Beleuchtung off") unless [Garten.Beleuchtung] eq "off"}
3xRaspberry PI, Homematic, SELVE Rollos, 1-wire, Logitech Harmony, Alexa, Fussbodenheizung (ESP8266), Netatmo