Carportbeleuchtung mit Bewegungsmelder und WifiLight

Begonnen von Take-Off, 05 August 2015, 22:50:41

Vorheriges Thema - Nächstes Thema

Take-Off

Hallo zusammen,

ich habe eine etwas komplexere Beleuchtung für mein Carport vor.

- Bei Bewegungserkennung sollen die LEDs auf Weiß 100% wechseln.
- Wenn vorher eine andere Farbe/Helligkeit eingestellt ist soll diese nach Ablauf einer Zeit wieder aufgerufen werden.

Das ganze habe ich in einer Subroutine wie folgt gelöst:

sub Carport_Motion($)
{
my $hueC = ReadingsVal('CarportLED','hue','');
my $satC = ReadingsVal('CarportLED','saturation','');
my $valC = ReadingsVal('CarportLED','brightness','');

fhem("delete CarportMotionAus;
set CarportLED HSV 0,0,100 2;
define CarportMotionAus at +00:00:15 set CarportLED HSV $hueC,$satC,$valC 5 ")

}


Funktioniert soweit.

Jetzt aber folgendes Problem:

Erkennt der Bewegungsmelder eine Person wechseln die LEDs auf Weiß 100%. Erkennt er VOR Ablauf der Zeit eine weitere Bewegung wird natürlich
der vorher gespeicherte Wert auf Weiß 100% gesetzt. Ergo die Lampen bleiben an.

Jetzt fehlt mir der Wink mit dem Zaunpfahl. Wie kann ich bei einer zweiten Bewegungserkennung einfach nur die Zeit verlängern, nicht aber neue Werte abspeichern?

Vielen Dank schonmal

Gruß Take-Off
FHEM auf Raspberry Pi4
CUL868, CUL433, HM-CFG-USB2, HMW-LGW

herrmannj

#1
Hi,

ich glaub so den richtigen "Zaunpfahl" gibt es da gar nicht.

Auf das "at" könntest Du verzichten und das statt dessen über die queue abbilden. Das würde ich auch so machen weil man dann jederzeit eingreifen könnte. Zum Beispiel wäre es dann möglich noch innerhalb der 15min einfacher manuell auszuschalten ohne das nach Ablauf der 15min das "at", dann ungewollt, zündet.

set CarportLED HSV 0,0,100 2; set CarportLED 0,0,100 900 q; set CarportLED $h,$s,$v 2 q

Unter der Voraussetzung das unter $h,$s,$v die "alten" Werte zwischengespeichert sind. Genau genommen brauchst Du nur $s und $v - hue kann (und sollte) ja bleiben.

Löst Dein Problem aber noch nicht wenn der Bewegungsmelder erneut anschlägt. Man könnte jetzt ein userReading auf dem device erstellen welches die "Sollfarbe" speichert und dann in der sub Carport_Motion jeweils wie oben die queue schreiben und mit den Werten aus dem userreading beenden. Wenn jetzt der Bewegungsmelder neu auslöst wird die queue jedes mal mit 15min Weiß danach "wie im userreading" überschrieben.

Damit bleibt nur die Frage wer wann das userreading setzt. Das hängt jetzt sehr von den konkreten Umständen ab. Wenn Du das Licht ohnehin mit Automatiken steuerst (sunset, timer etc) ist es sicher einfach,

vg
joerg

herrmannj

oh, geht vmtl doch auch anders. "modify CarportMotionAus +15" könnte reichen, habe ich aber nicht getestet.

Dann müsste man aber vorher schauen ob das "at" existiert. ($defs{} ..). Ob das dadurch einfacher wird ist sicher Geschmackssache.


vg
joerg

Take-Off

Zitat von: herrmannj am 05 August 2015, 23:34:24
Dann müsste man aber vorher schauen ob das "at" existiert. ($defs{} ..). Ob das dadurch einfacher wird ist sicher Geschmackssache.


Vielen Dank schonmal. :)

Ich glaube mit der zweiten Lösung komm ich besser klar. Allerdings sagt mir $defs überhaupt gar nichts. Kannst du mir das genauer erklären?
Ich hätte jetzt ne if-Schleife im Kopf. Wie ich damit allerdings abfrage ob ein at existiert ist mir auch noch nicht klar.
FHEM auf Raspberry Pi4
CUL868, CUL433, HM-CFG-USB2, HMW-LGW

herrmannj

$defs ist ein fhem interner hash. Dort sind alle definitionen gespeichert. Das meinte ich mit "nicht jedermanns Sache".

Kannst ja auch folgendes probieren: wenn Du das at modifizierst ohne das es exisitiert wird es eine Fehlermeldung geben, die könnte man testen.

Pseudocode:

if (fhem "modifiy .." ne "") {fhem"define at ..."};

Wirst dann im log jedesmal einen Fehler gemeldet bekommen (den Fehler vom modify wenn das at nicht da ist). Aber da Du ja weißt wo der herkommt und das auch ok ist, ist das ja eigentlich kein Fehler, also kein Problem ... (?)

vg
joerg

krikan

Könnte man das Fehlermeldungs-"problem" nicht über http://fhem.de/commandref.html#defmod verhindern ?
Gruß, Christian

herrmannj

#6
dies scheint mir die perfekt Lösung :)

Danke
Joerg

ps: ich kannte das nicht ...

pps: 'naja. Die "alte" Farbe müsste halt immer noch aus dem userreading kommen.

Take-Off

#7
Ich habs mir jetzt 5mal durchgelesen, aber komme da nicht ganz klar drauf. ???


sub Carport_Motion($)
{
if (Value("CarportMotionAus") ne "")
("
my $hueC = ReadingsVal('CarportLED','hue','');
my $satC = ReadingsVal('CarportLED','saturation','');
my $valC = ReadingsVal('CarportLED','brightness','');
")

fhem("delete CarportMotionAus;
set CarportLED HSV 0,0,100 2;
define CarportMotionAus at +00:00:15 set CarportLED HSV $hueC,$satC,$valC 5 ")


Wäre das irgendwie eine Option oder bin ich auf dem falschen Dampfer?
Irgendwo ist auch noch ein Fehler drin den ich nicht finde.

Nochmal danke dass ihr euch so Mühe gebt. :)
FHEM auf Raspberry Pi4
CUL868, CUL433, HM-CFG-USB2, HMW-LGW