Virtueller Controller VCCU: Unterschied zwischen den Versionen

Version vom 27. Januar 2016, 17:32 Uhr

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 überlicherweise 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. 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älen zur Verfügung, mit denen HomeMatic-Geräte gepeert werden können.
"Geordnete" Termination von Nachrichten.

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

Mehrere VCCUs in einer Installation

Theoretisch erlaubt Fhem die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann 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.

Todo: Können mehrere VCCU das selbe I/O-Device nutzen?

Todo: Können HomeMatic-Geräte, die mit unterschiedlichen VCCUs gepaired wurden, untereinander gepeert werden?

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.

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

Allerdings muss das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so

attr <device> IOgrp VCCU

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

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

Einrichten

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

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 Installtion. IOList beinhaltet die Komma-getrennte Liste der IOs, so wie sie in FHEM angelegt sind.

Es seien z.b. in FHEM bereits die beiden Schnittstellen HMLAN und CULHM 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 der selben hmId angelgt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

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

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

Auswirkungen auf IOs / Funkschnittstellen

Sind IOs durch das Attribut IOList einer VCCU zugewiesen, 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.

Pairen von HM Devices

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

 hmPairForSec
 hmPairSerial

verwendet. Es ist im übrigen weiter möglich (aber nicht sinnvoll / empfehlenswert) 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)

Dynamisches IO

FHEM sendet Befehle an 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. Ausserdem gibt es bewegliche Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen werden könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp

attr <dev> 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.

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 Redunanz bei Ausfall einer Schnittstelle erhalten.

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 haben keine Funktion. Es zeigt jedoch 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>

@@ Zeile 1: / Zeile 1: @@
-HM Sensoren und Geräte werden klassisch mit einer (Funk)Schnittstelle ("IO") gepaired, diese ist über die ''hmId'' identifiziert. 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össerung der Funkabdeckung durch mehrere Schnittstellen.
+Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing und Peering|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).
-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 Kritereien (z.B. RSSI) auswählt. Dadurch kann die Redundanz sowohl als auch die Funkabdeckung erhöht werden.
+HomeMatic-Geräte werden überlicherweise 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. Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:
-Zusätzlich bietet eine VCCU weiter Vorteile wie die bessere Unterstützung von HM Kanälen und die "geordnete" Termination von Messages: 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äge im Log.
+* 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älen zur Verfügung, mit denen HomeMatic-Geräte [[Homematic Peering Beispiele|gepeert]] werden können.
+* "Geordnete" Termination von Nachrichten.
+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 ==
+== Mehrere VCCUs in einer Installation==
-Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) zum Beispiel den [[HM-CFG-LAN]] einer "klassischen" Fhem-Konfiguration.
-Einer VCCU kann ein oder mehrere ''I/O-Devices'' (Ein-/Ausgabe-Geräte, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]) zugeordnet werden. Diese I/O-Devices werden zu einem ''Device-Pool'' gebündelt. Den HomeMatic-Geräten in Fhem (Aktoren, Sensoren) kann mit dem <code>IOgrp</code>-Attribut die VCCU als Kommunikationspartner zugeordnet werden.
-Durch diese Gruppierung der I/O-Devices zu einem Device-Pool und der Zuordnung zur VCCU entstehen zwei Vorteile:
-; Ausfallsicherheit
-: Ein beliebiges I/O-Device des Device-Pools der VCCU kann ausfallen und die verbliebenden I/O-Devices übernehmen die Kommunikation, die sonst das ausgefallene I/O-Device bearbeitet hätte (vorausgesetzt das HomeMatic-Gerät befindet sich im Empfangsbereich eines anderen I/O-Devices). Die VCCU wird das nächste verfügbare I/O-Device zum Senden und Empfangen verwenden.
-; Erweiterung des Signalbereichs
-: Die VCCU nutzt das I/O-Device, welches die beste Signalstärke aufweist. Das ist insbesondere bei beweglichen Komponenten (Fernbedienungen) interessant oder wenn die Signalqualität durch andere Faktoren beeinflusst wird, zum Beispiel eine geschlossene Tür.
-== Wann ist eine VCCU sinnvoll ==
-Der Einsatz einer VCCU ist im Grunde immer sinnvoll und sollte auch bei der Nutzung nur eines IO Devices in FHEM angelegt sein, zumindest da dies eine spätere Erweiterung erleichtert.
-Zusätzlich bietet eine VCCU weiter Vorteile wie die bessere Unterstützung von HM Kanälen und die "geordnete" Termination von Messages (keine Logmeldungen der Art
-''HMLAN1: Unknown code A0E2682021DFBCF1DFE3A0101C80028::-65:HMLAN1, help me!'').
-Es entstehen keine Nachteile (ausser des geringen Mehraufwandes der Erstanlage der VCCU)
+Theoretisch erlaubt Fhem die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].
-== Mehrere VCCUs in einer Installation==
-FHEM erlaubt die Nutzung mehrer VCCUs parallel. Das System kann in Gruppen aufgeteilt und jeder VCCU eine Reihe von IOs zuwiesen werden.
-Jede dieser VCCUs hätte dann eine eigene ''hmId'' und HM Sensoren und Geräte würden nur mit einer VCCU gekoppelt werden (können).
-Dies ist jedoch eher eine theoretische Möglichkeit, die in der Regel gegenüber der Anlage einer einzigen VCCU keine Vorteile bietet.
+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.
-Empfohlen wird daher die Definition einer einzigen VCCU, welcher man alle IOs für HM zuweist. Es ist insbesondere nicht erforderlich, mehrere VCCUs für unterschiedliche Schnittstellentypen (CUL, [[HM-CFG-LAN LAN Konfigurations-Adapter|HM-LAN-Konfigurator]] oder HMUSB) einzurichten, vielmehr können alle IOs unabhängig vom Typ an eine VCCU angebunden werden.
+{{Todo|Können mehrere VCCU das selbe I/O-Device nutzen?}}
+{{Todo|Können HomeMatic-Geräte, die mit unterschiedlichen VCCUs gepaired wurden, untereinander gepeert werden?}}
 == Definition der VCCU==