[gelöst] HM-SEC-SCo Über CUL in FHEM anbinden und Fragen

[rapster]

Hallo Zusammen,

nachdem ich nach stunden langem trial&error es endlich geschafft habe meine HM-SEC-SCo über einen CUL in FHEM einzubinden (gibt ja leider noch kein Wiki oder ähnliches) hier ein kleines HowTo dazu:

Hinweis: Nach jedem Schritt warten bis die LED am Fensterkontakt nicht mehr leuchtet/blinkt!

1. Sabotagekontakt auslößen (Deckel entfernen und weg lassen)
2. Fensterkontakt Resetten (>5sec Programmierkontakt drücken bis rot blinkt, anschließend nochmal >5sec Programmierkontakt drücken bis schnell rot blinkt)
3. Fensterkontakt an HM-Konfigurator anlernen. (Über HM-CFG-USB-2, HMLan, oder anderes AES fähiges HM-Gerät)
    (LED blinkt kurz langsam, anschließend dauerhaft schnell orange und quittiert mit andauernd grün)
4. Übertragungsmodus im HM-Konfigurator auf "Standard" stellen, und sobald "Servicemedlungen" orange aufleuchtet die Programmiertaste am Fensterkontakt drücken.
   (LED blinkt kurz langsam, anschließend dauerhaft schnell orange und quittiert mit andauernd grün)
5. Überprüfen: Nach einem Reload des HM-Konfigurator WebUI sollte jetzt nicht nur der Channel auf "Standard" stehen sondern auch das Device selber.
6. Das FHEM-IODev in den hmPairForSec Modus versetzen und Programmiertaste am Fensterkontakt betätigen.
    Es wird in FHEM über Autocreate ein Device definiert, allerdings wird das Pearing (noch) nicht abgeschlossen!
    (LED blink dauerhaft langsam orange)
7. Im HM-Konfigurator "Aktion=>Löschen=>Gerät ablernen" wählen und mit Löschen bestätigen.
    Nach der Meldung dass das Device nicht erreicht werden kann, den Fensterkontakt in den Programmiermodus versetzen (kurz Programmiertaste betätigen), und im HM-Konfigurator "Erneut Löschen" wählen.
    Im selben Moment wird die Device-definition von FHEM automatisch erweitert, allerdings wird das Pearing (noch) nicht abgeschlossen!
    (LED blinkt kurz langsam, anschließend dauerhaft schnell orange und quittiert mit andauernd grün)
8. Nach Abschluss des Löschvorgangs noch 1x kurz die Programmiertaste am Fensterkontakt betätigen und FHEM führt das restliche pairing des Gerätes durch.
    (LED blinkt kurz langsam, anschließend dauerhaft schnell orange und quittiert mit andauernd grün)
9. Sabotagekontakt schließen (deckel wieder aufsetzen)
(10.) Sollte nach erfolgreichem Pairing selbst nach wiederholtem getConfig (und Betätigung der Programmiertaste), das Reading "R-pairCentral bzw. PairedTo" auf dem Wert 0x0 stehen (bei mir bei 1 von 3 Fensterkontakten passiert), muss über folgenden Befehl noch die hmId manuell dem Fensterkontakt beigebracht werden. (Nach jedem Cmd welches den Fensterkontakt betrifft, Programmiertaste betätigen)
        set <FensterkontaktName> regSet pairCentral <hmId>
(11.) Anschließend kann der Fensterkontakt z.B. mit dem Heizkörper-Thermostat _WindowRec Channel gepeert werden (Nach jedem Cmd welches den Fensterkontakt betrifft, Programmiertaste betätigen):
        set <FensterkontaktName> peerChan 0 <HeizkoerperThermostat_WindowRec> single set
        (LED blinkt kurz langsam, anschließend dauerhaft schnell orange und quittiert mit andauernd grün)

Nun zu meiner Frage:

ein peerXref gibt mir folgende Warnings für die Fensterkontakte zurück (376xxx ist meine hmId):

Code Auswählen Erweitern


warning: sensor triggers but no config found
    og_bz_fensterkontakt triggers 376xxx
    og_ez_fensterkontakt triggers 376xxx
    og_sz_fensterkontakt triggers 376xxx


Nach einem clear triggers sind diese zwar verschwunden, sobald allerdings der fensterkontakt nächstes mal eine Zustandänderung bemerkt (Fenster auf/zu) sind die warnings wieder da.

Kann hier jemand helfen?

Hier noch ein list des Fensterkontakts:

Code Auswählen Erweitern


fhem> list og_ez_fensterkontakt
Internals:
   CFGFN      ./FHEM/devices.cfg
   CUL1_MSGCNT 19
   CUL1_RAWMSG A0C56A6412D9745376xxx012100::-57.5:CUL1
   CUL1_RSSI  -57.5
   CUL1_TIME  2014-11-07 01:58:27
   DEF        2D9745
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     19
   NAME       og_ez_fensterkontakt
   NR         56
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:56 - t:41 s:2D9745 d:376xxx 012100
   peerList   og_ez_heizkoerper_WindowRec,og_ez_wandthermostat_WindowRec,
   protLastRcv 2014-11-07 01:58:27
   protSnd    7 last_at:2014-11-07 01:58:27
   protState  CMDs_done
   rssi_at_CUL1 lst:-57.5 max:-57.5 cnt:19 min:-63.5 avg:-60.6
   Readings:
     2014-11-07 01:36:51   Activity        alive
     2014-11-06 23:34:05   CommandAccepted yes
     2014-11-06 23:34:04   D-firmware      1.0
     2014-11-06 23:34:04   D-serialNr      LEQ0922163
     2014-11-06 23:34:05   PairedTo        0x376xxx
     2014-11-06 23:27:04   R-cyclicInfoMsg on
     2014-11-05 22:35:08   R-eventDlyTime  0 s
     2014-11-06 23:27:04   R-msgScPosA     open
     2014-11-06 23:27:04   R-msgScPosB     closed
     2014-11-06 23:27:05   R-og_ez_heizkoerper_WindowRec-expectAES off
     2014-11-06 23:27:05   R-og_ez_heizkoerper_WindowRec-peerNeedsBurst on
     2014-11-06 23:27:05   R-og_ez_wandthermostat_WindowRec-expectAES off
     2014-11-06 23:27:05   R-og_ez_wandthermostat_WindowRec-peerNeedsBurst on
     2014-11-06 23:27:04   R-pairCentral   0x376xxx
     2014-11-06 23:27:04   R-sabotageMsg   on
     2014-11-06 23:27:04   R-sign          off
     2014-11-06 23:27:04   R-transmDevTryMax 6
     2014-11-06 23:27:04   R-transmitTryMax 6
     2014-11-06 23:34:05   RegL_00:        02:00 09:01 0A:37 0B:65 0C:14 10:01 14:06 00:00
     2014-11-06 23:34:05   RegL_01:        08:00 20:9C 21:00 30:06 00:00
     2014-11-06 23:34:06   RegL_04:og_ez_heizkoerper_WindowRec 01:01 00:00
     2014-11-06 23:34:06   RegL_04:og_ez_wandthermostat_WindowRec 01:01 00:00
     2014-11-07 01:34:23   alive           yes
     2014-11-07 01:58:27   battery         ok
     2014-11-07 01:58:27   contact         closed (to vccu)
     2014-11-07 01:24:11   peerList        og_ez_heizkoerper_WindowRec,og_ez_wandthermostat_WindowRec,
     2014-11-07 01:34:23   recentStateType info
     2014-11-07 01:34:23   sabotageError   off
     2014-11-07 01:58:27   state           closed
     2014-11-07 01:58:27   trigDst_vccu    noConfig
   Helper:
     mId        00C7
     rxType     28
     Io:
       newChn     +2D9745,00,01,1E
       nextSend   1415321907.72824
       prefIO
       rxt        2
       vccu       vccu
       p:
         2D9745
         00
         01
         1E
     Mrssi:
       mNo        56
       Io:
         CUL1       -55.5
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL1
       flg        A
       ts         1415321907.62893
       ack:
         HASH(0x4d5f548)
         568002376xxx2D97450101C800
     Rssi:
       At_cul1:
         avg        -60.6052631578947
         cnt        19
         lst        -57.5
         max        -57.5
         min        -63.5
     Shadowreg:
Attributes:
   IODev      CUL1
   IOgrp      vccu
   actCycle   000:50
   actStatus  alive
   alias      EZ_Fensterkontakt
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-SEC-SCo
   peerIDs    00000000,2B745D03,31FE9003,
   serialNr   LEQ0922163
   subType    threeStateSensor

fhem>



Gruß Claudiu

[martinp876]

ist dein fensterkontakt nicht gepeert?
Zeichne einmal die messages (roh) auf und poste sie.

[rapster]

Hallo Martin,

Danke für die schnelle Rückmeldung, und die Lösung

Habe die Fensterkontakte nun zusätzlich zum HeizkörperThermostat & WandThermostat noch mit einem virtuellen Channel der vccu gepeert.
Warnungen werden nun keine mehr ausgegeben, und alles funktioniert!

Noch eine Grundsatzfrage: Sollte man eigentlich Taster/Sensor/Sender (Aktoren?) grundsätzlich mit einem vccu-Channel peeren, oder nur wenn Probleme wie diese auftreten?


Hier trotzdem noch die Roh Messages (vor dem peeren mit der vccu) eines Fensterkontaktes beim öffnen und gleich wieder schließen falls für irgendwas nützlich.

Code Auswählen Erweitern


2014.11.07 01:50:22.366 4: CUL_Parse: CUL1 A 0C 45 B641 2D9745 2B745D 011CC819 -61.5
2014.11.07 01:50:22.493 4: CUL_Parse: CUL1 A 0A 45 8002 2B745D 2D9745 0029 -53.5
2014.11.07 01:50:22.638 4: CUL_Parse: CUL1 A 0C 46 A241 2D9745 31FE90 011CC815 -63.5
2014.11.07 01:50:22.764 4: CUL_Parse: CUL1 A 0A 46 8002 31FE90 2D9745 0029 -53.5
2014.11.07 01:50:22.909 4: CUL_Parse: CUL1 A 0C 47 A641 2D9745 376514 011CC816 -63
2014.11.07 01:50:23.010 4: CUL_send:  CUL1As 0D 47 8002 376514 2D9745 0101C800
2014.11.07 01:50:24.860 4: CUL_Parse: CUL1 A 0C 48 B641 2D9745 2B745D 011D001C -60
2014.11.07 01:50:24.987 4: CUL_Parse: CUL1 A 0A 48 8002 2B745D 2D9745 0029 -53.5
2014.11.07 01:50:25.132 4: CUL_Parse: CUL1 A 0C 49 A241 2D9745 31FE90 011D001C -60
2014.11.07 01:50:25.259 4: CUL_Parse: CUL1 A 0A 49 8002 31FE90 2D9745 0029 -53.5
2014.11.07 01:50:25.404 4: CUL_Parse: CUL1 A 0C 4A A641 2D9745 376514 011D001C -60
2014.11.07 01:50:25.504 4: CUL_send:  CUL1As 0D 4A 8002 376514 2D9745 0101C800


Gruß Claudiu

[martinp876]

Man muss nicht zwingend mit einer vccu peeren.
In diesem speziellen fall kann ich nicht erkennen, wie ich es filtern koennte. Peeren loest es dabei am einfachsten

[rapster]

Alles klar, Danke Dir!

Gruß Claudiu

[JayP]

Hallo,

ich habe leider keinen HM-CFG-USB- oder, HMLan.
Bekomme ich den HM-SEC-SCo trotzdem irgendwie gepaired?

Bei mir bleibt PairedTo immer auf set_0xB89B12 stehen.

List:

Code Auswählen Erweitern

Internals:
   DEF        4E4F36
   IODev      CUL868
   NAME       HM_4E4F36
   NOTIFYDEV  global
   NR         303
   NTFY_ORDER 50-HM_4E4F36
   STATE      closed
   TYPE       CUL_HM
   Readings:
     2016-11-14 14:01:03   Activity        alive
     2016-11-10 23:19:27   CommandAccepted yes
     2016-11-13 20:58:07   D-firmware      1.0
     2016-11-13 20:58:07   D-serialNr      BLUBB
     2016-11-10 23:18:06   PairedTo        set_0xB89B12
     2016-11-10 23:18:06   R-cyclicInfoMsg on
     2016-11-10 23:18:06   R-eventDlyTime  0 s
     2016-11-10 23:19:55   R-pairCentral   set_0xB89B12
     2016-11-10 23:18:06   R-sabotageMsg   on
     2016-11-10 23:18:06   R-sign          on
     2016-11-10 23:19:27   aesCommToDev    ok
     2016-11-10 23:19:28   aesKeyNbr       00
     2016-11-14 13:50:09   alive           yes
     2016-11-14 13:50:09   battery         ok
     2016-11-14 13:50:09   contact         closed (to VCCU)
     2016-11-14 13:50:09   recentStateType info
     2016-11-14 13:50:09   sabotageError   off
     2016-11-14 13:50:09   state           closed
     2016-11-14 09:43:05   trigger_cnt     95
   Helper:
     HM_CMDNR   1
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4E4F36,00,01,00
       prefIO
       rxt        2
       vccu
       p:
         4E4F36
         00
         01
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Tmpl:
Attributes:
   IODev      CUL868
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       CUL_HM
   serialNr   BLUBB
   subType    threeStateSensor