Benutzer:Amenophis86/Artikelentwurf: Unterschied zwischen den Versionen

Amenophis86/Artikelentwurf
Zweck / Funktion
	Ausführung von Befehlen auf anderer Instanz
Allgemein
Typ	undefiniert
Details
Dokumentation	ModUndef
Support (Forum)	Automatisierung
Modulname	93_RFHEM.pm
Ersteller	chris1284 (Forum )
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Version vom 14. März 2016, 05:02 Uhr

RFHEM ist ein Modul um zwischen verschiedenen FHEM Instanzen Befehle abzusetzen. Das Modul wird nicht supported und ist somit auch nicht offiziell per Update installiert.

Zielsetzung

Ziel des Moduls ist es Befehle auf einer anderen Instanz abzusetzen. Verwirklich wird das ganze per Telnet. Das Modul ist angelehnt an FHEM2FHEM. Der Unterschied ist, dass hier quasi alle Devices, auch die von FHEM2FHEM nicht unterstützten, gesteuert werden können.

Herunterladen des Moduls

Das Modul selbst bekommen wir in diesem Forums Beitrag. Nochmal, das Modul wird aktuell nicht supported und ist dem entsprechend alt.

Wir laden das Modul in den Ordern ./FHEMInstallation/FHEM/. Bei einem PI wäre das dann /opt/fhem/FHEM. Danach starten wir FHEM neu.

Definieren des Device

Nun müssen wir uns ein Device anlegen. Dies machen wir klassisch in der Kommandozeile mittels

define Name RFHEM hostip [:port] [pw]

Sollte eure zweite Instanz auf der gleichen Hardware laufen, den Port 7073 (Standard ist 7072 bei fhem und auch beim Modul, wenn keiner angegeben wird) und kein Passwort besitzen, wäre die Definition:

define FHEM2 RFHEM 127.0.0.1:7073

Befehle senden

Mittels

set <name> cmd <befehl>

setzt ihr eure Befehle ab, welche in der zweiten Instanz ausgeführt werden. Wollen wir zum Beispiel die Lampe1 anschalten, müssen wir folgendes in die Kommandozeile eingeben:

set FHEM2 cmd set Lampe1 on

Im Log der sendenden Instanz erscheint der Hinweis "command executed" und die zweite Instanz sollte die Lampe1 eingeschaltet haben.

Einschränkungen

Einfache Befehle

Einfache Befehle können auf der zweiten Instanz ausgeführt werden. Beispiele:

Dummy schalten:

set FHEM2 cmd setreading Dummy1 Reading1 'Test 1 2 3'

Dummy definieren:

set FHEM2 cmd define Dummy1 dummy

Notifys erstellen:

set RemotePI cmd define b3lampV1 notify btn3 set lamp on
set RemotePI cmd define b3lampV1 notify btn3 {}

Perlcode

Was nicht funktioniert ist einen Perlcode auf der zweiten Instanz auszuführen. FHEM bezieht den Perlcode auf die erste Instanz. Somit würde zum Beispiel folgender Befehl nicht funktionieren:

set RemotePI cmd define a1 at 17:00:00 {fhem("set xyz on");}

Die Instanz, auf welcher der Befehl abgesetzt wurde, würde selbst den Code "{fhem ("set xyz on");}" ausführen wollen.

SSL Auth

SSL Auth ist leider auch nicht möglich.

Nicht funktionierende Befehle

Bisher sind keine Befehle bekannt. Solltet jemand einen oder mehrere finden, so möge er diese bitte diesem Thread posten. Vielleicht findet sich ja noch jemand, der den Befehl korrigieren kann.

Nützliche Hilfen

Typischer Fall, wie dieses Modul genutzt werden kann ist folgender. Man hat auf der gleichen, oder einer anderen, Hardware eine zweite FHEM Instanz. Der Grund mag sein, dass man blockierende Module auslagert (gleiche Hardware) oder Empfangslücken überbrücken möchte (andere Hardware).

Wir nennen unsere Hauptinstanz MASTER und unsere zweite Instanz SLAVE. Auf SLAVE haben wir ein blockierendes Modul installiert, dessen Daten wir aber regelmäßig in MASTER haben möchten. Das Modul heißt TEST-Modul und hat die Readings TEST-Modul-R1 und TEST-Modul-R2.

Wir installieren auf SLAVE das hier beschriebene Modul RFHEM und nennen es "Daten.Senden". Auf SLAVE muss also regelmäßig, am besten bei einem Update der Readings, die Daten an MASTER gesendet werden. Dies lässt sich am einfachsten mittels eines notify. MASTER muss jedoch auch die Daten empfangen können. Hierfür bietet sich ein Dummy an. Den Dummy definieren wir auf Master wie folgt:

define Dummy.Empfang dummy

Das sendende Notify, wird auf SLAVE wie folgt definiert:

define Daten.Senden.Notify notify Test-Modul.* set Daten.Senden cmd setreading Dummy.Empfang $EVENT

Nun schreibt der SLAVE bei jedem Update eines Readings in den Dummy des MASTERS die Werte. Auf dem Master können wir diese Veränderung nun auch abgreifen, wie bei jedem normalen Modul. Grafisch würde das ganze so aussehen:

SLAVE: Readings Update an Test-Modul --> Meldung an Notify --> Meldung an MASTER --> Empfang der Daten im Dummy

Doppelpunkte im Reading beim Dummy

Es kann vorkommen, dass die Readings im Dummy einen Doppelpunkt haben. In unserem Fall würde dann im Dummy "Dummy.Empfang" das Reading eins wie folgt stehen "Test-Modul-R1:". Doppelpunkte sollte es zum Einen in Readings nicht geben, deswegen gibt es auch einen Hinweis im Log, wenn ihr FHEM startet und dies der Fall ist. Zum Zweiten kann es zu Problemen auf der MASTER Instanz kommen, wenn man zB ein DOIF auf die Readings des Dummy lauschen lässt.

Aktuell muss man sich bei der Lösung des Problems noch selbst helfen, da es keinen Maintainer des Moduls gibt. Die Lösung hierzu könnte wie folgt aussehen. Wir erstellen uns eine Sub in der MyUtils (99_myUtils_anlegen) an, welche für uns die Doppelpunkte löscht. Diese Sub könnte wie folgt aussehen:

Command executed ausschalten

Sollte man viele Befehle mittels RFHEM senden, empfiehlt es sich das Attribut "Verbose" auf 0 zu setzen. Dies führt zwar dazu, dass keine Fehler mehr angezeigt werden, aber es führt auch dazu, dass nicht bei jeder Befehlsausführung das Log voll geschrieben wird.

@@ Zeile 1: / Zeile 1: @@
-[[HM-CC-RT-DN Fehlerüberwachung]] ist ein Code Snippet zur Überwachung der [[HM-CC-RT-DN Funk-Heizkörperthermostat]] von Homematic.
+{{SEITENTITEL:RFHEM}}
+{{Infobox Modul
+|ModPurpose=Ausführung von Befehlen auf anderer Instanz
+|ModForumArea=Automatisierung
+|ModTechName=93_RFHEM.pm
+|ModOwner=chris1284 ({{Link2FU|5217|Forum}})
+}}
+[[RFHEM]] ist ein Modul um zwischen verschiedenen FHEM Instanzen Befehle abzusetzen. Das Modul wird nicht supported und ist somit auch nicht offiziell per Update installiert.
 == Zielsetzung ==
-Es kann vorkommen, dass das Display der Ventile nicht immer im Sichtbereich liegt und somit ein Fehler eines Thermostats durch den Anwender nicht erkannt wird. Durch FHEM kann man sich auf diesen Fehler hinweisen lassen.
+Ziel des Moduls ist es Befehle auf einer anderen Instanz abzusetzen. Verwirklich wird das ganze per Telnet. Das Modul ist angelehnt an [[FHEM2FHEM]]. Der Unterschied ist, dass hier quasi alle Devices, auch die von FHEM2FHEM nicht unterstützten, gesteuert werden können.
-== Erstellen der nötigen Funktionen ==
+== Herunterladen des Moduls ==
-Dazu muss eine [[readingsGroup]] erstellt werden, welche alle Thermostate überwacht. Das Reading, auf welches die readingsGroup achtet ist "motorErr". Somit definieren wir die readingsGroup wie folgt:
+Das Modul selbst bekommen wir in {{Link2Forum|Topic=23638|Message=169011|LinkText=diesem}} Forums Beitrag. Nochmal, das Modul wird aktuell nicht supported und ist dem entsprechend alt.
-<pre>define MotorUeberwachung readingsGroup .*:motorErr</pre>
-Anzumerken ist, dass bei der Anlegung sowohl die Hauptdevice, als auch der Channel Clima genommen wird.
+Wir laden das Modul in den Ordern ./FHEMInstallation/FHEM/. Bei einem PI wäre das dann /opt/fhem/FHEM. Danach starten wir FHEM neu.
-Damit wir eine farbliche Übersicht haben, welches Thermostat in Ordnung ist und welches einen Fehler hat, werden wir mittels des Attributs ValueStyle die Farbe der Anzeige ändern:
+== Definieren des Device ==
-<pre>attr MotorUeberwachung {($READING eq "motorErr" && $VALUE eq "ok")?'style="color:green"':'style="color:red"'</pre>
+Nun müssen wir uns ein Device anlegen. Dies machen wir klassisch in der Kommandozeile mittels
+<pre>define Name RFHEM hostip [:port] [pw]</pre>
-Wir sagen somit FHEM, wenn das Reading "motorErr" dem Wert "ok" gleicht, dann soll es in grün angezeigt werden. Ist das nicht der Fall, dann soll es in rot angezeigt werden.
+Sollte eure zweite Instanz auf der gleichen Hardware laufen, den Port 7073 (Standard ist 7072 bei fhem und auch beim Modul, wenn keiner angegeben wird) und kein Passwort besitzen, wäre die Definition:
+<pre>define FHEM2 RFHEM 127.0.0.1:7073</pre>
+== Befehle senden ==
+Mittels
+<pre>set <name> cmd <befehl></pre>
+setzt ihr eure Befehle ab, welche in der zweiten Instanz ausgeführt werden. Wollen wir zum Beispiel die Lampe1 anschalten, müssen wir folgendes in die Kommandozeile eingeben:
+<pre>set FHEM2 cmd set Lampe1 on</pre>
-== Benachrichtigung mittels Pushover ==
+Im Log der sendenden Instanz erscheint der Hinweis "command executed" und die zweite Instanz sollte die Lampe1 eingeschaltet haben.
-Jetzt können wir uns noch über das [[Pushover]] Modul zusammen mit [[Notify]] eine Nachricht schicken lassen, welche uns darüber informiert, dass ein Thermostat einen Fehler hat. Voraussetzung ist, dass das Pushovermodul angelegt und funktionsfähig ist. Der Code hierzu kann wie folgt aussehen
-<pre>define MotorMeldung notify .*:motorErr.* {if($EVENT !~ m/ok/) { fhem("set Pushover1 msg 'Heizungs Warnung' '$NAME meldet den Fehler $EVPART1' 'HA_Ede' 0 ''") }}</pre>
+== Einschränkungen ==
+=== Einfache Befehle ===
+Einfache Befehle können auf der zweiten Instanz ausgeführt werden. Beispiele:
-Somit wird über Pushover eine Nachricht gesendet, sobald irgendein Thermostat im Reading "motorErr" eine andere Meldung, als "ok" sendet. In der Nachricht ist der Name ($Name) des Device enthalten, als auch die Fehlermeldung ($EVTPART1).
+Dummy schalten:
+<pre>set FHEM2 cmd setreading Dummy1 Reading1 'Test 1 2 3'</pre>
-Wichtig ist, dass diese Definition auch für alle anderen Devices gilt, welche das Reading "motorErr" haben. Möchte man diese Meldung nur bei seinen Thermostaten haben, kann man wie folgt vorgehen:
+Dummy definieren:
+<pre>set FHEM2 cmd define Dummy1 dummy</pre>
-<pre>define MotorMeldung notify (NameThermostat1|NameThermostat2|...):motorErr.* {if($EVENT !~ m/ok/) { fhem("set Pushover1 msg 'Heizungs Warnung' '$NAME meldet den Fehler $EVPART1' 'HA_Ede' 0 ''") }}</pre>
+Notifys erstellen:
+<pre>set RemotePI cmd define b3lampV1 notify btn3 set lamp on
+set RemotePI cmd define b3lampV1 notify btn3 {}</pre>
-Weiterhin sollte für die Thermostate das Attribut [[event-on-change-reading]] in Verbindung mit "motorErr" gesetzt werden. Sonst bekommt man alle 3 Minuten eine Meldung per Pushover, dass der Motor einen Fehler hat. Gerade, wenn man unterwegs ist, kann dies sehr nerven.
+=== Perlcode ===
+Was nicht funktioniert ist einen Perlcode auf der zweiten Instanz auszuführen. FHEM bezieht den Perlcode auf die erste Instanz. Somit würde zum Beispiel folgender Befehl nicht funktionieren:
+<pre>set RemotePI cmd define a1 at 17:00:00 {fhem("set xyz on");}</pre>
+Die Instanz, auf welcher der Befehl abgesetzt wurde, würde selbst den Code "{fhem ("set xyz on");}" ausführen wollen.
+=== SSL Auth ===
+SSL Auth ist leider auch nicht möglich.
+=== Nicht funktionierende Befehle ===
+Bisher sind keine Befehle bekannt. Solltet jemand einen oder mehrere finden, so möge er diese bitte {{Link2Forum|Topic=23638|Message=169011|LinkText=diesem}} Thread posten. Vielleicht findet sich ja noch jemand, der den Befehl korrigieren kann.
+== Nützliche Hilfen ==
+Typischer Fall, wie dieses Modul genutzt werden kann ist folgender. Man hat auf der gleichen, oder einer anderen, Hardware eine zweite FHEM Instanz. Der Grund mag sein, dass man blockierende Module auslagert (gleiche Hardware) oder Empfangslücken überbrücken möchte (andere Hardware).
+Wir nennen unsere Hauptinstanz MASTER und unsere zweite Instanz SLAVE. Auf SLAVE haben wir ein blockierendes Modul installiert, dessen Daten wir aber regelmäßig in MASTER haben möchten. Das Modul heißt TEST-Modul und hat die Readings TEST-Modul-R1 und TEST-Modul-R2.
+Wir installieren auf SLAVE das hier beschriebene Modul RFHEM und nennen es "Daten.Senden". Auf SLAVE muss also regelmäßig, am besten bei einem Update der Readings, die Daten an MASTER gesendet werden. Dies lässt sich am einfachsten mittels eines [[notify]]. MASTER muss jedoch auch die Daten empfangen können. Hierfür bietet sich ein Dummy an. Den Dummy definieren wir auf Master wie folgt:
+<pre>define Dummy.Empfang dummy</pre>
+Das sendende Notify, wird auf SLAVE wie folgt definiert:
+<pre>
+define Daten.Senden.Notify notify Test-Modul.* set Daten.Senden cmd setreading Dummy.Empfang $EVENT
+</pre>
+Nun schreibt der SLAVE bei jedem Update eines Readings in den Dummy des MASTERS die Werte. Auf dem Master können wir diese Veränderung nun auch abgreifen, wie bei jedem normalen Modul. Grafisch würde das ganze so aussehen:
+<pre>SLAVE: Readings Update an Test-Modul --> Meldung an Notify --> Meldung an MASTER --> Empfang der Daten im Dummy</pre>
+== Doppelpunkte im Reading beim Dummy ==
+Es kann vorkommen, dass die Readings im Dummy einen Doppelpunkt haben. In unserem Fall würde dann im Dummy "Dummy.Empfang" das Reading eins wie folgt stehen "Test-Modul-R1:". Doppelpunkte sollte es zum Einen in Readings nicht geben, deswegen gibt es auch einen Hinweis im Log, wenn ihr FHEM startet und dies der Fall ist. Zum Zweiten kann es zu Problemen auf der MASTER Instanz kommen, wenn man zB ein [[DOIF]] auf die Readings des Dummy lauschen lässt.
+Aktuell muss man sich bei der Lösung des Problems noch selbst helfen, da es keinen Maintainer des Moduls gibt. Die Lösung hierzu könnte wie folgt aussehen. Wir erstellen uns eine Sub in der MyUtils ([[99_myUtils_anlegen]]) an, welche für uns die Doppelpunkte löscht. Diese Sub könnte wie folgt aussehen:
+<pre>
+</pre>
+== Command executed ausschalten ==
+Sollte man viele Befehle mittels RFHEM senden, empfiehlt es sich das Attribut "Verbose" auf 0 zu setzen. Dies führt zwar dazu, dass keine Fehler mehr angezeigt werden, aber es führt auch dazu, dass nicht bei jeder Befehlsausführung das Log voll geschrieben wird.