... vermutlich sehe ich den Wand vor lauter Bäumen nicht mehr; ich traue mich mal zu fragen ...
Zwischenzeitlich hängen die beiden PIR an ihrem Platz. Ebenfalls fasse ich die beiden Helligkeitswerte zusammen als schnöden Mittelwert und stelle diesen so wie die beiden gelieferten Werte in einem Plot dar; so weit, so gut.
Nun versuche ich seit einer Stunde, auf Basis des Mittelwertes Schaltaktionen auszuführen, was mir aber irgendwie nicht gelingt >:(
Der Reihe nach...
Die Werte der Sensoren werden zusammengefasst und in ein Log geschrieben zur Kontrolle:
define brightness.av DOIF
attr brightness.av state {([OD_IR_GA:brightness]+[OD_IR_HT:brightness])/2}
define FileLog_brightness.av FileLog ./log/%Y-%m_PIR-brightness.log brightness.av
attr FileLog_brightness.av logtype text
attr FileLog_brightness.av room _Logdateien_
Im Logfile tauchen die Werte dann auch brav auf:
...
2016-04-16_19:48:33 brightness.av 155.5
2016-04-16_19:49:34 brightness.av 154
2016-04-16_19:54:49 brightness.av 150.5
2016-04-16_19:55:09 brightness.av 147.5
2016-04-16_20:00:14 brightness.av 146.5
2016-04-16_20:00:34 brightness.av 145
2016-04-16_20:04:48 brightness.av 139.5
2016-04-16_20:05:49 brightness.av 135...
Also dachte ich mir, tue ich mal so:
define EsIstDunkel DOIF ([brightness.av:state] < 150 ) (set STD_(1|2|3) on;;set HM4A1_4 on ELSE set HM4A1_4 off)
Dieser und ähnliche Vorversuche machen gar nix, und ich komme einfach nicht dahinter, warum nicht...
Wo mache ich da meinen Denkfehler? Das hat doch bestimmt schon jemand gemacht...
Zitat von: M_I_B am 16 April 2016, 20:13:16
... vermutlich sehe ich den Wand vor lauter Bäumen nicht mehr; ich traue mich mal zu fragen ...
Zwischenzeitlich hängen die beiden PIR an ihrem Platz. Ebenfalls fasse ich die beiden Helligkeitswerte zusammen als schnöden Mittelwert und stelle diesen so wie die beiden gelieferten Werte in einem Plot dar; so weit, so gut.
Nun versuche ich seit einer Stunde, auf Basis des Mittelwertes Schaltaktionen auszuführen, was mir aber irgendwie nicht gelingt >:(
Der Reihe nach...
Die Werte der Sensoren werden zusammengefasst und in ein Log geschrieben zur Kontrolle:
define brightness.av DOIF
attr brightness.av state {([OD_IR_GA:brightness]+[OD_IR_HT:brightness])/2}
define FileLog_brightness.av FileLog ./log/%Y-%m_PIR-brightness.log brightness.av
attr FileLog_brightness.av logtype text
attr FileLog_brightness.av room _Logdateien_
Im Logfile tauchen die Werte dann auch brav auf:
...
2016-04-16_19:48:33 brightness.av 155.5
2016-04-16_19:49:34 brightness.av 154
2016-04-16_19:54:49 brightness.av 150.5
2016-04-16_19:55:09 brightness.av 147.5
2016-04-16_20:00:14 brightness.av 146.5
2016-04-16_20:00:34 brightness.av 145
2016-04-16_20:04:48 brightness.av 139.5
2016-04-16_20:05:49 brightness.av 135...
Also dachte ich mir, tue ich mal so:
define EsIstDunkel DOIF ([brightness.av:state] < 150 ) (set STD_(1|2|3) on;;set HM4A1_4 on ELSE set HM4A1_4 off)
Dieser und ähnliche Vorversuche machen gar nix, und ich komme einfach nicht dahinter, warum nicht...
Wo mache ich da meinen Denkfehler? Das hat doch bestimmt schon jemand gemacht...
Was sagt Ausgabe von: list EsIstDunkel
... hmmm, schon wieder was gelernt!
Internals:
CFGFN /opt/fhem/timer.cfg
DEF ([brightness.av:state] < 150 ) (set STD_(1|2|3) on;set HM4A1_4 on ELSE set HM4A1_4 off)
NAME EsIstDunkel
NR 809
NTFY_ORDER 50-EsIstDunkel
STATE Next: 20:00:00
TYPE DOIF
Readings:
2016-04-16 23:19:02 Device brightness.av
2016-04-16 18:35:59 cmd_event brightness.av
2016-04-16 18:35:59 cmd_nr 1
2016-04-16 18:36:27 e_brightness.av_brightness 0
2016-04-16 20:05:49 e_brightness.av_brightness.av 0
2016-04-16 23:19:02 e_brightness.av_state 22.5
2016-04-16 18:39:41 error reading does not exist: [brightness.av:brightness.av]
2016-04-16 22:10:22 state Next: 20:00:00
Condition:
0 ReadingValDoIf($hash,'brightness.av','state','','',AttrVal($hash->{NAME},'notexist',undef)) < 150
Devices:
0 brightness.av
all brightness.av
Do:
0:
0 set STD_(1|2|3) on;set HM4A1_4 on ELSE set HM4A1_4 off
Helper:
event 22.5
globalinit 1
last_timer 0
sleeptimer -1
timerdev brightness.av
timerevent 22.5
triggerDev brightness.av
timerevents:
22.5
triggerEvents:
22.5
Internals:
Itimer:
Readings:
0 brightness.av:state
all brightness.av:state
Regexp:
0:
All:
State:
Trigger:
Attributes:
Ich denke mal, "reading does not exist: [brightness.av:brightness.av]" dürfte das Problem sein, wobei ich nicht verstehe, warum das so ist. Ich hatte es auch schon mit [brightness.av:state] versucht am Anfang, da ja "attr brightness.av state {([OD_IR_GA:brightness]+[OD_IR_HT:brightness])/2}" gesetzt wird, aber das Ergebnis war identisch.
... das Problem hat sich erledigt. Ich habe mich mal in das Thema DOIF eingelesen und es damit gelöst. Damit funktioniert das bei gleichem Reading und ich konnte es noch problemlos um einige Regeln erweitern ^^ Ich denke, DOIF wird mein Freund ;)
Allerdings ist mir gestern Abend was anderes aufgefallen:
Da "state" ja nach dem Auslösen auf "motion" stehen bleibt, habe ich nach einer Lösung gesucht und diese in Form eines WatchDog hier im Forum gefunden. Dieses habe ich entsprechend angepasst und für beide Melder (OD_IR_HT resp. OD_IR_GA = xx) gesetzt like:
define OD_IR_xx_WD watchdog OD_IR_xx:motion 00:00:45 SAME setreading OD_IR_xx state nomotion
Bei dem einen PIR funktioniert das, bei dem anderen nicht, obwohl die ansonsten bezgl. Internals, Readings, Attributes und Association 1:1 vergleichbar sind. Bei jenem, der sich per WatchDog nicht zurückschalten lassen will, kann ich es aber problemlos über die FHEM-Eingabe auf "nomotion" setzen. Er bleibt dann auch bis zu einer erkannten Bewegung so stehen, schaltet auf "motion" und bleibt dann da; der WatchDog macht da nix...
Jemand eine Idee, woran das liegen könnte? Oder gibt es ggf. eine andere Option, den Status nach Bewegungserkennung zurückzusetzen?
Zitat von: M_I_B am 18 April 2016, 10:08:17
Allerdings ist mir gestern Abend was anderes aufgefallen:
Da "state" ja nach dem Auslösen auf "motion" stehen bleibt, habe ich nach einer Lösung gesucht und diese in Form eines WatchDog hier im Forum gefunden. Dieses habe ich entsprechend angepasst und für beide Melder (OD_IR_HT resp. OD_IR_GA = xx) gesetzt like:
define OD_IR_xx_WD watchdog OD_IR_xx:motion 00:00:45 SAME setreading OD_IR_xx state nomotion
Hallo,
nach heutigem Update sollte ein watchdog auf Basis dieser Ankündigung (https://forum.fhem.de/index.php/topic,52305.0.html) nicht mehr nötig sein.
Der MDIR liefert nun im state "motion/noMotion".
Beim mir funktioniert's.
Andreas
... SUPER! Werde ich heute Abend gleich mal antesten; Dank für die Info, die ansonsten an mir vorbeigegangen wäre ^^
... dank Martin tut das jetzt so, wie man es erwartet; super !
Aber kann es sein, das der Status motion:on/no resp. motion/noMotion seeeehr lange stehen bleibt, bevor ein Rücksetzen stattgefunden hat?
Ich mache von den derzeit 2 PIR einen Plot, welcher in der gplot so zusammengesetzt ist:
#FileLog_OD_IR_GA 4:motion\x3a:0:$fld[2]=~"on"?1:0
#FileLog_OD_IR_HT 4:motion\x3a:0:$fld[2]=~"on"?1:0
Im Screenshot kann man im oberen Plot gegen 00:30 einen kurzen Anstieg der Außenhelligkeit auf etwa 100 erkennen; da habe ich unseren Hund noch mal in'n Garten gelassen. Im unteren Plot erkennt man auch, das der Sensor "Haustür" reagiert hat, aber natürlich habe ich nicht bis 07:30 vor der Haustür rumgehampelt, wie vom Plot dargestellt ::)
Kann man dieses "Falschmeldung" irgendwie ausmerzen?
(Ich bin da vieleicht von den klassischen Bewegungsmeldern "versaut". Die verdrahteten BM geben je nach Hersteller und/oder Einstellung bei Bewegung einen durch weitere Bewegung retriggerbaren Impuls von 1-10 Sekunden ab. Wenn also nichts erkannt wird, ist der Status "Motion" nach spätestens 10 Sekunden weg...)
Hallo,
gib doch mal ein list des Bewegungssensors.
Ohne mich jetzt mit den Details Deiner Definiton der Plots auseinandergesetzt zu haben, vielleicht liegt es ja (auch) an den Konfigurationswerten für
R-brightFilter (0)
R-captInInterval (off)
R-evtFltrNum (1)
R-evtFltrPeriod (1 s)
R-minInterval (60)
Meine Konfigurationswerte sind in Klammern.
Weitere Infos zu den möglichen Konfigurationen gibt's im Wiki (http://www.fhemwiki.de/wiki/HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen#Anzeige_aller_dekodierten_Register).
Andreas
... danke für den Hint, aber daran wird es nicht liegen:
R-brightFilter = 5
R-captInInterval = on
R-evtFltrNum = 2
R-evtFltrPeriod = 0.5
R-minInterval = 30
Die eingestellten Werte sind zwar für meine Situation noch nicht ganz optimal, aber nahe dran. Demnach müsste nach spätestens 30 Sekunden der entsprechende Status auf noMotion o.ä. gehen; tut er auch: "event" geht auf "noMotion" und "motion" geht zeitgleich auf "no". Dennoch wird das im Plot ignoriert...
Irgendwie muß das mit dem Logfiles und/oder in der gplot haken...
EDIT:
Das Problem wäre gelöst *puhhh*
Ist eigentlich ganz einfach, wenn man denn mal drauf kommt. Ich habe jetzt allerdings gleich mehrere Änderungen getätigt; vielleicht hilft es irgend wem...
Änderung bei "event-min-interval"
Die Zeile habe ich nunmehr gesetzt auf:
event-min-interval state:86400,motion:5,brightness:300,battery:86400,cover:86400,motionCount:86400,trigger_cnt:86400,Activity:86400
Hier habe ich den Intervall für Motion auf 5 herunter gesetzt, damit er auch ja keinen verpasst. Ob das so richtig oder nötig ist, würde ich gerne von Euch erfahren.
Erweiterung bei der Plot- Definition (hat keinen Einfluß auf das ursprüngliche Problem)
label "PIR-Bewegung - Garage ".substr($data{currdate1},11,8)." / Haustür ".substr($data{currdate2},11,8)
Das sorgt lediglich dafür, das jeweils die Uhrzeit der letzten Aktivierung ohne Datum zum jeweiligen Melder mit angezeigt wird (set title '<L1>' in der gplot)
Änderung in der gplot- Datei; das war die eigentliche Ursache
ls l1 lw 1 with ibars
Zum einen funktioniert das nicht mit Quadern, zum anderen nicht mit Filled; reiner Denkfehler in Ermangelung tieferen Wissens bezgl. der Optionen