Hallo zusammen,
ich habe seit ein paar Tagen einen HM-SEN-MDIR-O und betreibe ihn am CUL.
Ich würde das Sendeintervall ( Info Nachrichten) gerne nach oben sezten bzw. generell auf on-change ( nur bei Bewegung/Helligkeitsänderung) setzen, da der Bewegungsmelder aktuell alle ca. 4 min seinen Alive bzw. Batterie status sendet. 24 h würden mir auch reichen.
Ist das möglich?
Ein set Bewegungsmelder regSet cyclicInfoMsg off
scheint zumindest nicht zu funktionieren da er cyclicInfoMsg nicht kennt.
Auszug Bewegungsmelder Log:
2014-01-19_20:28:48 Bewegungsmelder brightness: 141
2014-01-19_20:28:48 Bewegungsmelder cover: closed
2014-01-19_20:28:48 Bewegungsmelder battery: ok
2014-01-19_20:33:04 Bewegungsmelder brightness: 141
2014-01-19_20:33:04 Bewegungsmelder cover: closed
2014-01-19_20:33:04 Bewegungsmelder battery: ok
2014-01-19_20:38:58 Bewegungsmelder brightness: 141
2014-01-19_20:38:58 Bewegungsmelder cover: closed
2014-01-19_20:38:58 Bewegungsmelder battery: ok
2014-01-19_20:44:24 Bewegungsmelder brightness: 144
2014-01-19_20:44:24 Bewegungsmelder cover: closed
2014-01-19_20:44:24 Bewegungsmelder battery: ok
Viele Grüße
Guiseppe
>> list Bewegungsmelder liefert:
Internals:
CUL1_MSGCNT 21
CUL1_RAWMSG A0D11A6412099E1000001013790800C
CUL1_RSSI -68
CUL1_TIME 2014-01-19 20:45:13
DEF 2099E1
IODev CUL1
LASTInputDev CUL1
MSGCNT 21
NAME Bewegungsmelder
NR 92
STATE motion
TYPE CUL_HM
lastMsg No:11 - t:41 s:2099E1 d:000001 01379080
protLastRcv 2014-01-19 20:45:13
protResnd 1 last_at:2014-01-19 19:59:14
protSnd 15 last_at:2014-01-19 20:45:13
protState CMDs_done
rssi_at_CUL1 avg:-70.49 min:-81.5 max:-64.5 lst:-68 cnt:21
Readings:
2014-01-19 20:22:04 Activity alive
2014-01-19 20:01:03 PairedTo 0x1
2014-01-19 20:01:03 R-brightFilter 7
2014-01-19 20:01:03 R-captInInterval off
2014-01-19 20:01:03 R-evtFltrNum 1
2014-01-19 19:28:43 R-evtFltrPeriod 1 s
2014-01-19 19:28:43 R-ledOnTime 0 s
2014-01-19 20:01:03 R-minInterval 240
2014-01-19 20:01:02 R-pairCentral 0x1
2014-01-19 20:01:03 RegL_00: 02:01 0A:00 0B:00 0C:01 00:00
2014-01-19 20:01:03 RegL_01: 01:12 02:74 08:00 22:00 00:00
2014-01-19 20:44:24 battery ok
2014-01-19 20:45:13 brightness 144
2014-01-19 20:44:24 cover closed
2014-01-19 20:45:13 motion on (to CUL1)
2014-01-19 20:45:13 motionCount 55_next:8-240
2014-01-19 20:44:24 recentStateType info
2014-01-19 20:45:13 state motion
Helper:
cSnd 010000012099E100040000000000
mId 005D
peerIDsRaw ,00000000
rxType 28
Io:
nextSend 1390160713.45491
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL1
flg A
ts 1390160713.36429
ack:
HASH(0xe7dfd8)
1180020000012099E101019000
HASH(0xe7dfd8)
1180020000012099E10101C800
Rssi:
At_cul1:
avg -70.5
cnt 21
lst -68
max -64.5
min -81.5
Shadowreg:
Attributes:
IODev CUL1
actCycle 000:10
actStatus alive
alias Bewegungsmelder
autoReadReg 4_reqStatus
expert 2_full
firmware 1.6
model HM-Sen-MDIR-O
peerIDs 00000000,
room 02_Garten
serialNr KEQ0193552
subType motionDetector
Hi Guiseppe,
die message kann man wohl nicht abschalten.
Ich rate aber generell doppelte events zu unterdrücken
attr Bewegungsmelder event-on-change-reading .*
das empfehle ich bei JEDEM device - es sollte default sein.... Ich spiele immer wieder mit dem Gedanken, es so einzubauen, da es unerfahrene User sicher übersehen. Aber es gibt auch immer wieder Gegenstimmen...
wobei beim MDIR eine Ausnahme zu machen ist, da "motion" sich inhaltlich nicht ändert. Das unterdrücken muss hier aufgehoben werden:
attr Bewegungsmelder event-on-change-update motion
Gruss Martin
Hallo Martin,
schade das man die message nicht abschalten kann.
aber vielen Dank für den Hinweis.
Ich habe die attributes so gesetzt.
-Das hilft auf jeden Fall.
Ich hab das tatsächlich übersehen, bin allerdings auch tatsächlich wie vermutet ein unerfahrener User.
Es muss aber vermutlich event-on-update-reading heissen.
Vielen Dank für die Infos nochmal.
Grüße
Guiseppe
Moin martinp876,
Eventuell ne Schnapsidee, vielleicht auch nicht.
wäre es nicht vielleicht sinnvoll, den Bewegungsmeldern ein Attribut zu spendieren, dass einen internen Timer setzt, der nach Ablauf "motion off" sendet, wenn in dieser Zeit kein neues motion gesendet wurde. Standarteinstellung wäre die "Totzeit" des 'Melders ( minInterval --> minimum interval in sec options:240,60,120,30,15).
Vorteile, die ich sehe:
- einfacher zu plotten
- notify's und at's könnten besser triggern
- man könnte, wenn der Timer größer ist, wie die "Totzeit", abwarten, ob ein neues motion im Timerinterval kommt, und motion off wird nicht gesendet, bis das nächste Intervall ohne motion abgelaufen ist.
Gruß Joachim
Hallo Joachim,
hm - nicht so ganz befriedigend.
dennoch bin ich erst einmal ein bisschen vorsichtig.
Zitat- notify's und at's könnten besser triggern
verstehe ich nicht. der timer eines MotionOff wird dem User i.A nicht weiterhelfen, da meist Aktionen mit anderen timern notwendig sein werden. Bei MotionOn sollte ein keinen Probleme geben.
Zitat- man könnte, wenn der Timer größer ist, wie die "Totzeit", abwarten, ob ein neues motion im Timerinterval kommt, und motion off wird nicht gesendet, bis das nächste Intervall ohne motion abgelaufen ist.
klar - falls es eingebaut würde , müsste es so funktionieren.
Aber schon bei der Berechnung sind vergraben: stehen die Register zu Verfügung und sind sie verlässlich/aktuell? wenn nicht, was dann?
User haben schon notifies am laufen - die darf man nicht stören - Änderungen sind also vorsichtig zu machen.
man sollte es auch mit einem notify erschlagen können, so man will.
Gruss Martin
Moin Martin,
Ich sagte ja schon:
ZitatEventuell ne Schnapsidee, vielleicht auch nicht.
ZitatUser haben schon notifies am laufen - die darf man nicht stören - Änderungen sind also vorsichtig zu machen.
deshalb die Idee mit einem Attribut, wenn nicht gesetzt, bleibt alles beim alten.
Zitatder timer eines MotionOff wird dem User i.A nicht weiterhelfen,
man könnte gezielt auf motion off triggern, also den Internen Timer hoch genug stellen ("Totzeit" + Sicherheitsreserve), dass bei Anwesenheit im Raum kein motion off gesendet wird. Wenn der Raum definitiv verlassen ist, kommt ein Motion off, und das Licht o.ä. wird abgeschaltet
ZitatAber schon bei der Berechnung sind vergraben: stehen die Register zu Verfügung und sind sie verlässlich/aktuell? wenn nicht, was dann?
den verstehe ich jetzt nicht, bei einem fehlerfrei laufenden FHEM sollte die Information letztes "motion" vorhanden sein. Wenn ich die Verläßlichkeit der Register anzweifeln muss, dann stimmt mit meiner Installation was nicht, dann habe ich andere Probleme.
Gruß Joachim
Hallo Joachim,
baue die doch dies ein
define mdOff notify .*motionCount.* {\
if($defs{"at".$NAME}){\
fhem "delete at$NAME";;fhem "setreading $NAME currentMotion on";;}\
fhem "define at$NAME at +00:00:10 setreading $NAME currentMotion off";;\
}
Zitatman könnte gezielt auf motion off triggern, also den Internen Timer hoch genug stellen ("Totzeit" + Sicherheitsreserve), dass bei Anwesenheit im Raum kein motion off gesendet wird. Wenn der Raum definitiv verlassen ist, kommt ein Motion off, und das Licht o.ä. wird abgeschaltet
Korrekt. Aber HM-peers machen das sowieso - die Timer sind im Device. FHEM muss das nicht aktiv tun.
Ich weiss, ich stehe etwas auf der Bremse... ich will den CUL_HM level nicht überfrachten.
ZitatWenn ich die Verläßlichkeit der Register anzweifeln muss, dann stimmt mit meiner Installation was nicht, dann habe ich andere Probleme.
bislang werden keine Aktionen (habe glaube ich nichts übersehen...) aus den registerwerten abgeleitet. Die Werte sollten stimmen... was mich zurückhaltend sein lässt ist
- die werte können nicht gelesen sein. Der User lässt sie nicht automatisch lesen,... lesen geht schief...
- die werte können veraltet sein.
- config-devices können nicht gelesen werden
- device-resets sind nicht berücksichtigt
Prinzipiell gebe ich dir recht, man sollte sich darauf verlassen können. Und wenn die Werte nicht vorliegen könnte man in diesem Fall die max-time als default nehmen.
Dennoch - beim Treppenhauslicht bleibt das Licht deutlich länger an, als die letzte "motion". Der User braucht dann sowieso einen Timer, wann das licht aus gehen soll(so er es nicht sowieso im HM device realisiert).
Nicht falsch verstehen: für "mehrwertprocessing" suche ich gute Gründe warum diese hier eingebaut werden sollten.
Was hältst du vom notify? Ein es für beliebig viele MDs - so man es will. Nachteil konnte sein, dass das Define zu rechenintensiv ist - kannst es mit apptime ausmessen...
Gruss Martin
Moin Martin,
Ich kann damit leben, war ja auch nur eine (Schnaps)idee.
Gruß Joachim