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:
Zitat
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):
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:
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
ist dein fensterkontakt nicht gepeert?
Zeichne einmal die messages (roh) auf und poste sie.
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.
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
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
Alles klar, Danke Dir!
Gruß Claudiu
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:
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