Virtueller Controller VCCU

Kurzbeschreibung

Ein virtueller Controller VCCU ist der Protokoll-Endpunkt der Zentrale.
Es können einer VCCU einzelne, oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere IO Devices (z.B. CUL's) zu einem Pool. Den Devices in FHEM (Aktoren, Sensoren) kann dann als IO Device die VCCU zugeordnet werden. Dies wird im weiteren als dynamische IO's bezeichnet

Durch diese Gruppierung der IO Devices und dem zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges IO Device im Device Pool der VCCU ausfallen und das oder die verbliebenden IO Devices übernehmen diese Funktion (abhängig der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare IO Device zum senden/empfangen verwenden. Dies ist empfehlenswert für jeden der eine gewisse Ausfallsicherheit einzelner Komponenten erreichen möchte.
Ein weitere Vorteil ist das durch die VCCU auch das IO Device genutzt werden kann welches die beste Funkqualität aufweist. Dies kann z.B. bei beweglichen Sensoren/Aktoren (Fernbedienungen) sinnvoll sein, oder wenn die Funkqualität durch andere Faktoren beeinflusst wird (z.B. Tür/Tor oder andere "bewegliche" Störfaktoren).

Wann ist eine VCCU sinnvoll

Der Einsatz einer VCCU ist immer sinnvoll und sollte auch nur bei der Nutzung eines einzelnen IO Devices in FHEM angelegt sein. Es entstehen keine Nachteile.
Daher gilt die Empfehlung immer eine VCCU anzulegen.

Mehrere VCCUs in einer Installation

FHEM erlaubt die Nutzung mehrer VCCUs parallel. Das System kann in Gruppen aufteilen werden und jeder VCCU eine Reihe von IOs zuweisen.
Empfohlen wird die Definition einer einzigen VCCU, welcher man alle IOs für HM zuweist.

Definition

HMId 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 noch nicht verwendete wählen.
Eindeutig ist im Bereich CUL_HM. Eine HMId eines IO kann/sollte verwendet werden da diese keine CUL_HM Devices sind.

Eine VCCU gibt HMId an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Definiert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die HMId des IO verwendet werden.

In der Regel nimmt man die HMId des IOs, welcher später der VCCU zugeordnet werden soll.

Einrichten

 define vccu CUL_HM <HMId>
 attr vccu model CCU-FHEM
 attr vccu IOList <io1>[,<io2>,...]

IOList beinhaltet die Komma-getrennte Liste der IOs welche die VCCU nutzen soll/darf.

Auswirkungen auf IOs

Sind IOs durch das Attribut IOList einer VCCU zugewiesen werden die notwendigen Attribute im IO gesetzt. Die HMId wird durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in Internals owner und owner_CCU des IO automatisch eingetragen.

Best Current Practice

Folgenden Aktionen sind weiter im IO möglich, sollten aber in der VCCU genutzt werden.

 hmPairForSec
 hmPairSerial

Dynamisches IO

Devices senden in der Regel immer über das gleiche IO device. Fällt es aus wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Weiter gibt es bewegliche Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.
FHEM stellt hierzu 2 Methoden zu Verfügung.

IO Ersatzschaltung

Bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt. Man definiert ein preferredIO.

 attr <dev> IOgrp <vccu>:<preferredIO>

Beispiel:

 attr LichtFlur IOgrp vccu:HMLAN1

FHEM sendet zum Device LichtFlur über HMLAN1 so lange dies verfügbar ist. Bei Ausfall von HMLAN1 aus der IOList des VCCU nach einem Ersatz gesucht.
HMLAN1 muss in der IOList der VCCU enthalten sein.

IO nach Empfangspegel

Bewegliche Fernbedienungen haben naturgemäß kein preferredIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun das IO mit dem aktuell besten Empfangspegel genutzt.

 attr Fernbedienung1 IOgrp vccu

Bemerkungen

Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp.
Das Attribut IODev wird automatisch gesetzt, Usereinträge sind irrelevant. Es zeigt indirekt das letzte genutzte output-device.
Die besprochene Steuerung betrifft das Senden. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.

Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl

Hat man eine bestehende Fhem-Installation mit mehreren/vielen Devices, kann das Setzen der IOgrp aufwändig sein. Erleichtern kann man dies mittels des Befehls:

 attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu
 save

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen).

virtuelle Kanäle der VCCU

Eine VCCU kann bis zu 50 virtuelle Kanäle bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.
Man peert beispielsweise eine virtuellen Kanal mit einem Dimmer um das Verhalten bei Tastendruck lang und kurz festzulegen. Aus der Zentrale kann man den Tastendruck auslösen. Es können mehrere Aktoren an einen virtuellen Kanal gepeert werden und so alle Lichter der Gruppe mit einem "press" verzögerungslos schalten.

Anlegen

 set vccu virtual <AnzahlButton>

z.B.

 set vccu virtual 10

legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

Kommandos

für Kommandos siehe CommandRef und

 get vccu_Btn1 cmdList

insbesondere gibt es

 set vccu_Btn1 press short
 set vccu_Btn1 press long
 set vccu_Btn1 postEvent <condition>