Hallo Leute,
ich habe in meinem SmartHome mittlerweile einige HomeMatic Aktoren installiert die auch funktionieren. Ich habe das direkt über HMLAN gemacht. Jetzt habe ich zwischenzeitlich oft gelesen, dass man das über eine VCCU machen soll. Also habe ich das testweise für einen neuen Fensterkontakt aufgesetzt.
Ich habe autocreate=1 und in der fhem.cfg sieht das ganze jetzt so aus:
define VCCU CUL_HM XXXXXX
attr VCCU IODev meinLGW:keepAlive
attr VCCU IOList myLGW
attr VCCU expert 2_raw
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
define HM_XXXXXX CUL_HM XXXXXX
attr HM_XXXXXX IODev meinLGW:keepAlive
attr HM_XXXXXX actCycle 002:50
attr HM_XXXXXX actStatus alive
attr HM_XXXXXX autoReadReg 4_reqStatus
attr HM_XXXXXX expert 2_raw
attr HM_XXXXXX firmware 1.0
attr HM_XXXXXX model HM-SEC-SCo
attr HM_XXXXXX room CUL_HM
attr HM_XXXXXX serialNr XXXXXXXXXX
attr HM_XXXXXX subType threeStateSensor
define FileLog_HM_XXXXXX FileLog ./log/HM_XXXXXX-%Y.log HM_XXXXXX
attr FileLog_HM_XXXXXX logtype text
attr FileLog_HM_XXXXXX room CUL_HM
Ist das so korrekt? Ich kann an dem Fensterkontakt keinen Unterschied zu anderen (HMLAN) Fensterkontakten erkennen, außer
attr HM_XXXXXX IODev meinLGW:keepAlive.
Heißt das dass dieser Fensterkontakt jetzt über die VCCU läuft? Oder woran kann man das erkennen?
Außerdem ist mir gerade folgendes aufgefallen:
attr VCCU IOList myLGW
Müsste das nicht "meinLGW" sein (so heißt mein HMLAN)?
Grüße,
Eddy
Hallo Eddy,
in die IOList sollten die vorhandenen Devices eingetragen werden. Es ist eher seltsam, dass der FK überhaupt angelegt wurde.
Er läuft jedenfalls nicht über die VCCU, sonst müßte dort das attr <dev> IOgrp <vccu>:<preferredIO>korrekt gesetzt sein bzw. überhaupt vorhanden.
Wenn du die VCCU "testen" willst, also erst mal die IOList korrigieren, dann an dem FK die IOgrp ergänzen (VCCU sollte genügen).
Dann sollte am Gerät nach einem Senden ein "(to VCCU)" zu sehen sein.
Wenn das paßt, kannst du das attr direkt mit einem einzigen Befehl für alle CUL_HM-Devices ausrollen. Als Denkanstoß dazu: list TYPE=CUL_HM
Gruß, Beta-User
Hi Eddi,
hier ist alles beschrieben -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
myLGW hat der Pumuckel in deine DEF geschrieben?
Gruß Otto
ZitatmyLGW hat der Pumuckel in deine DEF geschrieben?
Vermutlich nicht. Das muss eher in geistiger Abwesenheit passiert sein. Danke für den Hinweis :o
Es ist übrigens einfach alles auf eine VCCU umzuziehen - man muss nichts neu machen. Wenn Du nicht klar kommst dann fragen :)
Gruß Otto
Zitat von: Beta-User am 10 November 2017, 09:21:11
Wenn du die VCCU "testen" willst, also erst mal die IOList korrigieren, dann an dem FK die IOgrp ergänzen (VCCU sollte genügen).
Dann sollte am Gerät nach einem Senden ein "(to VCCU)" zu sehen sein.
So, jetzt konnte ich das testen. Ich habe einen neuen FK angelernt. Das hat jetzt super geklappt. Jetzt steht das auch "to VCCU". Allerdings habe ich auch versucht einen vorhandenen FK mit der VCCU zu koppeln. Dazu bin ich folgendermaßen vorgegangen.
attr HM_XXXXXX IOgrp VCCU:meinLGWIch bekomme im LOG- File allerdings immer noch den Zusatz "to brodcast". Es scheint hier also nicht geklappt zu haben.
define Tuer_Wohnzimmer_Wintergarten_EG CUL_HM XXXXXX
attr Tuer_Wohnzimmer_Wintergarten_EG IODev meinLGW
attr Tuer_Wohnzimmer_Wintergarten_EG IOgrp VCCU:meinLGW
attr Tuer_Wohnzimmer_Wintergarten_EG actCycle 028:00
attr Tuer_Wohnzimmer_Wintergarten_EG actStatus alive
attr Tuer_Wohnzimmer_Wintergarten_EG autoReadReg 4_reqStatus
attr Tuer_Wohnzimmer_Wintergarten_EG expert 2_raw
attr Tuer_Wohnzimmer_Wintergarten_EG firmware 2.4
attr Tuer_Wohnzimmer_Wintergarten_EG model HM-SEC-SC-2
attr Tuer_Wohnzimmer_Wintergarten_EG room EG_Wohnzimmer
attr Tuer_Wohnzimmer_Wintergarten_EG serialNr XXXXXXXXXXX
attr Tuer_Wohnzimmer_Wintergarten_EG subType threeStateSensor
Hat jemand eine Idee woran das noch liegen kann? Würde ungern alle Autoren neu anlernen.
mach mal ein list Tuer_Wohnzimmer_Wintergarten_EG
Ich glaube der Eintrag to broadcast ist nicht ungewöhnlich.
Gruß Otto
Internals:
DEF XXXXXX
IODev meinLGW
LASTInputDev meinLGW
MSGCNT 10
NAME Tuer_Wohnzimmer_Wintergarten_EG
NOTIFYDEV global
NR 70
STATE closed
TYPE CUL_HM
lastMsg No:14 - t:41 s:559BB8 d:000000 010D00
meinLGW_MSGCNT 10
meinLGW_RAWMSG 0500003B148441559BB8000000010D00
meinLGW_RSSI -59
meinLGW_TIME 2017-11-10 20:30:04
protCmdPend 3 CMDs_pending
protLastRcv 2017-11-10 20:30:04
protState CMDs_pending
rssi_at_meinLGW avg:-59.3 max:-56 cnt:10 lst:-59 min:-63
Readings:
2017-11-10 15:38:26 Activity alive
2017-11-02 21:45:04 D-firmware 2.4
2017-11-02 21:45:04 D-serialNr XXXXXXXXXX
2017-11-02 22:33:23 alive yes
2017-11-10 20:30:04 battery ok
2017-11-10 20:30:04 contact closed (to broadcast)
2017-11-02 22:33:23 recentStateType info
2017-11-02 22:33:23 sabotageError on
2017-11-10 20:30:04 state closed
2017-11-10 20:30:04 trigger_cnt 13
cmdStack:
++A001123123559BB800040000000000
++A001123123559BB801040000000001
++A001123123559BB80103
Helper:
HM_CMDNR 20
getCfgList all
getCfgListNo ,4
mId 00B1
rxType 28
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +559BB8,02,00,00
nextSend 1510342204.38209
rxt 2
vccu VCCU
p:
559BB8
00
00
00
prefIO:
meinLGW
Mrssi:
mNo 14
Io:
meinLGW -57
Prt:
bErr 0
sProc 2
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_meinlgw:
avg -59.3
cnt 10
lst -59
max -56
min -63
Attributes:
IODev meinLGW
IOgrp VCCU:meinLGW
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.4
model HM-SEC-SC-2
room EG_Wohnzimmer
serialNr XXXXXXXXXX
subType threeStateSensor
Der ist nicht gepairt. FHEM kennt ihn zwar und Du siehst den Status.
protCmdPend 3 CMDs_pending die musst Du abarbeiten.
Configtaster drücken ohne den Sensor auszulösen, notfalls mehrfach mit Pausen!
Zeit nehmen! Nicht sinnlos reset machen!
Pairing wiederholen.
eventuell msgEvents löschen und wiederholen.
Gruß Otto
Vielen Dank für den Hinweis. Ich habe mittlerweile alle Geräte gelöscht und neu angelernt. Jetzt sieht alles sauber aus.
Ich denke das sollte jetzt so alles passen.