HomeMatic Peering Beispiele

Dieser Artikel beschreibt wie mit FHEM HomeMatic Sensoren und Aktoren gepeert werden können. Peering ist nicht zu verwechseln mit Pairing, d.h. dem Verknüpfen von HomeMatic Geräten mit einer Zentrale (wie beispielsweise FHEM). Details zum Pairing findet man hier.

Grundlagen

Beim Peering (deutsch sinngemäß: Verbindung von Gleichen) handelt es sich um das Verknüpfen von Kanälen (Channels) verschiedender HomeMatic-Geräte, um diese auch ohne Zentrale kommunizieren zu lassen. Nach dem Peering sendet meist ein Sensorkanal (remote, push-button, Bewegungsmelder,...) einen Trigger an einen Aktorkanal des anderen Gerätes. Besonderheiten:

• peeren kann man nur Channels, nicht HomeMatic-Geräte. Die Peer-Listen der verschiedenen Kanäle eines Gerätes sind unabhängig voneinander.
• gepeert werden immer ein oder mehrere Sensorkanäle mit einem oder mehreren Aktorkanälen
• der Sensor sendet einen Trigger, evtl. mit einem Zusatzwert. Es ist immer der Aktorkanal, der festlegt, welche Aktion ergriffen wird. Ein Button kann demnach gleichzeitig ein Einschalter für einen Aktor und ein Ausschalter für einen anderen Aktor sein.

Achtung: Das in vielen mitgelieferten HomeMatic-Anleitungen beschriebene Peering von Kanälen ohne Zentrale funktioniert nur, wenn keines der beiden Geräte gepairt ist. Im Folgenden gehen wir davon aus, dass beide Geräte bereits mit einer HomeMatic-Zentrale (z.B. FHEM) gepairt sind.

Die im Folgenden beschriebenen Kommandos erfordern zur erfolgreichen Ausführung eine Datenübertragung zu den beteiligten Geräten. Bei Aktoren braucht man meist nur etwas Zeit, bei den Sensoren (Tasten, Fernbedienungen) muss man in der Regel den Konfigtaster betätigen. Die Datenübertragung wird durch unregelmäßiges Blinken der LED signalisiert.

Kommandos

peerSmart

 set <actChan> peerSmart <sensChan> 

peerSmart peert (verbindet) interaktiv (durch Auswahlboxen) einen Aktorkanal mit einem Sensorkanal ohne irgendwelche Funktionen und default Werte. Es gibt keine automatischen Verbindungen wie beim direkten Anlernen der Geräte untereinander. Dabei ist <actChan> der Name des Aktorkanals und <sensChan> der Name des Sensorkanals.

 set <actChan> tplSet_<sensChan> <Template> 

tplSet_<sensChan> setzt ein <Template> und damit eine bestimmte Funktion für den vorhandenen peer im Aktor. Der Befehl taucht erst nach einem erfolgreichen peer Vorgang im Menü auf, d.h. die Datenübertragung in beiden Geräten muss abgeschlossen sein! Mit welcher Methode gepeert wurde ist dabei egal. Mit dem Template werden nur Register im Aktor gesetzt (Datenübertragung), zum Sensor wird nichts übertragen.

Dabei ist tplSet_<sensChan> das aus den vorhanden Peers gebildete Kommando und <Template> der Name des Templates welches im System hinterlegt ist.

 set <actChan> tplParaNNN_<sensChan>_(short|long)_<Template>_<Param> 

tplParaNNN_<sensChan> setzt einen zusätzlichen Parameter NNN bei Templates die weitere Parameter benötigen (z.B. Zeit bei autoOff).

Dabei ist tplParaNNN_<sensChan> das aus den vorhanden Peers gebildete Kommando für Parameter fortlaufende Nummer NNN beginnend bei 000, (short|long) der jeweilige Tastdruck und <Template> der Name des Templates welches schon zugweisen wurde sowie <Param> der sprechende Parameterbezeichner.

 set <actChan> tplDel ...

tplDel löscht ein zuvor zugewiesenes Template.

 set <actChan> peerSmart remove_<sensChan>

remove_<sensChan> entfernt ein zuvor gesetztes Peering mit <sensChan>.

peerChan

 set <sensChan> peerChan 0 <actChan> [single|dual] [set|unset]

peerChan peert (verbindet) einen Sensorkanal mit einem Aktorkanal. Dabei ist <sensChan> der Name des Sensorkanals und <actChan> der Name des Aktorkanals.

• Mit dem Schlüsselwort single wird genau dieser Sensorkanal gepeert.
• Mit dem Schlüsselwort dual werden zwei zusammengehörende Sensorkanäle mit dem Aktorkanal verknüpft. Die beiden Sensorkanäle lösen unterschiedliche Aktionen aus, beispielsweise an und aus.
• Das Schlüsselwort set legt das Peering an, das Schlüsselwort unset hebt es auf.

Das Kommando unterliegt den allgemeinen Regeln. Es wirkt auf zwei Geräte gleichzeitig, weshalb beide Geräte beobachtet werden sollten – ggf. muss an einem oder beiden Geräten die Anlerntaste gedrückt werden.

peerIODev

 set <actChan> peerIODev <IO> <chan> [set|unset]

peerIODev peert (verbindet) einen Aktorkanal mit einem I/O-Device. Dabei ist <IO> der Namen des I/O-Devices und <chan> die Nummer des virtuellen Kanals ist. Kanäle von 1 bis 50 sind zulässig.

peerBulk

 set <sensChan> peerBulk <peer1,peer2,...>

peerBulk dient der Wiederherstellung einer gesicherten Konfiguration. Dieser Befehlt erlaubt eine Liste von Peers en-block in ein Gerät zu schreiben. Die Gegenstelle und die Kommunikation der Beiden wird nicht berücksichtigt.

Sensoren

Ist ein Sensorkanal mit einem Aktorkanal gepeert, gibt es meist nur wenige mögliche Einstellungen. Wichtige Beispiele sind

• Notwendigkeit, den Peer mit einem burst aufzuwecken (Register peerNeedsBurst).
• Erwartung von AES-Verschlüsselung/Authentifizierung (Register expectAES).

LED

Ein ungepeerter Sensorkanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert, wird mit einer grünen LED signalisiert, dass ALLE Peers den Empfang des Triggers bestätigt (d.h. "ACK" gesendet) haben. Sollten nicht alle Peers eine Bestätigung senden, wird mit einer rot LED quittiert.

Aktoren

Ist ein Sensorkanal mit einem Aktorkanal gepeert, muss im Aktorkanal eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit R-<peername>... zusammengefasst sind. Meist sind 2 Gruppen je Peer vorhanden, eine für langen lg und eine für kurzen sh Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das Register multiExec in der Gruppe long.

Für das Setzen des Wertes im Aktorkanal gilt die Syntax

  set <actChan> regSet <register> <value> <peername>

Condition Table

Mit den Registern der Condition Table CT kann man Trigger filtern. So sendet beispielsweise ein Fensterkontakt einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, Hi und Lo. Der Zusatzwert des Triggers wird entsprechend der Einträge in der CT verglichen. Ist der Schalter z.B. an, dann wird beim Eintrag in CtOn nachgesehen. Steht dort geLo wird geprüft, ob der Zusatzwert des triggers größer oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt. Register zur Condition Table sind:

  CtDlyOff |  literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
  CtDlyOn  |  literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
  CtOff    |  literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
  CtOn     |  literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
  CtValHi  |0 to 255  | Condition value high for CT table
  CtValLo  |0 to 255  | Condition value low for CT table

Remotes liefern keinen Zusatzwert. Die Condition Table wird nicht genutzt.

Jump Table

In der Jump Table wird zusammen mit ActionType festgelegt, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig.

Interne Peers

Aktoren können eingebaute oder direkt angeschlossene Taster oder Tasteneingänge haben, die auch als Peers verarbeitet werden. Normalerweise sind diese nicht sichtbar, sie können aber durch Absetzen des Befehls

 set <device> regSet intKeyVisib visib

sichtbar und einstellbar gemacht werden.

Virtuelle Entities

Soll ein FHEM-Befehl bei einem Aktor nicht nur eine Aktion auslösen, muss er mit einem Kanal einer virtuellen Entität oder einer IO Entität gepeert werden. Das Peering erfolgt wie bei realen HomeMatic-Geräten. Achtung: da diese virtuellen Peers nicht in einem realen Gerät gespeichert werden, ist nach der Definition ein Save config nötig.
Dadurch lassen sich nicht nur einfache Befehle je Kanal aussenden, sondern die Peering-Listen in Aktoren nutzen um mit einem Funkbefehl z.B.

• Schleifen zu starten (z.B. bei Alarmauslösung ein Pulsieren der Beleuchtung, alle x Min eine kurze Unterbrechung, ...)
• Abläufe zu starten (z.B. Treppenhauslicht mit Vorwarnung bei Dimmern, ...)
• mehrere Aktoren gleichzeitig schalten zu lassen

Sonst müsste man für jede Zustandsänderung bzw. für jeden Aktor einen eigenen Befehl senden. Somit reagieren mehrere Aktoren auf ein FHEM-Kommando gleichzeitig.

IO Entities

IO Entities sind virtuelle Kanäle eines IO-Devices (z.B. VCCU, HMLAN, ...) und können somit gepeert werden. Hierfür gibt es das Kommando peerIODev.

Beispiele

Peering der Kanäle einer Fernbedienung mit einem Aktor

Dabei muss beachtet werden, dass auf den Fernbedienungen immer zwei Buttons zusammengehören, also z.B. lock/unlock, open/light oder Btn01/Btn02, Btn03/Btn04. Achtung: Für ein erfolgreiches Peering muss ggf. auf der Fernbedienung die Anlerntaste gedrückt werden.

Bei einem "dual" Peering werden die beiden zusammengehörenden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - einer der Buttons wirkt dann als "on", der andere als "off"-Schalter.

 set fb_Btn03 peerChan 0 blind

peert die Buttons Btn03 und Btn04 mit dem Aktorkanal blind

Bei einem "single" Peering wird nur einer der beiden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - als Aktion wird dann im Aktorkanal ein "toggle" eingetragen.

 set fb_Btn07 peerChan 0 blind single

peert nur den Button Btn07 mit dem Aktorkanal blind

Das Unpeering, also das Löschen einer Paarung, erfolgt z.B. durch den Befehl

 set fb_Btn07 peerChan 0 blind single unset

Peering von I/O-Entities

set blind peerIODev HMLAN1 5
set blind peerIODev HMLAN1 7 unset