Hallo zusammen!
Ich habe mir eine HM-Innensirene zugelegt und in FHEM integriert. Anschließend über FHEM mit HM-SEC-SCo verbunden, um Alarm bei sich öffnenden Fenstern bzw. Türen auszulösen. Das hat mit 6 Kontakten reibungslos funktioniert. Allerdings macht ein Kontakt Probleme.
Das Peering ist erfolgt. Er ist allerdings nur in Innensirene "eingetragen". In seinen eigenen peerIDs ist überhaupt gar kein Eintrag. Auffällig ist auch, dass in den Readings unter den Punkten expectAES, peerNeedsBurst, cyclicInfoMsg und pairCentral die gleichen Eintragung wie bei allen anderen Kontakten stehen außer, dass überall "set_" davorsteht.
Bei aktivierter Sirene wird bei Öffnen dieses Fensters auch kein Alarm ausgelöst.
Kann mir jemand helfen?
Das set_ bedeutet, dass die Befehle noch "in Bearbeitung" sind.
Ich habe jetzt nicht genau verstanden wo die set_ sind aber dort mal das "Anlernknöpfchen" drücken bzw. prüfen, ob das besagte Gerät überhaupt korrekt GEPAIRED ist (R-PairCentral bzw. PairedTo dort muss die HMID stehen) ansonsten nimmt es keine Befehle an.
Lists der beteiligten Geräte würden mehr/besser helfen als zu beschreiben wo welche Readings etc. stehen oder fehlen.
Also mal ein list eines Fensterkontaktes der tut und des problematischen Fensterkontaktes und dann noch von der Sirene.
Also:
list DeviceName
in das FhemWeb-cmd und dann die Ausgabe hier in "code-Tags" posten (das '#' im Menü).
Gruß, Joachim
unter R-pairCentral steht ebenfalls "set_0x000041". Bei einem korrekt verbundenem Kontakt steht da nur 0x000041.
Der Sensor ist an einer Stelle, wo die Funkverbindung nicht besonders gut ist. Würde es was bringen, den Kontakt zu demontieren und die ganze Prozedur etwas näher am HMLAN1 durchzuführen?
Also das list vom defekten Kontaktes sieht so aus:
Internals:
DEF 5BED11
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG E5BED11,0000,003B8805,FF,FFA3,7C86105BED1100000006010000
HMLAN1_RSSI -93
HMLAN1_TIME 2019-01-01 15:26:16
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1
NAME FTK_Garage_Tuer
NOTIFYDEV global
NR 503
STATE closed
TYPE CUL_HM
lastMsg No:7C - t:10 s:5BED11 d:000000 06010000
protCmdPend 3 CMDs pending
protLastRcv 2019-01-01 15:26:16
protResnd 1 last_at:2019-01-01 15:26:21
protSnd 1 last_at:2019-01-01 15:26:16
protState CMDs_pending
rssi_at_HMLAN1 avg:-93 min:-93 max:-93 lst:-93 cnt:1
READINGS:
2019-01-01 14:57:48 Activity alive
2019-01-01 13:49:33 CommandAccepted yes
2019-01-01 13:49:42 D-firmware 1.0
2019-01-01 13:49:42 D-serialNr OEQ0707849
2019-01-01 13:51:15 R-Innensirene_Sen_01-expectAES set_off
2019-01-01 13:51:15 R-Innensirene_Sen_01-peerNeedsBurst set_on
2019-01-01 13:42:36 R-cyclicInfoMsg set_on
2019-01-01 13:35:44 R-pairCentral set_0x000041
2019-01-01 13:49:34 aesCommToDev pending
2019-01-01 13:49:34 aesKeyNbr 00
2019-01-01 15:26:16 alive yes
2019-01-01 15:26:16 battery ok
2019-01-01 15:26:16 contact closed (to broadcast)
2019-01-01 15:26:16 recentStateType info
2019-01-01 15:26:16 sabotageError off
2019-01-01 15:26:16 state closed
2019-01-01 13:48:02 trigDst_broadcast noConfig
2019-01-01 14:40:19 trigger_cnt 27
cmdStack:
++A0010000415BED1100040000000000
++A0010000415BED1101040000000001
++A0010000415BED110103
helper:
HM_CMDNR 125
getCfgList all
getCfgListNo ,4
mId 00C7
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5BED11,02,00,00
nextSend 1546352776.24045
rxt 2
vccu vccu
p:
5BED11
00
00
00
prefIO:
HMLAN1
mRssi:
mNo 7C
io:
HMLAN1 -91
prt:
bErr 0
sProc 2
wuReSent 2
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMLAN1:
avg -93
cnt 1
lst -93
max -93
min -93
tmpl:
Attributes:
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_door_right_open closed:fts_door_right
expert 2_raw
firmware 1.0
icon hue_filled_hds
model HM-SEC-SCo
peerIDs
room CUL_HM,FT_Kontakte
serialNr OEQ0707849
subType threeStateSensor
das eines inakten Kontakt so:
Internals:
DEF 5BE58D
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG E5BE58D,0000,0038286C,FF,FFBB,33A6105BE58D00004106010000
HMLAN1_RSSI -69
HMLAN1_TIME 2019-01-01 15:22:35
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1
NAME FTK_Kueche
NOTIFYDEV global
NR 515
STATE closed
TYPE CUL_HM
lastMsg No:33 - t:10 s:5BE58D d:000041 06010000
peerList Innensirene_Sen_01,
protLastRcv 2019-01-01 15:22:35
protSnd 1 last_at:2019-01-01 15:22:35
protState CMDs_done
rssi_at_HMLAN1 avg:-69 min:-69 max:-69 lst:-69 cnt:1
READINGS:
2019-01-01 14:57:48 Activity alive
2018-12-31 17:09:40 CommandAccepted yes
2018-12-31 17:09:40 D-firmware 1.0
2018-12-31 17:09:40 D-serialNr OEQ0705892
2018-12-31 17:09:41 PairedTo 0x000041
2018-12-31 17:00:17 R-Innensirene_Sen_01-expectAES off
2018-12-31 17:00:17 R-Innensirene_Sen_01-peerNeedsBurst on
2018-02-10 14:41:30 R-cyclicInfoMsg on
2018-02-10 16:30:38 R-eventDlyTime 0 s
2018-02-10 14:41:30 R-pairCentral 0x000041
2018-02-10 14:41:30 R-sabotageMsg on
2018-02-10 16:30:38 R-sign on
2018-12-31 17:09:41 RegL_00. 02:01 09:01 0A:00 0B:00 0C:41 10:01 14:06 00:00
2018-12-31 17:09:41 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2018-12-31 17:09:42 RegL_04.Innensirene_Sen_01 01:01 00:00
2018-12-31 17:09:40 aesCommToDev ok
2018-12-31 17:09:40 aesKeyNbr 00
2019-01-01 15:22:35 alive yes
2019-01-01 15:22:35 battery ok
2019-01-01 15:22:35 contact closed (to vccu)
2019-01-01 14:57:48 peerList Innensirene_Sen_01,
2019-01-01 15:22:35 recentStateType info
2019-01-01 15:22:35 sabotageError off
2019-01-01 15:22:35 state closed
2018-02-07 23:27:58 trigDst_broadcast noConfig
2018-12-31 21:47:01 trigger_cnt 204
helper:
HM_CMDNR 51
mId 00C7
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5BE58D,00,00,00
nextSend 1546352555.1909
rxt 2
vccu vccu
p:
5BE58D
00
00
00
prefIO:
HMLAN1
mRssi:
mNo 33
io:
HMLAN1 -67
prt:
bErr 0
sProc 0
sleeping 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMLAN1
flg A
ts 1546352555.11497
ack:
HASH(0x37cd2b0)
3380020000415BE58D00
rssi:
at_HMLAN1:
avg -69
cnt 1
lst -69
max -69
min -69
tmpl:
Attributes:
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 002:50
actStatus alive
alarmDevice Sensor
alarmSettings |||on
autoReadReg 4_reqStatus
devStateIcon closed:fts_window_1w open:fts_window_1w_tilt
expert 2_raw
firmware 1.0
icon hue_filled_hds
model HM-SEC-SCo
peerIDs 00000000,59630F01,
room CUL_HM,FT_Kontakte,Küche
serialNr OEQ0705892
subType threeStateSensor
Die RSSI Werte sind schon echt schlecht.
Also für das aktuelle Problem könnte näher bringen und ein paar mal das "Anlernknöpfchen" drücken (solange bis cmds_pending weg ist und auch die set_)...
Wird aber auf Dauer wohl problematisch bleiben (Vermutung).
Evtl. einen abgesetzten HMOD-PCB per WLAN: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi bzw. http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html
Und dann eine vccu (bzw. besser vorher falls nicht eh schon vorhanden): https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Solange der Fensterkontakt nicht sauber GEPAIRED ist (also statt set_ bei R-PairCentral die HMID) wird auch ein PEERING (Verbindung Sensor/Aktor) nicht funktionieren, da das Gerät keine Befehle annimmt bevor es nicht sauber GEPAIRED (mit Zentrale bzw. HMID verbunden) ist.
Gruß, Joachim
Hallo Joachim!
Ich habe den Kontakt demontiert, ihn in die Nähe des HMLAN gebracht und noch einmal gepaired. Anschließend dann erneut mit der Sirene gepeered. Nun ist alles in Ordnung und der Kontakt gibt die entsprechende Rückmeldung an die Sirene, wenn diese scharf geschaltet ist.
Vielen Dank für Deine Antworten und noch einen ruhigen Tag!
Gruß Sascha
Das Problem ist also gelöst!
Dieses Problem ja aber evtl. wegen schlechter Funkverbindung kommt wieder was...
Einfach mal noch mal drüber nachdenken, siehe meine Antwort/Links...
Tja, dann als gelöst "kennzeichnen", umbenennen in beispielsweise "[gelöst] HM-SEC-SCo; Set-Eintrag Readings"
Dann viel Spaß noch, Joachim
Die schlechte Lesbarkeit des SCo bezüglich FHEM scheint ja weniger das Problem zu sein und sagt auch nichts darüber, wie die Innensirene den Kontakt "sieht" - und weiteres Interface verbessert zwar den Kontakt zu FHEM, nicht aber zur Sirene...