HM-Sec-SD-2 peering unvollständig

[Omega]

Ich habe ein schon länger bestehendes Rauchmelderteam. In dieses Team möchte ich 3 weitere RM aufnehmen. Bei einem hat das Peering problemlos funktioniert, bei 2 weiteren wurde der Peer zwar im Team eingetragen aber nicht im RM selber. Ein unset des Peerings und Wiederholungen haben nichts gebracht (mehrfach getestet). Bin mit meinem Latein am Ende und hoffe auf Unterstützung.

LG
Holger

Das Team

Code Auswählen Erweitern


Internals:
   DEF        11000201
   NAME       Rauchmelder_2_Team
   NOTIFYDEV  global
   NR         684
   NTFY_ORDER 50-Rauchmelder_2_Team
   STATE      off
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   device     Rauchmelder_2
   peerList   RM_Kellerflur_Heizung,RM_Werkzeugkeller,RM_Vorratskeller,RM_Schlafzimmer,RM_OG.Jami,RM_OG.Kinder,
   sdTeam     sdLead
   Helper:
     DBLOG:
       state:
         myFHEMdb:
           TIME       1512732760.59736
           VALUE      off
         myFHEMdb_LT:
           TIME       1512732760.60289
           VALUE      off
   READINGS:
     2017-07-19 15:48:48   aesCBCCounter   000082
     2017-07-19 15:49:19   eventNo         12
     2017-07-19 15:49:19   level           0
     2017-12-08 12:32:40   peerList        RM_Kellerflur_Heizung,RM_Werkzeugkeller,RM_Vorratskeller,RM_Schlafzimmer,RM_OG.Jami,RM_OG.Kinder,
     2017-07-19 15:49:19   smoke_detect    none
     2017-12-08 12:32:40   state           off
     2016-09-22 11:23:42   teamCall        from Rauchmelder_2:03
     2017-07-19 15:49:19   trigger_cnt     18
   helper:
     fkt        sdLead2
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     role:
       chn        1
       vrt        1
     shadowReg:
     tmpl:
Attributes:
   devStateIcon off:general_ok .*:secur_alarm
   event-on-change-reading .*
   expert     251_anything
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    4C814701,4C815701,4C817901,5DC36001,5DC49901,5DC50E01,
   room       Rauchmelder
   webCmd     teamCall:alarmOn:alarmOff

RM_Schlafzimmer (5DC36001) und RM_OG.Kinder (5DC50E01) sind korrekt eingetragen.

Und ein List eines der widerspenstigen RM

Code Auswählen Erweitern


Internals:
   DEF        5DC360
   HMLGW_2_MSGCNT 13
   HMLGW_2_RAWMSG 040C01276880025DC360272E5700B5B90C0D
   HMLGW_2_RSSI -39
   HMLGW_2_TIME 2017-12-08 12:32:45
   HMLGW_3_MSGCNT 10
   HMLGW_3_RAWMSG 050000366880025DC360272E5700B5B90C0D
   HMLGW_3_RSSI -54
   HMLGW_3_TIME 2017-12-08 12:32:45
   HMLGW_MSGCNT 8
   HMLGW_RAWMSG 050000346880025DC360272E5700B5B90C0D
   HMLGW_RSSI -52
   HMLGW_TIME 2017-12-08 12:32:45
   IODev      HMLGW
   LASTInputDev HMLGW_2
   MSGCNT     31
   NAME       RM_Schlafzimmer
   NOTIFYDEV  global
   NR         919
   NTFY_ORDER 50-RM_Schlafzimmer
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:68 - t:02 s:5DC360 d:272E57 00B5B90C0D
   protEvt_AESCom-ok 3 last_at:2017-12-08 12:32:45
   protLastRcv 2017-12-08 12:32:45
   protResnd  2 last_at:2017-12-08 12:32:44
   protSnd    13 last_at:2017-12-08 12:32:44
   protState  CMDs_done
   rssi_HMLGW_2 lst:-35 min:-35 avg:-35 cnt:1 max:-35
   rssi_at_HMLGW cnt:8 max:-51 lst:-52 min:-53 avg:-52.12
   rssi_at_HMLGW_2 max:-38 cnt:7 avg:-38.57 lst:-39 min:-40
   rssi_at_HMLGW_3 max:-54 cnt:10 avg:-54.3 lst:-54 min:-55
   Helper:
     DBLOG:
       aesCommToDev:
         myFHEMdb:
           TIME       1512732765.24049
           VALUE      ok
       aesKeyNbr:
         myFHEMdb:
           TIME       1512732765.21424
           VALUE      02
       alarmTest:
         myFHEMdb:
           TIME       1512732043.3272
           VALUE      ok
       battery:
         myFHEMdb:
           TIME       1512732043.3272
           VALUE      ok
       level:
         myFHEMdb:
           TIME       1512732043.3272
           VALUE      0
       sdRepeat:
         myFHEMdb:
           TIME       1512732421.82065
           VALUE      off
       smokeChamber:
         myFHEMdb:
           TIME       1512732043.3272
           VALUE      ok
       state:
         myFHEMdb:
           TIME       1512732043.3272
           VALUE      off
         myFHEMdb_LT:
           TIME       1512732043.33311
           VALUE      off
   READINGS:
     2017-12-08 12:20:23   Activity        alive
     2017-12-08 12:32:45   CommandAccepted yes
     from archivexx        D-firmware      1.0
     from archivexx        D-serialNr      OEQ1269496
     2017-12-08 12:27:01   PairedTo        0x272E57
     2017-12-08 10:33:33   R-devRepeatCntMax 0
     2017-12-08 10:33:33   R-pairCentral   0x272E57
     2017-12-08 12:27:01   RegL_00.          02:01 0A:27 0B:2E 0C:57 16:00 1F:00 00:00
     2017-12-08 12:32:45   aesCommToDev    ok
     2017-12-08 12:32:45   aesKeyNbr       02
     2017-12-08 12:20:43   alarmTest       ok
     2017-12-08 12:20:43   battery         ok
     2017-12-08 12:20:43   level           0
     2017-12-08 12:20:43   recentStateType info
     2017-12-08 12:27:01   sdRepeat        off
     2017-12-08 12:20:43   smokeChamber    ok
     2017-12-08 12:20:43   state           off
   helper:
     HM_CMDNR   104
     cSnd       01272E575DC36001011100020100,01272E575DC36001011100020100
     mId        00AA
     peerIDsRaw ,00000000
     rxType     6
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +5DC360,00,01,00
       nextSend   1512732765.2734
       rxt        0
       vccu       vccu
       p:
         5DC360
         00
         01
         00
     mRssi:
       mNo        68
       io:
         HMLGW      -52
         HMLGW_2    -39
         HMLGW_3    -54
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat
     role:
       chn        1
       dev        1
     rssi:
       HMLGW_2:
         avg        -35
         cnt        1
         lst        -35
         max        -35
         min        -35
       at_HMLGW:
         avg        -52.125
         cnt        8
         lst        -52
         max        -51
         min        -53
       at_HMLGW_2:
         avg        -38.5714285714286
         cnt        7
         lst        -39
         max        -38
         min        -40
       at_HMLGW_3:
         avg        -54.3
         cnt        10
         lst        -54
         max        -54
         min        -55
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLGW
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon off:general_ok .*:secur_alarm
   expert     251_anything
   firmware   1.0
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       Rauchmelder
   serialNr   OEQ1269496
   subType    smokeDetector
   webCmd     statusRequest



Nachtrag:
Manche Geräte haben ein Eigenleben. Heute abend sind die Peerings mit einem mal vorhanden. So richtig vertrauen erweckend ist das nicht.

[Otto123]

Nachtrag:
Manche Geräte haben ein Eigenleben. Heute abend sind die Peerings mit einem mal vorhanden. So richtig vertrauen erweckend ist das nicht.

Hallo Holger,

Übertragung der Daten braucht Zeit, hektisches Vorgehen ist da Kontraproduktiv.
Du hast 3 IO's, der RM redet mit allen. Auch das macht es nicht einfacher

Ich weiß nicht woran es lag. Wenn es geht ist es gut.

Mit hmInfo configCeck kannst Du Deine Umgebung prüfen.

Gruß Otto

[martinp876]

Evtl eine. Getconfig schicken.a) sollte es abgearbeitet werden - sodann ist Kommunikation ok und b) siehst du, ob ein Peer eingetragen ist. Ist es der falsche Peer musst du ihn löschen. Ist es der richtige bist du fertig. Ist es keiner noch einmal peeren.

Unpeeren ist nicht nötig.

[Omega]

hektisches Vorgehen ist da Kontraproduktiv

da gebe ich dir grundsätzlich recht. Allerdings habe ich nach jedem Befehl gewartet, bis CMDs_done erschien. Und vom 1. Auftreten des fehlerhaften Peerings bis zur Forumsmeldung sind auch ca. 2 Std. vergangen. Das kann es eigentlich nicht sein. Und hmInfo configCeck hat mich ja auch immer auf den fehlerhaften Peer verwiesen.

@Martin
getConfig hatte ich auch durchgeführt - und auch gewartet, bis alles abgearbeitet war.

Ich bin mir halt relativ sicher, keinen der üblichen Fehler gemacht zu haben. Und die Anweisung, den Peer zu setzen, wird ja auch nicht gespeichert. Nach CMDS_done sollte doch alles durch sein.

Was ich mir evtl. vorstellen könnte, dass durch das attr autoReadReg 5_readMissing irgendwann etwas ausgelöst wurde, was im Endeffekt zu den korrekten Einträgen geführt haben könnte.

Aber zum Glück ist jetzt alles gut.

LG
Holger