Virtueller Controller VCCU: Unterschied zwischen den Versionen

Aus FHEMWiki
Zeile 55: Zeile 55:


Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) setzt das Attribut bei allen Devices, und zwar allen, deren '''DEF''' genau 6 Zeichen lang ist.
Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) setzt das Attribut bei allen Devices, und zwar allen, deren '''DEF''' genau 6 Zeichen lang ist.
Mittels des Befehls


== virtuelle Kanäle der vccu==
== virtuelle Kanäle der vccu==

Version vom 12. Februar 2015, 09:21 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.
FHEM erlaubt die Nutzung mehrer vccus parallel. Der Nutzer kann damit sein System in Gruppen aufteilen und jeder vccu eine Reihe von IOs zuweisen.
Empfohlen wird die Definition einer einzigen vccu, welcher man alle IOs für HM zuweist.


Anders ausgedrückt:

Manchmal ist es sehr hilfreich, mehrere HM Sender (=IOs) im Gebäude zu verteilen. Beispielsweise weil einige Geräte nicht mehr zuverlässig in Funkreichweite sind. Die VCCU kümmert sich dann automatisch darum, mit welchem Sendemodul (also HM-CFG-LAN, HM-CFG-USB oder CUL) die einzelnen HM Aktoren am besten angesprochen werden können.

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 Wählen, die noch nicht verwendet wird.
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.
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.

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>,...]

Auswirkungen auf IOs

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.

Best Current Practice

Folgenden Aktionen sind weiter möglich, werden aber besser in der vccu erledigt

 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. Ferner könnte man bewegliche Fernbedienungen haben, welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.
Es können hierzu 2 Methoden angewendet werden.

IO Ersatzschaltung

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 sinnvoll sein, wenn das bevorzugte IO ausgefallen ist. Diese Zuordnung macht man über

 attr <dev> IOgrp <vccu>:<preferedIO>

In der Praxis könnte es heißen

 attr LichtFlur IOgrp vccu:HMLAN1

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.
HMLAN1 muss in der IOList der vccu eingerichtet sein, incl preferedIO.

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

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) setzt das Attribut bei allen Devices, und zwar allen, deren DEF genau 6 Zeichen lang ist.

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>