Rauchmelder Problem

[Blebbens]

Hi,

Ich glaube, irgendetwas habe ich nicht verstanden...:

Code Auswählen Erweitern

DEF 10001001
NAME Sdteam
NR 69
STATE NACK
TESTNR 3
TYPE CUL_HM
chanNo 01
device TeamDev
peerList OG_FLUR_RM3,DG_FLUR_RM4,UG_FLUR_RM2,EG_WZ_RM1
sdTeam sdLead

peerList OG_FLUR_RM3,DG_FLUR_RM4,UG_FLUR_RM2,EG_WZ_RM1,


Ich habe den Sdteam mit den Rauchmeldern nun gepeert.
Aber den teamCall kann ich nicht auslösen... auch keinen Alarm.

Wo liegt denn noch mein Fehler, kann jemand kurz helfen ?
Würde am liebsten alles von Beginn an per Wiki neu probieren, es ist aber halt schon soviel gepaart und verändert.

[martinp876]

der Team sieht gut aus - aber wie sieht der SD aus? Kannt du ein List eines der SDs schicken? evtl ein getConfig vorher ausführen (zur Sicherheit)

[Blebbens]

Code Auswählen Erweitern


DEF
23418D
IODev
hmusb
LASTInputDev
hmusb
MSGCNT
2
NAME
EG_WZ_RM1
NR
41
STATE
off
TYPE
CUL_HM
hmusb_MSGCNT
2
hmusb_RAWMSG
RBF610151,0001,149C0D54,FF,FFCC,03A01023418D4242420601000035
hmusb_RSSI
-52
hmusb_TIME
2014-06-21 19:02:24
lastMsg
No:03 - t:10 s:23418D d:424242 0601000035
peerList
OG_FLUR_RM3
protCmdPend
1 CMDs pending
protLastRcv
2014-06-21 19:02:24
protSnd
3 last_at:2014-06-21 21:08:40
protState
CMDs_processing...
rssi_at_hmusb
avg:-52 min:-52 max:-52 lst:-52 cnt:2
rssi_hmusb
avg:-53 min:-53 max:-53 lst:-53 cnt:1


Code Auswählen Erweitern


Activity
alive
2014-06-21 19:02:20
CommandAccepted
no
2014-06-21 18:06:12
D-firmware
1.0
2014-06-01 17:38:05
D-serialNr
KEQ0708084
2014-06-01 17:38:05
PairedTo
0x424242
2014-06-21 18:06:16
R-pairCentral
0x424242
2014-06-21 21:08:40
RegL_00:
battery
ok
2014-06-21 19:02:24
level
0
2014-06-21 19:02:24
peerList
OG_FLUR_RM3,
2014-06-21 19:02:20
recentStateType
info
2014-06-21 19:02:24
state
off
2014-06-21 19:02:24


Kann man das so lesen? Geht derzeit leider nicht besser von unterwegs aus. Hoffe, es hilft, dort muss ja ein Fehler liegen.

[Mr. P]

Da sieht man allerdings ein paar Dinge.

*) Es handelt sich um das Gerät 'EG_WZ_RM1'.
*) Pairing mit der Zentrale passt.
*) Sollte dieses mit dem virtuellen Lead gepeert sein.
*) Es ist aber mit 'OG_FLUR_RM3' gepeert.
*) Scheint FHEM irgendeine Nachricht (1 CMDs pending) an den 'EG_WZ_RM1' loswerden zu wollen, was ihm aber nicht gelingt. Hier hilft vielleicht Druck auf den Config-Button vom SD. Wenn alles gut ist, sollte 'CMDs_done' erscheinen.
*) Im virtuellen Lead sind zwar die Peerings zu den einzelnen SDs eingetragen, aber die Konfiguration dürfte sich noch nicht zu den Geräten durchgesprochen haben. Anders gesagt: Du hast zwar das Peering durchgeführt, aber die Geräte wissen nichts davon.

Versuche zuerst einmal das Peering zwischen den SDs loszuwerden. Dies ist notwendig, damit du sie dem neuen Team hinzufügen kannst. Wenn die peerListen leer sind (leer bedeutet: peerIDs    00000000), mach anschließend noch ein getConfig auf den SD um die Config nochmals zu aktualisieren und sicher zu gehen, dass alles so ist, wie es sein soll und kontrolliere nochmals die Register.
Danach nochmal neu peeren.
Aber mach mal ein Gerät nach dem anderen. Erst wenn das eine tut, wie es soll, ist das Nächste dran.
Wichtig beim Peering hier ist immer, dass du in beiden peerListen der Geräte jeweils den Partner eingetragen haben musst. Vorher ist es nicht abgeschlossen und wird nicht funktionieren.

[Blebbens]

Ok, ich muss also die einzelnen Rauchmelder selbst in fhem unpeeren, da sie zur Zeit untereinander, aber eben nicht mit Sdteam (Teamlead) gepeert sind.

Nun finde ich den Befehl unpair, nicht aber so etwas wie unpeer.

Oder, unter den peerIDs ist folgendes eingetragen:
peerIDs 00000000,2339DB01

Müsste ich nicht einfach deleteattr zu diesen peerIDs sagen und anschließend ein peerChan zum Sdteam anlegen ?
Oder verstehe ich das falsch ?

Der Unpeer funktioniert nämlich nicht:
set EG_WZ_RM1 peerChan 0 OG_FLUR_RM3 single unset

fhem antwortet mit: "use - single [set|unset] actor - for smoke detector"

[marc2]

Hi !

Geht mit wie gewohnt mit "peerChan" aber "unset"  statt "set"

Gruß, Marc

[Blebbens]

Ne,
bei set EG_WZ_RM1 peerChan 0 OG_FLUR_RM3 single unset meckert fhem
bei set EG_WZ_RM1 peerChan 0 OG_FLUR_RM3 unset meckert fhem

Möchte doch den peer zwischen den Rauchmeldern lösen und jeweils den Peer zum Teamlead einstellen.

[marc2]

Also ich verstehe zwar nicht, warum der default "both" beim SD nicht zieht, aber folge doch einfach dem
Rat der Fehlermeldung und spendiere ein "actor" ....

Wenn das nicht hilft, würde ich die Dinger von der Decke reißen, kurz resetten und neu mit FHEM pairen.
Da FHEM die SDs noch kennt, bleiben die Einstellungen erhalten (room, etc). Du musst hinterher nur
gemäß Wiki neu mit dem Lead peeren.

Gruß, Marc

[Blebbens]

Hm, möchte doch einfach nur unpeeren... das muss doch gehen...
Warum funktioniert nicht: "set EG_WZ_RM1 peerChan 0 OG_FLUR_RM3 single unset"
Ist der Befehl falsch ? Der Peer besteht zwischen den obigen beiden Rauchmeldern.

Code Auswählen Erweitern

DEF 23418D
IODev hmusb
LASTInputDev hmusb
MSGCNT 2
NAME EG_WZ_RM1
NR 41
STATE off
TYPE CUL_HM
hmusb_MSGCNT 2
hmusb_RAWMSG RC4ABFDEE,0001,19E707A3,FF,FFCB,03A01023418D4242420601000035
hmusb_RSSI -53
hmusb_TIME 2014-06-22 19:42:24
lastMsg No:03 - t:10 s:23418D d:424242 0601000035
peerList OG_FLUR_RM3
protLastRcv 2014-06-22 19:42:24
protSnd 2 last_at:2014-06-22 19:42:24
protState CMDs_done
rssi_at_hmusb avg:-53 min:-53 max:-53 lst:-53 cnt:2
rssi_hmusbavg: -53 min:-53 max:-53 lst:-53 cnt:1

[marc2]

Wie gesagt, probier mal ein

Code Auswählen Erweitern

set EG_WZ_RM1 peerChan 0 OG_FLUR_RM3 single unset actor

Gruß, Marc

[Blebbens]

Der Befehl wird angenommen, wenn auch (nach getConfig) weiterhin die alte peerID ausgewiesen wird?!
Versuche dann das Peering zum Sdteam...

Aber, sagt mal, sollte fhem mal ausfallen, müssen die Rauchmelder ja dennoch untereinander funken können. Dazu hatte ich diese vor fhem mal miteinander bekannt gemacht. Das bleibt weiterhin bestehen?

Ich habe die einzelnen Rauchmelder nun mit dem Teamlead "Sdteam" geleert mit:
set EG_WZ_RM1 peerChan 0 Sdteam single set actor (für jeweils jeden der vier Rauchmelder)

Dann sieht es nach 2 Minuten folgendermaßen aus (ohne gleich getConfig auszuführen) für einen Melder aus dem Dachgeschoss:

Code Auswählen Erweitern

DEF 2339F6
IODev hmusb
LASTInputDev hmusb
MSGCNT 14
NAME DG_FLUR_RM4
NR 48
STATE off
TYPE CUL_HM
hmusb_MSGCNT 14
hmusb_RAWMSG RC52B02E0,0001,1A660A51,FF,FFC2,25A0102339F6424242012339DB0100000000
hmusb_RSSI -62
hmusb_TIME 2014-06-22 22:01:08
lastMsg No:25 - t:10 s:2339F6 d:424242 012339DB0100000000
peerList OG_FLUR_RM3
protLastRcv 2014-06-22 22:01:08
protSnd 14 last_at:2014-06-22 22:01:08
protState CMDs_done
rssi_at_hmusb avg:-62 min:-62 max:-62 lst:-62 cnt:14
rssi_hmusb avg:-61 min:-61 max:-61 lst:-61 cnt:1

Code Auswählen Erweitern

Activity alive
2014-06-22 19:42:20
CommandAccepted no 2014-06-21 18:05:45
D-firmware 1.0 2014-06-01 17:47:47
D-serialNr KEQ0711668 2014-06-01 17:47:47
PairedTo 0x424242 2014-06-22 22:01:08
R-pairCentral 0x424242 2014-06-22 20:08:47
RegL_00: 02:01 0A:42 0B:42 0C:42 00:00 2014-06-22 22:01:08
battery ok 2014-06-22 19:42:23
level 0
2014-06-22 19:42:23
peerList OG_FLUR_RM3, 2014-06-22 22:01:08
recentStateType info 2014-06-22 19:42:23
state off 2014-06-22 19:42:23
teamCall from TeamDev:1

Code Auswählen Erweitern

IODev hmusb deleteattr
actCycle 099:00 deleteattr
actStatus alive deleteattr
autoReadReg 4_reqStatus deleteattr
devStateIcon off:general_ok *:secur_alarm deleteattr
event-on-change-reading .* deleteattr
expert 2_full deleteattr
firmware 1.0 deleteattr
icon secur_smoke_detector deleteattr
model HM-SEC-SD deleteattr
msgRepeat 1 deleteattr
peerIDs 00000000,2339DB01 deleteattr
room CUL_HM deleteattr
serialNr KEQ0711668 deleteattr
subType smokeDetector deleteattr
webCmd statusRequest

Wäre super, wenn jemand schaut, ob das so okay ist. Mich verwirrt zumindest die peerID.

[martinp876]

sollte in Wiki erklärt sein:
alle SD wird an einen "teamLead" gepeert.
Wenn einer einen Alarm erkennt sendet er als teamlead einen Alarm und alle SDs die diese ID eingetragen haben heulen
FHEM  muss nicht laufen, auch wenn der Teamlead ein virtueller ist.

[Blebbens]

Okay, im Beitrag der c't stand, dass man vor fhem die Melder untereinander peeren muss, falls fhem mal ausfällt.

Nun bin ich nicht daheim, aber sehen alle obige zitierte Readings etc gut aus? Mich verwirrt noch die doppelte peerID.

[Pfriemler]

Mich verwirrt noch die doppelte peerID.

Ich sehe keine doppelte? Der von Dir zitierte DG_FLUR_RM4 ist aktuell gepeert mit OG_FLUR_RM3 (Reading "peerList"), in den Attributes taucht unter "peerIDs" neben der immer vorhandenen 00000000 noch die 2339DB01 auf, also Channel 1 vom 2339DB - was Du im Internal DEF" von  OG_FLUR_RM3 wiederfinden solltest, d.h. peerIDs nennt immer die FHEM-internen ID-Nummern, in peerList steht der übersetzte Name des Device(channels). OK?

[Blebbens]

Als etwas abstrakt empfinde ich es schon.

Mein Teamlead "Sdteam" listet nun die einzelnen SDs in der peerlist auf.
Der SD OG_Flur_RM3 meldet peerList self01, auch sagt er Teamcall from TeamDev... Aber ich höre keinen der Melder auf den CLl reagieren.

Dahingegen ist ein weiterer SD namens DG_Flur_RM4 zum SD OG_Flur_RM3 gepeert lt. Peerlist.

Mir ist noch schleierhaft, warum in den peerLists unterschiedliche Peerings stehen und warum die SD den teamCall sehen, aber nicht piepen. Und, muss die peerID 000000 nicht raus?

PeerIDs des Teamleads lauten...

Code Auswählen Erweitern

peerIDs 2339DB01,2339F601,233B6C01,23418D01
peerList OG_FLUR_RM3,DG_FLUR_RM4,UG_FLUR_RM2,EG_WZ_RM1,

So ganz verstehe ich noch nicht, was dann bei den einzelnen Meldern genau stehen muss unter PeerList und PeerID und was dort nicht stehen darf.