Hallo zusammen,
man liest hier immer öfter, dass eine VCCU genutzt wird.
Im Wiki steht Eine vccu sollte immer angelegt werden.
Nun stelle ich mir auch nach stöbern im Forum, als auch die Wiki Seite die Frage, wozu diese eigentlich sein soll und was der Vorteil ist?
Derzeit läuft mein System mittels HM LAN und HM Sensoren/Aktoren abgesehen von ein paar Missing ack recht stabil.
Und getreu dem Motto "Never touch a running system" würde ich nun eigentlich keine VCCU einsetzen wollen.
Aber wenn dies empfohlen wird, werde ich dem natürlich folgen.
Aber auch da ist es für mich noch nicht ganz klar, wie die Implementierung aussieht.
Definition der VCCU ist klar, aber dann?
Muss jetzt den Devices (und auch virtuelle Devices?) überall die IOgrp gesetzt werden?
So eine Art Kochrezept "Von einem HM System ohne VCCU zu einem mit VCCU - für Dummies" wäre ggf mit ein paar Beispielen doch hilfreich. Denn für mich hört sich die VCCU mal nach etwas zentralem an.
Einen schönen Sonntag noch.
In einem anderen Beitrag wurde mir die Zuweisung von IOgrp beim Device empfohlen. Weiterhin ist dem VCCU eine IOList mit Verweis auf die CUL zu geben. Außer, dass ich das Konzept einer VCCU halbwegs verstanden, und Du wohl auch die gleichen Quellen gelesen hast, kann ich dir keine Vor- oder Nachteile aus eigener Erfahrung nennen. Ich kann nur sagen, dass auch mit einer VCCU alles mindestens genausogut funktioniert wie zuvor auch. Es schadet also nicht. ;) Ein wenig ausprobieren und mit anderen die Erfahrung austauschen ist die Aktion wert. ;D
ZitatUnd getreu dem Motto "Never touch a running system" würde ich nun eigentlich keine VCCU einsetzen wollen.
dann lass es doch einfach!
ZitatAber auch da ist es für mich noch nicht ganz klar, wie die Implementierung aussieht.
wie in Wiki beschrieben!
ZitatMuss jetzt den Devices (und auch virtuelle Devices?) überall die IOgrp gesetzt werden?
macht sinn. Wenn du nur ein IO hast macht es keinen Unterschied - nur akademisch. Bei mehreren IOs bekommst du eben die Ersatzschaltung wie beschrieben.
ZitatSo eine Art Kochrezept "Von einem HM System ohne VCCU zu einem mit VCCU - für Dummies"
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Einrichten
gilt auch für dummies. Der rest ist Kür, je nachdem, was du willst.
ZitatDenn für mich hört sich die VCCU mal nach etwas zentralem an.
ja. und? was ist jetzt nicht beschrieben?
Im Wiki steht:
ZitatEine vccu sollte immer angelegt werden.
FHEM erlaubt die Nutzung mehrer vccus parallel. Der Nutzer kann damit sein System in Gruppen aufteilen und jeder vccu eine Reihe von IOs zuweisen.
Empfohlen wird die Definition einer einzigen vccu, welcher man alle IOs für HM zuweist.
Ich habe nicht bislang noch nicht verstanden, warum ich
immer eine anlegen soll, ich mehrere anlegen kann aber nur eine sinnvoll ist.
Dient die VCCU zum verteilen der Befehle auf mehrere Sender? Ist sie somit eine Art Router?
Und wofür brauche ich dann diese virtuellen Kanäle?
Herr 3x
Es ist deswegen sinnvoll, von vorneherein eine anzulegen, damit Du im Falle der Erweiterung um ein/mehrere weiteres IO-Device(s) mit minimalstem Konfigurations-Aufwand Deine Zentrale (sauber) erweitert hast.
Die vCCU ist die klassische (virtuelle) Zentrale, die von ihren IO-Devices die Infos über die Sensoren/Aktoren bekommt bzw. über eine selbst-verwaltete Verteilung mit Präferenzen der IO-Devices an diese rausgibt.
devices senden immer wieder an die Zentrale. Diese sollte in CUL_HM repräsentiert sein.
Ein IO hat fast nichts mit CUL_HM zu tun. Die messages laufen ins leere.
Zusatzfeatures (u.a. iogrp, Channels) sind optional (m.e. sinnvoll)
Warum hat jeder Angst davor? Die beisst doch nicht. weil man es manuell einrichten muss? wenn es automatisch wäre würde sicher keiner fragen.
weiß den jeder von euch wie der dispatcher arbeitet? braucht ihr den oder wollt ihr den besser abschalten?
Schon mal schönen Dank für die Antworten.
Zitat von: Ralli am 02 November 2014, 16:58:50
Es ist deswegen sinnvoll, von vorneherein eine anzulegen, damit Du im Falle der Erweiterung um ein/mehrere weiteres IO-Device(s) mit minimalstem Konfigurations-Aufwand Deine Zentrale (sauber) erweitert hast.
D.h., wenn ich plane einen zweiten HM-LAN irgendwo einzusetzen um die Erreichbarkeit von Sensoren/Aktoren zu vergrössern ist es einfacher, wenn ich jetzt bereits eine VCCU einrichte?
Was würde ich denn dann sparen, wenn es soweit ist?
Verstehe ich noch nicht ganz.
Zitat von: martinp876 am 02 November 2014, 17:12:37
Warum hat jeder Angst davor? Die beisst doch nicht. weil man es manuell einrichten muss? wenn es automatisch wäre würde sicher keiner fragen.
Da kann ich nur für mich sprechen. Angst davor ist ein wenig übertrieben. Nur einen zentralen Punkt an einem System ändern hat u.U. schon ein wenig Auswirkungen.
Zitat von: martinp876 am 02 November 2014, 17:12:37
weiß den jeder von euch wie der dispatcher arbeitet? braucht ihr den oder wollt ihr den besser abschalten?
Nö, aber Du wirst zugeben, dass wenn ich dispatcher hier in die Forumssuche eingebe ich nicht wirklich viele Treffer finden werde, so dass ich in die Versuchung gebracht werde damit etwas zu machen.
Suche ich allerdings nach vccu gibt es schon einige Treffer.
Dann denke ich halt, dass da unter umständen etwas dran sein könnte und daher meine Frage hier für mich etwas Licht ins Dunkel zu bringen.
Zitat von: martinp876 am 02 November 2014, 16:17:51
dann lass es doch einfach!
Das ist dann mal die für mich entscheidende Aussage.
Denn so richtig plausibel einen Mehrwert sehe ich für eine vccu nicht.
ZitatWarum hat jeder Angst davor?
Vielleicht weil nicht wirklich klar ist, warum man die VCCU einrichten sollte?
Der Nutzen kommt nicht so richtig rüber, auch im Wiki nicht. Für mich ist der verdeckt von technischen Details, die ich nicht einordnen kann.
Warum steht da nicht:
Die vccu braucht man, wenn man mehrere Sender (HMLAN, CUL) betreiben möchte. Die kann beispielsweise bei schlechtem Funkempfang sinnvoll sein.
Die Zuordnung der Homaticgeräten zu den vorhanden Sendern wird durch die vccu geregelt.
Plant man eine größere Homatic-Installation ist es sinnvoll von Anfang an eine vccu aufzusetzen.
ZitatEin IO hat fast nichts mit CUL_HM zu tun. Die messages laufen ins leere.
Wieder so ein Satz, den ich überhaupt nicht verstehe :o Wie bekommt fhem denn mit, wenn ich einen Schalter drücke, wenn messages in Leere laufen?
Verwirrt: Herr 3x
Hallo,
also grundsätzlich kann ich den Sinn erkennen.
IOgrp hört sich nach einer interessanten Sache an, vorallem wenn man mehrer zB. HMLANs in betrieb nehmen will. und portable zB Handsender verwendet. Oder aber beim einem Ausfall eines HMLAN.
Aber die Umsetzung selbst erschliesst sich mich nicht ganz.
Ok, der define der vccu geht klar, auch das attr für die IOgrp kann ich jedem meiner bisher angelernten Devices manuell hinzufügen.
Aber:
ZitatDas Attribut IODev wird automatisch gesetzt, der User muss hier nichts mehr eintragen.
Wie muss ich das verstehen? Wo wird es gesetzt und wie automatisch? Sorry falls die Frage blöd ist.
Und wie lerne ich meine evtl neuen Devices an?
Weiterhin mit:
ZitathmPairForSec
hmPairSerial
Klar das geht, steht ja im Wiki... Oder aber wie bei einer vccu zB.?
Hat evtl. jemand eine Beispielkonfiguration mit VCCU und ein paar Devices?
Viele Grüße
Zitat von: maxritti am 02 November 2014, 17:45:02
D.h., wenn ich plane einen zweiten HM-LAN irgendwo einzusetzen um die Erreichbarkeit von Sensoren/Aktoren zu vergrössern ist es einfacher, wenn ich jetzt bereits eine VCCU einrichte?
Was würde ich denn dann sparen, wenn es soweit ist?
Verstehe ich noch nicht ganz.
Denn so richtig plausibel einen Mehrwert sehe ich für eine vccu nicht.
Wenn Du keine vCCU einrichtest sondern parallel mehrere IO-Devices mit der gleichen HMID betreibst, wird es nur so von Dupes, also doppelten Nachrichten, wimmeln. Und wenn ACKs bzw. AES-signs angefordert werden, geht das oftmals in die Hose. Das habe ich selbst bei mir vor kurzem genau so gehabt und über die vCCU dann erfolgreich umgestellt. Es wären halt sonst für sich eigenständige IO-Devices. Ausserdem musst Du ohne vCCU jedem Device ein IO-Device fest zuordnen, hast also keine Redundanz bzw. das System kann nicht auf sich verändernde Sende-/Empfangsbedingungen flexibel reagieren.
Mit einer vCCU entscheidet die vCCU dynamisch, welches IO-Device es den Devices am besten zuordnet. Im Falle eines Ausfalls von einem IO-Dev können die Aktoren/Sensoren mit dem/den anderen IO-Devs weiter betrieben werden.
Bei einer Erweiterung mit einem weiteren IO-Device muss nur dieses IO-Device definiert und in der vCCU als weiteres IO-Device hinzugefügt werden. Fertig. Ab diesem Zeitpunkt weist die vCCU dieses IO-Device den Devices ebenfalls dynamisch zu.
Beispiel:
define HMLAN0 HMLAN 192.168.178.123:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmKey 01:xyz
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic
define CCU CUL_HM 123456
attr CCU IOList CUL0,HMLAN0
attr CCU model CCU-FHEM
attr CCU subType virtual
attr CCU webCmd virtual:update
Bei den Devices wird jeweils das Attribut IOgrp mit CCU gesetzt, also
attr <dev> IOgrp CCU
Das Attribut IODev wird automatisch von der CCU verwaltet und gesetzt.
Danke Ralli.
Das denke ich jetzt verstanden zu haben.
Also jetzt wäre die vccu "nur" nice to have.
Gerne.
nice-to-have nur, wenn man lediglich ein einziges IO-Device (für ein Protokoll) hat. Wenn man mehrere hat, ist es eher ein must-have.
@Phil___:
Wie vorher auch. z.B. mit
set CCU hmPairForSec 60
wobei hier CCU die definierte virtuelle CCU ist. Das Setzen der Attribute IODev erfolgt insofern automatisch, als das dies eben automatisch erfolgt :) :).
@Ralli
bei meinem Device wäre der folgende Eintrag ok?
IOgrp myVCCU:CUL_0 deleteattr
Das "deleteattr" hat da nichts zu suchen.
Der Eintrag lautet
attr <dev> IOgrp myVCCU:CUL_0
oder
attr <dev> IOgrp myVCCU
Der erste Eintrag bewirkt, dass das Device über die vCCU myVCCU die Kommunikation abwickelt und die vCCU dafür das IO-Device CUL_0 verwenden muss! Der zweite Eintrag bewirkt, dass das Device über die vCCU myVCCU die Kommunikation abwickelt und die vCCU das IO-Device selbständig aussucht anhand der Liste, die in der Definition von myVCCU konfiguriert ist!
sogar bei nur einem io, kann die vccu beim eleminieren von "unknown code, help me" logeinträgen, die durch den homematic-park des nachbarn entstehen, sehr hilfreich sein. ;)
Hallo,
also mit meinem laienhaften Verstand:
Ich hab einen HM-Lan
definier eine vCCU und weise dieser unter IOList den HM-Lan zu
paire neue Devices nur mit der vCCU
trage diesen Devices als IOgrp die vCCU ein
die vCCU ist momentan noch nice-to-have da kein weiteres IODev für HM
Nun kommt ein zweiter HM-Lan (oder CFG-USB oder CUL oder was auch immer für HM) ins Spiel.
Ich definier das neue IODev ganz normal in FHEM und füge es der vCCU unter IOList zu
paire ein neues Device mit der vCCU und das wars?
Grüße
Zitatund das wars?
genau. 8)
wer jetzt noch nicht verstanden hat, versteht es nie :)
Puschel Du hast es, auch für Dummies wie mich, auf den Punkt gebracht.
Zitat von: Puschel74 am 02 November 2014, 18:33:08
definier eine vCCU und weise dieser unter IOList den HM-Lan zu
paire neue Devices nur mit der vCCU
Bis hierhin richtig.
Zitat
trage diesen Devices als IOgrp die vCCU ein
Nein, dass funktionert beim Pairen von neuen Geräten mit einer bestehenden vCCU natürlich automatisch.
Zitat
die vCCU ist momentan noch nice-to-have da kein weiteres IODev für HM
Nun kommt ein zweiter HM-Lan (oder CFG-USB oder CUL oder was auch immer für HM) ins Spiel.
Ich definier das neue IODev ganz normal in FHEM und füge es der vCCU unter IOList zu
paire ein neues Device mit der vCCU und das wars?
Genau.
Na das Beispiel von Puschel mit der Anmerkung von Ralli und dem "unknown code, help me" Tip von Frank im Wiki zur vccu schaden mMn nicht.
Schön in Worte gekleidet ohne viel technischem Schnickschnack und es hilft zum Verständnis. :D
Just my two cents
Hallo,
Zitat von: Ralli am 02 November 2014, 18:41:47
Nein, dass funktionert beim Pairen von neuen Geräten mit einer bestehenden vCCU natürlich automatisch.
Krass.
Ich leg mir gleich ne vCCU an 8)
Danke für die Hilfe Jungs.
Grüße
Edith: Warum hat die vCCU einen "Schieberegler"?
Edith2: Ok - damit kann man schonmal virtuelle Kanäle anlegen - es wird immer genialer
Zitat von: Puschel74 am 02 November 2014, 18:33:08
Hallo,
also mit meinem laienhaften Verstand:
Ich hab einen HM-Lan
definier eine vCCU und weise dieser unter IOList den HM-Lan zu
paire neue Devices nur mit der vCCU
trage diesen Devices als IOgrp die vCCU ein
die vCCU ist momentan noch nice-to-have da kein weiteres IODev für HM
Nun kommt ein zweiter HM-Lan (oder CFG-USB oder CUL oder was auch immer für HM) ins Spiel.
Ich definier das neue IODev ganz normal in FHEM und füge es der vCCU unter IOList zu
paire ein neues Device mit der vCCU und das wars?
Grüße
Vorgehen bei vorhandenen / bereits angelernten Devices?
Ich trage in den bereits angelernten Devices das attr IOgrp mit der vccu ein, ok.
Aber was mache ich mit dem vorhanden attr xyz IODev HMLAN ???
Umschreiben auf die vCCU 8)
Zitat von: Puschel74 am 02 November 2014, 20:00:34
Umschreiben auf die vCCU 8)
Also aus:
attr xyz IODev HMLANwird
attr xyz IOgrp VCCU??
zu kurz gesprungen.
noch einmal:
die vccu hat aktuell 3 (in worten DREI) funktionen.
1) das beliebte schalten von IOs, ersatzschalten bei ausfall,.... . Sinnvoll so man mehrere IOs nutzt - insbesondere mit der gleichen HMId.
1a) umschalten eines device von einem IO zu einem anderen. Notwendig bei HMLAN/USB aus protokollsicht
2) terminieren von messages an die Zentrale. Ohne vccu kein endpunkt für messages an dieselbe. Die messages führen zu den beliebten "helpme" meldungen in log. Könnte sein, dass in Zukunft auch auswertungen gefahren werden.
Eigentlich war das der Primäre grund für die VCCU
3) peeren / (virtuelle) kanäle der Zentrale. das peerIODev ist eine fehlgeburt - passt so garnicht. Ist im System nicht darstellbar. nur wenn man eine vccu hat kann man auch Kanäle der vccu einrichten/verwenden/auswerten.
Diese Kanäle unterschieden sich von den "nicht-vccu-virtuellen-kanälen" im protokoll von HMLAN/USB. Sie sind effektiefer, können aber nicht alles (sd-teamlead, virtual-temp,...).
auch das steht im Wiki - (wohl zu weit hinten).
=> ohne vccu läuft das system unsauber/unvollständig definiert. Egal ob man mehrere IOs hat oder nicht.
=> IOs sollten deutlich mehr von einer VCCU kontrolliert werden - aktuell passiert nur das notwendigste (rudi blockiert es noch bei der cul...)
@Phil__
1)IODev ist wurscht
2)IOgrp auf die vccu ausrichten, ggf das prefered device eintragen
==> wiki lesen
Zitat von: martinp876 am 02 November 2014, 20:05:33
@Phil__
1)IODev ist wurscht
2)IOgrp auf die vccu ausrichten, ggf das prefered device eintragen
==> wiki lesen
Auch aus dem Wiki wird mir nicht klar was ich mit dem vorhanden IODev der Devices machen soll.
Lassen wie sie sind, löschen?
Lassen.
Hallo,
d.h. ich hätte bei meinen Geräten nicht das IODev ändern sollen?
Ich hab nur (erst) einen HM-Lan und hab diesen in der vCCU als IOList zugewiesen.
Dann habe ich ALLEN HM-Device als IODev den HMLAN1 entzogen und anstelle dessen die vCCU eingefügt?
Schlecht?
Weniger schlecht?
Oder ganz falsch?
???
Grüße
ZitatLassen wie sie sind, löschen?
hm - was wollte ich sage mit
ZitatDas Attribut IODev wird automatisch gesetzt,
das heisst, der user kann es gerne setzen - oder löschen - oder blödsinn eintragen. Alles egal. Das System wird es bei bedarf überschreiben.
Zitatder User muss hier nichts mehr eintragen
sollte eindeutig sein. Wirft es zweifel auf?
Es stellt für altuser klar, dass sie hiermit nicht mehr das IO selektieren können. Sicher haben es die meisten bisher garnicht bemerkt - und brauchen es jetzt auch nicht mehr.
Zitat von: Puschel74 am 02 November 2014, 20:19:46
d.h. ich hätte bei meinen Geräten nicht das IODev ändern sollen?
War nicht nötig, ist aber auch kein Problem.
Zitat
Ich hab nur (erst) einen HM-Lan und hab diesen in der vCCU als IOList zugewiesen.
Das ist korrekt.
Zitat
Dann habe ich ALLEN HM-Device als IODev den HMLAN1 entzogen und anstelle dessen die vCCU eingefügt?
Oder ganz falsch?
???
Die vCCU wird nicht über das Attribut IODev sondern über das Attribut IOgrp zugwiesen. Wenn Du das damit meinst, ist es korrekt.
Wenn Du aber bei dem Attribut IODev die vCCU eingetragen hast, wäre das falsch.
Das Attribut IODev wird danach automatisch von der vCCU verwaltet/gesetzt/verändert.
Hej folks,
da ich auch gerade dabei bin, bei meiner ersten Installation eine VCCU einzurichten, ist mir eine Frage eingefallen, die vielleicht nicht ganz unwichtig ist:
Wenn ich eine Kombination aus COC und HM-CFG-USB-2 verwende und es ein paar Komponenten gibt, die AES verwenden...
Erkennt die VCCU entsprechende Kommunikation und leitet es auf das IO-Device um, das auch entsprechende versteht oder muss ich das IO-Gerät als preferedIO eintragen?
Vielen Dank für eure Antworten! :-)
Präferiertes Device vorgeben, welches das unterstützt.
http://forum.fhem.de/index.php/topic,28588.msg214268.html#msg214268
Hallo,
nochmal langsam.
Ich hab eben erst eine vCCU eingerichtet.
Ich habe bisher nur einen Hm-Lan der HMLAN1 heisst.
list der vCCU:
Internals:
CFGFN
DEF 123ABC
IODev HMLAN1
NAME vCCU
NR 276563
STATE HMLAN1:ok,
TYPE CUL_HM
assignedIOs HMLAN1
channel_01 vCCU_Btn1
Readings:
Helper:
mId FFF0
rxType 1
Io:
newChn +123ABC,00,01,00
prefIO
rxt 0
vccu
ioList:
HMLAN1
p:
123ABC
00
01
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Cap:
Role:
dev 1
vrt 1
Attributes:
IODev HMLAN1
IOList HMLAN1
expert 2_full
model CCU-FHEM
room CUL_HM
subType virtual
webCmd virtual:update
list des HMLAN1:
Internals:
CFGFN ./Konfig/Globale_Def.cfg
DEF 192.168.2.165:1000
DeviceName 192.168.2.165:1000
FD 41
HMLAN1_MSGCNT 290829
HMLAN1_TIME 2014-11-02 20:44:03
HM_CMDNR 125
NAME HMLAN1
NR 68
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E26865A,0000,46096DDB,FF,FFB9,AA867026865A0000007F5464
RSSI -71
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 50 report:45
msgKeepAlive dlyMax:1.36 bufferMin:3
msgLoadEst 1hour:3% 10min steps: 0/0/1/0/0/0
msgParseDly min:-2187 max:6749 last:4 cnt:289227
owner 123ABC
owner_CCU vCCU
uptime 013 326:23:43.067
CHANGETIME:
Helper:
Dblog:
D-hmidassigned:
Mydblog:
TIME 1412452551.83663
VALUE 123ABC
D-hmidoriginal:
Mydblog:
TIME 1412452551.83663
VALUE 1EA0DB
D-firmware:
Mydblog:
TIME 1412452551.83663
VALUE 0.961
D-serialnr:
Mydblog:
TIME 1412452551.83663
VALUE JEQ0706728
Xmit-events:
Mydblog:
TIME 1414947699.63471
VALUE timeout:1 ok:3 disconnected:3 init:3
Cond:
Mydblog:
TIME 1414947699.63471
VALUE ok
Prot_disconnected:
Mydblog:
TIME 1414947636.89554
VALUE last
Prot_init:
Mydblog:
TIME 1414947699.02545
VALUE last
Prot_ok:
Mydblog:
TIME 1414947699.63471
VALUE last
Prot_timeout:
Mydblog:
TIME 1414947636.81557
VALUE last
State:
Mydblog:
TIME 1414947699.06616
VALUE CONNECTED
Readings:
2014-10-04 21:55:51 D-HMIdAssigned 123ABC
2014-10-04 21:55:51 D-HMIdOriginal 1EA0DB
2014-10-04 21:55:51 D-firmware 0.961
2014-10-04 21:55:51 D-serialNr JEQ0706728
2014-11-02 18:01:39 Xmit-Events timeout:1 ok:3 disconnected:3 init:3
2014-11-02 18:01:39 cond ok
2014-11-02 18:00:36 prot_disconnected last
2014-11-02 18:01:39 prot_init last
2014-05-16 20:01:17 prot_keepAlive last
2014-11-02 18:01:39 prot_ok last
2014-11-02 18:00:36 prot_timeout last
Helper:
assIdCnt 50
assIdRep 45
info 03C1,JEQ0706728,1EA0DB,123ABC
Cnd:
0 3
252 1
253 3
255 3
Dly:
cnt 289227
lst 4
max 6749
min -2187
Ids:
115332:
chn 02
flg 0
msg
name OG_Zimmer_Fenster_Antrieb
to 1412452574.66629
1678ee:
chn 02
flg 0
msg
name Wasserpumpe
to 1414577147.21783
1c21f8:
chn 02
flg 0
msg
name CUL_HM_HM_LC_DIM1T_FM_1C21F8
to 1412709766.52529
1c2223:
chn 02
flg 0
msg
name EG_Vorraum_Licht_HM
to 1414952714.68252
1d4afa:
chn 80
flg 0
msg
name EG_EZ_Display
to 1414952788.827
1eb13f:
chn 14
flg 0
msg
name CUL_HM_HM_PB_4DIS_WM_1EB13F
to 1414340894.09123
1f3134:
chn 00
flg 0
msg
name OG_Zimmer_Licht2
to 1414416691.52538
1f3164:
chn 02
flg 0
msg
name EG_Eingang_Licht_aussen
to 1414952757.2686
1f63b5:
chn 02
flg 0
msg
name EG_Eingang_Licht_innen
to 1414952699.64202
1f6460:
chn 02
flg 0
msg
name OG_Zimmer_Licht_Decke
to 1414933897.59218
1f650c:
chn 02
flg 0
msg
name OG_Flur_Licht
to 1414957432.82217
1f6be6:
chn 01
flg 0
msg
name CUL_HM_HM_LC_DIM1T_CV_1F6BE6
to 1412452574.23976
205933:
name OG_Zimmer_Device
208445:
chn 02
flg 0
msg
name WZ_Fernsehlicht
to 1414955895.83082
20936a:
name EG_Terrassenfenster
20abb3:
chn 01
flg 0
msg
name EG_Eingang_Aussen_Bewegungsmelder
to 1414952666.90164
20c718:
chn 02
flg 0
msg
name Display_Keller_Lader
to 1414956989.67439
20c79f:
chn 01
flg 0
msg
name Reserve1
to 1412452591.49611
20e4aa:
name OG_Suedseite
21e5b0:
name OG_Schlafzimmer_Fenster_mitte
22ecb2:
name EG_Eingang
22ecb4:
name EG_Terrasse
22eed1:
name Garage
2393c7:
chn 02
flg 0
msg
name OG_4fach_1
to 1414941627.57325
248688:
name Keller_Heizung_GZ
248693:
name Keller_Heizung
2486c5:
name Keller_Heizung_DG
24b015:
chn 02
flg 0
msg
name Telefon_Bar_Device
to 1414676775.94045
2515d4:
name DG_Badezimmer
2518d5:
chn 02
flg 0
msg
name Telefon_GZ_Device
to 1414682905.25845
251a01:
chn 02
flg 0
msg
name Fahrrad_Lader_Device
to 1414405125.72526
251d95:
chn 02
flg 0
msg
name Laptop_Lader_Device
to 1414916506.47673
257df6:
chn 02
flg 0
msg
name WZ_Fensterlicht
to 1414952670.28033
257ebb:
chn 01
flg 0
msg
name Reserve2
to 1412452591.25835
257ed7:
chn 01
flg 0
msg
name Reserve3
to 1412452590.3989
2685e3:
name Keller_Kuehlschrank
26865a:
flg 0
msg
name Keller_Gefrierschrank
to 1412453090.65798
273e77:
chn 00
flg 0
msg
name CUL_HM_HM_LC_DIM1T_FM_273E77
to 1412688809.90065
273f18:
chn 02
flg 0
msg
name CUL_HM_HM_LC_DIM1T_FM_273F18
to 1412688316.24463
2740ae:
chn 02
flg 0
msg
name Telefon_EG_Device
to 1414678519.76314
280716:
name CUL_HM_HM_PB_2_WM55_2_280716
2807b9:
chn 00
flg 0
msg
name CUL_HM_HM_PB_2_WM55_2_2807B9
to 1412688795.21546
288033:
chn 00
flg 0
msg
name OG_Zimmer_Schalter
to 1414265606.43387
28e0b2:
chn 80
flg 0
msg
name EG_Gong
to 1414950422.01646
291585:
chn 02
flg 0
msg
name DG_4fach_2
to 1414160023.88653
2a4f36:
chn 02
flg 0
msg
name Telefon_SZ_Device
to 1414670416.24271
2a4f5e:
chn 01
flg 0
msg
name Keller_USV_Device
to 1412452571.0887
2c1e90:
chn 01
flg 0
msg
name CUL_HM_HM_SEC_SCo_2C1E90
to 1412696508.62986
2d0159:
chn 02
flg 0
msg
name DG_4fach_1
to 1413735621.71909
2eab34:
chn 02
flg 0
msg
name OG_Zimmer_Rollo
to 1414945709.04698
K:
BufMin 3
DlyMax 1.36
Next 1414957453.11354
Start 1414957428.11354
Log:
all 0
sys 0
ids:
ARRAY(0x1b32700)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 84
1 225
2 519
3 50
4 404
5 252
last 4
sum 1534
Ref:
drft -0.000119985601727793
hmtL 1175007852
kTs 0
offL 1413782420265
sysL 1414957428117
Attributes:
hmId 123ABC
hmLanQlen 1_min
room 80_Definition
wdTimer 25
Ich habe an allen Devices die bisher HMLAN1 als IODev zugewiesen hatten das per FHEM-Oberfläche auf vCCU geändert.
alt:
attr <Device> IODev HMLAN1
neu
attr <Device> IODev vCCU
Fakt: Die Geräte lassen sich nichtmehr schalten :-[
Ich denke mal ich hab da doch einiges falsch verstanden :-\
Grüße
@Puschel74: Steht alles hier im Thread. IODev musst du überhaupt nicht anfassen. Das ist mit Definition der VCCU überflüssig. IOGrp ist das Attribut, welches auf die VCCU gesetzt werden muss.
Hallo,
ZitatIOGrp ist das Attribut, welches auf die VCCU gesetzt werden muss.
Das hab ich doch.
Es geht mir nur um bereits angelernte Geräte.
Was muss ich an diesen am IODev machen?
Nichts?
Auch wenn ich vor langer Zeit manuell den HMLAN1 zugewiesen habe?
Wird das dennoch dynamisch von der vCCU verwaltet?
Grüße
Zitat von: Ralli am 02 November 2014, 20:35:08
Die vCCU wird nicht über das Attribut IODev sondern über das Attribut IOgrp zugwiesen. Wenn Du das damit meinst, ist es korrekt.
Wenn Du aber bei dem Attribut IODev die vCCU eingetragen hast, wäre das falsch.
Das Attribut IODev wird danach automatisch von der vCCU verwaltet/gesetzt/verändert.
Du musst bei jedem bereits bestehenden Gerät das (zusätzliche) Attribut IOgrp mit dem Wert vCCU setzen.
@Ralli:Das stimmt nicht ganz. IODev wird, soweit ich weiß, vom Kernal, nicht von der VCCU gesetzt, falls es nicht manuell gesetzt wird. IODev als Attribut ist bei Einsatz einer VCCU zwar immer da, aber völlig überflüssig.
Hallo,
ich kann leider an allen meiner HM-Device kein IOgrp auswählen und zuweisen.
Ich kann am HM-Device (egal welchem) nur IODev zuweisen.
Evtl. muss ich mal ein update machen :-[
Ich dachte das IOgrp nur für die vCCU gilt und DORT HMLAN1 und etwaige später HM-IODev eingetragen gehören.
Grüße
P.S.: Update mach ich morgen mal
Dann muss deine Version aber schon recht alt sein. Eigentlich geht das alles schon ein eganze Weile. Definiere mal die VCCU, save und shutdown restart neu, dann sollte das Attribut da sein.
Ich update recht selten ::)
Da ich laufend im Forum wieder lese "Problem mit diesem und jenem update"
Aber ich werd morgen mal ein update einwerfen - heut klappt das nichtmehr ;D
Ich update regelmäßig - mache aber immer vorher ein Backup!
Nachdem ich mein zweites IODev bekam, dann hier im Forum bezüglich der Dupes gefragt hatte und den Hinweis auf die vCCU bekam, hab ich sie sofort eingerichtet und seitdem läuft das absolut problemlos bei mir. Und mittlerweile habe ich wirklich viele HM-Devices ...
Hallo,
bei der definition der vccu bekomme ich folgenden Fehler:
ZitatERROR:
use IOList only for ccu device
IOList kommt in meiner Konfiguration nirgends mehr vor.
Kennt sich da jemand aus?
define VCCU CUL_HM 123456
attr VCCU model FHEM-CCU
attr VCCU IOList HMLAN1
Hi,
probiers mal mit CCU-FHEM statt FHEM-CCU, ist im wiki meiner Meinung nach falsch.
define VCCU CUL_HM 123456
attr VCCU model CCU-FHEM
attr VCCU IOList HMLAN1
Grüße,
Stephan
Zitat von: CaptainHook am 03 November 2014, 10:12:38
Hi,
probiers mal mit CCU-FHEM statt FHEM-CCU, ist im wiki meiner Meinung nach falsch.
define VCCU CUL_HM 123456
attr VCCU model CCU-FHEM
attr VCCU IOList HMLAN1
Grüße,
Stephan
Danke,
das war der Fehler!
Ist im Wiki also falsch!
Viele Grüße
Hallo,
meine VCCU scheint nun grundsätzlich zu funktionieren.
Doch, bei zB einem Tür/Fenster Kontakt (HM-SEC-SC) wird bei öffnen/schließen das erfolgreiche Senden immer mit dem leuchten der LED in GRÜN bestätigt (direkt beim öffnen schließen).
Betreibe ich die das Device über die VCCU so leuchtet die LED nach dem öffnen/schließen längere Zeit orange und dann kurz rot.
Der Status wird in FHEM zwar richtig erkannt und ohne Fehler im Logfile geloggt, aber es irritiert mich schon ein wenig!
Kann mir jemand das Verhalten erklären oder bei der Problemlösung behilflich sein?
Zitat2014-11-03_10:35:44 HT_TFK battery: ok
2014-11-03_10:35:44 HT_TFK open
2014-11-03_10:35:44 HT_TFK contact: open (to BADB33)
2014-11-03_10:35:52 HT_TFK battery: ok
2014-11-03_10:35:52 HT_TFK closed
2014-11-03_10:35:52 HT_TFK contact: closed (to BADB33)
Viele Grüße
Einfach die vCCU in Pairing-Modus versetzen und den Kontakt nochmal anlernen.
Muss ich das jetzt mit allen bereits angelernten Geräten machen?
Woran liegt das Problem?
Ist es normal das der HMLAN die hmid von der VCCU automatisch übernimmt?
nach meiner Definition sah es anfangs so aus:
define HMLAN1 HMLAN 192.168.50.49:1000
attr HMLAN1 hmId BADB33
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 hmProtocolEvents 0_off
attr HMLAN1 wdTimer 25
##############################################
##############################################
define VCCU CUL_HM 040913
attr VCCU model CCU-FHEM
attr VCCU IOList HMLAN1
nach einem save config und shutdown restart dann so:
define HMLAN1 HMLAN 192.168.50.49:1000
attr HMLAN1 hmId 040913
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 hmProtocolEvents 0_off
attr HMLAN1 wdTimer 25
##############################################
##############################################
define VCCU CUL_HM 040913
attr VCCU IODev HMLAN1
attr VCCU IOList HMLAN1
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Normal??
Ja.
Der Fehler war, dass Du die ursprüngliche HMId des LAN-Adapters nicht als HMId der gesamten vCCU genommen hast.
Ja danke, wer lesen kann ist klar im Vorteil! Sorry!
ZitatHMId wählen
Eine vccu benötigt wie alle HM devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein, man muss also eine Wählen, die noch nicht verwendet wird.
Eine vccu wird ihre HMId an die ihr zugewiesenen IOs weitergeben. Definiert man eine vccu erst nachdem schon IOs (CUL oder HMLAN) für Homematic angelegt sind sollte die HMId des IO verwendet werden.
Wenn die HMId im System ein-eindeitig für ein Device sein muss trifft des also nicht auf IOs zu. IOs sind keine CUL_HM devices.
In der Regel nimmt man die HMId des IOs, welcher später der vccu zugeordnet werden soll.
100 Punkte.
... das erklärt auch, warum der Sensor sich mit einer roten LED beschwert hat. Sollest Du ihn zwischenzeitlich an der vCCU neu angelernt haben, musst Du das jetzt nochmal tun, nachdem Du der vCCU die richtige HMId verpasst hast. Die anderen Aktoren/Sensoren, die nicht neu angelernt wurden, sollten aber keine Probleme haben.
:-D
Strafe muss sein!
Eine Frage noch, wenn ein zweiter HMLAN hinzu kommt, bekommt gibt man diesem dann die gleiche hmid wie der VCCU und dem ersten HMLAN?
Ähem. Hast Du gelesen und verstanden, was Du zitiert hast? SCNR
Ja schon.
Das heißt ich paire den neuen hmlan mit fhem.
Anschließend füge ich ihn der IOList des vccu hinzu und dann passt sich die hmid des neuen hmlan automatisch an die der vccu an!!
Zitat von: Phil__ am 03 November 2014, 13:30:55
Ja schon.
Das heißt ich paire den neuen hmlan mit fhem.
Nein, Du pairst ihn nicht, Du definierst ihn in fhem nur.
Zitat
Anschließend füge ich ihn der IOList des vccu hinzu und dann passt sich die hmid des neuen hmlan automatisch an die der vccu an!!
Genau.
Nachdem Wiki Eintrag hatte ich nur Fragezeichen überm Kopf aber nach dem Lesen dieser Beiträge hier wurde mir alles klar warum, wieso und wie! Es ist sehr einfach, auch bei der nachträglichen Einrichtung! Vielen Dank für eure Beiträge und ich wäre dafür den Wiki Beitrag mit den Erkenntnissen aus diesem Thread zu füttern um es Anfängern verständlicher zu machen.
Grüße
Dirk
Zitatich wäre dafür den Wiki Beitrag mit den Erkenntnissen aus diesem Thread zu füttern um es Anfängern verständlicher zu machen.
Leg los :)
OK :)
Hallo,
ich möchte mir auch jetzt alles auf VCCU umstellen und habe das auch alles soweit verstanden.
Wie kann ich am schnellsten herausfinden, wie viele HM Devices z.Z. an meinen HMLAN1 angebunden sind, damit ich diesen das
attr <device> IOgrp <vccu>
zuweisen kann ?
Ich habe nämlich schon einige HM devices in meiner config.
Gruß Marcel
***************** Edit
Habe es gefunden, kann man über den z.Z. definierten HMLAN1 unter get assignIDs anzeigen lassen.
get hminfo param -d IODev
damit siehst du die einstellung von attr iodev in allen devices, was hoffentlich das selbe ergebnis liefert. so siehst du auch gleich das neue attr iogrp
get hminfo param -d IODev IOgrp
Eine Frage zum Verständnis der vccu habe ich noch,
da ich mir einen 2ten HMLAN bestellt habe, (der ca. 2m vom anderen HMLAN aufgestellt werden soll) wird dann der entstehende traffic auf beide gleichmässig aufgeteilt oder sendet immer der, der den "besseren" Empfang hat und wenn dieser im Overload ist, der andere ?
Ich habe mir einen 2ten HMLAN bestellt, da ich, wenn alle Geräte in Betrieb sind, ab und an in den prot_Warning-HighLoad Bereich komme, es gab zwar noch kein Overload, aber kurz davor.
mit
attr <device> IOgrp vccu
wird der hmlan mit den besten rssi gewählt, falls seine condition=ok ist.
attr <device> IOgrp vccu:hmlan1
damit wird zuerst versucht mit hmlan1 zu senden, falls er ok ist. wenn nicht, der nächste mit den besten rssi. so kannst du also deinen traffic verteilen.
Wäre es eigentlich möglich die aktuelle VCCU so zu erweitern, dass man mit dieser sämtlich Gateways "verwalten" könnte?
Aktuell beschränkt sich die Nutzung ja lediglich auf Homematic.
Danke, dann kann ich z.B. die Alarmanlagen Sachen über den 1ten HMLAN machen, falls dieser dann im overload sein sollte, wird es über den 2ten HMLAN gesendet.
So läuft ja alles ohne Probleme, mal schauen wenn mein 2ter HMLAN da ist, wie sich das alles verhält.
Zwei Fragen hab ich noch, ich habe für meine Rauchmelder einen Virtuellen Teamrauchmelder angelegt, kann ich diesen behalten und alles läuft normal weiter oder muss ich den Teamrauchmelder löschen und alle Rauchmelder mit einem virtuellen Kanal der vcci paaren ?
Im Wiki steht :
Zitatattr vccu IOList <io1>[,<io2>,...]
IOList beinhaltet die Komma-getrennte Liste der IOs welche die VCCU nutzen soll/darf.
Muss das 2te IO in den eckigen Klammern stehen oder wie der Satz darunter aussagt, nur mit einem Komma getrennt ?
Komma-getrennt ist richtig!
Die eckige Klammer bei einer Syntax-Erklärung sagt lediglich aus, dass es sich um eine optionale Angabe handelt.
Die Spitze Klammer kennzeichnet dabei übrigens einen obligatorischen Parameter.
Danke, wieder was gelernt. 8)
Hi all,
da ich wie viele andere den Wikiartikel nicht kapiert habe (sorry Martin), habe ich mich nach dem erhellenden Durchlesen dieses Threads daran gesetzt, den Wikiartikel zu ergänzen und teilweise umzuformulieren. Hinzugekommen ist ausserdem eine Art Einleitung.
Gelegentlich könnte mal jemand nachsehen, ob ich da irgendwo doch was nicht richtig verstanden habe und da nun Blödsinn drin steht.
Besonders im hinteren Bereich (Virtuelle Kanäle der VCCU) bin ich noch nicht fertig, da ich bisher das ganze Konzept "Kanäle" noch nicht ganz verstanden habe.
Für die Überarbeitung des Artikels bin ich dankbar. Und wenn es von der Allgemeinheit besser verstanden wird, perfekt. Ich erhebe auf die Artikel keinen editieranspruch, eher das Gegenteil.
Technisch sehe ich ein paar Probleme in der Beschreibung. Eine vccu ist ein hm-device. Eine zentrale. Virtuell, da keine Physik. Iodevices sind immer relativ dumm. Das aendert eine vccu nicht.
Das Zusammenspiel mehrere IOs ohne Nutzung einer vccu ist nicht korrekt beschrieben, zumindest würde ich es nicht verstehen. Duplikate messages sind nicht das Problem in Empfangsrichtung, die werden immer gefiltert. Mit und ohne vccu.
Der Text suggeriert lattent, dass man IOs gruppieren kann nach cul und hm. Wichtig ist aber, dass man alle IOs wild mischen kann. Der user hat keine Einschränkung.
Die technische Präzision fehlt an ein paar stellen. Wenn sie nicht notwendig ist (trifft auf 90% der user zu) sollte man es weglassen und abstrakt beschreiben. Sonst verwirrt es die Leser mit technischen Anspruch - glaube ich zumindest.
Okay, ich sehe noch mal rein und werde deine Anmerkungen einarbeiten so gut ich kann.
Mein Ziel ist in der Tat eher das für 90% verständlich zu machen anstatt vollständig/präzise.
Und dann ist da noch das Problem, dass ich viele Sachen selbst nicht weiss.(besonders HM ist bei mir zwar im Einsatz aber richtig tief drin bin ich nicht)
ggf müsste ich dann 2-3 Fragen an dich stellen, ggf per PN.
Ob du dann antworten willst ist natürlich dir und deiner freien Zeit überlassen.
So oder so aber nächstes Jahr erst ;)
Hallo Ihr,
ich habe hier die Seiten und die Wiki durchgelesen, doch irgendwo fehlt mir der Zusammenhang.
Ich habe eine VCCU eingerichtet. Jetzt lassen sie Jalousieaktoren nicht mehr schalten.
Wenn ich die Jalousie von Hand am Taster schalte, wird der aktuelle Status in fhem angezeigt. Sobald ich die Jalousien über fhem steuern möchte,
kommt der Status "Missing Act" und es passiert nichts.
Hier die List vccu:
Internals:
DEF 357684
IODev Teil_an_Fritzbox
LASTInputDev Teil_an_Fritzbox
MSGCNT 1
NAME vccu
NR 219
NTFY_ORDER 50-vccu
STATE Teil_an_Fritzbox:ok,
TYPE CUL_HM
Teil_an_Fritzbox_MSGCNT 1
Teil_an_Fritzbox_RAWMSG A0DC0861037BB950000000601C800::-104:Teil_an_Fritzbox
Teil_an_Fritzbox_RSSI -104
Teil_an_Fritzbox_TIME 2016-01-29 22:53:10
assignedIOs Teil_an_Fritzbox
channel_01 vccu_Btn1
Readings:
2016-01-29 22:44:00 state Teil_an_Fritzbox:ok,
2016-01-29 15:08:47 unknown_3574C0 received
2016-01-29 21:11:37 unknown_37B6C7 received
2016-01-29 20:47:40 unknown_37B6FD received
2016-01-29 22:18:10 unknown_37BB32 received
2016-01-29 22:53:10 unknown_37BB95 received
2016-01-29 22:17:34 unknown_37BB96 received
2016-01-29 18:04:06 unknown_37BB99 received
Helper:
HM_CMDNR 1
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
vccu vccu
ioList:
Teil_an_Fritzbox
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
vrt 1
Attributes:
IODev Teil_an_Fritzbox
IOList Teil_an_Fritzbox
IOgrp vccu
expert 2_raw
model CCU-FHEM
room VCCU
subType virtual
webCmd virtual:update
list einer Jalousie:
Internals:
DEF 3146F9
IODev Teil_an_Fritzbox
NAME Jalo_Bad
NR 43
NTFY_ORDER 50-Jalo_Bad
STATE MISSING ACK
TYPE CUL_HM
Readings:
2016-01-29 08:42:40 CommandAccepted yes
2016-01-14 10:09:41 D-firmware 2.3
2016-01-14 10:09:41 D-serialNr LEQ1025089
2016-01-15 09:20:16 PairedTo 0xF11034
2016-01-15 09:20:17 R-driveDown 31.2 s
2016-01-15 09:20:17 R-driveTurn 0.5 s
2016-01-15 09:20:17 R-driveUp 31.2 s
2016-01-15 09:20:16 R-pairCentral 0xF11034
2016-01-15 09:20:17 R-sign off
2016-01-15 09:20:16 RegL_00. 02:01 0A:F1 0B:10 0C:34 15:FF 18:00 00:00
2016-01-15 09:20:17 RegL_01. 08:00 09:00 0A:00 0B:01 0C:38 0D:01 0E:38 0F:05 10:00 30:06 57:24 00:00
2016-01-29 10:54:17 deviceMsg 94.5 (to F11034)
2016-01-29 10:54:17 level 94.5
2016-01-29 10:54:17 motor stop:94.5
2016-01-29 10:54:17 pct 94.5
2016-01-29 10:54:17 recentStateType info
2016-01-29 17:12:06 state MISSING ACK
2016-01-29 10:54:17 timedOn off
Helper:
HM_CMDNR 1
mId 006A
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3146F9,00,00,00
rxt 0
vccu vccu
p:
3146F9
00
00
00
Mrssi:
mNo
Io:
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat 00
Role:
chn 1
dev 1
prs 1
Attributes:
IODev Teil_an_Fritzbox
IOgrp vccu
alleRollos Rollo_Gruppe
autoReadReg 4_reqStatus
eventMap off:Runter on:Hoch
expert 2_full
firmware 2.3
fp_Erdgeschoss 180,210,4,
group Jalousien,Jalousien_seite
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room Bad,Jalousien
serialNr LEQ1025089
set Rollo_Gruppe
subType blindActuator
userattr alleRollos alleRollos_map room_map set set_map structexclude
webCmd statusRequest:toggle:on:off:up:down:stop
Lieben Gruß
Hoffi
deine hmid F11034 muss auch dem DEF der vccu entsprechen
ZitatDEF 357684
sollt aber F11034 sein
Danke :) das wars.
Lieben Gruß
Hoffi
steht nebenbei auch prominent im WIKI Artikel, oder?
Da steht:
ZitatDefiniert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die hmId der bereits vorhandene Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen.
(soll keine Besserwisserei sein, sondern vielmehr eine Nachfrage ob das unklar formuliert ist, denn der aktuelle Artikel kommt zum Teil von mir)
Edit:
Uhh, ich sehe gerade, jemand hat den Artikel nach mir signifikant umgeschrieben... ich bin mir nicht sicher ob ich das jetzt noch verstanden hätte. Da sind ein paar Aspekte jetzt doch zumindest für mich weniger deutlich als vorher.
Hallo Zusammen,
obwohl hier "geklärt" steht und der Thread schn einige Wochen nicht benutzt wurde, hätte ich dennoch einige Frage in die Runde.
Leider habe ich damals beim Anlegen meines CUL die hmId nicht ganz sauer definiert , also nicht explizit nochmal angegeben.
Läuft aber seit Jahren tadellos ;)
define CUL_HM CUL /dev/ttyACM0@38400 2222
attr CUL_HM addvaltrigger 1
attr CUL_HM icon usb
attr CUL_HM model CUL
attr CUL_HM rfmode HomeMatic
attr CUL_HM room System
Außerdem ist diese nicht 6-stellig , aber es wird ja automatisch F1 vorangestellt == F12222
Vermute aber mal das bei Anlegen der vCCU jetzt die hmId komplett angegeben werden muss , also so ..
define vCCU CUL_HM [b]F12222[/b]
attr vCCU IODev CUL_HM
attr vCCU IOList CUL_HM
attr vCCU model CCU-FHEM
attr vCCU room Homematic
attr vCCU subType virtual
attr vCCU webCmd virtual:update
Weiterhin möchte ich dann (u.a. zur Reichweiterverbesserung) einen HM_LAN_Adapter (eine Etage tiefer) integrieren.
Der hat (derzeit im testsystem) aber eine andere hmId !
Im Wiki haben aber der CUL und der HM_LAN_Adapter die gleiche hmId ! Ist das Zufall oder muss das so eingestellt werden ?
Macht es Sinn (z.B. Performance) bei den Devices das Preferd IO Device zu setzen..... (steht zwar so im WIKI), wie ist Eure Erfahrung ?
Bei neue stationären Devices könnte man dann nach dem Anlernen nachsehen (IOgrp) und dann ggf. ergänzen ?
Danke für jeden Hinweis / jede Idee!
kvo1
ZitatAußerdem ist diese nicht 6-stellig , aber es wird ja automatisch F1 vorangestellt == F12222
diese "automatische" generierung einer hmid wird durchgeführt, wenn man
nicht das attribut hmId benutzt.
ZitatIm Wiki haben aber der CUL und der HM_LAN_Adapter die gleiche hmId ! Ist das Zufall oder muss das so eingestellt werden ?
die vccu stellt das automatisch ein, bei allen io's in der IOList.
ZitatBei neue stationären Devices könnte man dann nach dem Anlernen nachsehen (IOgrp) und dann ggf. ergänzen ?
genau.
Hallo Frank,
Danke für Deine Antworten.
Ja das Attribut hmid hatte ich damals (aus Unwissenheit) nicht benutzt 😔
Dennoch wäre demnach für die vCCU ......
Define vCCU CUL_HM F12222
Anzugeben ? Oder ?
ZitatDennoch wäre demnach für die vCCU ......
Define vCCU CUL_HM F12222
Anzugeben ? Oder ?
genau. andernfalls müsstest du neu pairen.
ZitatIm Wiki haben aber der CUL und der HM_LAN_Adapter die gleiche hmId ! Ist das Zufall oder muss das so eingestellt werden ?
Es ist im Grunde schon gesagt, aber sicherheitshalber:
Alle einer VCCU zugewiesene I/Os bekommen die hmID der VCCU "übergeholfen". Wenn du an das I/O, das dann einen andere hmID bekommen wird, schon Geräte gepairt hast, dann musst du die hinterher neu pairen.
Zitat von: Zrrronggg! am 02 Juni 2016, 16:33:31
Es ist im Grunde schon gesagt, aber sicherheitshalber:
Alle einer VCCU zugewiesene I/Os bekommen die hmID der VCCU "übergeholfen". Wenn du an das I/O, das dann einen andere hmID bekommen wird, schon Geräte gepairt hast, dann musst du die hinterher neu pairen.
Verstanden, danke 😎
Hallo Zusammen,
ich habe mein System auf VCCU umgestellt , hat auch soweit alles gut funktioniert. Alle Devices sind ergänzt um ..
attr <DEVICE> IOgrp VCCUDas
IODev bleibt aber auf CUL_HM !?
bzw. wenn mann das Attribute löscht wird das nach einen reboot (oder rereadcfg) wieder so angelegt ?
Ist das okay ???
Jetzt habe ich aus einem Testsystem einen HMLAN-Adpater dazu definiert.
define HMLAN1 HMLAN 192.xxx.xxx.xxx:1000
attr HMLAN1 hmId F12222
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 icon hm_lan@orange
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room OG_Arbeitszimmerdie hmId war im Testsystem 25751B , hier mal ein list
ZitatReadings:
2016-06-11 00:59:39 D-HMIdAssigned F11234
2016-06-11 00:59:39 D-HMIdOriginal 25751B
2016-06-11 00:59:39 D-firmware 0.964
2016-06-11 00:59:39 D-serialNr KEQ1023208
2016-06-11 00:59:41 Xmit-Events ok:1 disconnected:1 init:1
2016-06-11 00:59:41 cond ok
2016-06-11 01:19:46 loadLvl low
2016-06-11 00:59:13 prot_disconnected last
2016-06-11 00:59:13 prot_init last
2016-06-11 00:59:41 prot_ok last
2016-06-11 00:59:13 state opened
Helper:
assIdCnt 0
assIdRep 0
info 03C4,KEQ1023208,25751B,F12222
setTime 44726
Cnd:
0 1
253 1
255 1
Dly:
cnt 211
lst 177
max 4406
min 5
Ids:
K:
BufMin 1
DlyMax 3.983
Next 1465600811.23935
Start 1465600786.23935
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x309e7a8)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 1
loadNo 3
scnt 1
apIDs:
Ref:
drft -0.000600120024004801
hmtL 1815742
kTs 0
offL 1465598970505
sysL 1465600786247
Attributes:
hmId F12222
hmLanQlen 1_min
icon hm_lan@orange
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room OG_Arbeitszimmer
Leider connected sich keines der Devices mit dem HMLAN-Adapter !
ein
get hm param -d IODev IOgrp zeigt für alle das gleiche Ergebnis
AZ3fachSchalter : CUL_HM |VCCU
AZ_HKT : CUL_HM |VCCU
AZ_Licht : CUL_HM |VCCU
AZ_Rollladen : CUL_HM |VCCU
BZ_HKT : CUL_HM |VCCU
BZ_Licht_D : CUL_HM |VCCU
BZ_Rollladen : CUL_HM |VCCU
BZ_Sensor_THPL : CUL_HM |VCCU
Brunnen : CUL_HM |VCCU
EG_Tuer : CUL_HM |VCCU
EZ1_HKT : CUL_HM |VCCU
EZ2_HKT : CUL_HM |VCCU
FL_HKT : CUL_HM |VCCU
G1_Sensor_THPL : CUL_HM |VCCU
G2_Sensor_TUPL : CUL_HM |VCCU
GW_HKT : CUL_HM |VCCU
GW_Rollladen : CUL_HM |VCCU
KU_HKT : CUL_HM |VCCU
KU_Rollladen : CUL_HM |VCCU
KZ1_HKT : CUL_HM |VCCU
KZ2_HKT : CUL_HM |VCCU
KZ_Rollladen : CUL_HM |VCCU
liegt das an der "D-HMIdOriginal 25751B" ???
oder habe ich hier etwas übersehen ??
Danke für jeden Hinweis :-[
Zeig bitte mal ein List von deiner vccu
bevor ich jetzt dir eine Antwort schreibe zu deinen Fragen
Zitat von: fhem-hm-knecht am 11 Juni 2016, 11:38:43
Zeig bitte mal ein List von deiner vccu
bevor ich jetzt dir eine Antwort schreibe zu deinen Fragen
Ich tippe ja mal, dass der VCCU gar kein IO (der HMLAN1) zugeordnet ist. ;)
Hallo Hary,
bittschön ...
Internals:
CUL_HM_MSGCNT 61
CUL_HM_RAWMSG A0B4EA2403AF27725751B431E::-66.5:CUL_HM
CUL_HM_RSSI -66.5
CUL_HM_TIME 2016-06-11 12:03:23
DEF F11234
HMLAN1_MSGCNT 1093
HMLAN1_RAWMSG EF11234,0000,0284B9C7,FF,FFBD,128002F1123486C40D00
HMLAN1_RSSI -67
HMLAN1_TIME 2016-06-11 12:33:36
IODev CUL_HM
LASTInputDev HMLAN1
MSGCNT 1154
NAME VCCU
NR 1532
STATE CUL_HM:ok,HMLAN1:ok,
TYPE CUL_HM
assignedIOs CUL_HM,HMLAN1
lastMsg No:12 - t:02 s:F11234 d:86C40D 00
protLastRcv 2016-06-11 12:33:36
rssi_at_CUL_HM avg:-74.75 min:-86.5 max:-71.5 lst:-78.5 cnt:43
rssi_at_HMLAN1 avg:-69.62 min:-83 max:-66 lst:-67 cnt:1076
Readings:
2016-06-11 12:33:36 CommandAccepted yes
2016-06-11 11:31:38 recentStateType ack
2016-06-11 05:36:33 state CUL_HM:ok,HMLAN1:ok,
2016-06-11 12:03:23 unknown_3AF277 received
2016-06-11 01:37:37 unknown_999999 received
Helper:
HM_CMDNR 18
PONtest 1
mId FFF0
rxType 1
Io:
nextSend 1465641163.66484
vccu VCCU
ioList:
CUL_HM
HMLAN1
Mrssi:
mNo 12
Io:
HMLAN1 -67
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul_hm:
avg -74.7558139534884
cnt 43
lst -78.5
max -71.5
min -86.5
At_hmlan1:
avg -69.6236059479556
cnt 1076
lst -67
max -66
min -83
Attributes:
IODev CUL_HM
IOList CUL_HM,HMLAN1
IOgrp VCCU
autoReadReg 4_reqStatus
expert 2_full
model CCU-FHEM
room OG_Arbeitszimmer
subType virtual
webCmd virtual:update
HINWEIS:
die id (F12222) aus meinem vorherigen Beiträgen hatte ich geändert , richtig ist F11234 ........!
Woran erkennt man an welchem I/O (hier CUL_HM oder LANHM1) ein Device sendet ???
Danke für die Hlife
Klaus
könnte es erkennbar an...
Internals
LASTInputDev HMLAN1 festzumachen sein ?
Was ist den CUL_HM bei dir für ein device?
Steht in der vccu ja in der IOList.
ZitatWoran erkennt man an welchem I/O (hier CUL_HM oder LANHM1) ein Device sendet
Ein device sendet , wenn wir dein Bsp. nehmen an die Zentrale F11234, du hast 2 Empfänger Cul und Hmlan1, beide empfangen, beide geben es an fhem.pl ,
und hier werden doppelte Nachrichten Inhalte standardmäßig (0,5 Sekunden ) aussortiert !
attr global dupTimeout <sekunden>
hat erstmal garnichts mit der vccu zu tun
die vccu entscheidet aber , wenn nur am Device
attr IOgrp VCCU gesetzt ist, nach der besten rssi Empfang und sendet dann über dieses I/O
CUL_HM ist sein Cul , hat er schlecht benannt, steht doch weiter oben in den Beiträgen
Zitat von: fhem-hm-knecht am 11 Juni 2016, 13:28:15
CUL_HM ist sein Cul , hat er schlecht benannt, steht doch weiter oben in den Beiträgen
Ja das stimmt, hatte ich damals wirklich schlecht benannt aber funktioniert ja ;)
Hary, danke für die super Beschreibung. Dennoch würde ich gern wissen wollen mit welchem I/O das jeweilige Device kommuniziert
um hier dann eine feste Zuordnung vornehmen zu können, also ....
am Device
attr IOgrp VCCU:CUL_HM bzw.
attr IOgrp VCCU:HMLAN1! oder ist das nicht notwendig / nicht sinnvoll ?
Da ich nur feste Devices habe würde ich je Device den mit dem besten rssi Empfang eintragen. Steht ja auch so als Tipp im WIKI
"Gefühlt" ist die Reaktion einiger Devices derzeit jetzt langsamer als ohne VCCU !
Ahhhh, noch was. Ich habe bei der VCCU ein
attr IODev CUL_HM..... ist das überhaupt richtig / notwendig
Gruss Klaus
Zitatam Device attr IOgrp VCCU:CUL_HM bzw. attr IOgrp VCCU:HMLAN1
betrifft nur das senden von Fhem, ich habe bei mir auch entsprechend die bevorzugten I/O s eingetragen,
aber nur wegen der Lastverteilung 1% Regel,
bei dir mit dem Cul, könnte es nocht interessant sein , wenn du Zicken hast, die lieber mit dem Hmlan reden wollen , sofern im sende Bereich
Zitatattr IODev CUL_HM.
das bekommt man automatisch von fhem , ohne Bedeutung
Hallo Hary,
Danke nochmal, das sieht soweit ganz gut aus, zumindest schalten alle Devices jetzt zuverlässig.
Was ich noch nicht herausgefunden habe , warum bei einigen Devices bei den Internals nur nur der
HMLAN1 auftaucht und nicht auch der CUL_HM ?
Klaus
wenn nur der HMLAN1 auftaucht --> dann wurde von deinem Cul auch nichts empfangen
Hallo Hary,
muss nochmal eine kurze Frage loswerden. Das mit der VCCU läuft wunderbar.
Ich habe aber jetzt für das angelegt Device VCCU jede Menge Readings ........
Sind das Devices die die VCCU erkennt, die aber nicht gepairt sind/wurden ?
Kann man diese readings wieder löschen ???
Gruss
klaus
Klar kann man:
http://fhem.de/commandref_DE.html#deletereading
Die werden aber, so lange es wirklich unbekannte devices sind, die senden, wahrscheinlich bald wieder auftauchen.
Hallo Benni,
Stimmt, die tauchen wieder auf ;) , das sind Devices aus
meinem Livesystem und die Readings wurden im Testsystem angelegt.
Demnach lässt man die einfach , oder...
Oder über Attr .....ignore.....
Ja, wenn die devices vom autocreate angelegt sind kannst du das Attribute Ignore setzen. Und anschließend die Readings löschen. Sie sollten dann nicht mehr auftauchen, da die devices ja jetzt bekannt sind, aber eben ignoriert werden.
eigenartiger Weise waren die devices nicht angelegt, obwohl autocreate aktiv ist !
Ich habe diese mal per Hand angelegt und auf "ignore 1" gesetzt !
ZitatIch habe diese mal per Hand angelegt und auf "ignore 1" gesetzt !
das funktioniert eleganter mit "set vccu defIgnUnknown". ;)
Zitat von: frank am 03 Juli 2016, 11:11:08
das funktioniert eleganter mit "set vccu defIgnUnknown". ;)
Danke! Kannte ich auch noch nicht! :)
bei HM bzw. vccu würde ich die readings nicht mit dem Befehl deletereading löschen, sondern mit
set vccu clear readings
da sind sie in einem rutsch weg
Zitat von: frank am 03 Juli 2016, 11:11:08
das funktioniert eleganter mit "set vccu defIgnUnknown". ;)
Danke, kannte ich so auch nicht ;)
@hary, auch dafür DANKE, man lernt nie aus !
Hallo Leute,
ich habe eine vccu definiert und alles funktioniert prima, ist es möglich, wenn man das so definiert hat
attr <device> IOgrp VCCU:HMLAN1
ein zweites IO festzulegen, wenn das erste nicht erreichbar ist, dass dann das zweite IO verwendet wird (ggfs. auch ein drittes und viertes) und dann erst das IO mit dem besten RSSI?
Grüße Marcel
man kann auch mehrere prefered io's definieren, die in der angegebenen reihenfolge genutzt werden, wenn sie verfügbar sind. wenn nicht, dann alle restlichen io's nach rssi.
Werden die dann durch ein Komma oder ein Leerzeichen getrennt?
Muss dann nochmals VCCU davor
1.
attr <device> IOgrp VCCU:HMLAN1,VCCU:HMLAN2
2.
attr <device> IOgrp VCCU:HMLAN1 VCCU:HMLAN2
3.
attr <device> IOgrp VCCU:HMLAN1,HMLAN2
4.
attr <device> IOgrp VCCU:HMLAN1 HMLAN2
Grüße Marcel
Laut Commandref Version 3.
Bitte die Doku lesen!
Sogar in deutscher Sprache:
Zitat
kann an Devices vergeben werden udn zeigt auf eine virtuelle ccu. Danach wird die ccu beim Senden das passende IO für das Device auswählen. Es ist notwendig, dass die virtuelle ccu definiert und alle erlaubten IOs eingetragen sind. Beim Senden wird die ccu prüfen welches IO operational ist und welches den besten rssi-faktor für das Device hat.
Optional kann ein bevorzugtes IO definiert werden. In diesem Fall wird es, wenn operational, genutzt - unabhängig von den rssi Werten.
Beispiel:
attr myDevice1 IOgrp vccu
attr myDevice2 IOgrp vccu:prefIO1,prefIO2,prefIO3
Danke, ich habe nur das was im Wiki steht gefunden und da steht es nicht drin.
Gesendet von iPhone mit Tapatalk
Reihenfolge: Doku, Forum lesen, Wiki, Forum fragen.
@martinp876 falls Du mal zufällig an der Stelle bist, da ist ein Dreher udn -> und
Zitatkann an Devices vergeben werden udn zeigt auf eine virtuelle ccu. Danach wird die ccu beim Senden das passende IO für das Device auswählen. Es ist notwendig, dass die virtuelle ccu definiert und alle erlaubten IOs eingetragen sind. Beim Senden wird die ccu prüfen welches IO operational ist und welches den besten rssi-faktor für das Device hat.
Optional kann ein bevorzugtes IO definiert werden. In diesem Fall wird es, wenn operational, genutzt - unabhängig von den rssi Werten.
Beispiel:
Ich habe das im Wiki (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Dynamisches_IO)mal ergänzt, in der commandref ist es nicht ganz leicht zu finden.
Gruß Otto
Ich rufe die commandref auf, drücke STRG+F und gebe "iogrp" ein. Leichter geht es nicht ;)
Ja das stimmt, es ist auch die einzige Stelle die man findet wenn man vccu eingibt. Aber wenn man eine VCCU definieren will, findet man das in der commandref eigentlich nicht. Das steht alles im Thema CUL_HM verteilt. Deswegen ist es doch gut wenn es in dem Artikel der VCCU mit drinsteht 8)
Zitat von: marvin78 am 06 Oktober 2016, 08:36:26
Reihenfolge: Doku, Forum lesen, Wiki, Forum fragen.
Dann scheint für Dich das Wiki ja extrem schlecht geschrieben/gewartet zu sein. Oder interpretiere ich das falsch?
Ich halte das für den effizientesten Weg. 95% der Problem, die direkt mit FHEM und seinen Modulen zu tun haben, lassen sich durch aufmerksames lesen und durchsuchen der commandref lösen. Andernfalls ist über die Google Suche das Forum dann prima nach Stichworten durchsuchbar. Das Wiki ist brauchbar für Beispiele und Zusatzinformationen. Es ersetzt nicht die Doku und ist nicht einmal nah dran an einer solchen. Und ja, sie enthält teilweise auch hoffnungslos veraltete und irreführende Infos. Die kann man aber leicht über die Einbeziehung anderer Quellen filtern.
Ich finde gerade zum Thema VCCU den Wiki Artikel so schlecht nicht. Ich habe jedenfalls nach dem Lesen der Commandref erstmal nicht kapiert, wozu die VCCU überhaupt da sein soll.
Wie ich sehe hat Otto die fragliche Stelle auch ergänzt, das finde ich gut, weil die Commandref in der Tat die Infos sehr verteilt hat.
Ich gehen daher immer anders vor, ich lese zuerst das Wiki und dann die Commandref und dann Forum und dann Fragen. Komme ich besser mit klar. Wenn im Wiki was veraltet ist, bekommt man es nach Lesen der Commandref meistens schnell mit. Hoffentlich.
Ich habe nicht gesagt, dass das Wiki im allgemeinen schlecht ist, auch nicht im speziellen.
Der effizienteste Weg sich schnell selbst Hilfe zu verschaffen, ist trotzdem der, den ich beschrieben habe. Damit ist man in den meisten Fällen in < 5 Minuten am Ziel. Warum man nicht zuerst die Doku liest, werde ich niemals verstehen. Darin steht die vom Autor vorgesehene Dokumentation. Damit soll es das aber auch von mir gewesen sein.
mMn ist die effiktivste Reihenfolge: Doku -> Wiki -> Forum, deshalb auch meine Frage an Marvin. Ein Wiki sollte doch (zusätzliche) Informationen aus Doku, Forum und ??? in konzentrierter Form enthalten. Aber im Endeffekt macht es eh jeder wie er will ;)
Aber das sind wir ja (fast) alle einer Meinung ;)
Was aus meiner Sicht ein Problem ist, ist die Suche.
Mit der Doku ist es relativ simpel ctrl + f und fertig, aber man muss das richtige Wort haben.
Das Wiki kapiere ich in letzter Zeit nicht, gibt man einen Begriff ein der ganz sicher sowohl im Titel als auch im Text vorkommt findet er ihn manchmal nicht. Manchmal reicht auch ein Teil des Wortes manchmal muss man das ganze Wort exakt eingeben.
Beim Forum hatte ich irgendwann mal begriffen, dass er ab dem Thread sucht wo man gerade steht. Aber in letzter Zeit habe ich das Gefühl, das stimmt auch nicht immer.
Im Forum suche ich mit Google, das geht meist besser --> site:forum.fhem.de
Ich muss mal probieren ob das im Wiki auch besser geht.
Gruß Otto
Zitat von: Otto123 am 11 Oktober 2016, 11:31:57
Im Forum suche ich mit Google, das geht meist besser --> site:forum.fhem.de
Funktioniert auch für's Wiki, wobei eine externe Suchmaschine nie ganz aktuell ist: Jetzt gerade wurde noch kein "readingsBulkUpdateIfChanged" im Wiki geunden. Aber damit kann ich leben ;)
Nur mal folgende Spekulation für mich als Laien:
Ich richte mir eine virtuelle CCU ein. Mein HMLAN geht kaputt.
Kann ich diesen dann einfach durch einen neuen ersetzen und muss nicht neu pairen!?
Stimmt das so?
So ungefähr. 8)
Nur das es den HMLAN nicht mehr neu gibt ;)
Gruß Otto
Zitat von: pointde am 10 April 2017, 22:13:51
Ich richte mir eine virtuelle CCU ein. Mein HMLAN geht kaputt.
Kann ich diesen dann einfach durch einen neuen ersetzen und muss nicht neu pairen!?
Um genau zu sein würde das auch ohne VCCU funktionieren. Das Ersatz-IO muss von FHEM lediglich die selbe HMId bekommen, die auch der defekte HMLAN hatte.
Nichts desto trotz ist für HM der Einsatz einer VCCU generell zu empfehlen.
Dafür brauchst du nicht einmal eine VCCU. Das verwenden der gleichen HMID beim neuen HMLAN reicht. Es geht sogar jedes andere HM-IODev. Neu pairen ist nie notwendig, da pairen nur bedeutet, dass die HMID in die Devices geschrieben wird.
Edit: Natürlich mal wieder die neue Seite nicht gesehen ;)
Hallo,
nachdem ich nun genau in dieser Situation war (bestehendes HM System mit CUL_0 und 2x HMLAN, nachträgliches Einrichten der VCCU), versuche ich mal als Kochbuch die Dinge (am Ende doch viel einfacher) auf den Punkt zu bringen:
Definition der VCCU:
define myVCCU CUL_HM <alte hmID des CUL_0 vermutlich bei vielen die 0xF11034>
attr myVCCU IOList CUL_0,HMLAN_1,HMLAN_2
attr myVCCU IOgrp myVCCU
attr myVCCU model CCU-FHEM
attr myVCCU subType virtual
attr myVCCU webCmd virtual:update
Danach noch:
attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp myVCCU
und fertig. Ich sehe, das myVCCU den Status "ok" für alle IODev anzeigt. Da bei mir in der fhem.cfg das Ganze an letzter Stelle gelandet ist, habe ich das an den Anfang, direkt nach define CUL_0, define HMLAN_1, define HMLAN_2 geschoben.
Preferred IODev habe ich nicht festgelegt, gehe jetzt davon aus, dass der VCCU Dispatcher das schon ordentlich macht.
Ich habe die IODev in den Einzelgeräten unverändert gelassen, da ich gelesen habe, dass die durch die IOgrp überschrieben werden. Richtig?
Habe ich was vergessen?
Es funktioniert bei mir immer noch alles einwandfrei, allerdings hatte ich noch gehofft, dass auch die Mehrfachkommandos an alle Geräte aufhören. Da bin ich jetzt nicht sicher, ob ich das richtig prüfe. Ich sehe immer noch, dass über alle IODev (CUL_0, HMLAN_1, HMLAN_2) gesendet wird.
Vielen Dank für kurze knappe Antworten!
Viele Grüße
Thorsten
Moin Thorsten,
kurz und knapp: klingt gut. Die Sache mit Mehrfachkommandos an alle Geräte verstehe ich nicht, muss ich da irgendwo anders lesen?
Gruß Otto
ZitatEs funktioniert bei mir immer noch alles einwandfrei, allerdings hatte ich noch gehofft, dass auch die Mehrfachkommandos an alle Geräte aufhören. Da bin ich jetzt nicht sicher, ob ich das richtig prüfe. Ich sehe immer noch, dass über alle IODev (CUL_0, HMLAN_1, HMLAN_2) gesendet wird.
Vielen Dank für kurze knappe Antworten!
na wenn du Hilfe willst solltest du uns auch zeigen was du siehst, du weißt doch, dass die Glaskugel da recht trübe reagiert!
und was sind dem "Mehrfachkommandos" bei dir?
Sorry, das habe ich schlecht erklärt und Danke für die schnellen Rückmeldungen!
Ich sehe, wenn ich mir z.B. die Internals von einem HM-LC-Sw1-DR anschaue
CUL_0_RSSI -51.5
CUL_0_TIME 2019-03-23 09:54:43
HMLAN_1_RSSI -69
HMLAN_1_TIME 2019-03-23 09:54:43
HMLAN_2_RSSI -82
HMLAN_2_TIME 2019-03-23 09:54:43
...
IODev CUL_0
LASTInputDev HMLAN_2
Dem entnehme ich, dass alle 3 IODev tatsächlich das Schalt-Kommando in derselben Sekunde gesendet haben (Mehrfachkommando), wo ich erwartet hätte, dass nur das das Kommando sendet, dass beim letzten Schaltvorgang das beste RSSI hatte (VCCU Dispatcher gesteuert).
Zudem überrascht mich hier konkret noch, dass das LASTInputDev tatsächlich das mit dem schlechtesten RSSI ist.
Aber vielleicht habe ich da noch einen Gedankenfehler.
Das mit dem "Mehrfachkommando" ist bei mir auch oft so, aber nicht generell.
Das LASTInputDev sagt ja bloß, dass er nur als letztes von ihm empfangen hat.
Und immerhin ist ja der mit dem Besten rssi als IODev eingetragen, ist bei mir auch so. ;)
Ich habe mir darüber noch nicht soviel Gedanken gemacht...
die internals daten der gateways waren sicherlich messages vom device an die zentrale (sieht man gut an der message). wahrscheinlich sind hier nur die empfangenen messages zu sehen, bin mir aber nicht sicher.
in der vccu sind wahrscheinlich dann die von der zentrale gesendeten zu sehen.
ausserdem empfangen die nicht sendenden io auch die gesendeten messages des sendenden io. ob gesendet oder empfangen wurde lässt sich schon mal an dieser stelle gar nicht unterscheiden.
sniffe wie im wiki beschrieben und schaue dir die messages in fhem.log an.
unter get hminfo msgStat siehst du die anzahl gesendeter messages pro io. mit geschickter verteilung von prefered io aller devices, kannst du die sendenden io bestimmt schön erkennen.
Hi,
also hier nochmal alle Internals, inklusive der Messages (sorry für die Formattierung).
CUL_0_MSGCNT 8
CUL_0_RAWMSG A0E2F8002656A20F110340101000034::-52:CUL_0
CUL_0_RSSI -52
CUL_0_TIME 2019-03-24 09:32:06
DEF 656A20
HMLAN_1_MSGCNT 8
HMLAN_1_RAWMSG E656A20,0000,AEB21C47,FF,FFBC,2F8002656A20F110340101000034
HMLAN_1_RSSI -68
HMLAN_1_TIME 2019-03-24 09:32:06
HMLAN_2_MSGCNT 8
HMLAN_2_RAWMSG E656A20,0000,050DFA75,FF,FFB2,2F8002656A20F110340101000034
HMLAN_2_RSSI -78
HMLAN_2_TIME 2019-03-24 09:32:06
IODev CUL_0
LASTInputDev HMLAN_2
MSGCNT 24
NAME GangLichtSchalter
NOTIFYDEV global
NR 158
STATE off
TYPE CUL_HM
lastMsg No:2F - t:02 s:656A20 d:F11034 0101000034
protLastRcv 2019-03-24 09:32:06
protRcv 8 last_at:2019-03-24 09:32:06
protSnd 8 last_at:2019-03-24 09:32:06
protState CMDs_done
rssi_CUL_0 cnt:7 min:-55 max:-52 avg:-53.14 lst:-52
rssi_at_CUL_0 cnt:8 min:-52.5 max:-49 avg:-51.06 lst:-52
rssi_at_HMLAN_1 cnt:8 min:-69 max:-66 avg:-67.75 lst:-68
rssi_at_HMLAN_2 cnt:8 min:-92 max:-75 avg:-80.75 lst:-78
Wie gesagt, das sind die Internals eines Schalters, also Empfänger der Befehle.
Das mit dem "sniffe wie im wiki beschrieben": könnt ihr mir da nochmal den Link posten? Im VCCU wiki habe ich das nicht gefunden.
Im fhem.log, muss ich da noch irgendein "verbose" level aktivieren? Wonach suche ich?
"get hminfo" teste ich in Ruhe, danke dafür.
Grundsätzlich: ich muss nicht preferred IODev vergeben, um das Aussenden der Befehle über alle IODev zu reduzieren, oder? Das macht der VCCU Dispatcher dynamisch auch, oder?
Moin,
https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen
Und meine Notizen (https://heinz-otto.blogspot.com/search?q=sniffen)
Gruß Otto