Hallo liebe Leute,
ich habe draußen zwei der PIR/LUM- Sensoren HM-Sen-MDIR-O. Die Helligkeitsdaten benutze ich global für diverse Aufgaben, die Bewegungserkennung u.a., um bei Dunkelheit die Außenbeleuchtung zu schalten; üblicher Anwendungszweck denke ich.
Nun ist es aber hier so, das die Beleuchtung im Dachkranz auch den Wert der gemeldeten Helligkeit nach oben treibt, was letztlich in einem gewissen Bereich der gemessenen Helligkeit zu Endlosschleifen mit netten, aber ungewollten Lichtorgel- Effekten führt.
Eine weitere Erhöhung der Hysterese macht hier keinen Sinn und ist kontraproduktiv...
Ich habe jetzt z.B. versucht, bei aktivierter Außenbeleuchtung einen involvierten Dummy oder eine involvierte DOIF zu deaktivieren und nach Abschalten des Außenlichts wieder zu aktivieren. Das sah auf den ersten Blick schlau aus, ist es aber nicht, da es zu ganz merkwürdigem Schaltverhalten führt.
Dann kam ich auf die Idee, den "zusätzlichen" Helligkeitswert bei eingeschalteter Außenbeleuchtung vom gemeldeten Wert zu subtrahieren, aber auch da musste ich den Denkfehler zur Kenntnis nehmen, das die Sache leider ganz und gar nicht nicht linear ist. Somit auch unbrauchbar.
Frage ist also, ob hier jemand vielleicht schon mal vor dem gleichen Problem stand und eine richtig elegante Lösung des Problems gefunden hat? Mir gehen so langsam die Idee'n aus :-[
Hallo!
Du könntest es z.B. so machen:
DOIF setzt wenn ein neuer Helligkeitswert gemessen wird ein "custom-reading" oder einen Dummy auf den aktuellen Helligkeitswert, WENN die Außenbeleuchtung aus ist.
DOIF2 schaltet die Außenbeleuchtung ein, wenn Bewegung und der neue Dummy<X ist
--> Du verwertest die Helligkeit nur dann, wenn die Außenbeleuchtung aus ist.
Nachteil:
Wenn es gerade hell wird, bleibt die Beleuchtung so lange eingeschaltet, bis keine Bewegung mehr ist - unabhängig von der Helligkeit.
Grüße
... jupp, habe es jetzt so ähnlich gelöst:
# Helligkeit mitteln und auf 100% umrechnen, wenn keine der Außenlampen in Betrieb
define LUM_set DOIF (([+300] or ["HM2BB"]) and [HM4SW1_1] eq "off" and [HM4SW2_1] eq "off") \
(set LUM W3 [LUM:W2], set LUM W2 [LUM:W1], set LUM W1 [LUM:W0], set LUM W0 {([HM2BB1:brightness]+[HM2BB2:brightness])/2}) \
(set LUM {(int((100*(([HM2BB1:brightness]+[HM2BB2:brightness])/2+0.5))/250))})
attr LUM_set do always
Das funktioniert so weit. Aus dem "Schieberegister" W0-3 generiere ich zusätzlich eine Art Tendenz und werte nach Helligkeit steigend, gleich fallend aus...
# Aus dem Helligkeitsverlauf Tendenz ermitteln
define LUM_avg DOIF ([LUM:W0] > ([LUM:W1]+[LUM:W2]+[LUM:W3])/3+0.3) (set LUM T 1) \
DOELSEIF ([LUM:W0] < ([LUM:W1]+[LUM:W2]+[LUM:W3])/3-0.3) (set LUM T -1) \
DOELSE (set LUM T 0)
Allerdings konnte ich jetzt feststellen, das andere Fremdeinflüsse, wie z.B. vorbeifahrende Autos mit Fernlicht oder wenn wir heim kommen und mit den PKW auf'n Hof fahren, in der Nähe der Schaltschwellen die ganze Sache immer noch aus dem Tritt bringen. Das führt ab- und an zu recht lustigen Effekten im Haus ::)
Ich komme so langsam zu der Einsicht, das die Verwendung der Helligkeitssensoren im Bewegungsmelder, welche ja naturgemäß immer da hin schauen, wo Aktion erwartet wird, eine doofe Idee ist, wenn man damit mehr machen möchte ...
vielleicht noch eine zeitliche begrenzung einbauen.
zb kurz vor sonnenuntergang nur 1 x über lichtwert einschalten und kurz vor sonnenaufgang nur 1x über lichtwert ausschalten.
... ja, das hatte ich anfänglich auch so. Nur wird es am Tage ja auch manchmal düster (Gewitter, Angriff der Zylonen, ...) ...
Ich werde wohl nicht umhin kommen, einen Sensor (ggf. DIY mit WEMOS) auf's Dach zu tackern, welcher von den bodennahen Einflüssen nichts mit bekommt. Dann kann ich immer noch die beiden zur Straße weisenden (und später im Garten befindlichen) PIR via Modul VALVES und priority-device mit einbinden ...
wenn du so genau detektieren willst, ist ein besser positionierter sensor sicherlich effektiver.