Virtueller Controller VCCU: Unterschied zwischen den Versionen
(→Einrichten: Beispiel) |
(→Einrichten: Ergänzung im Abschnitt VCCU) |
||
(104 dazwischenliegende Versionen von 14 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{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]]). | |||
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 [[HomeMatic Peering Beispiele|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 | 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== | == Mehrere VCCUs in einer Installation== | ||
FHEM | 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. | |||
== Definition == | 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 === | === hmId wählen === | ||
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen ist dies eine ''hmId''. Da die VCCU | 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 hmId an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. | 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 | * 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 === | ||
{{Randnotiz|RNTyp=g|RNText=Achtung, die Reihenfolge der Befehle muss exakt eingehalten werden.}} | |||
Diese Befehlsfolge erzeugt eine VCCU, bitte die Reihenfolge genau so abarbeiten! | |||
{{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. | |||
Es seien z. | ''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 | define HMLAN0 HMLAN 192.168.168.2:1000 | ||
Zeile 55: | Zeile 73: | ||
attr CUL0 icon cul_cul | attr CUL0 icon cul_cul | ||
attr CUL0 rfmode HomeMatic | attr CUL0 rfmode HomeMatic | ||
Dann | 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> | |||
define | === 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 | 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 == | ||
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 === | === Bemerkungen === | ||
Es wird empfohlen, das Attribut IOgrp in | 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, Usereinträge | |||
=== 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.<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== | == 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. | {{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 | set VCCU virtual <Anzahl Button> | ||
z.B. | z.B. | ||
set | 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 === | ||
: ''→ Siehe auch: {{Link2CmdRef|Anker=CUL_HM-set-virtual}}'' | |||
Verfügbare Kommandos auflisten: | |||
get vccu_Btn1 cmdList | get vccu_Btn1 cmdList | ||
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:HomeMatic | |||
[[Kategorie:HOWTOS]] | [[Kategorie:HOWTOS]] |
Aktuelle Version vom 20. Dezember 2022, 12:55 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 ü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
Diese Befehlsfolge erzeugt eine VCCU, bitte die Reihenfolge genau so abarbeiten!
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
- virtueller Fensterkontakt
- virtueller Temperaturfühler
- virtueller HM-CC-TC
- virtueller TeamLead für Rauchmelder
- → 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>