Wahrscheinich übersehe ich wieder nur ein kleines Detail, daher muss ich hier doch jetzt um Rat fragen.
Vor etwa einem Jahr habe ich drei HM-SEC-SD-2 eingerichtet. Dabei habe ich auch einen virtuellen TeamLead eingerichtet. Hat etwas gebraucht, da ich doch nicht so in HM stecke, aber letztendlich hat es funktioniert.
Jetzt habe ich mir vier weitere HM-SEC-SD-2 gekauft und wollte auch diese in das Team integrieren. Dar Pairing hat geklappt (autocreate aktivieren nicht vergessen :-[) und auch das Peering scheint funktioniert zu haben. Alle 7 HM-SEC-SD-2 sind nun in der peerList des TeamLead, der TeamLead ist in der peerList aller 7 HM-SEC-SD-2.
Vielleicht noch gut zu sagen: Die Attribute habe ich für die neuen HM-SEC-SD-2 analog zu den alten eingerichtet. Die Readings und die Internals stimmen allerdings nicht komplett überein.
Jetzt reagieren aber die neuen HM-SEC-SD-2 leider nicht auf die TeamLead-Befehle. Ein set Rauchmelder_Team teamCall oder set Rauchmelder_Team alarmOn lässt die alten drei ordnungsgemäß reagieren, die neuen vier hingegen zeigen sich unbeeindruckt. Sie blinken nicht und sie geben keinen Alarm.
Hat mir jemand einen Tipp?
Hier sind die Listings von
Rauchmelder_Team
Internals:
DEF 31126801
FUUID 5db5da52-f33f-10de-8c7c-820c9ed0d8fad121
NAME Rauchmelder_Team
NOTIFYDEV global
NR 71
STATE off
TESTNR 7
TYPE CUL_HM
chanNo 01
device HM_RM_TeamDev
peerList HM_673520,HM_67352F,HM_673533,HM_72A624,HM_72A627,HM_72A73A,HM_72A781,
sdTeam sdLead
READINGS:
2020-12-06 22:55:36 aesCBCCounter 0000CE
2020-12-06 22:25:19 cfgState ok
2020-12-06 22:55:37 eventNo 07
2020-12-06 22:53:07 level 0
2020-12-06 22:09:52 peerList HM_673520,HM_67352F,HM_673533,HM_72A624,HM_72A627,HM_72A73A,HM_72A781,
2020-12-06 22:55:37 smoke_detect none
2020-12-07 09:44:05 state off
2020-12-06 22:55:37 teamCall from HM_RM_TeamDev:07
2019-10-31 04:29:10 trigger Short_1
2020-12-06 22:55:37 trigger_cnt 7
helper:
fkt sdLead2
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst
cmds:
TmplKey HM_673520,HM_67352F,HM_673533,HM_72A624,HM_72A627,HM_72A73A,HM_72A781,:no:1607288992.52793
TmplTs 1607288992.52793
cmdKey 1:0:1:sdLead2:HM_RM_TeamDev:FFF1:01:HM_673520,HM_67352F,HM_673533,HM_72A624,HM_72A627,HM_72A73A,HM_72A781,
cmdLst:
alarmOff noArg
alarmOn noArg
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
teamCall [(1..255;1)]
tplSet_0 -tplChan-
tplSet_HM_673520 -tplPeer-
tplSet_HM_67352F -tplPeer-
tplSet_HM_673533 -tplPeer-
tplSet_HM_72A624 -tplPeer-
tplSet_HM_72A627 -tplPeer-
tplSet_HM_72A73A -tplPeer-
tplSet_HM_72A781 -tplPeer-
lst:
condition slider,0,1,255
peer HM_673520,HM_67352F,HM_673533,HM_72A624,HM_72A627,HM_72A73A,HM_72A781
peerOpt remove_HM_673520,remove_HM_67352F,remove_HM_673533,remove_HM_72A624,remove_HM_72A627,remove_HM_72A73A,remove_HM_72A781,Beamer_Power,HM_33C21B_SenF,HM_33C21B_SenI,HM_33C21B_SenPwr,HM_33C21B_SenU,HM_33C21B_Sw,HM_3E57B1_SenF,HM_3E57B1_SenI,HM_3E57B1_SenPwr,HM_3E57B1_SenU,HM_3E57B1_Sw,HM_4AA1BC_SenF,HM_4AA1BC_SenI,HM_4AA1BC_SenPwr,HM_4AA1BC_SenU,HM_4CAE58_SenF,HM_4CAE58_SenI,HM_4CAE58_SenPwr,HM_4CAE58_SenU,HM_507161,HM_50722A,Licht_Da,Licht_Ki,Licht_Ku,Waschmaschine
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
param -param-
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
Attributes:
icon hm_ccu
model VIRTUAL
peerIDs 67352001,67352F01,67353301,72A62401,72A62701,72A73A01,72A78101,
room CUL,CUL_HM
webCmd press short:press long
Einer der alten drei Rauchmeldern
Internals:
DEF 673520
FUUID 5db5e4f8-f33f-10de-1797-a9b968742b596123
HMLANGW_MSGCNT 2
HMLANGW_RAWMSG 05000040C1A61067352028076506010000
HMLANGW_RSSI -64
HMLANGW_TIME 2020-12-06 23:27:26
HMUSB_MSGCNT 5
HMUSB_RAWMSG E673520,0000,1F896526,FF,FFBB,C1A61067352028076506010000
HMUSB_RSSI -69
HMUSB_TIME 2020-12-06 23:27:26
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 7
NAME HM_673520
NOTIFYDEV global
NR 1815
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:C1 - t:10 s:673520 d:280765 06010000
peerList Rauchmelder_Team,
protCmdDel 4
protLastRcv 2020-12-06 23:27:26
protRcv 3 last_at:2020-12-06 23:27:26
protResnd 2 last_at:2020-12-06 22:37:48
protResndFail 2 last_at:2020-12-06 22:37:52
protSnd 7 last_at:2020-12-06 23:27:26
protSndB 6 last_at:2020-12-06 22:37:58
protState CMDs_done
rssi_HMUSB cnt:2 min:-61 max:-51 avg:-56 lst:-61
rssi_at_HMLANGW cnt:2 min:-72 max:-64 avg:-68 lst:-64
rssi_at_HMUSB cnt:5 min:-70 max:-61 avg:-66.2 lst:-69
READINGS:
2020-12-06 21:32:33 Activity alive
2019-10-27 21:02:17 CommandAccepted yes
2020-12-06 21:22:33 D-firmware 1.0
2020-12-06 21:22:33 D-serialNr OEQ2616793
2020-12-06 21:20:25 PairedTo 0x280765
2019-10-27 21:02:19 R-pairCentral 0x280765
2020-12-06 21:20:25 RegL_00. 00:00 02:01 0A:28 0B:07 0C:65 16:00 1F:00
2019-10-27 21:02:17 aesCommToDev ok
2019-10-27 21:02:16 aesKeyNbr 00
2020-12-06 23:27:26 alarmTest ok
2020-12-06 23:27:26 battery ok
2020-12-06 22:25:19 cfgState ok
2020-12-06 23:27:26 commState CMDs_done
2020-12-06 23:27:26 level 0
2020-12-06 22:09:50 peerList Rauchmelder_Team,
2020-12-05 12:09:53 powerOn 2020-12-05 12:09:53
2020-12-06 23:27:26 recentStateType info
2020-12-06 21:20:25 sdRepeat off
2020-12-06 23:27:26 smokeChamber ok
2020-12-06 22:55:37 smoke_detect none
2020-12-06 23:27:26 state off
2020-12-06 22:55:37 teamCall from HM_RM_TeamDev:07
2019-10-28 18:40:03 trigLast Rauchmelder_Team:0
2019-10-28 18:40:03 trig_Rauchmelder_Team 0_1
helper:
HM_CMDNR 193
cSnd 01280765673520010E,01280765673520010E
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
ack:
cmds:
TmplKey Rauchmelder_Team,:no:1607288990.65711
TmplTs 1607288990.65711
cmdKey 1:1:0::HM_673520:00AA:01:Rauchmelder_Team,
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [({actor})]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_Rauchmelder_Team -tplPeer-
unpair noArg
lst:
condition Smoke Alarm,no alarm,tone off
peer Rauchmelder_Team
peerOpt remove_Rauchmelder_Team
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +673520,00,00,00
nextSend 1607293646.83125
rxt 0
vccu VCCU
p:
673520
00
00
00
prefIO:
HMUSB
mRssi:
mNo C1
io:
HMLANGW:
-64
-64
HMUSB:
-65
-65
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMLANGW
flg A
ts 1607293646.71795
ack:
HASH(0x6d42d50)
C1800228076567352000
rssi:
HMUSB:
avg -56
cnt 2
lst -61
max -51
min -61
at_HMLANGW:
avg -68
cnt 2
lst -64
max -64
min -72
at_HMUSB:
avg -66.2
cnt 5
lst -69
max -61
min -70
tmpl:
Attributes:
IODev HMLANGW
IOgrp VCCU:HMUSB
actCycle 099:00
actStatus alive
alias Rauchmelder_1
autoReadReg 5_readMissing
devStateIcon off:Wecker.Aus .*:Wecker.Immer
event-on-change-reading .*
expert defReg,rawReg
firmware 1.0
icon secur_smoke_detector
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,31126801,
room CUL_HM,Security
serialNr OEQ2616793
subType smokeDetector
webCmd statusRequest
Und zuletzt einer der neuen RM
Internals:
DEF 72A781
FUUID 5fcbc0bc-f33f-10de-98e5-a4452d1739e2f342
HMLANGW_MSGCNT 6
HMLANGW_RAWMSG 0501003A82A61072A781280765060100003E
HMLANGW_RSSI -58
HMLANGW_TIME 2020-12-06 23:15:11
HMUSB_MSGCNT 6
HMUSB_RAWMSG E72A781,0000,1F7E2DE8,FF,FFC5,82A61072A781280765060100003E
HMUSB_RSSI -59
HMUSB_TIME 2020-12-06 23:15:11
IODev HMLANGW
LASTInputDev HMLANGW
MSGCNT 12
NAME HM_72A781
NOTIFYDEV global
NR 1822
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:82 - t:10 s:72A781 d:280765 060100003E
peerList Rauchmelder_Team,
protCmdDel 11
protLastRcv 2020-12-06 23:15:11
protRcv 6 last_at:2020-12-06 23:15:11
protResnd 7 last_at:2020-12-06 23:09:49
protResndFail 6 last_at:2020-12-06 23:09:54
protSnd 16 last_at:2020-12-06 23:15:11
protSndB 16 last_at:2020-12-06 23:15:11
protState CMDs_done
rssi_HMLANGW cnt:3 min:-62 max:-58 avg:-59.66 lst:-62
rssi_at_HMLANGW cnt:6 min:-68 max:-58 avg:-62.66 lst:-58
rssi_at_HMUSB cnt:6 min:-59 max:-52 avg:-54.66 lst:-59
READINGS:
2020-12-05 22:50:06 CommandAccepted yes
2020-12-06 21:41:09 D-firmware 1.0
2020-12-06 21:41:09 D-serialNr REQ1168770
2020-12-06 22:39:21 PairedTo 0x280765
2020-12-06 22:03:26 R-pairCentral 0x280765
2020-12-06 22:39:21 RegL_00. 00:00 02:01 0A:28 0B:07 0C:65 16:00 1F:00
2020-12-06 21:40:46 aesCommToDev pending
2020-12-06 21:40:46 aesKeyNbr 00
2020-12-06 23:15:11 alarmTest ok
2020-12-06 23:15:11 battery ok
2020-12-06 22:39:51 cfgState ok
2020-12-06 23:15:11 commState CMDs_done
2020-12-06 23:15:11 level 0
2020-12-06 22:39:21 peerList Rauchmelder_Team,
2020-12-06 22:57:56 powerOn 2020-12-06 22:57:56
2020-12-06 23:15:11 recentStateType info
2020-12-06 22:39:21 sdRepeat off
2020-12-06 23:15:11 smokeChamber ok
2020-12-06 22:55:37 smoke_detect none
2020-12-06 23:15:11 state off
2020-12-06 22:55:37 teamCall from HM_RM_TeamDev:07
helper:
HM_CMDNR 130
cSnd 0128076572A781010E,0128076572A781010E
mId 00AA
peerFriend peerSD
peerIDsRaw ,31126801,00000000
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
ack:
cmds:
TmplKey Rauchmelder_Team,:no:1607288991.63404
TmplTs 1607288991.63404
cmdKey 1:1:0::HM_72A781:00AA:01:Rauchmelder_Team,
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [({actor})]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_Rauchmelder_Team -tplPeer-
unpair noArg
lst:
condition Smoke Alarm,no alarm,tone off
peer Rauchmelder_Team
peerOpt remove_Rauchmelder_Team,HM_673520,HM_67352F,HM_673533,HM_72A624,HM_72A627,HM_72A73A
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +72A781,00,00,00
nextSend 1607292912.1634
rxt 0
vccu VCCU
p:
72A781
00
00
00
prefIO:
HMLANGW
mRssi:
mNo 82
io:
HMLANGW:
-52
-52
HMUSB:
-59
-59
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO HMUSB
flg A
ts 1607292911.77762
ack:
HASH(0x6c8e050)
82800228076572A78100
rssi:
HMLANGW:
avg -59.6666666666667
cnt 3
lst -62
max -58
min -62
at_HMLANGW:
avg -62.6666666666667
cnt 6
lst -58
max -58
min -68
at_HMUSB:
avg -54.6666666666667
cnt 6
lst -59
max -52
min -59
shadowReg:
tmpl:
Attributes:
IODev HMLANGW
IOgrp VCCU:HMLANGW
actCycle 099:00
actStatus alive
alias Rauchmelder_4
autoReadReg 5_readMissing
devStateIcon off:Wecker.Aus .*:Wecker.Immer
event-on-change-reading .*
expert defReg,rawReg
firmware 1.0
icon secur_smoke_detector
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,31126801,
room CUL_HM,Security
serialNr REQ1168770
subType smokeDetector
webCmd statusRequest
ich würde zunächst hminfo configcheck checken.
sind die sd2 neu oder gebraucht?
scheinbar gibt es ein aes problem, da aesCommToDev=pending.
könnte vielleicht mit dem aesCBCCounter problem aus dem sd-wiki zusammenhängen.
Hi,
ich meine mich zu erinnern: es könnte was mit dem aesCBCCounter zu tun haben.
Ich habe keine Lösung und kein Vorgehen dazu parat, aber vielleicht hilft das bei der weiteren Suche.
Gruß Otto
Besten Dank Euch beiden.
Die SD2 sind neu. das mit dem aesCommToDev=pending habe ich wahrgenommen. Interessanterweise tritt es aber bei einem den neuen nicht auf, aber auch dieser reagiert nicht.
Ich versuche mich mal mit diesen Stichworten weiter zu hangeln (aesCBCCounter).
EDIT:
Das werde ich demnächst probieren: https://forum.fhem.de/index.php?topic=94472.0,
also alle sieben Rauchmelder zurücksetzen auf Werkseinstellung.
Hatte beim Lesen des Threads doch so ein gewisses Déjà-vu.
Schade um die schöne Arbeit bisher - gibt es da keine elegantere Lösung? :o
klar, wie im wiki beschrieben. 8)
@frank: Damit meinst Du das langsame Hochzählen? Ich liebe diese präzisen Hinweise. Sei mir nicht böse, aber ich habe das Wiki gestern geschätzte 20 Mal dahingehend erfolglos versucht zu verstehen.
mein verständnis zum "hochzählen":
dein 1. versuch, da dein zähler bei 0000CE steht => 000100
setreading Rauchmelder_Team aesCBCCounter 000100
2. versuch: 000200
...
15. versuch: 000F00
16. versuch: 001000
17. versuch: 001100
Ich danke Dir. Ich hatte schon einen Blick darauf, bin aber (wie im oben zitierten Thread auch erwähnt wurde) davon ausgegangen, dass die neuen Melder sicher mit einer niedrigeren Zahl als die bereits seit einem Jahr im Betrieb befindlichen sein müsste. Daher hatte ich diese Ursache ausgeschlossen.
Zitat von: duke-f am 07 Dezember 2020, 13:57:14
Ich danke Dir. Ich hatte schon einen Blick darauf, bin aber (wie im oben zitierten Thread auch erwähnt wurde) davon ausgegangen, dass die neuen Melder sicher mit einer niedrigeren Zahl als die bereits seit einem Jahr im Betrieb befindlichen sein müsste. Daher hatte ich diese Ursache ausgeschlossen.
das hatte ich auch vermutet. daher die frage nach "gebraucht".
aber ein paar setreadings sind ein versuch wert.
ich würde eventuell auch grössere "stufen" probieren, da dein zitierter thread ja darauf deutet, dass der zähler sich grundsätzlich zurücksetzen lässt.
beim zurücksetzen, würde ich aber zunächst nur einen neuen sd probieren.
Ich hatte auch schon daran gedacht, ein zweites Team anzulegen für die neuen Melder. Dann weiß ich aber nicht, was ich mir dabei wieder einfange: Zwei Teams -> zwei TeamLeads -> zwei neue Probleme???
Zunächst versuche ich wahrscheinlich mal, den Generationenzähler um eins hochzusetzen. Ich hoffe ja nicht, bis in zehn Jahren dann schon auf 255 damit zu kommen....
Was ich vergaß zu beantworten: hm configCheck bringt keine Meldungen, scheint also alles ok zu sein.
... eine halbe Nacht später und eigentlich keinen Schritt weiter - bis auf ein deutlich hochgezähltes aesCBCCounter.
Auch das Rücksetzen und komlette Neueinrichten eines der neuen RM hat nichts gebracht.
Jetzt werde ich wohl in den sauren Apfel beißen und alle sieben RM komplett aus FHEM löschen - inklusive virtuellem TeamLead, alle rücksetzen und einen nach dem anderen wieder neu einrichten. Ist dabei die Reihenfolge die richtige?
1. virtueller TeamLead
2. ersten RM pairen
3. set erster_RM asignHmKey
4. ersten RM mit virtuellem TeamLead peeren
5. zweiten RM pairen
Bin ja neugierig, ob ich am Ende ein funktionsfähiges System oder 7 einzelne teure Rauchmelder außerhalb meines SmartHomes haben werde....
Bin jetzt nicht wirklich glücklich, muss ich zugeben.
...
EDIT:
Hat sich heute morgen doch etwas anders dargestellt: Gestern hatte ich ja alle sieben RM deaktiviert und nur den ersten der vier neuen eingeschaltet (durch Entfernen/Einsetzen der Befestigungsplatte). Diesen einen hatte ich resettet auf Werkseinstellungen und in FHEM komplett gelöscht. virtueller TeamLeader und alle anderen RM habe ich in FHEM gelassen. Dann habe ich diesen einen neu gepairt, assignHmKey gesetzt und gepeert mit dem TeamLead. hat zunächst einiges an Fehlern gemeldet im Eventmonitor, ich habe einige Male die Config abgefragt und einige Male den RM auf Pairingmode gesetzt, scheinbar erfolglos. Dann habe ich alles liegen lassen wie es war und siehe da: Heute morgen hat dieser auf teamCall des TeamLead tatsächlich reagiert.
Wenn sich das heute abend mit den verbleibenden drei so wiederholen lässt bleibt mir zumindest das Neuanlernen der alten drei und die Einrichtung des virtuellen TeamLead erspart. Wahrscheinlich hätte ich auch das Hochsetzen von aesCBCCounter nicht gebraucht. Das lief sowieso irgendwie seltsam: Der Generationenzähler steigt, aber der MessageCounter setzt da weiter an, wo er vor dem Hochsetzen stand. Steht er also auf 0001CE und ich setze manuell auf 000200 setzt er fort bei 0002CD. Aktuell stehe ich bei 0003F6 - hab' also noch gute 60 000 Generationen vor mir ;).
Was lerne ich daraus (sollte es heute abend wirklich mit den weiteren RM auch funktionieren)?
Entweder habe ich
- am WE beim ersten Einrichten etwas falsch gemacht (evtl. habe ich erst gepeert und dann versucht assignHmKey zu setzen - kann das falsch sein??) oder
- ich habe zu wenig Zeit zwischen dem Einstellen der vier RM gelassen und sie haben sich dann selber gestört (wurden aber alle ordnungsgemäß mit Seriennummer und allem erkannt - also wieder unwahrscheinlich) oder
- es haben sich alle sieben gegenseitig gestört. Irgendwie ist ja zuerst bei einigen einfach auch nach einem Tag das "pending" nicht verschwunden, das gibt es jetzt nicht mehr bei dem einen erfolgreichen.
Ich werde nun also immer alle außer einem ausschalten, bis dieser jeweils erfolgreich auf teamCall reagiert - hoffentlich klappt's.
Besten Dank nochmal für die Unterstützung.
in deinen lists habe ich nur hinweise auf den default key mit nr 00 gesehen.
warum machst du assignHmKey, wenn es gar keinen eigenen key gibt?
Hmmm ... gute Frage. Eigentlich fühle ich mir hier sicher, da meine Nachbarschaft überschaubar ist und ich keine Angriffe für Wahrscheinlich halte. Allerdings war ich mir nicht mehr sicher, ob ich nicht doch zu meinen Anfangszeiten von HM einen Key gesetzt hätte und hielt es daher für einen möglichen Fehler, dies eben nicht aufgerufen zu haben.
Nr. 00 habe ich gesehen, war aber nicht sicher, ob der erste Schlüssel vielleicht mit 0 gezählt wird. Danke dem Hinweis, dann versuche ich den nächste auch ohne assignHmKey. Fällt ein Punkt aus meiner Liste der Ursachensuche schon mal weg.
das löschen des fhem devices ist sicherlich auch unnötig, denn es ist ja nur das abbild des realen devices.
solange es automatisch von fhem erstellt wird, kann es nicht "defekt" sein.
es kann höchstens unvollständig sein, wenn noch daten fehlen. oder nicht mehr aktuell sein, wenn das reale device von aussen verändert wurde (zb reset durch knöpfchen drücken).
in jedem fall wird das fhem device immer aktualisiert, wenn neue daten in fhem eintreffen.
eventuell hatte sich etwas "verharkt" im realen device durch dass assignHmKey.
allerdings hätte sich dieses problem ja scheinbar selbst "geheilt".
ich würde vor dem nächsten reset des zweiten sd, erst noch eine "normale" kommunikation testen.
zb set getConfig.
erst wenn das funktioniert hat, nochmal den teamcall probieren.
Ja, hab ich gemacht, hat auch funktioniert. Trotzdem ging teamCall nicht. Auch ein versehentlicher Alarm am RM ausgelöst kam an. Heute Abend mache ich mich an den nächsten. Bin ja wieder optimistisch. Da ich mir zwischendurch immer wieder die Config sichere, vergleiche ich dann mal zwischen funktionierend und nicht-funktionierend. So gesehen halte ich auch einen Fehler im realen RM für durchaus möglich. Vielleicht auch dadurch verursacht, dass ich zu schnell nacheinander alle vier einrichten wollte.
meine letzte idee betrifft deine io.
es gibt ja mindestens 2.
eine normale kommunikation sendet fhem über das io, welches im fhem device über die attribute iodev/iogrp konfiguriert ist.
welches zuletzt verwendet wurde, ist im internal IODev zu sehen.
das senden des teamcall sollte aber im hauptdevice vom teamlead zu sehen sein.
es könnte also ein anderes io sein.
die sd müssen dieses io natürlich auch hören können.
in deinen lists, hatte der neue sd jedenfalls ein anderes io, als der alte funktionierende.
können alle sd beide io hören?
Ja, das können sie. Kann man ja auch im RSSI-Werten in den Internals sehen, beispielsweise aktuell für den neuen, funktionierenden:
HMLANGW_MSGCNT
93
HMLANGW_RAWMSG
050100498CA61072A781280765060100003D
HMLANGW_RSSI
-73
HMLANGW_TIME
2020-12-08 09:50:58
HMUSB_MSGCNT
92
HMUSB_RAWMSG
E72A781,0000,26EAA627,FF,FFBB,8CA61072A781280765060100003D
HMUSB_RSSI
-69
HMUSB_TIME
2020-12-08 09:50:58
Ist es nicht so, das bezüglich Team die SDs immer untereinander reden? Der Teamlead spendet doch nur die peer Id?
Oder ist Teamcall anders als Alarm?
Auszug aus dem Handbuch
ZitatJeder Rauchwarnmelder innerhalb eines Systems muss jeden
anderen Rauchwarnmelder des Systems und ggf. die Zentrale
erreichen können!
Mal den Teamcall vom Melder selbst probiert? Der sollte doch auch gehen? Abschnitt 7.2
Und dann spielen die SD2 doch auch Repeater Abschnitt 7.5 (https://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf)
Das habe ich auch so verstanden. Ich habe aber gestern noch nicht probiert, ob die RM untereinander kommunizieren (unabhängig von FHEM), diesen Teil der Doku hatte ich mir erst kurz vor dem Schlafen nochmal angesehen. Der virtuelle TeamLead existiert ja aber nur in FHEM und soll von da aus dann alle realen RM ansprechen. Es gibt auch in den settings zu den einzelnen RM gar kein alarmOn bzw alarmOff, das geht nur über den TeamLead.
Hab ich auch nicht gesagt :)
Der virtuelle Teamlead liefert eine peerID und die steht in den RM! Feuer geht ohne FHEM !!! und ich denke Teamcall auch? Unechter Alarm geht nur mit FHEM ;)
Ok, hab' ich falsch verstanden. Be(un)ruhigend zu wissen, dass Feuer auch ohne FHEM geht ....
Wie gesagt, Teamcall (in der Doku als Kommunikation bezeichnet) zwischen den RM habe ich noch nicht probiert. Gepeert sind sie ja eigentlich.
OT: Habe gesehen, dass sich die Auswahllisten bei peerSmart unterscheiden zwischen alten RM und funktionierendem neuen RM. Alter RM: Nur TeamLead taucht auf, neuer RM: TemaLead+alle 6 anderen RM tauchen auf. Solange es funktioniert, ist mir das ja egal.
EDIT (nochmal, mein Text ist gerade ins Nirvana verschwunden, daher jetzt nur kurz).
Der zweite neue lies sich jetzt auch einrichten, ohne dass er vorher in FHEM gelöscht wurde. @frank hatte wohl recht, dass sich im realen RM etwas verhakt haben muss. Wahrscheinlich hatte ich nicht genügend Zeit jedem für die vollständige Einrichtung gegeben und so kam etwas durcheinander. Jetzt habe ich alle anderen 6 stromlos gemacht und dann den einen resettet auf Werkseinstellung, dann neu gepaired, dann gepeered (vielleicht unnötig) und dann einige Male Status abgefragt und gewartet. Jetzt ist auch der über TeamCall aus FHEM heraus erreichbar.
@Otto123: Ja, stimmt, "Teamcall von einem RM aus geht auch außerhalb FHEM
Danke nochmal Euch beiden für die Geduld.