HomeMatic Peering Beispiele: Unterschied zwischen den Versionen

Aus FHEMWiki
Keine Bearbeitungszusammenfassung
Zeile 2: Zeile 2:


= Grundlagen =
= Grundlagen =
Peeren ist das Verknüpfen von Kanälen (Channels), um diese auch ohne Zentrale kommunizieren zu lassen. Mittels peering sendet ein Sensor-kanal (remote, push-button, Bewegungsmelder,...) trigger an einen Aktor-Kanal.  
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 Devices
* peeren kann man nur Channels, nicht HomeMatic-Geräte. Die Peer-Listen der verschiedenen Kanäle eines Gerätes sind unabhängig voneinander.
* gepeert wird immer ein Sensor mit einem Aktor
* gepeert werden immer ein oder mehrere Sensorkanäle mit einem oder mehreren Aktorkanälen
* Ein Sensor kann mit mehreren Aktor-kanälen gepeert sein
* 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.
* Ein Aktor-channel kann mit mehreren Sensor-kanälen gepeert sein.
* der Sensor sendet eine Trigger, evtl mit einem Zusatz-wert. Es ist '''immer''' der Aktor-Kanal, der festlegt, welche Aktion ergriffen wird. Ein Button weiß also nicht, ob er ein Ein- oder Ausschalter ist, das weiss nur der Aktor! Ein Button kann demnach gleichzeitig ein Einschalter in einem Aktor und ein Ausschalter in einem anderen Aktor sein.


==Sensoren ==
==Sensoren ==
Ist ein Sensor mit einem Aktor gepeert, gibt es meist nur wenig mögliche Einstellungen. Man kann meist einstellen, dass der Peer mit burst aufgeweckt werden muss (Register peerNeedsBurst). Auch ob man mit AES rechnen muss ist einstellbar (Register expectAES).
Ist ein Sensorkanal mit einem Aktorkanal gepeert, gibt es meist nur wenig mögliche Einstellungen. Wichtige Beispiele sind
===LEDs===
* Notwendigkeit, den Peer mit einem burst aufzuwecken (Register peerNeedsBurst).  
Ein ungepeerter Sensor Kanal 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 (ACK gesendet) haben. Sollten nicht alle peers ein ACK senden wird mit rot quittiert.  
* 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==
==Aktoren==
Ist ein Sensor an den Aktor gepeert, muss im Aktor 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 multiExec in der Gruppe long.
Ist ein Sensorkanal mit diesem 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.
===Condition table===
===Condition Table===
Mit den Register 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 des Einträgen in der CT-tabelle verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt.
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 des Einträgen in der CT-tabelle verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt.
Register zur Conditiontable sind:
Register zur Conditiontable sind:
   CtDlyOff |  literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
   CtDlyOff |  literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
Zeile 25: Zeile 25:
   CtValHi  |0 to 255  | Condition value high for CT table
   CtValHi  |0 to 255  | Condition value high for CT table
   CtValLo  |0 to 255  | Condition value low for CT table
   CtValLo  |0 to 255  | Condition value low for CT table
Remotes liefern keinen Zusatzwert. Die Conditontable wird nicht genutzt.  
Remotes liefern keinen Zusatzwert. Die Conditon Table wird nicht genutzt.  
===jump table===
===Jump Table===
In der Jumptable wird festgelegt, zusammen mit ActionType, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig
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.


===internal peers===
===Interne Peers===
Aktoren können eingebaute oder direkt angeschlossene Taster oder Taster-eingänge haben. Faktisch sind diese auch peers. Per Default sind diese nicht sichtbar. Man muss den Befehl
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 intKeysVisib visib
   set <device> regSet intKeysVisib visib
eingeben, um diese sichtbar und einstellbar zu machen.
sichtbar und einstelllbar gemacht werden.
==virtuelle Entities==
==virtuelle Entities==
Peeren kann man auch <u>[[HomeMatic#Virtuelle_Entities|virtuelle Entities]]</u>. Diese können also Aktor oder Sensor genutzt werden. Das peeren erfolgt wie bei realen Entities. Da die Peers nicht im realen Device gespeichert werden wird es im Config-file abgelegt. Nach einem peeren ist somit ein '''save''' unerlässlich.  
Peeren kann man in Fhem auch <u>[[HomeMatic#Virtuelle_Entities|virtuelle Entitäten]]</u>, diese können als Aktor oder Sensor genutzt werden. Das Peering erfolgt wie bei realen Homematic-Geräten. Da diese virtuellen Peers nicht in einem realen Gerät gespeichert werden, sondern nur in de Fhem-Konfiguration bestehen, ist somit nach der Definition ein '''save''' unerlässlich.  
==IO Entities==
==IO Entities==
<u>[[HomeMatic#IO_Entities|IO Entities]]</u> kann man peeren. Hierzu ist das Kommando eerIODev zu nutzen. Siehe unten.
<u>[[HomeMatic#IO_Entities|IO Entities]]</u> kann man peeren. Hierzu ist das Kommando peerIODev zu nutzen. Siehe unten.


= Beispiele=
= Beispiele=

Version vom 25. Juni 2014, 13:57 Uhr

Dieser Artikel beschreibt wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht mit Pairing zu verwechseln - das wäre das Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM über die IOs CUL oder HMLAN). 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.

Sensoren

Ist ein Sensorkanal mit einem Aktorkanal gepeert, gibt es meist nur wenig 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 diesem 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.

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 des Einträgen in der CT-tabelle verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in CTon genutzt. Steht dort geLo wird gprüft, ob der Zusatzwert des triggers grösser oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt. Register zur Conditiontable 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 Conditon 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 intKeysVisib visib

sichtbar und einstelllbar gemacht werden.

virtuelle Entities

Peeren kann man in Fhem auch virtuelle Entitäten, diese können als Aktor oder Sensor genutzt werden. Das Peering erfolgt wie bei realen Homematic-Geräten. Da diese virtuellen Peers nicht in einem realen Gerät gespeichert werden, sondern nur in de Fhem-Konfiguration bestehen, ist somit nach der Definition ein save unerlässlich.

IO Entities

IO Entities kann man peeren. Hierzu ist das Kommando peerIODev zu nutzen. Siehe unten.

Beispiele

Allgemein

Man kann Kanäle ohne Zentrale miteinander peeren. Das funktioniert nur, wenn keines der Devices gepairt ist, was hier nicht betrachtet wird. Es wird nur die Möglichkeit des peerens von Geräten betrachtet, die bereits mit einer Homematic-Zentrale (wie FHEM) gepairt sind. Die Grundsyntax des Befehls lautet:

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

wobei "<sensChan>" den Name des Sensor-Kanals (z.B.Button) und "<actChan>" den Name des Aktor-Kanals widerspiegelt.
Das Kommando unterliegt den allgemeinen Regeln. Besonders ist, dass es auf 2 Devices gleichzeitig wirkt, somit beide beobachtet werden müssen.

Auswirkung

Das Peeren sollte immer in beiden Devices ausgeführt werden, dem Sensor und dem Aktor, was per Default so ist.

Peering der Kanäle einer Fernbedienung mit einem Aktor

Beschrieben wird hier das Peering-Vorgehen einer HM-Fernbedienung mit mehreren Aktor.

 set fb_Btn03 peerChan 0 blind

peert die Kanäle 03 und 04 mit dem Rollo. Dabei wird ein Button für hoch und einer für runter festgelegt.

 set fb_Btn07 peerChan 0 blind single

peert nur den Button 07. Hier wird per Default ein toggle realisiert.

 set fb_Btn07 peerChan 0 blind single unset

löscht den Peer wieder.

Peering von IO Entities

set <name> peerIODev <IO> <btn> [set|unset]
set <name> peerIODev HMLAN1 5 
set <name> peerIODev HMLAN1 7 unset

wobei <IO> der Namen des IO device ist und <btn> die Nummer des virtuellen Kanals. Kanäle von 1 bis 50 sind zulässig. <name> sollte ein Aktor sein, kein Sensor.

Peering manuell

Insbesondere zur wiederherstellung gesicherter Konfigurationen, nicht aber zru normalen Nutzung ist das Kommando

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

gedacht. Hiermit kann man eine Liste von Peers en-block in ein Device schreiben. Die Gegenstelle und die Kommunikation der Beiden wird nicht berücksichtigt.