Hallo, Martin
seit dem gestrigen Update(05.10.) meckert der HM-WDS30-OT2-SM immer Missing Ack. Die 4 Channels liefern aber trotzdem die Temperaturwerte. Nach einem get Config und CMD processing ist dann auch alles OK, bis man fhem neustartet oder die fhem.cfg rereadet.
Ist da irgendwas anders in der HMConfig.pm bzw. 10_CUL_HM.pm
DEF
20BD8B
EVENTS
9
HMLAN1_MSGCNT
14
HMLAN1_RAWMSG
R8CA59C7E,0001,0DBFC159,FF,FFBF,4CA01020BD8B123ABC0100000000
HMLAN1_RSSI
-65
HMLAN1_TIME
2013-10-06 09:22:45
IODev
HMLAN1
LASTInputDev
HMLAN1
MSGCNT
14
NAME
Diff_Temp_Sensor
NR
110
STATE
MISSING ACK
TYPE
CUL_HM
channel_01
Temperatur_1
channel_02
Temperatur_2
channel_03
Differenz_1_2
channel_04
Differenz_2_1
lastMsg
No:4C - t:10 s:20BD8B d:123ABC 0100000000
protCmdDel
4
protCondBurst
off
protLastRcv
2013-10-06 09:22:45
protResnd
3 last_at:2013-10-06 09:22:59
protResndFail
1 last_at:2013-10-06 09:23:04
protSnd
14 last_at:2013-10-06 09:22:45
protState
CMDs_done_events:4
rssi_at_HMLAN1
avg:-65.21 min:-66 max:-65 lst:-65 cnt:14
Der selbe Fehler, Missing Ack auch beim HM-WDS10-TH-O
Und beim HM-SEC-MDIR RESPONSE TIMEOUT:RegisterRead
Vor dem Update vom 05.10. traten diese Fehlermeldungen nie auf.
VG Frank
Bin jetzt auf die 10_CUL_HM.pm 3993 zurück und die Fehlermeldungen sind weg.
VG
Frank
Hatte das gleiche Problem. Musste auch auf das Backup zurückgreifen.
Gruss Peter
Hallo Peter,Frank,
ja, hat sich etwas geaendert. die devices sollten auch "burst" können - und ich habe mit dem RT eingebaut, dass dies abgetestet wird. beim RT funktioniert es.
zum ersten: wenn ihr das Register burstRx auf "on" setzt sollte man quasi immer mit dem device reden könnnen. Wenn es "off" ist, muss man auf wakeup warten.
da ich das device nicht habe, kann einer von euch ein paar logs schicken?
burstRx=off
aktionen machen - was auch immer zum Fehler führt.
FHEM wird versuchen, denOT zu erwecken, was nicht klappt. danach sollten die messages im stack bleiben und CMDs_pending angezeigt werden.
burstRx=on
alle Aktionen sollten übertragen werden.
Danke Martin
Hallo Martin, habe jetzt wieder die 3993 drauf, kann ich wahrscheinlich erst morgen testen da der IR-Sensor auch Zicken macht und die Familie nachher Licht braucht :-)
Bestätigen kann ich das Missing Ack nur solange da ist bis eine Aktion stattfindet, beim IR-Sensor z.B. motion erkannt wird oder bei den Temp. Sensoren set getConfig ausgeführt wird.Im fhem Log taucht nichts auf, im Device Log:
2013-10-06_09:39:41 Temperatur_Garten temperature: 13.3
2013-10-06_09:39:41 Temperatur_Garten humidity: 98
2013-10-06_09:39:41 Temperatur_Garten T: 13.3 H: 98
2013-10-06_09:39:42 Temperatur_Garten R-intKeyVisib: invisib
2013-10-06_09:39:42 Temperatur_Garten R-pairCentral: 0x123ABC
2013-10-06_09:39:42 Temperatur_Garten R-burstRx: off
2013-10-06_09:40:01 Temperatur_Garten MISSING ACK
VG Frank
Hallo Frank,
hm - beim TC erhalte ich kein missing-ack. wenn es normal läuft unterdrücke ich es in diesem Fall.
bin auf die logs gespannt.
Probieren bitte mit der letzten SW
Gruss Martin
Hallo Martin, wie gesagt im Log taucht nichts auf, habe verbose aber auch nur auf 3. Setze jetzt mal auf 5 und kopiere die neue (von heute) CUL_HM.pm wieder rein. Hier das Log
2013.10.06 19:09:04 5: Cmd: >setstate Deckenventilator 2013-10-06 09:36:21 state off<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor MISSING ACK<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:43 Activity alive<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:33 CommandAccepted yes<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 PairedTo 0x123ABC<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 R-burstRx off<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 R-cyclicInfoMsgDis 0<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 R-intKeyVisib invisib<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 R-localResDis off<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 R-pairCentral 0x123ABC<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 R-paramSel T1_T2<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:34 RegL_00: 01:00 02:01 0A:12 0B:3A 0C:BC 11:00 18:00 1B:03 00:00<
2013.10.06 19:09:04 5: Cmd: >setstate Diff_Temp_Sensor 2013-10-06 19:08:54 state MISSING ACK<
Mit verbose Level 5
Das ist nur der Abschnit vom Differenz Temp Sensor
Und vom 2. Sensor
2013.10.06 19:13:42 5: Triggering THSensor (3 changes)
2013.10.06 19:13:42 5: Notify loop for THSensor temperature: 22.8
2013.10.06 19:13:43 5: HMLAN_Parse: HMLAN1 R:R8EC2A622 stat:0001 t:0FDCDEF0 d:FF r:FFC2 m:56 8002 206AA2 123ABC 00
2013.10.06 19:13:43 5: HMLAN1 dispatch A0A568002206AA2123ABC00::-62:HMLAN1
2013.10.06 19:13:43 5: HMLAN_Send: HMLAN1 I:+206AA2,00,00,
2013.10.06 19:13:43 5: HMLAN_Send: HMLAN1 S:S8EC2A721 stat: 00 t:00000000 d:01 r:8EC2A721 m:57 A001 123ABC 206AA2 0009
2013.10.06 19:13:43 5: HMLAN_Parse: HMLAN1 R:R8EC2A721 stat:0001 t:0FDCE084 d:FF r:FFC2 m:57 8010 206AA2 123ABC 004B455130303534323338
2013.10.06 19:13:43 5: HMLAN1 dispatch A14578010206AA2123ABC004B455130303534323338::-62:HMLAN1
2013.10.06 19:13:43 5: HMLAN_Send: HMLAN1 S:S8EC2A8AF stat: 00 t:00000000 d:01 r:8EC2A8AF m:58 A001 123ABC 206AA2 00040000000000
2013.10.06 19:13:43 5: HMLAN_Parse: HMLAN1 R:R8EC2A8AF stat:0001 t:0FDCE21E d:FF r:FFC2 m:58 8010 206AA2 123ABC 020100020105000A120B3A0CBC0F000000
2013.10.06 19:13:43 5: HMLAN1 dispatch A1A588010206AA2123ABC020100020105000A120B3A0CBC0F000000::-62:HMLAN1
2013.10.06 19:13:43 5: HMLAN_Send: HMLAN1 S:+206AA2,00,01,
2013.10.06 19:13:43 5: HMLAN_Send: HMLAN1 S:S8EC2AA53 stat: 00 t:00000000 d:01 r:8EC2AA53 m:59 A001 123ABC 206AA2 0103
2013.10.06 19:13:43 5: Triggering THSensor (3 changes)
2013.10.06 19:13:43 5: Notify loop for THSensor R-intKeyVisib: invisib
2013.10.06 19:13:44 5: HMLAN_Parse: HMLAN1 R:E206AA2 stat:0000 t:0FDCE3A8 d:FF r:FFC2 m:59 A010 206AA2 123ABC 0100000000
2013.10.06 19:13:44 5: HMLAN1 dispatch A0E59A010206AA2123ABC0100000000::-62:HMLAN1
2013.10.06 19:13:44 5: HMLAN_Parse: HMLAN1 R:R8EC2AA53 stat:0001 t:0FDCE3AD d:FF r:FFC2 m:59 A010 206AA2 123ABC 0100000000
2013.10.06 19:13:44 5: HMLAN1 dispatch A0E59A010206AA2123ABC0100000000::-62:HMLAN1
2013.10.06 19:13:44 4: CUL_HM THSensor dup: dont process
2013.10.06 19:13:44 5: HMLAN_Send: HMLAN1 S:S8EC2ACA7 stat: 00 t:00000000 d:01 r:8EC2ACA7 m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:45 5: HMLAN_Parse: HMLAN1 R:R8EC2ACA7 stat:0008 t:00000000 d:FF r:7FFF m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:45 5: HMLAN_Parse: HMLAN1 no ACK from 206AA2
2013.10.06 19:13:46 5: HMLAN_Send: HMLAN1 S:S8EC2B51F stat: 00 t:00000000 d:01 r:8EC2B51F m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:46 4: CUL_HM_Resend: THSensor nr 2
2013.10.06 19:13:47 5: HMLAN_Parse: HMLAN1 R:R8EC2B51F stat:0008 t:00000000 d:FF r:7FFF m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:47 5: HMLAN_Parse: HMLAN1 no ACK from 206AA2
2013.10.06 19:13:52 5: HMLAN_Send: HMLAN1 S:S8EC2CC82 stat: 00 t:00000000 d:01 r:8EC2CC82 m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:52 4: CUL_HM_Resend: THSensor nr 3
2013.10.06 19:13:53 5: HMLAN_Parse: HMLAN1 R:R8EC2CC82 stat:0008 t:00000000 d:FF r:7FFF m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:53 5: HMLAN_Parse: HMLAN1 no ACK from 206AA2
2013.10.06 19:13:58 5: HMLAN_Send: HMLAN1 S:S8EC2E2B5 stat: 00 t:00000000 d:01 r:8EC2E2B5 m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:58 4: CUL_HM_Resend: THSensor nr 4
2013.10.06 19:13:58 5: HMLAN_Parse: HMLAN1 R:R8EC2E2B5 stat:0008 t:00000000 d:FF r:7FFF m:5A A001 123ABC 206AA2 010E
2013.10.06 19:13:58 5: HMLAN_Parse: HMLAN1 no ACK from 206AA2
2013.10.06 19:14:02 5: HMLAN_Send: HMLAN1 I:K
2013.10.06 19:14:02 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707561 d:1E9D1E O:123ABC t:0FDD2B2E IDcnt:000C
2013.10.06 19:14:02 5: Triggering THSensor (1 changes)
2013.10.06 19:14:02 5: Notify loop for THSensor MISSING ACK
VG Frank
Hallo Frank,
hat der OT2 jemals auf statusRequest reagiert? das funktioniert in diesem zusammenhang nicht. wenn es generell nicht eingebaut ist sperre ich es und es sollte ok sein
Gruss Martin
Einen Status Request quitiert der OT jedesmal mit Missing Ack, auch mit der CUL_HM 3993. CMD processing 4 CMDs pending und dann Missing Ack.
Nach dem status Request ist der OT tot. Selbst nach shutdown restart immer noch CMDs pending.
PS nehme die Batterie jetzt mal raus.
Nach dem "stromlos" sofort CMD done. Sowie ich einen status Request mache, dass gleiche Spiel
Gut wäre den Batterie Status mit einzubauen.
VG Frank
Hatte nach dem setReg burstRx on vergessen den Anlern Button zu drücken. Ich denke das fhem desshalb das Komando nicht an den OT absetzen konnte.
VG Frank
Hallo Frank,
a) ich werde das Kommando statusRequest ausbauen.
b) wenn kommandos pending sind kannst du diese loswerden mit "set <dev> clear msgEvents"
c) der OT2 sollte nach 10 min die Kommandos automatisch "fressen". Mit Burst-on macht er es sofort
Gruss Martin
Hallo Frank,
die aenderung ist drin.
kannst du testen,dass autoReadReg jezt beim OT2 keine Probleme mehr macht?
Danke Martin
Hallo Martin, bin gerade dabei fhem vom RPi auf den Stick auszulagern, soweit fhem wieder läuft werde ich es testen.
Ist es schon in den Updates drinne oder muss ich vom SVN runterladen?
VG Frank
heute musst du es noch aus SVN holen
Hallo Martin, das mit dem OT scheint mit dem heutigen Update der 10_CUL_HM behoben zu sein, jedenfalls konnte ich den Fehler nicht mehr reproduzieren. Das einzige Device was noch "spinnt" ist der HM-SEC-MDIR. Der bringt im State jetzt laufend Response Timeout:SerialRead dann RESPONSE TIMEOUT:RegisterRead.
Nachdem motion erkannt wurde ist alles wieder OK.
VG Frank
Hallo,
nach dem update steht bei mir ein "RESPONSE TIMEOUT:SerialRead" in allen HM-SEC-SCs, bei denen ich cyclicInfoMsg auf on gestellt habe.
Ich habe in letzter Zeit, bei einem meiner 5 HM-SEC-RHS, das gleiche Problem.
RESPONSE TIMEOUT:SerialRead bzw. RESPONSE TIMEOUT:RegisterRead im STATE.
Im Reading contact seht der richtige Wert, also open/closed/tilted
nun - die scheinen bei nichts mitspielen zu wollen.
ich werde das Kommando für diese Gruppe sperren - scheint nicht implementiert zu sein
Gruss Martin
Zitat von: martinp876 schrieb am Di, 08 Oktober 2013 22:59nun - die scheinen bei nichts mitspielen zu wollen.
ich werde das Kommando für diese Gruppe sperren - scheint nicht implementiert zu sein
RESPONSE TIMEOUT:SerialRead kommt jetzt kontinuierlich bei HM-SEC-WDS.
auch da werde ich es unterbinden.
aber warum kontinuierlich? was wird da abgefragt? kannst du genauer werden, zum trigger?
Zitat von: martinp876 schrieb am Mi, 09 Oktober 2013 13:44auch da werde ich es unterbinden.
aber warum kontinuierlich? was wird da abgefragt? kannst du genauer werden, zum trigger?
Kontinuierlich meint, dass trotz der empfangenen periodischen Statusmeldungen des HM-SEC-WDS z. B. "dry" das Reading state immer auf "RESPONSE TIMEOUT:SerialRead" bleibt.
also STATE ist richtig aber reading state ist inkorrekt? und wird nicht erneuert?
muss ich einmal suchen. das Reading state sollte warscheinlich garnicht existieren
Gruss Martin
Zitat von: martinp876 schrieb am Mi, 09 Oktober 2013 17:45also STATE ist richtig aber reading state ist inkorrekt? und wird nicht erneuert?
muss ich einmal suchen. das Reading state sollte warscheinlich garnicht existieren
Gruss Martin
STATE und state zeigen "RESPONSE TIMEOUT:SerialRead"
Bei mir hagelts jetzt MISSING ACKS bei den HM-CC-VDs.
Version:
# $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4017 2013-10-07 15:29:00Z martinp876 $
# $Id: 01_FHEMWEB.pm 3963 2013-09-26 08:55:32Z martinp876 $
# $Id: 10_FS20.pm 3764 2013-08-22 07:09:38Z rudolfkoenig $
# $Id: 92_FileLog.pm 3759 2013-08-21 08:13:08Z rudolfkoenig $
# $Id: 00_HMLAN.pm 4005 2013-10-04 14:28:11Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 90_at.pm 4011 2013-10-06 08:15:26Z rudolfkoenig $
# $Id: 98_autocreate.pm 3999 2013-10-04 05:15:46Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_watchdog.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
das mit den VDs habe ich gesehen. Die können auch ein Kommando nicht, fehler in der referenzliste
sollte morgen erledigt sein
das verstehe ich nicht. state sollte bei
kannst du ein list des WDS schicken?
hat der WDS channels definiert?
Zitat von: martinp876 schrieb am Mi, 09 Oktober 2013 19:15das verstehe ich nicht. state sollte bei
kannst du ein list des WDS schicken?
hat der WDS channels definiert?
Internals:
CUL_0_MSGCNT 1
CUL_0_RAWMSG A0D05A4101A5C753F1E990601000003
CUL_0_RSSI -72.5
CUL_0_TIME 2013-10-09 15:50:06
DEF 1A5C75
EVENTS 1
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 1
NAME Wassermelder_Heizung
NR 82
STATE RESPONSE TIMEOUT:SerialRead
TYPE CUL_HM
lastMsg No:05 - t:10 s:1A5C75 d:3F1E99 06010000
protCmdDel 5
protLastRcv 2013-10-09 15:50:06
protResndFail 1 last_at:2013-10-09 15:50:11
protSnd 2 last_at:2013-10-09 15:50:07
protState CMDs_done_events:1
rssi_at_CUL_0 avg:-72.5 min:-72.5 max:-72.5 lst:-72.5 cnt:1
Readings:
2013-10-09 15:53:23 Activity alive
2013-10-09 15:50:06 alive yes
2013-10-09 15:50:06 battery ok
2013-10-09 15:50:06 contact dry (to CUL_0)
2013-10-09 15:50:11 state RESPONSE TIMEOUT:SerialRead
Helper:
burstEvtCnt 1
getCfgList all
getCfgListNo 4
mId 0045
rxType 12
Prt:
sProc 0
Role:
chn 1
dev 1
Rssi:
At_cul_0:
avg -72.5
cnt 1
lst -72.5
max -72.5
min -72.5
Attributes:
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.1
model HM-SEC-WDS
peerIDs
room wald1
serialNr JEQ0185120
subType threeStateSensor
hm - einiges klar, nicht alles
die letzte empfangene Nachricht ist von 50:06,das war sicher der Trigger und sollte auch state auf "dry" gesetzt haben
danach wird ein getSerial gesendet, 50:07. Aber das versteht der OT2 nicht und state wird um 50:11 überschrieben.
das mit dem getSerial wird nach dem nächsten update nicht mehr auftreten, dann ist es für den OT2 gesperrt.
Was mich stört ist, dass es so mitten drin gesendet wird. Es ist mir unklar wer es losgeschickt hat. würde mich interessieren, was nach einem empfangen des "Dry" passiert (auch mit der neuen Version).
Gruss Martin
Zitat von: martinp876 schrieb am Mi, 09 Oktober 2013 22:34hm - einiges klar, nicht alles
die letzte empfangene Nachricht ist von 50:06,das war sicher der Trigger und sollte auch state auf "dry" gesetzt haben
danach wird ein getSerial gesendet, 50:07. Aber das versteht der OT2 nicht und state wird um 50:11 überschrieben.
das mit dem getSerial wird nach dem nächsten update nicht mehr auftreten, dann ist es für den OT2 gesperrt.
Was mich stört ist, dass es so mitten drin gesendet wird. Es ist mir unklar wer es losgeschickt hat. würde mich interessieren, was nach einem empfangen des "Dry" passiert (auch mit der neuen Version).
Problem beseitigt, danke.
Internals:
CUL_0_MSGCNT 1
CUL_0_RAWMSG A0D06A4101A5C753F1E9906010000FE
CUL_0_RSSI -75
CUL_0_TIME 2013-10-10 15:41:14
DEF 1A5C75
EVENTS 1
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 1
NAME Wassermelder_Heizung
NR 82
STATE dry
TYPE CUL_HM
autoRead scheduled
lastMsg No:06 - t:10 s:1A5C75 d:3F1E99 06010000
protLastRcv 2013-10-10 15:41:14
protSnd 1 last_at:2013-10-10 15:41:14
protState CMDs_done
rssi_at_CUL_0 avg:-75 min:-75 max:-75 lst:-75 cnt:1
Readings:
2013-10-10 15:42:52 Activity alive
2013-10-10 15:41:14 alive yes
2013-10-10 15:41:14 battery ok
2013-10-10 15:41:14 contact dry (to CUL_0)
2013-10-10 15:41:14 state dry
Helper:
mId 0045
rxType 12
Prt:
bErr 0
sProc 0
Rspwait:
Role:
chn 1
dev 1
Rssi:
At_cul_0:
avg -75
cnt 1
lst -75
max -75
min -75
Attributes:
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.1
model HM-SEC-WDS
peerIDs
room wald1
serialNr JEQ0185120
subType threeStateSensor
Hallo Martin, nach dem heutigen Update immer noch ein RESPONSE TIMEOUT:RegisterRead bei dem HM-SEC-MDIR. Das hält an bis motion erkannt wurde.
VG Frank
Hallo Frank,
nach spec hat der mdir register und sollte auf wakeup reagieren. Wakeup sollte so alle paar minuten stattfinden.
Dennoch scheint es nicht zu funktionieren.
kannt du einmal rohmessages aufzeichnen, dann ein getConfig auslösen und warten - so nach keiner 10 min sollte der Fehler auftreten...
dann die Logs schicken...
Andere Frage: hast du schon getestet ob der mdir kommandos automatisch abholt - ohne config zu drücken?
Gruss Martin
Hallo Martin, der mdir hat auf jedenfall Register, ich hab nach einem getConfig motion Intervall z.B. runtergesetzt, da der Sensor sonst zu träge für die Steuerung war.
Ich weiß nicht genau was du mit Rohmessages meinst.
Ob Kommandos automatisch abgeholt werden, habe ich noch nicht getestet.
Ich nehme verbose jetzt auf 5 und mache ein getConfig.
Im Log ist nichts, hab jetzt 3x drübergeschaut.
DEF
1A4F71
IODev
HMLAN1
NAME
IR_Sensor
NR
156
STATE
RESPONSE TIMEOUT:RegisterRead
TYPE
CUL_HM
autoRead
scheduled
Readings
Activity
unknown
2013-10-10 20:32:39
battery
ok
2013-10-10 20:31:43
brightness
33
2013-10-10 20:31:43
cover
closed
2013-10-10 20:31:43
motion
on (to broadcast)
2013-10-10 19:56:49
motionCount
116_next:4-15
2013-10-10 19:56:49
state
RESPONSE TIMEOUT:RegisterRead
2013-10-10 20:27:44
IR_Sensor Attributes
actCycle
000:10
deleteattr
actStatus
unknown
deleteattr
autoReadReg
4_reqStatus
deleteattr
expert
2_full
deleteattr
firmware
1.0
deleteattr
model
HM-SEC-MDIR
deleteattr
peerIDs
deleteattr
room
Bad
deleteattr
serialNr
JEQ0155556
deleteattr
subType
motionDetector
deleteattr
Probably associated with
Bewegung_Bad
notify
Daemmerung
notify
FileLog_IR_Sensor
FileLog
Nach einigen Minuten dann:
DEF
1A4F71
IODev
HMLAN1
NAME
IR_Sensor
NR
156
STATE
RESPONSE TIMEOUT:RegisterRead
TYPE
CUL_HM
autoRead
scheduled
protCmdPend
3 CMDs_pending
protState
CMDs_pending
Readings
Activity
alive
2013-10-10 20:37:39
battery
ok
2013-10-10 20:37:26
brightness
33
2013-10-10 20:39:27
cover
closed
2013-10-10 20:37:26
motion
on (to broadcast)
2013-10-10 20:39:27
motionCount
117_next:4-15
2013-10-10 20:39:27
state
RESPONSE TIMEOUT:RegisterRead
2013-10-10 20:27:44
IR_Sensor Attributes
actCycle
000:10
deleteattr
actStatus
unknown
deleteattr
autoReadReg
4_reqStatus
deleteattr
expert
2_full
deleteattr
firmware
1.0
deleteattr
model
HM-SEC-MDIR
deleteattr
peerIDs
deleteattr
room
Bad
deleteattr
serialNr
JEQ0155556
deleteattr
subType
motionDetector
deleteattr
Probably associated with
Bewegung_Bad
notify
Daemmerung
notify
FileLog_IR_Sensor
FileLog
z.Zt. kann ich auch nicht viel testen, da der MDIR, nachdem er motion erkannt hat OK ist und das Bad jetzt ziemlich frequentiert ist und dauernd motion ausgelöst wird.
VG Frank
hi Frank,
die rohmessages gehen am "reinsten" mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1
Die ergebnisse stehen dann im allgemeinen logfile.
auch wenn motion kommt sollte die zyklische message gesendet werden.... hoffe ich.
evtl kannst du in einer ruhigen minute einmal einige Zeit aufeichnen
wäre gut, das kommando abzusetzen (noch einmal) und einige Zeit zu warten - min 10 minuten - wenn du Zeit hast auch über Nacht.
Gerne auch einmal eine "motion" zwischenrein...
FHEM hat jedenfalls einmal zu senden begonnen - der start-trigger kam also
Gruss Martin
Hi Frank,
probiere es einmal mit Version 4030. Das gefällt auch dem VD besser. Vielleicht ist dies das Problem.
Gruss Martin
Zitat von: martinp876 schrieb am Do, 10 Oktober 2013 23:26Hi Frank,
probiere es einmal mit Version 4030. Das gefällt auch dem VD besser. Vielleicht ist dies das Problem.
Gruss Martin
OK, habe jetzt noch die 4028, denke die 4030 ist im heutigen update? Heute nach der Arbeit.
Gruss Frank
ja, ist im update.
File ist 00_HMLAN
hallo Martin
Habe gerade, über VPN, mal das heutige Update eingespielt. Aber wie es aussieht bringt der MDIR nach einem Neustart von fhem immer noch RESPONSE TIMEOUT:RegisterRead.
Bis Motion erkannt wurde, dann ist alles OK.
Schicke dir heute Nachmittag mal die Rohmessages.
VG Frank
Hi Frank,
hast du auch HMLAN mitgenommen? Wichtig.
Ansonsten - kann ich logs bekommen? HMLAN traces
attr global mseclog 1
attr globalverbose 1
attr <hmlan> loglevel 1
Gruss Martin
ja, HMLAN und CUL_HM. Wenn ich auf CUL_HM 3993 zurück gehe, ist der Fehler auch weg. log im Anhang:
VG Frank
Und Hier noch das Log über 10 min, dann MDIR ausgelöst.
Hallo Frank,
da sind mehrere Dinge unklar - ich werden mehrere Schritte brauchen.
zum ersten kommt ein Ack, was glaube ich - unötig ist.
kannst du einmal das File im Anhang einbauen und noch einmal aufzeichnen?
Der Fehler kommt wahrscheinlich immer noch... oder das Kommando bleibt hängen - aber egal. Das log hätte ich gerne für Schritt 1
du kannst das File einfach reinkopieren und
reload 10_CUL_HM
eingeben danach ein
set <mdir> getConfig
und warten...
Gruss Martin
Hallo Martin, im Anhang das neue Logfile, mit der 10_CUL_HM aus deinem Anhang. Die Meldung RESPONSE TIMEOUT:RegisterRead scheint nicht mehr zu kommen. Während des loggens wurde der MDIR ausgelöst (Frau im Bad :-)
Hallo Frank,
Teil 1 sieht gut aus - der eingebaute ACK (historisch) war falsch.
Zum aktuellen Verhalten:
der MDIR sendet seinen Status alle 6 min - ich gehe davon aus, dass dieser Abstand regelmässig ist.
Es werden trigger an broadcast gesendet. Meine Frage:
- Der channel ist nicht gepeert?
- eine Reaktion auf die Trigger ist nicht zu sehen
so nun zum getConfig
- falls du vorher einen abgesetzt hast ist dieser sicher noch in der Queue - korrekt?
- der nächste Schritt ist, zu testen ob der MDIR 'ansprechbar' ist, wenn er des Status sendet. daher hier die nächste Version, die dies testet. Bitte beide Dateien laden.
Du musst 2 varianten testen: den trigger und die regelmässige status-Nachricht.
- getConfig senden
-> ins Bad gehen
(sicherheitshalber 2 mal machen - nicht dass der status-report überholt hat...)
und einmal getConfig und 10min warten
bin gespannt.
Gruss Martin
Hallo Martin,
der channel ist NICHT gepeert nur pairing mit HMLAN. Reaktion auf die Trigger kommt erst wenn der Sensor "dunkel" liefert, so wie jetzt im Log.
Der MDIR scheint anprechbar zu sein, wenn er Status sendet. Anbei Log 1.Teil, server shutdown, getConfig und dann Motion ausgelöst.
Hier der 2. Teil, getConfig und 10min gewartet. Jetzt ständig missing Ack. Der OT2 bringt jetzt auch wieder missing Ack.
Nach motion erkannt ist die missing Ack Message beim MDIR weg. Nach shutdown restart missing Ack beim OT2 auch weg.
so - meine welt ist hier wieder (fast) in ordnung. Sprich der Mechanismuss zum wakeup war ok, das (historische) ACK war falsch (hatte nur noch keinen Beweis).
Das wird jetzt so abgeliefert.
Was nicht in Ordnung ist, dass der Sensor bislang kein "bin wach" signal gesendet hat. In beiden Fällen hat das Device nicht reagiert.
Kann man nichts machen....
Hallo Martin,
ist morgen im update die Änderung drinne, bin jetzt mit restore auf die alte Version vom 09.10. zurück. Egal welcher Sensor, der OT2, der MDIR und TH, alle machen nach einem Server restart erstmal munter missing Ack bzw. Response Time out. Ist optisch nicht OK im webif :-), funktionieren tut ja alles, trotz der Meldungen.
VG
Frank
Hallo Frank,
die Änderung ist drin.
das überzählige ACK war im motion-detector drin - und sollte jetzt entfernt sein.
die devices sollten alle auf ein wakeup warten... und wenn sie aufwachen sollten sie auch sauber arbeiten.
Falls noch fehler auftreten:
kannst du mit der neuen Version noch einmal ein log nach dem Starten machen?
und als referenz für mich ein
set <HMInfo> param -dv DEF model autoReadReg
Gruss Martin