Virtueller Controller VCCU: Unterschied zwischen den Versionen
Zeile 32: | Zeile 32: | ||
== 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. | 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. Weiter gibt es bewegliche Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.<br> | ||
Es können hierzu 2 Methoden | Es können hierzu 2 Methoden genutzt werden. | ||
=== IO Ersatzschaltung === | === IO Ersatzschaltung === | ||
Bei stationären Devices - | Bei stationären Devices - der häufigste Fall - sollte man das beste IO finden und nutzen. Eine Umschaltung auf ein zweites IO ist nur bei Ausfall des Ersten sinnvoll. Man definiert ein preferedIO | ||
attr <dev> IOgrp <vccu>:<preferedIO> | attr <dev> IOgrp <vccu>:<preferedIO> | ||
Beispiel: | |||
attr LichtFlur IOgrp vccu:HMLAN1 | attr LichtFlur IOgrp vccu:HMLAN1 | ||
FHEM sendet zum Device LichtFlur | FHEM sendet zum Device LichtFlur über HMLAN1, so lange dies verfügbar ist. Bei Ausfall von HMLAN1 wird über IOList der vccu nach einem Ersatz gesucht. <br> | ||
HMLAN1 muss in der IOList der vccu eingerichtet sein | HMLAN1 muss in der IOList der vccu eingerichtet sein. <br> | ||
=== IO nach Empfangspegel === | === IO nach Empfangspegel === | ||
Zeile 48: | Zeile 48: | ||
=== 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> | Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp.<br> | ||
Das Attribut '''IODev''' wird automatisch gesetzt, | Das Attribut '''IODev''' wird automatisch gesetzt, Usereinträge sind irrelevant. Es zeigt indirekt das letzte genutzte output-device an.<br> | ||
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen. | Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen. | ||
Zeile 55: | Zeile 55: | ||
attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu | attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu | ||
save | |||
Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) | Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen). | ||
== virtuelle Kanäle der vccu== | == virtuelle Kanäle der vccu== |
Version vom 30. Mai 2015, 14:18 Uhr
Ein virtueller Controller vccu ist der Protokoll-Endpunkt der Zentrale. Weiter können Ihr IO devices zugeordnet werden und IOs dynamisch verwaltet werden.
Wann ist eine VCCU sinnvoll
Eine VCCU sollte immer angelegt werden.
Mehrere VCCUs in einer Installation
FHEM erlaubt die Nutzung mehrer VCCUs parallel. Das System kann in Gruppen aufteilen werden und jeder VCCU eine Reihe von IOs zuweisen.
Empfohlen wird die Definition einer einzigen VCCU, welcher man alle IOs für HM zuweist.
Definition
HMId wählen
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein. Man muss also eine noch nicht verwendete wählen.
Eindeutig ist im Bereich CUL_HM. Eine HMId eines IO kann/sollte verwendet werden da diese keine CUL_HM Devices sind.
Eine VCCU gibt HMId an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Definiert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die HMId des IO verwendet werden.
In der Regel nimmt man die HMId des IOs, welcher später der VCCU zugeordnet werden soll.
Einrichten
define vccu CUL_HM <HMId> attr vccu model CCU-FHEM attr vccu IOList <io1>[,<io2>,...]
IOList beinhaltet die Komma-getrennte Liste der IOs welche die VCCU nutzen soll/darf.
Auswirkungen auf IOs
Sind IOs durch das Attribut IOList einer VCCU zugewiesen werden die notwendigen Attribute im IO gesetzt. Die HMId wird durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in Internals owner und owner_CCU des IO automatisch eingetragen.
Best Current Practice
Folgenden Aktionen sind weiter im IO möglich, sollten aber in der VCCU genutzt werden.
hmPairForSec hmPairSerial
Dynamisches IO
Devices senden in der Regel immer über das gleiche IO device. Kommt es zu einem Ausfall werden keine Nachrichten mehr gesendet, auch wenn ein zweites IO bereit stehen würde. Weiter gibt es bewegliche Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.
Es können hierzu 2 Methoden genutzt werden.
IO Ersatzschaltung
Bei stationären Devices - der häufigste Fall - sollte man das beste IO finden und nutzen. Eine Umschaltung auf ein zweites IO ist nur bei Ausfall des Ersten sinnvoll. Man definiert ein preferedIO
attr <dev> IOgrp <vccu>:<preferedIO>
Beispiel:
attr LichtFlur IOgrp vccu:HMLAN1
FHEM sendet zum Device LichtFlur über HMLAN1, so lange dies verfügbar ist. Bei Ausfall von HMLAN1 wird über IOList der vccu nach einem Ersatz gesucht.
HMLAN1 muss in der IOList der vccu eingerichtet sein.
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.
attr Fernbedienung1 IOgrp vccu
Bemerkungen
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp.
Das Attribut IODev wird automatisch gesetzt, Usereinträge sind irrelevant. Es zeigt indirekt das letzte genutzte output-device an.
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 eingesetzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.
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.
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>