HM-MOD-EM-8BIT und Lebenszeichen

[FHEM_Starter]

Hallo,

ich betreibe den HM-MOD-EM-8BIT an einer 9V Blockbattarie um potentialfreie Kontakte meiner Haustür zu überwachen.
Leider habe ich keinen Hinweis gefunden, wie ich abfragen kann, ob der Sender noch alive ist.

Hat jemand dazu eine Idee?

Danke im voraus und Gruß
Wolfgang

[frank]

zeig ein list

[FHEM_Starter]

Hallo Frank,

anbei das list des Device:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CUL_0_MSGCNT 225
   CUL_0_RAWMSG 0501004A8584007859CAF110341001065445513037363035393340030000
   CUL_0_RSSI -74
   CUL_0_TIME 2025-01-27 15:30:21
   CUL_2_MSGCNT 111
   CUL_2_RAWMSG 0500005384A2417859CAF110340353EE
   CUL_2_RSSI -83
   CUL_2_TIME 2025-01-27 15:17:56
   CUL_4_MSGCNT 204
   CUL_4_RAWMSG 0500004F83A2417859CAF110340352EF
   CUL_4_RSSI -79
   CUL_4_TIME 2025-01-27 15:17:53
   DEF        7859CA
   FUUID      67976b46-f33f-21e6-d61c-0643ca087b07e6c2
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     540
   NAME       HM_7859CA
   NR         8461
   NTFY_ORDER 48-HM_7859CA
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_7859CA_Btn_01
   channel_02 HM_7859CA_Btn_02
   channel_03 HM_7859CA_Tr
   disableNotifyFn 1
   eventCount 367
   lastMsg    No:85 - t:00 s:7859CA d:F11034 1001065445513037363035393340030000
   protLastRcv 2025-01-27 15:30:21
   protRcv    227 last_at:2025-01-27 15:30:21
   protResnd  1 last_at:2025-01-27 12:17:45
   protSnd    202 last_at:2025-01-27 15:30:21
   protState  CMDs_done
   rssi_at_CUL_0 cnt:226 min:-94 max:-59 avg:-70.57 lst:-74
   rssi_at_CUL_2 cnt:111 min:-87 max:-76 avg:-82.54 lst:-83
   rssi_at_CUL_4 cnt:204 min:-86 max:-68 avg:-75.57 lst:-79
   READINGS:
     2025-01-27 15:16:07   CommandAccepted yes
     2025-01-27 15:30:21   D-firmware      1.0
     2025-01-27 15:30:21   D-serialNr      TEQ0760593
     2025-01-27 15:30:21   IODev           CUL_0
     2025-01-27 15:16:21   PairedTo        0xF11034
     2025-01-27 15:16:21   RegL_00.         00:00 02:01 05:00 0A:F1 0B:10 0C:34 12:46 14:03 18:00
     2025-01-27 15:17:56   battery         ok
     2025-01-27 15:17:23   cfgState        ok
     2025-01-27 15:30:21   commState       CMDs_done
     2025-01-27 15:30:21   state           CMDs_done
   helper:
     HM_CMDNR   173
     PONtest    1
     cSnd       01F110347859CA03040000000001,01F110347859CA0303
     cfgChkResult No regs found for:-ret--ret-HM_7859CA type:pushButton - -ret-list:peer register         :value-ret-   0:      ledMode          :off-ret-   0:      localResDis      :off-ret-   0:      lowBatLimitBA2   :7 V-ret-   0:      pairCentral      :0xF11034-ret-   0:      transmDevTryMax  :3-ret-                       -ret-                       -ret-
     cfgStateUpdt 0
     lastMsgTm  1737988221.32607
     mId        0106
     peerFriend -
     peerOpt    -:pushButton
     regLst     0
     rxType     28
     supp_Pair_Rep 1
     ack:
     cmds:
       TmplKey    :no:1737979241.12867
       TmplTs     1737979241.12867
       cmdKey     0:1:0::HM_7859CA:0106:00:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +7859CA,00,03,00
       nextSend   1737988221.4186
       rxt        2
       vccu       vCUL
       p:
         7859CA
         00
         03
         00
       prefIO:
     mRssi:
       mNo        85
       io:
         CUL_0:
           -72
           -72
         CUL_2:
           -83
         CUL_4:
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
       tryMsg:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       dev        1
     rssi:
       at_CUL_0:
         avg        -70.5796460176991
         cnt        226
         lst        -74
         max        -59
         min        -94
       at_CUL_2:
         avg        -82.5405405405406
         cnt        111
         lst        -83
         max        -76
         min        -87
       at_CUL_4:
         avg        -75.578431372549
         cnt        204
         lst        -79
         max        -68
         min        -86
     shadowReg:
     shadowRegChn:
       RegL_00.   00
     tmpl:
   nb:
     cnt        3
Attributes:
   IOgrp      vCUL:CUL_0
   autoReadReg 4_reqStatus
   expert     rawReg
   firmware   1.0
   model      HM-MOD-EM-8BIT
   room       CUL_HM
   serialNr   TEQ0760593
   subType    pushButton
   webCmd     getConfig:clear msgEvents

Gruß Wolfgang

[Otto123]

Hat jemand dazu eine Idee?

Du kannst dieses Attribute setzen. Allerdings hat dieses Gerät mW keine selbstständige zyklische Übertragung? Allerdings wenn es von Dir sowieso regelmäßig "benutzt" wird...

actCycle
actCycle <[hhh:mm]|off>
Bietet eine 'alive' oder besser 'not alive' Erkennung für Geräte. [hhh:mm] ist die maximale Zeit ohne Nachricht eines Geräts. Wenn innerhalb dieser Zeit keine Nachricht empfangen wird so wird das Event"<device> is dead" generiert. Sendet das Gerät wieder so wird die Nachricht"<device> is alive" ausgegeben.
Diese Erkennung wird durch 'autocreate' für jedes Gerät mit zyklischer Statusmeldung angelegt.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000".
Aufgrund von Performanceüberlegungen liegt die Antwortverzögerung bei 600 Sekunden (10min). Kann über das Attribut "actCycle" des "ActionDetector" kontrolliert werden.
Sobald die Überwachung aktiviert wurde hat das HM-Gerät 2 Attribute:
actStatus: Aktivitätsstatus des Geräts
actCycle: Detektionsspanne [hhh:mm]
Die gesamte Funktion kann über den "ActionDetector"-Eintrag überprüft werden. Der Status aller Instanzen liegt im READING-Bereich.
Hinweis: Diese Funktion kann ebenfalls für Geräte ohne zyklische Übertragung aktiviert werden. Es obliegt dem Nutzer eine vernünftige Zeitspanne festzulegen.

[frank]

da die xml datei auch den wakeup mode zeigt, könnte das device eventuell von selbst regelmässig senden, ähnlich wie die fensterkontakte (1std/24std) oder rauchmelder (72std).
https://github.com/AskSinPP/asksinpp-web/blob/master/rftypes/xmls/rf_em_8_bit.xml

[Otto123]

Er (also zumindest mein EM-8 ohne bit) hat aber das Register cyclicInfoMsg nicht    das müsste man doch setzen?

Oder muss man länger warten? Die Rauchmelder haben das Register auch nicht. Die Fenstersensoren schon.

Das alive/dead im Actiondetector funktioniert - aber eben nur wenn man ihn immer mal "bewegt".

[frank]

Er (also zumindest mein EM-8 ohne bit) hat aber das Register cyclicInfoMsg nicht    das müsste man doch setzen?

mit cyclicInfoMsg kann man es dort zumindestens zusätzlich steuern/abschalten, um batterie zu sparen.

denkbar wäre auch unterschiedliches verhalten des 8bit je nach konfiguration oder abhängig vom spannungseingang.
oder in der xml datei steht schrott! 

kann es der normale "em-8"?
die xml sieht ähnlich aus.

[Otto123]

kann es der normale "em-8"?

Naja, wie hoch müsste ich denn die Zeit setzen und ihn nicht bedienen um es zu sehen? Die Fenstersensoren senden 1 mal die Stunde. Ich kann mal mit 5h probieren, da müsste man nach der Nacht etwas sehen.

[Otto123]

Also ich meine, der sendet nicht von alleine. Der Actiondetector hat heute Nacht irgendwann den Tod meines EM-8 festgestellt.
Ich weiß nicht ob sich daran was ändert, wenn man das

lowBatLimitBA2  | 0.0 to 15V        |          | low batterie limit, step .1V

einstellt.
Zumindest muss er ja dann zumindest am Ende diesen Wert melden. Den könnte man ja auch überwachen. Per default ist kein Limit aktiv (0 Volt). Dann gäbe es vielleicht kein Lebenszeichen aber kurz vorm Ende die nahe Todesnachricht.

[frank]

moin otto,

Naja, wie hoch müsste ich denn die Zeit setzen und ihn nicht bedienen um es zu sehen? Die Fenstersensoren senden 1 mal die Stunde. Ich kann mal mit 5h probieren, da müsste man nach der Nacht etwas sehen.

1 std gilt nur für die SCO, da sie eine "grosse" batterie (keine knopfzelle) haben.
bein RHS und SC sind es 24 std.
vielleicht actioncycle nochmal auf 25 erhöhen?

lowBatLimitBA2 ist ne gute idee.
da es default auf 0 steht, könnte dadurch etwas abgeschaltet sein, um energie zu sparen.
wirklich sinn machen hier eigentlich nur werte grösser um die 2.4V.

Zumindest muss er ja dann zumindest am Ende diesen Wert melden. Den könnte man ja auch überwachen. Per default ist kein Limit aktiv (0 Volt). Dann gäbe es vielleicht kein Lebenszeichen aber kurz vorm Ende die nahe Todesnachricht.

vermutlich wird nicht der wert der spannung gesendet, sondern nur die binäre lowbat info, wenn die schwelle unterschritten ist.


die alive messages bei sc, rhs und sd sehen so aus:

2025.01.11 09:26:58.337 0: HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: A8 A6 10 1DF7C6 1ACE1F 06010000

da könnte man also sniffen für bestimmte devices einschalten und dann das log mit notify auf den string "10 xxxxxx" überwachen.
xxxxxx sind dann die hmids der sensoren.
beim öffnen der gehäuse werden diese info messages allerdings auch gesendet.