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
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
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.
Zitat von: Omega am 08 Dezember 2017, 13:04:40
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
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.
Zitathektisches 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