Hallo...
ich bin etwas verwundert über meinen HM-Sen-MDIR-O Bewegungsmelder. Dieser löst bei einem Event öfters auch ein set getConfig aus. Woran könnte das liegen? Das Attribut autoReadReg ist auf 5_readMissing gesetzt.
Wenn es komplett ist, sollte kein weiteres ausgefuehrt werden. Du kannst pruefen, ob die config komplett ist.
Kommt es zu uebertragungsproblemen ?
Schicke ein list mit allen kanaelen
HMInfo meldet mir keine Ungereimtheiten. Auch der RSSI ist im grünen Bereich. Ich hab auch noch nie eine missingAck bei dem Teil vernommen. Hier das Listing....
nternals:
DEF 34284D
HMLAN_0_MSGCNT 364
HMLAN_0_RAWMSG E34284D,0000,359DF32A,FF,FFB6,20841034284D29A17206019900
HMLAN_0_RSSI -74
HMLAN_0_TIME 2015-06-02 20:55:07
IODev HMLAN_0
LASTInputDev HMLAN_0
MSGCNT 364
NAME Bewegung_Eingang
NR 180
STATE motion
TYPE CUL_HM
lastMsg No:20 - t:10 s:34284D d:29A172 06019900
protLastRcv 2015-06-02 20:55:07
protResnd 2 last_at:2015-06-02 18:35:18
protSnd 50 last_at:2015-06-02 20:11:28
protState CMDs_done
rssi_at_HMLAN_0 avg:-73.03 min:-83 max:-70 lst:-74 cnt:364
Readings:
2015-06-01 15:33:38 Activity alive
2015-05-24 01:16:18 CommandAccepted yes
2015-03-25 18:12:26 D-firmware 1.6
2015-03-25 18:12:26 D-serialNr LEQ1278257
2015-06-02 20:11:27 PairedTo 0x29A172
2015-05-23 20:52:06 R-brightFilter set_0
2015-05-24 01:16:19 R-captInInterval off
2015-05-23 19:20:53 R-evtFltrNum 1
2015-05-23 19:20:53 R-evtFltrPeriod 0.5 s
2015-01-26 17:49:01 R-ledOnTime 0 s
2015-05-24 01:16:19 R-minInterval 240
2015-03-25 18:11:59 R-pairCentral 0x29A172
2015-06-02 20:11:27 RegL_00: 02:00 0A:29 0B:A1 0C:72 00:00
2015-06-02 20:11:27 RegL_01: 01:11 02:04 08:00 22:00 00:00
2015-06-02 20:55:07 battery ok
2015-06-02 20:55:07 brightness 153
2015-06-02 20:55:07 cover closed
2015-06-02 20:11:24 motion on (to virtualCCU)
2015-06-02 20:11:24 motionCount 152_next:116s
2015-06-02 16:18:28 powerOn 2015-06-02 16:18:28
2015-06-02 20:55:07 recentStateType info
2015-06-02 20:11:24 state motion
2015-06-02 20:11:24 trigDst_virtualCCU noConfig
2015-06-02 20:11:24 trigger_cnt 152
Helper:
cSnd 0129A17234284D0103
mId 005D
peerIDsRaw ,00000000
rxType 28
Io:
newCh 1
newChn +34284D,00,01,1E
nextSend 1433271307.97756
rxt 2
vccu virtualCCU
p:
34284D
00
01
1E
Mrssi:
mNo 20
Io:
HMLAN_0 -72
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan_0:
avg -73.032967032967
cnt 364
lst -74
max -70
min -83
Shadowreg:
Attributes:
IODev HMLAN_0
IOgrp virtualCCU
actCycle 000:50
actStatus alive
autoReadReg 5_readMissing
devStateIcon motion:user_available@00FF00 off:user_unknown
expert 2_full
firmware 1.6
group Bewegung
model HM-Sen-MDIR-O
peerIDs 00000000,
room Alarmanlage
serialNr LEQ1278257
sortby 01
subType motionDetector
die Daten sind komplett.
Das sollte nicht automatisch neu gelesen werden - evtl nach einem restart.
Also das Thema mit dem ständigen getConfig hatten wir hier schonmal: http://forum.fhem.de/index.php/topic,36157.msg296698.html#msg296698 (http://forum.fhem.de/index.php/topic,36157.msg296698.html#msg296698)
Ich habe die Melder inzwischen wieder auf autoReadReg 3 und meine vier Melder (ein HM-Sec-MDIR und zwei HM-Sen-MDIR-O und ein -SM) hatten in den ersten 3,75 Tagen dieses Monats bereits 19 getConfigs in unregelmäßigen Abständen, der kürzeste 13 Minuten auf einen Melder. Ich kann da beim besten Willen kein Muster erkennen, und Neustarts finden auch entsprechend selten statt. Ich habe jetzt mal auf 2 heruntergesetzt, mal sehen.
Ich habe mal meine alten Logs geflöht - die getConfigs auf die Bewegungsmelder gingen am 21.04.2015 los, ohne dass ich in der Konfig derselben irgendwas geändert hätte. Erst danach hatte ich mal testweise autoreadReg auf 4 gestellt (was natürlich in die falsche Richtung war).
Martin: Ich werde das Gefühl nicht los, dass sich da irgendwo was in FHEM geändert hat etwa um die Zeit. Am 20.04. hatte ich ein automatisches Update gefahren...
Ausstehende prüfungen kannst du in HMInfo protoEvents short sehen.
wenn in den requestPending einträgen keine auftauchen sollten auch keine mehr kommen - so lange nichts passiert.
Wenn du register änderst wird wieder geprüft - klar.
Kannst du also einmal das Device loggen? Rohmessages über längere Zeit - also mehrere getConfig?
Habe autoReadReg auf 2, derzeit ist "requestPendig" leer. Werde mal einen auf drei zurückstellen.
Rohmessages versuche ich dann mal.
Vielleicht kann ich etwas zu dem Thema beitragen. Auch ich beobachte tägliche getConfig bei meinem HM-SEN-MDIR-O. Das Verhalten trat so erst seit dem Frühjahr auf. Ich haben den Bewegungsmelder Anfang des Jahres in Betrieb genommen und da kam es erst mal nicht zu den häufigen getConfig.
Beim Durchschauen der Logs ist mir aufgefallen, dass eigentlich nicht das getConfig das Problem ist, sondern ein tägliches powerOn. GetConfig wird dann nur aufgerufen, sobald der Bewegungsmelder die erste Bewegung nach dem powerOn registriert. Das passt soweit auch zu meine Einstellungen und zur Doku von getConfig. Daher mutmaße ich mal, dass eher die Frage zu klären ist, warum der Bewegungmelder täglich powerOn meldet.
Hier mal ein Auszug aus dem Geräte-Log von gestern:
2015-06-04_06:12:11 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-04_06:12:11 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 175
2015-06-04_06:12:11 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-04_06:18:23 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-04_06:18:23 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 179
2015-06-04_06:18:23 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-04_06:18:23 CUL_HM_HM_Sen_MDIR_O_34297C powerOn: 2015-06-04 06:18:23
2015-06-04_06:23:24 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-04_06:23:24 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 179
2015-06-04_06:23:24 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
...
2015-06-04_15:52:31 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-04_15:52:31 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 213
2015-06-04_15:52:31 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-04_15:56:56 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 213
2015-06-04_15:56:56 CUL_HM_HM_Sen_MDIR_O_34297C motion: on (to vccu)
2015-06-04_15:56:56 CUL_HM_HM_Sen_MDIR_O_34297C motionCount: 237_next:116s
2015-06-04_15:56:56 CUL_HM_HM_Sen_MDIR_O_34297C motion
2015-06-04_15:56:56 CUL_HM_HM_Sen_MDIR_O_34297C trigDst_vccu: noConfig
2015-06-04_15:56:56 CUL_HM_HM_Sen_MDIR_O_34297C trigger_cnt: 237
Passend dazu im globalen Log:
2015.06.04 15:56:56 3: CUL_HM set CUL_HM_HM_Sen_MDIR_O_34297C getConfig
Und heute wieder:
2015-06-05_05:55:26 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-05_05:55:26 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 164
2015-06-05_05:55:26 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-05_06:01:38 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-05_06:01:38 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 168
2015-06-05_06:01:38 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-05_06:01:38 CUL_HM_HM_Sen_MDIR_O_34297C powerOn: 2015-06-05 06:01:38
2015-06-05_06:06:40 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-05_06:06:40 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 172
2015-06-05_06:06:40 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
...
2015-06-05_07:35:42 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-05_07:35:42 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 200
2015-06-05_07:35:42 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-05_07:39:46 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 200
2015-06-05_07:39:46 CUL_HM_HM_Sen_MDIR_O_34297C motion: on (to vccu)
2015-06-05_07:39:46 CUL_HM_HM_Sen_MDIR_O_34297C motionCount: 243_next:116s
2015-06-05_07:39:46 CUL_HM_HM_Sen_MDIR_O_34297C motion
2015-06-05_07:39:46 CUL_HM_HM_Sen_MDIR_O_34297C trigDst_vccu: noConfig
2015.06.05 07:39:46 3: CUL_HM set CUL_HM_HM_Sen_MDIR_O_34297C getConfig
Das erklaert es... das getconfig. Nach poweron will ich ein getconfig sehen. Wird im entsprechenden autoreadreg eingestellt.
Die vermeldeten pon sind also zu untersuchen. Werde mich dran machen.
Hallo
Habe das selbe auch eben gesehen.
Bei allen Bewegungsmelder.
könnt ihr da einmal loggen?
Loggen habe ich noch nie gemacht.
Meinst Du das
Zitathttp://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen
Zitatattr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys
Ich habe zwei HM-Lan Adapter.
Heisst es dann ?
Zitatattr vccu logIDs all,sys
oder
Zitatattr HMLAN1,HMLAN2 ........
attr HMLAN1,HMLAN2 ........
Hier mein Log des letzten powerOn:
2015-06-07_13:31:42 CUL_HM_HM_Sen_MDIR_O_34297C battery: ok
2015-06-07_13:31:42 CUL_HM_HM_Sen_MDIR_O_34297C brightness: 215
2015-06-07_13:31:42 CUL_HM_HM_Sen_MDIR_O_34297C cover: closed
2015-06-07_13:31:42 CUL_HM_HM_Sen_MDIR_O_34297C powerOn: 2015-06-07 13:31:42
2015.06.07 13:25:21.017 0: HMLAN_Send: hmusb I:K
2015.06.07 13:25:21.052 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70E8C60A IDcnt:0003
2015.06.07 13:25:28.412 0: HMLAN_Parse: hmusb R:E34297C stat:0000 t:70E8E2DC d:FF r:FFC7 m:FF 8410 34297C 030C48 0601D700
2015.06.07 13:25:46.024 0: HMLAN_Send: hmusb I:K
2015.06.07 13:25:46.076 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70E927CA IDcnt:0003
2015.06.07 13:26:11.026 0: HMLAN_Send: hmusb I:K
2015.06.07 13:26:11.068 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70E9896A IDcnt:0003
2015.06.07 13:26:36.052 0: HMLAN_Send: hmusb I:K
2015.06.07 13:26:36.092 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70E9EB29 IDcnt:0003
2015.06.07 13:27:01.057 0: HMLAN_Send: hmusb I:K
2015.06.07 13:27:01.116 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EA4CE8 IDcnt:0003
2015.06.07 13:27:26.082 0: HMLAN_Send: hmusb I:K
2015.06.07 13:27:26.140 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EAAEA8 IDcnt:0003
2015.06.07 13:27:51.084 0: HMLAN_Send: hmusb I:K
2015.06.07 13:27:51.132 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EB1047 IDcnt:0003
2015.06.07 13:28:16.106 0: HMLAN_Send: hmusb I:K
2015.06.07 13:28:16.156 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EB7206 IDcnt:0003
2015.06.07 13:28:41.113 0: HMLAN_Send: hmusb I:K
2015.06.07 13:28:41.148 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EBD3A6 IDcnt:0003
2015.06.07 13:29:06.123 0: HMLAN_Send: hmusb I:K
2015.06.07 13:29:06.172 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EC3565 IDcnt:0003
2015.06.07 13:29:31.140 0: HMLAN_Send: hmusb I:K
2015.06.07 13:29:31.196 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EC9725 IDcnt:0003
2015.06.07 13:29:56.142 0: HMLAN_Send: hmusb I:K
2015.06.07 13:29:56.188 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70ECF8C4 IDcnt:0003
2015.06.07 13:30:21.149 0: HMLAN_Send: hmusb I:K
2015.06.07 13:30:21.212 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70ED5A83 IDcnt:0003
2015.06.07 13:30:46.152 0: HMLAN_Send: hmusb I:K
2015.06.07 13:30:46.204 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EDBC23 IDcnt:0003
2015.06.07 13:31:11.166 0: HMLAN_Send: hmusb I:K
2015.06.07 13:31:11.228 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EE1DE2 IDcnt:0003
2015.06.07 13:31:36.174 0: HMLAN_Send: hmusb I:K
2015.06.07 13:31:36.220 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EE7F81 IDcnt:0003
2015.06.07 13:31:42.076 0: HMLAN_Parse: hmusb R:E34297C stat:0000 t:70EE966B d:FF r:FFC7 m:00 8410 34297C 030C48 0601D700
2015.06.07 13:32:01.181 0: HMLAN_Send: hmusb I:K
2015.06.07 13:32:01.244 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EEE141 IDcnt:0003
2015.06.07 13:32:26.194 0: HMLAN_Send: hmusb I:K
2015.06.07 13:32:26.236 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EF42E0 IDcnt:0003
2015.06.07 13:32:51.196 0: HMLAN_Send: hmusb I:K
2015.06.07 13:32:51.260 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70EFA4A0 IDcnt:0003
2015.06.07 13:33:16.214 0: HMLAN_Send: hmusb I:K
2015.06.07 13:33:16.252 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F0063F IDcnt:0003
2015.06.07 13:33:41.216 0: HMLAN_Send: hmusb I:K
2015.06.07 13:33:41.276 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F067FE IDcnt:0003
2015.06.07 13:34:06.225 0: HMLAN_Send: hmusb I:K
2015.06.07 13:34:06.268 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F0C99E IDcnt:0003
2015.06.07 13:34:31.228 0: HMLAN_Send: hmusb I:K
2015.06.07 13:34:31.292 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F12B5D IDcnt:0003
2015.06.07 13:34:56.230 0: HMLAN_Send: hmusb I:K
2015.06.07 13:34:56.284 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F18CFC IDcnt:0003
2015.06.07 13:35:21.236 0: HMLAN_Send: hmusb I:K
2015.06.07 13:35:21.276 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F1EE9C IDcnt:0003
2015.06.07 13:35:46.262 0: HMLAN_Send: hmusb I:K
2015.06.07 13:35:46.300 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F2505B IDcnt:0003
2015.06.07 13:36:11.274 0: HMLAN_Send: hmusb I:K
2015.06.07 13:36:11.324 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F2B21A IDcnt:0003
2015.06.07 13:36:36.300 0: HMLAN_Send: hmusb I:K
2015.06.07 13:36:36.348 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F313DA IDcnt:0003
2015.06.07 13:36:45.724 0: HMLAN_Parse: hmusb R:E34297C stat:0000 t:70F33888 d:FF r:FFC7 m:01 8410 34297C 030C48 0601D700
2015.06.07 13:37:01.307 0: HMLAN_Send: hmusb I:K
2015.06.07 13:37:01.372 0: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0658926 d:2CC7B7 O:030C48 t:70F37599 IDcnt:0003
Beim einfachen Draufschauen fällt mir auf, dass beim Parsen das Argument m überläuft. Es geht von FF nach 00.
ZitatBeim einfachen Draufschauen fällt mir auf, dass beim Parsen das Argument m überläuft. Es geht von FF nach 00.
ja, schon klar. das genau wollte ich sehen - und den code dazu.
Das device sendet keinen wirklichen power-up, daher wird es an anderen Indikatoren festgemacht - u.a. an diesem Zähler.
Leider wurde der Zähler bei dieser Art Statusmessages nicht "gemerkt" - was zur fehlinterpretation geführt hat.
Sollte jetzt klappen.
Zitat von: martinp876 am 07 Juni 2015, 17:53:14
Sollte jetzt klappen.
Das heißt, morgen per Update oder?
Fein, wenn da eine Lösung möglich ist. Bleibt die Frage interessehalber: Wieso wurden wir bis April von dem Bug verschont? (Da muss doch ein neuer Mechanismus diesen Nebeneffekt verursacht haben).
Und wieso ist das bisher so wenigen aufgefallen?
geht nich Gips nich ...
Da ich keinen habe ist es mir auch nicht aufgefallen. Geaendert hatte ich hier nichts... was auch immer lang ist.
Das verhalten ist jedenfalls klar
Habe zwar gestern das Update gemacht.
Hatte aber heute wieder einige getConfig der Bewegungsmelder im Log.
Habe nun wieder ein Update gemacht und neu gestartet.
Das Update hat bei mir leider nichts gebracht.
Hallo... bei mir ähnliche Situation auch nach dem Update. getConfig bei einer erkannten Bewegung nach einem powerOn.
: Oh sorry, habe das Update auf der falschen FHEM Instanz gemacht.
Habe das Update gestern gemacht und sehe seit mir als 24 h kein getConfig im Log. Eigentlich hatte ich das vorher mindestens ein mal pro Tag.