[Geklärt] Vorteile/Nachteile und Umsetzung einer VCCU

[maxritti]

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.

[Alcamar]

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. 

[martinp876]

Und getreu dem Motto "Never touch a running system" würde ich nun eigentlich keine VCCU einsetzen wollen.

dann lass es doch einfach!

Aber auch da ist es für mich noch nicht ganz klar, wie die Implementierung aussieht.

wie in Wiki beschrieben!

Muss 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.

So 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.

Denn für mich hört sich die VCCU mal nach etwas zentralem an.

ja. und? was ist jetzt nicht beschrieben?

[Herr 3x]

Im Wiki steht:

Eine 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

[Ralli]

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.

[martinp876]

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?

[maxritti]

Schon mal schönen Dank für die Antworten.

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.

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.

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.

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.

[Herr 3x]

Warum 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.

Ein IO hat fast nichts mit CUL_HM zu tun. Die messages laufen ins leere.

Wieder so ein Satz, den ich überhaupt nicht verstehe  Wie bekommt fhem denn mit, wenn ich einen Schalter drücke, wenn messages in Leere laufen?

Verwirrt: Herr 3x

[Phil__]

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:

Das 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:

hmPairForSec
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

[Ralli]

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:

Code Auswählen Erweitern


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

Code Auswählen Erweitern


attr <dev> IOgrp CCU


Das Attribut IODev wird automatisch von der CCU verwaltet und gesetzt.

[maxritti]

Danke Ralli.
Das denke ich jetzt verstanden zu haben.

Also jetzt wäre die vccu "nur" nice to have.

[Ralli]

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

Code Auswählen Erweitern


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 .

[Alcamar]

@Ralli
bei meinem Device wäre der folgende Eintrag ok?
IOgrp    myVCCU:CUL_0    deleteattr

[Ralli]

Das "deleteattr" hat da nichts zu suchen.

Der Eintrag lautet

Code Auswählen Erweitern


attr <dev> IOgrp myVCCU:CUL_0


oder

Code Auswählen Erweitern


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!

[frank]

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.