HM-SEC-SCo; Set-Eintrag Readings

Begonnen von FHEM_Newone, 01 Januar 2019, 15:11:54

Vorheriges Thema - Nächstes Thema

FHEM_Newone

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?

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

FHEM_Newone

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?

FHEM_Newone

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

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

FHEM_Newone

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

FHEM_Newone


MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Pfriemler

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...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."