FHEM Forum

Hallo,

ich habe hier einen HM-SEC-SCo, der inzwischen ganz ordentlich arbeitet. Allerdings meldet er dauernd wechselnd "dead" und "alive", obwohl der rssi-Wert selbst im Minimum nicht unter -66dB geht. Das hier ist ein einziger Tag:


2015-02-02_22:38:04 TF_Essz Activity: alive
2015-02-02_22:28:03 TF_Essz Activity: dead
2015-02-02_19:55:34 TF_Essz Activity: alive
2015-02-02_19:45:34 TF_Essz Activity: dead
2015-02-02_18:05:33 TF_Essz Activity: alive
2015-02-02_17:55:33 TF_Essz Activity: dead
2015-02-02_17:05:32 TF_Essz Activity: alive
2015-02-02_16:55:32 TF_Essz Activity: dead
2015-02-02_16:05:31 TF_Essz Activity: alive
2015-02-02_15:55:31 TF_Essz Activity: dead
2015-02-02_14:15:30 TF_Essz Activity: alive
2015-02-02_14:05:30 TF_Essz Activity: dead
2015-02-02_13:15:29 TF_Essz Activity: alive
2015-02-02_13:05:29 TF_Essz Activity: dead
2015-02-02_12:15:28 TF_Essz Activity: alive
2015-02-02_12:05:28 TF_Essz Activity: dead
2015-02-02_11:15:27 TF_Essz Activity: alive
2015-02-02_11:05:27 TF_Essz Activity: dead
2015-02-02_10:15:26 TF_Essz Activity: alive
2015-02-02_10:05:26 TF_Essz Activity: dead
2015-02-02_09:15:25 TF_Essz Activity: alive
2015-02-02_09:05:25 TF_Essz Activity: dead
2015-02-02_07:25:24 TF_Essz Activity: alive
2015-02-02_07:15:23 TF_Essz Activity: dead
2015-02-02_05:35:23 TF_Essz Activity: alive
2015-02-02_05:15:22 TF_Essz Activity: dead
2015-02-02_03:35:22 TF_Essz Activity: alive
2015-02-02_03:25:21 TF_Essz Activity: dead
2015-02-02_01:45:20 TF_Essz Activity: alive
2015-02-02_01:35:20 TF_Essz Activity: dead
2015-02-02_00:45:19 TF_Essz Activity: alive
2015-02-02_00:35:19 TF_Essz Activity: dead


Mal abgesehen davon, das mit event-on-change-reading auszublenden: Es scheint, dass FHEM öfter auf ein alive wartet, als das Ding sendet.  Gibt es irgendwo einen Timer, den man einstellen kann?

und wo ist ein list von deinem Device?

Hier ist es:


DEF 2DCABC
HMLAN1_MSGCNT 16
HMLAN1_RAWMSG E2DCABC,0000,0171E22B,FF,FFC3,78A6102DCABC2255B106010000
HMLAN1_RSSI -61
HMLAN1_TIME 2015-02-03 12:00:38
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 16
NAME TF_Essz
NR 581
STATE closed
TYPE CUL_HM
lastMsg No:78 - t:10 s:2DCABC d:2255B1 06010000
protLastRcv 2015-02-03 12:00:38
protSnd 16 last_at:2015-02-03 12:00:38
protState CMDs_done
rssi_at_HMLAN1 avg:-59.62 min:-62 max:-58 lst:-61 cnt:16

Readings
Activity alive

D-Firmware 1.0
D-serialNr LEQ0944581

PairedTo 0x2255B1
R-cyclicInfoMsg on
R-eventDlyTime 0 s
R-msgScPosA open
R-msgScPosB closed

R-pairCentral 0x2255B1
R-sabotageMsg on
R-sign on
R-transmDevTryMax 6
R-transmitTryMax 6
RegL_00: 02:01 09:01 0A:25 0B:77 0C:B1 10:01 14:06 00:00
RegL_01: 08:01 20:9C 21:00 30:06 00:00
alive yes
battery ok
contact closed (to HMLAN1)
recentStateType info
sabotageError off
state closed
trigDst_2255B1 noConfig
trigger_cnt 41

Attributes
IODev HMLAN1
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon closed:fts_door open:fts_door_open
event-on-change-reading .*
expert 2_full
Firmware 1.0
model HM-SEC-SCo
peerIDs 00000000
room Aussenbereich
serialNr LEQ0944581
subType threeStateSensor



dein actCycle 000:50 steht auf 50 Minuten
laut Log meldet sich deiner alle 60 Minuten, deswegen die Dead Meldung

ich würde es mal erhöhen auf 001:05

Danke, das klingt logisch. Ich werde es gleich mal ändern. Das Attribut hat sich das Ding übrigens beim autocreate selbst gegeben. Ich wußte nicht, wofür das ist.

Zitat von: fhem-hm-knecht am 03 Februar 2015, 14:22:58
dein actCycle 000:50 steht auf 50 Minuten
laut Log meldet sich deiner alle 60 Minuten, deswegen die Dead Meldung

ich würde es mal erhöhen auf 001:05

Danke für den Hinweis. Mir war bei meinen beiden HM-SEC-SCo auch schon aufgefallen, dass die immer mal wieder "dead" gemeldet wurden, obwohl sie reibungslos funktionieren.
Das ist dann wohl die Erklärung. Ich habe die actCycle jetzt mal auf 001:05 geändert und werde beobachten.

So, ich habe eben ins Log geschaut: Das war´s. Danke für den Tip.

hallo fhem Gemeinde

Ich habe seit einigen Tagen ebenfalls diesen Fensterkontakt im Einsatz. Was mich einfach extrem stutzig macht ist, dass der Kontakt die ganze Zeit Statusmeldungen sendet. Dies jedoch nicht wie in diesem Thread mit dead und wieder alive, sondern die ganze Zeit alive... Weiss jemand warum oder kann bei sich das selbe beobachten?

Log:

2015-05-29_08:32:18 HST_Sitzplatz geschlossen 2015-05-29_08:32:18 HST_Sitzplatz sabotageError: off 2015-05-29_08:32:18 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_08:32:18 HST_Sitzplatz battery: ok 2015-05-29_08:32:18 HST_Sitzplatz alive: yes 2015-05-29_07:37:23 HST_Sitzplatz geschlossen 2015-05-29_07:37:23 HST_Sitzplatz sabotageError: off 2015-05-29_07:37:23 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_07:37:23 HST_Sitzplatz battery: ok 2015-05-29_07:37:23 HST_Sitzplatz alive: yes 2015-05-29_06:38:58 HST_Sitzplatz geschlossen 2015-05-29_06:38:58 HST_Sitzplatz sabotageError: off 2015-05-29_06:38:58 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_06:38:58 HST_Sitzplatz battery: ok 2015-05-29_06:38:58 HST_Sitzplatz alive: yes 2015-05-29_05:59:40 HST_Sitzplatz trigger_cnt: 237 2015-05-29_05:59:40 HST_Sitzplatz trigDst_2BA0B4: noConfig 2015-05-29_05:59:40 HST_Sitzplatz geschlossen 2015-05-29_05:59:40 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_05:59:40 HST_Sitzplatz battery: ok 2015-05-29_05:45:17 HST_Sitzplatz trigger_cnt: 236 2015-05-29_05:45:17 HST_Sitzplatz trigDst_2BA0B4: noConfig 2015-05-29_05:45:17 HST_Sitzplatz offen 2015-05-29_05:45:17 HST_Sitzplatz contact: offen (to HMLAN1) 2015-05-29_05:45:17 HST_Sitzplatz battery: ok 2015-05-29_05:42:55 HST_Sitzplatz geschlossen 2015-05-29_05:42:55 HST_Sitzplatz sabotageError: off 2015-05-29_05:42:55 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_05:42:55 HST_Sitzplatz battery: ok 2015-05-29_05:42:55 HST_Sitzplatz alive: yes 2015-05-29_04:41:48 HST_Sitzplatz geschlossen 2015-05-29_04:41:48 HST_Sitzplatz sabotageError: off 2015-05-29_04:41:48 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_04:41:48 HST_Sitzplatz battery: ok 2015-05-29_04:41:48 HST_Sitzplatz alive: yes 2015-05-29_03:43:41 HST_Sitzplatz geschlossen 2015-05-29_03:43:41 HST_Sitzplatz sabotageError: off 2015-05-29_03:43:41 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_03:43:41 HST_Sitzplatz battery: ok 2015-05-29_03:43:41 HST_Sitzplatz alive: yes 2015-05-29_02:44:09 HST_Sitzplatz geschlossen 2015-05-29_02:44:09 HST_Sitzplatz sabotageError: off 2015-05-29_02:44:09 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_02:44:09 HST_Sitzplatz battery: ok 2015-05-29_02:44:09 HST_Sitzplatz alive: yes 2015-05-29_01:49:17 HST_Sitzplatz geschlossen 2015-05-29_01:49:17 HST_Sitzplatz sabotageError: off 2015-05-29_01:49:17 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_01:49:17 HST_Sitzplatz battery: ok 2015-05-29_01:49:17 HST_Sitzplatz alive: yes 2015-05-29_00:57:29 HST_Sitzplatz geschlossen 2015-05-29_00:57:29 HST_Sitzplatz sabotageError: off 2015-05-29_00:57:29 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_00:57:29 HST_Sitzplatz battery: ok 2015-05-29_00:57:29 HST_Sitzplatz alive: yes 2015-05-29_00:04:30 HST_Sitzplatz geschlossen 2015-05-29_00:04:30 HST_Sitzplatz sabotageError: off 2015-05-29_00:04:30 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-29_00:04:30 HST_Sitzplatz battery: ok 2015-05-29_00:04:30 HST_Sitzplatz alive: yes 2015-05-28_23:08:02 HST_Sitzplatz geschlossen 2015-05-28_23:08:02 HST_Sitzplatz sabotageError: off 2015-05-28_23:08:02 HST_Sitzplatz contact: geschlossen (to HMLAN1) 2015-05-28_23:08:02 HST_Sitzplatz battery: ok 2015-05-28_23:08:02 HST_Sitzplatz alive: yes

hier noch das List dazu:

Internals:    DEF        381B7E    HMLAN1_MSGCNT 62    HMLAN1_RAWMSG E381B7E,0000,7482E61C,FF,FFCA,79A610381B7E2BA0B406010000    HMLAN1_RSSI -54    HMLAN1_TIME 2015-05-29 08:32:18    IODev      HMLAN1    LASTInputDev HMLAN1    MSGCNT     62    NAME       HST_Sitzplatz    NR         165    STATE      geschlossen    TYPE       CUL_HM    lastMsg    No:79 - t:10 s:381B7E d:2BA0B4 06010000    protLastRcv 2015-05-29 08:32:18    protSnd    61 last_at:2015-05-29 08:32:18    protState  CMDs_done    rssi_at_HMLAN1 avg:-54.29 min:-65 max:-49 lst:-54 cnt:62    Readings:      2015-05-28 16:42:50   Activity        alive      2015-05-26 18:33:25   CommandAccepted no      2015-05-28 16:42:50   D-firmware      1.0      2015-05-28 16:42:50   D-serialNr      MEQ0032515      2015-05-26 22:16:49   PairedTo        0x2BA0B4      2015-05-26 22:16:49   R-cyclicInfoMsg on      2015-05-26 22:16:49   R-eventDlyTime  0 s      2015-05-26 22:16:49   R-msgScPosA     open      2015-05-26 22:16:49   R-msgScPosB     closed      2015-05-26 22:16:49   R-pairCentral   0x2BA0B4      2015-05-26 22:16:49   R-sabotageMsg   on      2015-05-26 22:16:49   R-sign          on      2015-05-26 22:16:49   R-transmDevTryMax 6      2015-05-26 22:16:49   R-transmitTryMax 6      2015-05-26 22:16:49   RegL_00:        02:01 09:01 0A:2B 0B:A0 0C:B4 10:01 14:06 00:00      2015-05-26 22:16:49   RegL_01:        08:01 20:9C 21:00 30:06 00:00      2015-05-26 18:32:54   aesKeyNbr       00      2015-05-29 08:32:18   alive           yes      2015-05-29 08:32:18   battery         ok      2015-05-29 08:32:18   contact         closed (to HMLAN1)      2015-05-29 08:32:18   recentStateType info      2015-05-29 08:32:18   sabotageError   off      2015-05-29 08:32:18   state           closed      2015-05-29 05:59:40   trigDst_2BA0B4  noConfig      2015-05-29 05:59:40   trigger_cnt     237    Helper:      mId        00C7      rxType     28      Io:        newChn     +381B7E,00,01,1E        nextSend   1432881138.46608        prefIO        rxt        2        vccu        p:          381B7E          00          01          1E      Mrssi:        mNo        79        Io:          HMLAN1     -52      Prt:        bErr       0        sProc      0        sleeping   0        Rspwait:      Q:        qReqConf        qReqStat      Role:        chn        1        dev        1      Rpt:        IO         HMLAN1        flg        A        ts         1432881138.38084        ack:          HASH(0x29dcfe0)          7980022BA0B4381B7E00      Rssi:        At_hmlan1:          avg        -54.2903225806452          cnt        62          lst        -54          max        -49          min        -65 Attributes:    IODev      HMLAN1    actCycle   001:05    actStatus  alive    autoReadReg 4_reqStatus    eventMap   open:offen closed:geschlossen    expert     2_full    firmware   1.0    group      Tür-/Fensterkontakte    icon       fts_door_slide_open    model      HM-SEC-SCo    peerIDs    00000000,    room       Fensterkontakte,Wohnzimmer    serialNr   MEQ0032515    subType    threeStateSensor

Weiss jemand Rat?

nach dem lesen des kurzen thread, würde ich behaupten, dass das verhalten normal ist. nicht grundlos ist das attr actCycle default auf 50 minuten oder nach den änderungen auf 1 stunde und 5 minuten eingestellt. wenn dich die vielen immer gleichen infos stören, setze einfach das attr event-on-change auf ".*".

Ich frage mich einfach ob mit dieser häufigen statusmitteilungen nicht die Batterie zügig leer sein wird. Grundsätzlich ist es mir egal ob er das immer logt. Ist einfach schade wenn ich dann fast monatlich die Batterie tauschen muss...

thermostate senden mindestens 20 mal die stunde und die batterien halten doch eine weile. wenn man den fensterkontakt aus der ferne konfigurieren kann, ohne manuellen eingriff, könntest du ja das register cyclicInfoMsg zb einmal am tag einschalten, bis eine statusmsg gekommen ist.

Mein optischer Fensterkontakt wird auch manchmal als Dead angezeigt obwohl ich die actCycle auf 001:05 eingestellt habe.

Gibt es hierzu weitere Infos welche ich noch nicht gefunden habe?

vielleicht schlechter funk und messages kommen nicht an?

könnte  besser sein aber noch ausreichend.

rssi_at_HMLAN1

avg:-78.76 min:-84 max:-74 lst:-81 cnt:46

"ausreichend" definiere ich etwas anders: alles funktioniert gerade noch einwandfrei.
je schlechter der rssi, umso anfälliger ist die funkstrecke auf störeinflüsse.

bei dir werden definitiv nicht alle messages verarbeitet. falls der sco korrekt alle 60 min sendet, ist der empfang zeitweise problematisch. entweder sind die messages durch störeinflüsse korrupt und werden verworfen, der hmlan ist gerade disconnected oder fhem ist eventuell blockiert.

ich würde den kontakt mal sniffen. dann siehst du, ob die messages regelmässig im vorgesehenen rythmus empfangen werden. falls sie manchmal einfach nur zu spät sind, vergrösserst du eben den actioncycle entsprechend. sollten manche messages entfallen, musst du weiter forschen. wenn dir die ursache nicht so wichtig ist, einfach gleich den actioncycle zb auf 3-4 std setzen. dann meldet der actiondetector erst dead, wenn mehrere messages in folge fehlen.

OK das werde ich mal probieren und beobachten. Vielen Dank für die Hilfe :)