FHEM2FHEM

FHEM2FHEM
Zweck / Funktion
Hilfsmodul, um mehrere FHEM-Installationen zu verbinden
Allgemein
Typ	Hilfsmodul
Details
Dokumentation	EN / DE
Support (Forum)	Automatisierung
Modulname	93_FHEM2FHEM.pm
Ersteller	rudolfkoenig (Forum / Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

FHEM2FHEM ist ein Hilfsmodul mit dem mehrere FHEM-Installationen -auch auf verschiedenen Rechnern- verbunden werden können

Todo: Fehlerkontrolle, Formatierung, Ergänzungen aus dem Forum, Bedeutung des Attributs dummy, Ergänzung Bekannte Probleme

Features / Funktionen

Dieses Modul bietet zwei grundsätzlich unterschiedliche Funktionsmöglichkeiten:

1. Es kann alle Ereignisse (Events) von einem entfernten (remote) host abgreifen und an die lokale FHEM Instanz zur Weiterverarbeitung weiterreichen.
2. Es kann die unaufbereitete Ereignisse (raw messages) von einem entfernten (remote) host und bestimmten Interfaces (z.B.CUL_0, keine einzelnen Endgräte/Aktoren) abgreifen und an die lokale FHEM Instanz weiterreichen.

Die Kommunikation ist unidirektional bzw. die Daten werden auf der lokalen Instanz von einer entfernten Instanz abgegriffen (pull Verfahren). Ein Element vom Type FHEM2FHEM wird auf der lokalen Instanz definiert.

Anwendung

Beispiele für die Anwendung sind

• zur Verteilung der Interfaces auf mehrere FHEM Instanzen,
  • Da an einer Hardwareinstanz ggf. zu wenig USB-Ports vorhanden sind, um stabil betrieben werden zu könne (z.B. RPi).
  • Um eine zeitkritische und eine weniger zeitkritische Hardwareinstanz zu betreiben, da bestimmte Module die FHEM Instanz für eine gewisse Zeit verzögern können (Verzögerungen verursachen z.B. disconnects des HMLan beim keepalive).
  • Um die Hauptinstanz von bestimmten Verarbeitungsschritten der Events zu entlasten, obwohl man hier zunächst untersuchen sollte, ob die Verarbeitung nicht eleganter und weniger Prozessorintensiv ausgeführt werden kann.
• Um längere örtliche Distanzen zu überbrücken,
  • da z.B. die Funkreichweite bestimmter Signale für einen stabilen Betrieb zu gering ist.
  • da ein Sensor nur lokal betrieben werden kann und die Distanz zur Hauptinstanz zu groß ist, z.B. bei direkt per USB an der Hardware Instanz angeschlossen Sensoren (CO2/VOC-Sensor)
• etc.

Lokale und remote FHEM-Instanz sind über ein Netzwerk verbunden.

Definition

Die Definition erfolgt über

define <name> FHEM2FHEM <host>[:<portnr>][:SSL] [LOG:regexp|RAW:devicename] {portpassword} 

Parameter

Die Parameter der Definition beziehen sich auf die Verbindung zur entfernten FHEM-Instanz, zum Type der übernommenen Events und auf das Portpasswort, falls bei der entfernten FHEM-Instanz vergeben.

<host>[:<portnr>][:SSL]

Über <host> ist die IP-Adresse der entfernten FHEM-Instanz zu definieren. Die Portnummer bezieht dich auf die Nummer der Telnetschnittstelle, wie sie auf der entfernten Instanz vergeben ist. Falls nicht explizit verändert, ist diese Nummer standardmäßig 7072. Der letzte Zusatz :SSL muss angegeben werden, wenn die entfernte Instanz eine SSL-verschlüsselte Kommunikation voraussetzt. Ist dieses der Fall, muss auch auf dem lokalen Host das Perl-Modul IO::Socket::SSL installiert sein.

[LOG:regexp|RAW:devicename]

Der nächste Parameter spezifiziert den Verbindungs-Typ:

LOG

Bei Verwendung dieses Verbindungstyps werden alle Ereignisse (Events) der entfernten FHEM-Instanz empfangen. Die Ereignisse sehen aus wie die, die nach dem inform on Befehl erzeugt werden. Sie können wie lokale Ereignisse durch FileLog oder notify genutzt werden und mit einem regulären Ausdruck gefiltert werden. Die Syntax dafür ist unter der notify-Definition beschrieben.

Einschränkungen: Geräte der entfernten FHEM-Instanz werden über autocreate lokal nicht automatisch angelegt und können weder mit list angezeigt noch lokal angesprochen werden.

Falls auf beiden FHEM-Installationen Geräte mit gleichem Namen angelegt wurden und die Geräte auch beide dasselbe Ereignis empfangen können (z.B. wenn an beiden Installationen CULs angeschlossen sind), werden logischer Weise alle FileLogs und notifys doppelt, einmal über das lokale Ereignis, einmal über das remote Ereignis ausgelöst.

RAW

Bei diesem Verbindungstyp werden unaufbereitete Ereignisse (raw messages) des remote FHEM-Geräts devicename genau so empfangen, als wäre das Gerät lokal verbunden.

Einschränkungen: Nur Geräte, welche die "Dispatch-Funktion" unterstützen (CUL, FHZ, CM11, SISPM, RFXCOM, TCM, TRX, TUL), erzeugen raw messages. Für jedes entfernte Gerät, von dem raw messages abgegriffen werden sollen, muss ein eigenes FHEM2FHEM Objekt definiert werden. Dabei ist darauf zu achten, dass der angegebene Name für devicename gleichlautend ist, wie der Devicename auf der entfernten FHEM-Instanz.

Zusätzlich der Definition des FHEM2FHEM Elements, muss für das übernommene Geräte auf der lokalen Instanz ein Dummygerät gleichen Typs, d.h. als device-node "none" definiert werden. An dieses Dummygerät werden alle raw messages von FHME2FHEM weitergeleitet, weshalb auch alle notwendigen Attribute lokal für dieses Dummygerät gesetzt sein müssen (z.B. rfmode, wenn die remote CUL im HomeMatic-Modus läuft). Die Verwendung bereits bestehender lokaler Geräte für die Weiterverarbeitung des raw messages ist zu vermeiden, weil sonst die Duplikatsfilterung nicht richtig funktioniert (siehe dupTimeout).

Komponenten, die über das Dummygerät erkannt werden, werden über autocreate automatisch angelegt.

{portpassword}

Falls ein Portpasswort auf der entfernten FHEM-Instanz gesetzt ist, übergibt dieser Parameter das entsprechende Passwort.

Attribute

dummy

???

disable

Deaktiviert die Verbindung.

disableForIntervals

Das Attribut ist eine leerzeichengetrennte Liste von Minuszeichen- getrennten HH:MM Paaren. Falls die aktuelle Uhrzeit zwischen diesen Werten fällt, dann wird die Ausführung, wie beim disable, ausgesetzt. Eine genaue Beschreibung findet sich in der commandref des Moduls at.

Set

reopen

Öffnet die Verbindung erneut.

Voraussetzungen

• Zwei FHEM-Instanzen verbunden über ein Netzwerk mit der Möglichkeit, von der einen (lokal) auf den Telnetport der anderen (entfernte/remote) zuzugreifen zu können.
• Aktivierter Telnetport der entfernten FHEM-Instanz. Diese ist standardmäßig aktiviert.
• Fall das Perl-Modul für die SSL-Verschlüsselung nicht installiert sein, so kann dieses je nach Platform z.B. über folgenden Befehl nachinstalliert werden:

sudo apt-get install libwww-perl

Anwendungsbeispiele

Type LOG

Verbindung von 2 Fritzboxen

Ich habe lange gesucht, wie ich FHEM2FHEM einsetzen kann. Das folgende habe ich mir (Danke an Rübezahl) von den entsprechenden Seiten zusammengeklaubt:

Code FritzBox 1 (entfernte Instanz):

define forwardRemote dummy

Code FritzBox 2 (lokale Instanz):

define Remoteserver FHEM2FHEM 192.168.178.1:7072 LOG:.*

define executeRemote notify forwardRemote {fhem "$EVENT"}

Gast-WLAN bei beiden Boxen ausschalten (siehe Beitrag "Fritzbox: WLAN ein/ausschalten", Dummys, notifys und 99_myUtils_irgendwas.pm müssen natürlich auf beiden Boxen vorhanden sein):

Aufruf FritzBox 1:

fhem("set D_G_WLAN off");;fhem("set forwardRemote set D_G_WLAN off");;

Für die eher visuell orientierten unter uns sieht das dann so aus:

             Fritzbox 1 (Sender)                                       Fritzbox 2 (Empfänger)
               192.168.178.1                                               192.168.178.10
+---------------------------------------+           +-----------------------------------------------------------+
!                                       !           !                                                           !
! define forwardRemote dummy            !           !                                                           !
!                                       !           !                                                           !
! [ fhem log ]                          ! --pull--> ! define Remoteserver FHEM2FHEM 192.168.178.1:7072 LOG:.*   !
!                                       !           !                                                           !
!                                       !           ! define executeRemote notify forwardRemote {fhem "$EVENT"} !
!                                       !           !                                                           !
! set forwardRemote set D_G_WLAN off    !           ! [ notify executeRemote -> {fhem "$EVENT"} ] ->            !
!                                       !           !                           set D_G_WLAN off                !
!                                       !           !                                                           !
+---------------------------------------+           +-----------------------------------------------------------+

Weitergabe von Events

An eine Fritzbox (entfernte Instanz) ist ein RFXtrx433 angeschlossen. Die Events der erkannten Geräte, in diesem Falle ein Strommesser Revolt-5461 und ein Temperatur- und Feuchtigkeitssensor TFA 30.3150 sollen auf der Hauptinstanz (lokale Instanz) zur Verfügung stehen. Darüber hinaus wird auf der Fritzbox noch der Spritpreis abgerufen, dessen Events ebenfalls auf der Hauptinstanz zur Verfügung stehen sollen.

Definition auf der entfernten Instanz

Auf der Fritzbox sind die Komponenten ganz normal definiert und loggen in mehrere Filelogs. Der Telnetport ist standardmäßig auf 7072 definiert. Es ist keine SSL Verschlüsselung aktiviert und kein Passwort vergeben.

Definition auf der lokalen Instanz

Die Definition lautet wie folgt, wobei für die Regexp die Readings, die übernommen werden sollen, filtert.

define FHEM_on_FB FHEM2FHEM 192.168.1.10:7072 LOG:.*(SuperE[0-9]|temperature|humidity|battery|voltage|energy_power|state).*

Damit auf der lokalen Instanz die Geräte dargestellt werden können und nicht nur die Daten in der Datenbank landen, wurden entsprechende Dummies und dazu passende Notfies definiert.

Für den Revolt-5461

define KU_Ofen_r dummy
attr KU_Ofen_r DbLogExclude .*

define KU_Ofen_notify notify KU_Ofen { $EVENT=~s/://;;;; fhem("setreading KU_Ofen_r $EVENT");;;; my $KU_Ofen_P= ReadingsVal("KU_Ofen_r","energy_power",0) ;;;; my $KU_Ofen_V= ReadingsVal("KU_Ofen_r","voltage",0) ;;;; fhem("setreading KU_Ofen_r state P: $KU_Ofen_P V: $KU_Ofen_V") }
attr KU_Ofen_notify DbLogExclude .*

Für den Spritpreismonitor

define Shell_r dummy
attr Shell DbLogExclude .*

define Shell_notify notify Shell { $EVENT=~s/://;;;; fhem("setreading Shell_r $EVENT") ;;;; my $Shell_SE10= ReadingsVal("Shell_r","SuperE10",0) ;;;; my $Shell_SE5= ReadingsVal("Shell_r","SuperE5",0) ;;;; fhem("setreading Shell_r state S_E10: $Shell_SE10 S_E5: $Shell_SE5")}
attr Shell_notify DbLogExclude .*

Für den TFA 30.3150

define Aussen_Temp_Hum_r dummy
attr Aussen_Temp_Hum DbLogExclude .*

define Aussen_Temp_Hum_notify notify Aussen_Temp_Hum { $EVENT=~s/://;;;; fhem("setreading Aussen_Temp_Hum_r $EVENT") ;;;; my $Aussen_Temp_Hum_T= ReadingsVal("Aussen_Temp_Hum_r","temperature",0) ;;;; my $Aussen_Temp_Hum_H= ReadingsVal("Aussen_Temp_Hum_r","humidity",0) ;;;; my $Aussen_Temp_Hum_D= ReadingsVal("Aussen_Temp_Hum_r","dewpoint",0) ;;;; fhem("setreading Aussen_Temp_Hum_r state T: $Aussen_Temp_Hum_T H: $Aussen_Temp_Hum_H D: $Aussen_Temp_Hum_D")}
attr Aussen_Temp_Hum_notify DbLogExclude .*

Das Logging in die Datenbank funktioniert bereits direkt über die FHEM2FHEM Definition. Für das Logging in Filelogs müssten diese wie üblich definiert werden. Damit die dummies und die notifies keine Extraeinträge in der Datenbank produzieren, wurde das Attribut DbLogExclude mit der Regexp .* gesetzt. Die Notfies lösen jeweils 2 Aktionen aus

1. Schreiben der Readings in das Dummy, wobei der zusätzliche Doppelpunkt übersprungen wird.
2. Zusammensammeln der wichtigsten Werte und schreiben des Readings "state" des Dummy

Type RAW

Weitergabe eines Interfaces

An eine Fritzbox (entfernte Instanz) ist ein RFXtrx433 angeschlossen. Alle raw messages sollen auf einer weiteren Hauptinstanz zur Verfügung stehen. Vom RFTtrx433 werden messages von einem Strommesser Revolt-5461 und einem Temperatur- und Feuchtigkeitssensor TFA 30.3150 empfangen.

Definition auf der entfernten Instanz

Auf der Fritzbox ist das Interface RFXtrx433 mit dem Namen RFXTRX_on_FB definiert. Der Telnetport ist standardmäßig auf 7072 definiert. Es ist keine SSL Verschlüsselung aktiviert und kein Passwort vergeben.

Definition auf der lokalen Instanz

Die Definition lautet wie folgt, wobei hinter RAW: der Name des abgegriffenen Interfaces angegeben wird.

define FHEM_on_FB FHEM2FHEM 192.168.1.10:7072 RAW:RFXTRX_on_FB
attr FHEM_on_FB DbLogExclude .*

Zusätzlich wird ein Dummygerät benötigt, das wie ein lokales Interface agiert.

define RFXTRX_on_FB TRX none 0000
attr RFXTRX_on_FB dummy 1

In dieser Konfiguration werden die Komponenten an der Fritzbox auf der lokalen Instanz als neue Geräte erkannt mit dem IODev RFXTRX_on_FB.

Bekannte Probleme

Bei auf Dummies gespiegelten Komponenten und einfachem notify/setreading (Type LOG),

• erhalten die Readings einen zusätzlichen Doppelpunkt (Abhilfe: siehe Beispiel bzw. Links)
• muss das Reading "state" explizit geschrieben werden. Sonst zeigt der Status des Dummy nur "???" (Abhilfe: siehe Beispiel)
• FHEM2FHEM stellt nicht immer neue Verbindung hier, wenn das entfernte FHEM stromlos gemacht wurde oder sich anderweitig "unfreundlich" verabschiedet hat. Lösung: Watchdog auf dem Hauptsystem, wie hier beschrieben. Dabei kann inzwischen statt "modify" auch ein "set <name> reopen" verwendet werden.

Troubleshooting

• Lässt sich der entfernte Host anpingen?
• Lässt sich vom lokalen Host auf der Kommandozeile auf die Telnet-Schnittstelle der entfernten FHEM-Instanz zugreifen?
• Welche Meldungen stehen im Logfile nach einem Restart und dem Versuch des Verbindungsaufbaus zur entfernten FHEM-Instanz?
• Mögliche Fehler beim Loggen
  • Tauchen die Messages im Event Monitor der lokalen Instanz auf?
  • etc.

Links

• Doppelpunkt hinter den Readings im Dummy (Forenbeitrag)