Virtueller Controller VCCU: Unterschied zwischen den Versionen

Aus FHEMWiki
K (Einrichtun angepasst: http://forum.fhem.de/index.php/topic,28568.msg214487.html#msg214487)
(→‎Einrichten: Ergänzung im Abschnitt VCCU)
 
(129 dazwischenliegende Versionen von 18 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Ein virtueller Controller '''vccu''' ist der Protokoll-Endpunkt der Zentrale.  
{{Randnotiz|RNTyp=r|RNText=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 (HomeMatic)|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).
Weiter können Ihr IO devices zugeordnet werden und IOs dynamisch verwaltet werden.  
 
== Wann macht eine vccu Sinn ==
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.  
Eine vccu sollte '''immer''' angelegt werden. <br>
 
FHEM erlaubt die Nutzung mehrer vccus parallel. Der Nutzer kann damit sein System in Gruppen aufteilen und jeder vccu eine Reihe von IOs zuweisen.<br>
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.
Empfohlen wird die Definition einer einzigen vccu, welcher man alle IOs für HM zuweist.  
 
== Definition ==
Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:
=== 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 Wählen, die noch nicht verwendet wird. <br>
* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
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. <br>
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
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.<br>
* Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte [[HomeMatic Peering Beispiele|gepeert]] werden können.
<br>
* "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)
In der Regel nimmt man die HMId des IOs, welcher später der vccu zugeordnet werden soll.
 
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 ===
=== Einrichten ===
  define vccu CUL_HM <HMId>
{{Randnotiz|RNTyp=g|RNText=Achtung, die Reihenfolge der Befehle muss exakt eingehalten werden.}}
  attr vccu model CCU-FHEM
Diese Befehlsfolge erzeugt eine VCCU, bitte die Reihenfolge genau so abarbeiten!
  attr vccu IOList <io1>[,<io2>,...]
{{Randnotiz|RNTyp=r|RNText=CUL_HM ist leider nicht Raw Definition fähig!}}
Die Werte in <> durch die echten Werte ersetzen und die <> weglassen! Beispiel: <code>attr VCCU IOgrp VCCU</code>
 
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.<pre>
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>
</pre>
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. <br>
 
=== 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.


=== Auswirkungen auf IOs===
=== Pairen von HM Devices===
Sind IOs durch das Attribut IOList einer vccu zugewiesen werden die entsprechenden 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 eingetragen. <br>
Ein erneutes Pairen nach dem Anlegen einer VCCU in bestehenden Installationen ist nicht notwendig!
=== Best Current Practice ===
Folgenden Aktionen sind weiter möglich, werden aber besser in der vccu erledigt
Neue HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
   hmPairForSec
   hmPairForSec
also z.b.
  set VCCU hmPairForSec 600
oder
   hmPairSerial
   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 ==
== Dynamisches IO ==
Devices senden in der Regel immer über das gleiche IO device. Kommt es zu einem Ausfall werden keine Nachrichten mehr gesendet, auch wenn ein zweites IO bereit stehen würde. Ferner könnte man bewegliche Fernbedienungen haben, welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.<br>
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.
Es können hierzu 2 Methoden angewendet werden.
 
=== IO Ersatzschaltung ===
Die VCCU adressiert beide Probleme:
Bei stationären Devices - meist die Masse der genutzten Devices - kann man i.d.R. das beste IO finden und will dies nutzen. Eine Umschaltung auf ein 2. IO würde nur Sinn machen, wenn das bevorzugte IO ausgefallen ist. Diese Zuordnung macht man über
 
  attr <dev> IOgrp <vccu>:<preferedIO>
Durch das Attibut IOgrp 
In der Praxis könnte es heißen
attr <device> IOgrp <vccu>:<preferredIO>
  attr LichtFlur IOgrp vccu:HMLAN1
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.
FHEM sendet zum Device LichtFlur immer über HMLAN1, so lange dies verfügbar ist. Sollte HMLAN1 nicht mehr erreichbar sein wird im Attribut IOList der vccu nach einem Ersatz gesucht. <br>
 
HMLAN1 muss in der IOList der vccu eingerichtet sein, incl preferedIO. <br>
Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.
=== IO nach Empfangspegel ===
 
Bewegliche Fernbedienungen haben naturgemäß kein preferedIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun versucht, das IO mit dem aktuell besten Empfangspegel zu nutzen.
Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt
  attr Fernbedienung1 IOgrp vccu
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 ===
=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp.<br>
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.
Das Attribut '''IODev''' wird automatisch gesetzt, der User muss hier nichts mehr eintragen. Es ist aus Systemgründen weiter notwendig und kann sich verändern. Es zeigt das letzte genutzte output-device an.<br>
 
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.
=== IOgrp bei nachträglicher Einrichtung einer VCCU ===
== virtuelle Kanäle der vccu==
Wie erwähnt wird beim Verwenden von Autocreate das Attribut IOgrp mit angelegt.
Eine vccu kann bis zu 50 virtuelle Kanäle bedienen. Diese können als Sender/Sensoren oder Empfänger eingesetzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern. <br>
Bei HM Devices die vor der Einrichtung einer VCCU angelegt wurden, fehlt das Attribut aber.
Man peert z.B. eine virtuellen Kanal mit einem Dimmer. Nun kann man im Dimmer das Verhalten bei Tastendruck lang und kurz festlegen. Aus der Zentrale kann man schließlich den Tastendruck simulieren, der Dimmer wird reagieren. Selbstverständlich kann man einen virtuellen Kanal mit mehreren Aktoren parallel peeren und so z.B. alle lichter einer Gruppe mit einem "press" ausschalten.  
Es wird empfohlen, das Attribut IOgrp in solchen Devices zu nachträglich setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp.<br>
Das Attribut '''IODev''' wird dann automatisch gelöscht, wenn es gesetzt war, Usereinträge haben keine Funktion.<br>
 
==== 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.
:<code>list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}</code>
 
Bitte nur '''VCCU''' durch den echten Namen der VCCU ersetzen!
:<code>attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU</code>
Anschließend nicht vergessen, die Konfiguration mit '''save''' zu speichern.
 
== Virtuelle Kanäle der VCCU==
{{Randnotiz|RNTyp=r|RNText= Die virtuellen Kanäle der VCCU funktionieren nicht als:
# virtueller Fensterkontakt
# virtueller Temperaturfühler
# virtueller HM-CC-TC
# 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 ===
=== Anlegen ===
   set vccu virtual <AnzahlButton>
   set VCCU virtual <Anzahl Button>
z.B.
z.B.
   set vccu virtual 10
   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.
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 ===
=== Kommandos ===
für Kommandos siehe CommandRef und
: ''→ Siehe auch: {{Link2CmdRef|Anker=CUL_HM-set-virtual}}''
 
Verfügbare Kommandos auflisten:
 
   get vccu_Btn1 cmdList
   get vccu_Btn1 cmdList
insbesondere gibt es  
 
Insbesondere gibt es:
   set vccu_Btn1 press short
   set vccu_Btn1 press short
   set vccu_Btn1 press long
   set vccu_Btn1 press long
   set vccu_Btn1 postEvent <condition>
   set vccu_Btn1 postEvent <condition>
 
   
[[Kategorie:HomeMatic supportDevice]]
   
   
 
[[Kategorie:HOWTOS]]
 
[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

Aktuelle Version vom 20. Dezember 2022, 12:55 Uhr

X mark.svgBitte 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

Info green.pngAchtung, die Reihenfolge der Befehle muss exakt eingehalten werden.

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

X mark.svgCUL_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

X mark.svgDie 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>