HM-WDS30-OT2-SM Missing Ack seit gestr. Update

ThorstenH · 08 Oktober 2013, 22:05:18

Hallo,

nach dem update steht bei mir ein "RESPONSE TIMEOUT:SerialRead" in allen HM-SEC-SCs, bei denen ich cyclicInfoMsg auf on gestellt habe.

jhohn · 08 Oktober 2013, 22:37:16

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

martinp876 · 08 Oktober 2013, 22:59:43

nun - die scheinen bei nichts mitspielen zu wollen.

ich werde das Kommando für diese Gruppe sperren - scheint nicht implementiert zu sein

Gruss Martin

klaus.schauer · 09 Oktober 2013, 13:12:26

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.

martinp876 · 09 Oktober 2013, 13:44:57

auch da werde ich es unterbinden.

aber warum kontinuierlich? was wird da abgefragt? kannst du genauer werden, zum trigger?

klaus.schauer · 09 Oktober 2013, 17:05:29

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.

martinp876 · 09 Oktober 2013, 17:45:32

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

klaus.schauer · 09 Oktober 2013, 17:47:27

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"

ThorstenH · 09 Oktober 2013, 17:52:08

Bei mir hagelts jetzt MISSING ACKS bei den HM-CC-VDs.
Version:

Code Auswählen

# $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 $

martinp876 · 09 Oktober 2013, 18:05:18

das mit den VDs habe ich gesehen. Die können auch ein Kommando nicht, fehler in der referenzliste
sollte morgen erledigt sein

martinp876 · 09 Oktober 2013, 19:15:51

das verstehe ich nicht. state sollte bei
kannst du ein list des WDS schicken?
hat der WDS channels definiert?

klaus.schauer · 09 Oktober 2013, 21:56:36

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

martinp876 · 09 Oktober 2013, 22:34:14

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

klaus.schauer · 10 Oktober 2013, 18:08:22

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.

Code Auswählen


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

franky08 · 10 Oktober 2013, 18:52:37

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