Virtueller Controller VCCU

Bitte beachten Sie: Eine VCCU innerhalb FHEM ist nicht zu verwechseln mit einer virtualisierten CCU3! Für letztere gibt es eine eigene Modulfalmilie HMCCU, hier geht es ausschließlich um Geräte des TYPE CUL_HM.

Eine Virtuelle CCU, auch VCCU genannt, ist eine Zentrale für HomeMatic-Geräte. Die VCCU tritt beim Pairing an die Stelle des I/O-Devices (auch "Schnittstelle" genannt, zum Beispiel CUL und HM-CFG-LAN).

HomeMatic-Geräte werden üblicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device (CUL, HM-CFG-LAN, …) selbst. Nachteilig dabei ist, dass der Ausfall der Schnittstelle bewirkt, dass alle gepairten Geräte nicht mehr bedient werden können. Dies lässt sich im Gegensatz zu ungepairten Protokollen (z.b. FS20) auch nicht durch doppelte Definition mit abweichenden IO-Devices lösen, da das Pairing nur mit einer hmId erfolgen kann. Daher kann auch durch mehrere Schnittstellen / IOs keine Redundanz erreicht werden. Ähnliches gilt für eine Vergrößerung der Funkabdeckung durch mehrere Schnittstellen.

Dieses Problem kann durch eine VCCU gelöst werden. Die VCCU ist eine virtuelle Zentrale; sie tritt beim Pairing an die Stelle der Schnittstelle. Sie erhält eine eigene hmId, mit der die HM Sensoren und Geräte gepaired werden. Die Funkschnittstelle(n) werden dann von der VCCU als reine "dumme" IOs verwaltet. Dieses bietet vielfältige Möglichkeiten, z.B. die Verwendung mehrerer IOs, aus denen die VCCU die "beste" nach diversen Kriterien (z.B. RSSI) auswählt. Dadurch kann sowohl die Redundanz als auch die Funkabdeckung erhöht werden.

Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

• Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
• Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
• Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte gepeert werden können.
• "Geordnete" Termination von Nachrichten (da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträgen im Log)

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom FHEM.

Kurzbeschreibung

Ein virtueller Controller VCCU ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) z.b. den HM-CFG-LAN LAN Konfigurations-Adapter einer "klassischen" FHEM Konfiguration

Es können einer VCCU einzelne oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere I/O Devices (z.B. CULs und HM-CFG-LANs) zu einem Pool. Den HM-Devices in FHEM (Aktoren, Sensoren) kann dann als I/O Device die VCCU zugeordnet werden, dies geschieht durch das Attribut IOgrp.

Durch diese Gruppierung der I/O Devices und dem Zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges I/O Device im Device Pool der VCCU ausfallen und das oder die verbliebenden I/O Devices übernehmen diese Funktion (abhängig von der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare I/O Device zum Senden/Empfangen verwenden.

Ein weiterer Vorteil ist, dass durch die VCCU auch das I/O 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)

Mehrere VCCUs in einer Installation

Theoretisch erlaubt FHEM die parallele Nutzung mehrerer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann bereits eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen CUL und ein HM-CFG-LAN.

Jede VCCUs muss eine eindeutige HomeMatic-ID haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit einer VCCU gepaired werden.

Die VCCU überschreibt die hmid eines I/O Device mit seiner eignen, daher können nicht mehrere VCCUs dasselbe I/O Device verwenden.

Definition der VCCU

hmId wählen

Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine hmId. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer hmId versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die hmId an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Damit haben alle von einer VCCU genutzten I/Os nach der Zuweisung dieselbe hmId.

• Definiert man eine VCCU nachdem IOs für HomeMatic angelegt und in Verwendung sind, sollte man die hmId der bereits vorhandenen Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen.
• Hat man bereits mehrere Funkschnittstellen im Einsatz, werden diese unterschiedliche hmIds haben, zumindest eine Schnittstelle wird nach der Zuweisung zur VCCU seine hmId also ändern.
• Für mit dieser Schnittstelle schon gepairte Devices ist ein Neupairen unumgänglich.

Außerdem muss in jedem Fall das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so

attr <device> IOgrp <Name der vccu>

(Siehe weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat der Inhalt des vorhandenen Attributes IODev eines HM_Devices keine Wirkung mehr. Statt dessen setzt die VCCU ein Internal IODev automatisch je nach Verfügbarkeit und Funklage. Das Attribut IODev ist dann nicht mehr notwendig und kann auch nicht mehr gesetzt werden, wenn IOgrp gesetzt ist.

Einrichten

Achtung, die Reihenfolge der Befehle muss exakt eingehalten werden.

Diese Befehlsfolge erzeugt eine VCCU, bitte die Reihenfolge genau so abarbeiten!

CUL_HM ist leider nicht Raw Definition fähig!

Die Werte in <> durch die echten Werte ersetzen und die <> weglassen! Beispiel: attr VCCU IOgrp VCCU

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installation.

IOList beinhaltet die Komma-getrennte Liste der IOs (keine Leerzeichen!), so wie sie in FHEM angelegt sind.

define <Name der vccu> CUL_HM <hmId>
attr <Name der vccu> model CCU-FHEM
attr <Name der vccu> IOList <Name des io1>[,<Name des io2>,...]
attr <Name der vccu> IOgrp <Name der vccu>

Die folgende Darstellung mit zwei IOs im Raw Definition Format dient nur als Beispiel. Diese Abfolge ist nicht zum Anlegen der VCCU geeignet!

Es seien z.B. in FHEM bereits die beiden Schnittstellen HMLAN0 und CUL0 angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
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

Dann kann zusätzlich die VCCU mit derselben hmId angelegt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU IOgrp VCCU
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandenen Schnittstellen abweichenden hmId angelegt, so wird die hmId der ihr zugewiesenen Schnittstelle(n) automatisch angepasst. Dies hat in der Regel zur Folge, dass HM Devices neu gepairt werden müssen.

Dies trifft auch zu, wenn bereits vorhandene Schnittstellen unterschiedliche hmIDs haben, dann wird sich die hmID mindestens einer Schnittstelle ändern. (Der Einfachheit halber war im obigen Beispiel angenommen, dass auch vorher die beiden Schnittstellen bereits die gleiche ID hatten.)

Auswirkungen auf IOs / Funkschnittstellen

Sind IOs durch das Attribut IOList einer VCCU zugewiesen und werden die notwendigen Attribute im IO gesetzt, so wird die hmId 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 den Internals owner und owner_CCU des IO automatisch eingetragen.

Was passiert beim Austausch/Wegfall von IOs

Häufig wird das Thema VCCU erst angefasst, wenn das System schon eine Weile besteht und ein zweiter IO eingebaut, oder der alte IO ausgetauscht werden soll. Dabei entsteht folgende ungünstige Struktur in der fhem.cfg

...
define erster IO
...
define alle möglichen HM Geräte
...
define VCCU
define neuer IO

Beim Start von FHEM wird die cfg Zeilenweise abgearbeitet und für jedes HM Gerät geprüft ob ein IO vorhanden ist, gegebenenfalls erfolgt ein Fehlereintrag im Log (unknown IODev specified). Wenn der neue IO erst am Ende der cfg definiert ist, ist er für alle davor liegenden HM Geräte nicht vorhanden. Das ist nur ein Schönheitsfehler beim Start von FHEM, im laufenden Betrieb spielt das keine Rolle.

Folgende Struktur wäre erstrebenswert

...
define Homematic IO 1
define Homematic IO 2
define VCCU
define HM Geräte 
...

Solange kein Modul die Einträge in der fhem.cfg entsprechend einsortiert, muss diese Korrektur von Hand erfolgen. Dies ist einer der wenigen Fälle, wo direktes Editieren der fhem.cfg z.B. mit dem eingebautem Editor unumgänglich ist. Soll der im Standard-WEBinterface von FHEM eingebaute Editor verwendet werden, muss zuerst das Attribut

attr WEB editConfig 1

in FHEM gesetzt werden. Anschließend die kompletten define Blöcke mit allem was dazu gehört entsprechend in die empfohlene Struktur bringen. Datei sichern und rereadcfg eingeben.

Pairen von HM Devices

Ein erneutes Pairen nach dem Anlegen einer VCCU in bestehenden Installationen ist nicht notwendig!

Neue HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle

 hmPairForSec

also z.b.

 set VCCU hmPairForSec 600

oder

 hmPairSerial

verwendet.

Es ist alternativ weiter möglich - auch nach Anlage einer VCCU - HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev).

Da die VCCU und alle IOs die selbe hmId teilen, hat diese nicht die Wirkung, dass das Geräte etwa nicht mit der VCCU, sondern nur mit dem gepairten IO angesprochen werden kann.

Ist der Pairvorgang nicht sofort (oder nur teilweise) erfolgreich, kann/muss er ohne Weiteres 2 bis 3 mal wiederholt werden. Dann sollte das Gerät erfolgreich gepairt sein. Mit hmInfo configCheck kann das einfach überprüft werden. Mitunter kann es auch sinnvoll sein, das Gerät in den Auslieferungszustand zu bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut zu pairen.

Autocreate

Sofern Autocreate eingeschaltet ist und das Pairing wie oben beschrieben an die VCCU erfolgt, wird unter anderem für das Device folgendes Attribut angelegt:

attr <device> IOgrp VCCU:<PhysischesIO>

z.B.

attr Thermostat_Bad IOgrp VCCU:HMLAN1

Das attr <device> IOgrp:... zeigt an, welches physikalische IO zum Zeitpunkt des Autocreates verwendet wurde, vermutlich ist das das IO mit der besseren Funklage (wenn mehrere existieren). Dasselbe IO wird mit

IOgrp VCCU:HMLAN1

auch als prefered eingetragen. D.h. die VCCU wird später zuerst prüfen ob HMLAN1 verfügbar ist (condition=ok) und es dann verwenden, andere IOs werden nur verwendet, wenn HMLAN1 nicht verfügbar ist. Dieser Eintrag kann manuell geändert werden, Details im folgenden Abschnitt.

Dynamisches IO

Ohne VCCU sendet das System Befehle an ein HM Device 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. Außerdem kann eine bewegliche Fernbedienung ihre Verbindung zu einem IO verlieren, obwohl sie über ein anderes IO gut kommunizieren könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp

attr <device> IOgrp <vccu>:<preferredIO>

kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: 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.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt

attr <device> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>

Beispiele:

Durch

attr <device> IOgrp VCCU:HMLAN1

wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok. Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch

attr <device> IOgrp VCCU

wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redundanz bei Ausfall einer Schnittstelle erhalten.

Bemerkungen

Die besprochene Steuerung betrifft das Senden. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen. Kanäle senden nicht selbständig und haben daher auch kein Attribut IOgrp.

IOgrp bei nachträglicher Einrichtung einer VCCU

Wie erwähnt wird beim Verwenden von Autocreate das Attribut IOgrp mit angelegt. Bei HM Devices die vor der Einrichtung einer VCCU angelegt wurden, fehlt das Attribut aber. Es wird empfohlen, das Attribut IOgrp in solchen Devices zu nachträglich setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp.
Das Attribut IODev wird dann automatisch gelöscht, wenn es gesetzt war, Usereinträge haben keine Funktion.

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

In einer bestehenden FHEM-Installation mit mehreren/vielen Devices, kann das Setzen der IOgrp aufwendig sein.

Mit folgendem Befehl werden alle Geräte mit einer 6 stelligen DEF (HEX Zahl) um das notwendige Attribut erweitert. Die DEF 000000 (ActionDetector) wird ausgespart.

Zunächst kann man den Filter testen und damit die Auswirkung auf Geräte prüfen.

list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}

Bitte nur VCCU durch den echten Namen der VCCU ersetzen!

attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU

Anschließend nicht vergessen, die Konfiguration mit save zu speichern.

Virtuelle Kanäle der VCCU

Die virtuellen Kanäle der VCCU funktionieren nicht als:

1. virtueller Fensterkontakt
2. virtueller Temperaturfühler
3. virtueller HM-CC-TC
4. virtueller TeamLead für Rauchmelder

Siehe Beispiel in HM-CC-RT-DN im Abschnitt externe Sensoren

→ Siehe auch: HomeMatic#IO_Entities

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte IO-Entities, 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 einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden. Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

Anlegen

 set VCCU virtual <Anzahl Button>

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

→ Siehe auch: commandref/CUL_HM-set-virtual

Verfügbare Kommandos auflisten:

 get vccu_Btn1 cmdList

Insbesondere gibt es:

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