GPIO-LED fernsteuern - FHEM2FHEM vs ECMD vs MQTT

[Pf@nne]

Moin,

für meine Hausautomatisierung möchte ich von einer Synology-FHEM-Instanz (A) eine LED auf einer anderen Raspberry-FHEM-Instanz (B) steuern. Auch soll der Status der LED (on / off) als Rückmeldung von B --> A zurück übertragen werden.

Es stellte sich jetzt die Frage ob dies besser mit FHEM2FHEM (im LOG-Mode) oder mit einer eigenen TCP-Verbindung über ECMD zu realisieren ist. Ich bin gerade dabei das für mich mal auszutesten und möchte den aktuellen Stand hier mal zusammenfassen.

Steuern einer entfernten LED über ECMD:

Zuerst müssen auf beiden Instanzen die entsprechenden TCP-Telnet-Server und die entsprechenden ECMD-Clients eingerichtet werden. Zur besseren Übersich nutze ich nicht den bereits vorhandenen Telnet-Server auf Port 7072.
Die besonderheit des ECMD-Clients ist die Definition der zu verwendenden Befehle in einem eigenen Config-File. Damit der ECMD-Config-File mit dem FHEM-Editor bearbeitet werden kann habe ich den File "ECMD_LED.cfg" im Instanzentsprechenden /FHEM Verzeichnis abgelegt:
z.B. "/volume1/@appstore/FHEM/share/fhem/FHEM/ECMD_LED.cfg" bei Synology-Instanz
bzw. "/opt/fhem/FHEM/ECMD_LED.cfg" bei der Raspberry-Instanz

Der Inhalt des Config-Files wird noch erläutert....um Fehlermeldungen zu vermeiden können die "ECMD-LED.cfg"-Files schon jetzt angelegt werden. Hierzu reicht es wenn im  Edit-Menü des WEB-IF die "myUtilsTemplate.pm" einfach unter dem Namen "ECMD-LED.cfg" gespeichert wird und der Inhalt gelöscht wird.

Steuernkanal von A-->B
TCP-Telnet-Server B

Code Auswählen Erweitern

define ECMD_RxD telnet 8001 global
attr ECMD_RxD room ECMD

TCP-ECMD-Client A

Code Auswählen Erweitern

define ECMD_TxD ECMD telnet 192.168.1.203:8001
attr ECMD_TxD classdefs ECMD_LED.class=/volume1/@appstore/FHEM/share/fhem/FHEM/ECMD_LED.cfg
attr ECMD_TxD room ECMD


Rückmeldekanal von B-->A
TCP-Telnet-Server A

Code Auswählen Erweitern

define ECMD_RxD telnet 8000 global
attr ECMD_RxD room ECMD
TCP-ECMD-Client B

Code Auswählen Erweitern

define ECMD_TxD ECMD telnet 192.168.1.3:8000
attr ECMD_TxD classdefs ECMD_LED.class=/opt/fhem/FHEM/ECMD_LED.cfg
attr ECMD_TxD room ECMD


Die beiden TCP-Verbindungen sollten jetzt stehen....

Als nächstes werden die eigentlichen Devices für die LED-Steuerung angelegt. Damit keine Schleife entsteht habe ich momentan die Steuerung und die Rückmeldung auf dem Steuernden System A getrennt angelegt.

LED Configuration
Empfängerseite B

Code Auswählen Erweitern

define Error_LED RPI_GPIO 5
attr Error_LED devStateIcon on:10px-kreis-rot off:1px-spacer
attr Error_LED direction output
attr Error_LED room Overheat

Senderseite A

Code Auswählen Erweitern

define RM_Error_LED dummy
attr RM_Error_LED devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr RM_Error_LED room Overheat

define Trigger_Error_LED dummy
attr Trigger_Error_LED room Overheat
attr Trigger_Error_LED setList on off


Jetzt werden die eigentlichen Steuermodule in Form von ECMDDevices angelegt. Die Funktionen des ECMDDevices werden in den "ECMD_LED.cfg"-Files definiert. Momentan beschränke ich mich auf den "set-Befehl" dieser sendet nur einen gültigen FHEM-Befehl ohne auf eine Antwort zu warten um diese dann noch ggf. auszuwerten.

ECMD-Config-class
Senderseite A

Code Auswählen Erweitern

set Error_LED_on cmd {"set Error_LED on\n\n"}
set Error_LED_off cmd {"set Error_LED off\n\n"}
set Error_LED_oft cmd {"set Error_LED on-for-timer 1\n\n"}

Empfängerseite B (Rückmeldung)

Code Auswählen Erweitern

set RM_Error_LED_on cmd {"set RM_Error_LED on\n\n"}
set RM_Error_LED_off cmd {"set RM_Error_LED off\n\n"}

Jetzt fehlen noch die entsprechenden notifys um die zugehörigen Triggerereignisse zum SENDEN auszulösen.
Es ist nicht nötig auf die ankommenden Ereignisse zu reagieren, da diese schon einen in einer interpretierbaren Form beim Empfänger ankommen.

notify Triggerereignisse
Senderseite A

Code Auswählen Erweitern

define Send_Error_LED_oft notify Trigger_Error_LED:on set ECMD_LED_Device Error_LED_oft
attr Send_Error_LED_oft room Overheat
#rücksetzen des Schalters (Tasterfunktion)
define Reset_Trigger_Error_LED notify Trigger_Error_LED:on set Trigger_Error_LED off
attr Reset_Trigger_Error_LED room Overheat

Empfängerseite B (Rückmeldung)

Code Auswählen Erweitern

define RM_Error_LED_on notify Error_LED:on set ECMD_LED_Device RM_Error_LED_on
attr RM_Error_LED_on room Overheat

define RM_Error_LED_off notify Error_LED:off set ECMD_LED_Device RM_Error_LED_off
attr RM_Error_LED_off room Overheat

Ich werde mich jetzt mal an die Umsetzung mit FHEM2FHEM machen. Jetzt wo FHEM2FHEM auch einen Sendefilter besitzt könnte es ein Kopf-an-Kopf rennen werden....


Steuern einer entfernten LED über FHEM2FHEM:

Zuerst müssen wieder die TCP-Verbindungen definiert und hergestellt werden. Hier verwende ich den Telnet-Standard-Server-Port 7072.
Um unnötigen Datentransfer zu vermeiden setzen wir die entsprechenden Filter.
Die Verbindung von A-->B (FHEM2FHEM-Client auf B) soll nur Events Empfangen die "Tigger_F2F" enthalten.
Die Verbindung von B-->A (FHEM2FHEM-Client auf A) soll nur Events Empfangen die "RM_F2F" enthalten.
Ganz aktuell werden die Filter zwar auf den empfangenden Instanzen gesetzt, sollen aber der sendenden Seite bereits gefiltert werden. Damit wäre dann nicht nur das LOG sauber, sondern auch der echte Datenverkehr aus der Leitung!
Das werde ich mir im Nachgang noch mal anschauen.

TCP-Clients
Empfängerseite B

Code Auswählen Erweitern

define FHEM_A FHEM2FHEM 192.168.1.4:7072 LOG:.*(Trigger_F2F).*
attr FHEM_A room FHEM2FHEM

Senderseite A

Code Auswählen Erweitern

define FHEM_B FHEM2FHEM 192.168.1.203:7072 LOG:.*(RM_F2F).*
attr FHEM_B room FHEM2FHEM


Jetzt werden alle relevanten Ereignisse auf den Instanzen im Event-LOG registriert.
Um Endlosschleifen zu vermeiden habe ich (vorerst, vielleich kann man hier noch optimieren) auf beiden Seiten je zwei Elemente angelegt.

LED Configuration
Senderseite A

Code Auswählen Erweitern

define RM_F2F_LED dummy
attr RM_F2F_LED devStateIcon on:10px-kreis-rot off:1px-spacer
attr RM_F2F_LED room FHEM2FHEM

define Trigger_F2F_LED dummy
attr Trigger_F2F_LED devStateIcon .*:Restart
attr Trigger_F2F_LED room FHEM2FHEM
attr Trigger_F2F_LED setList on off
#rücksetzen des Schalters (Tasterfunktion)
define Reset_Trigger_F2F_LED notify Trigger_F2F_LED:on set Trigger_F2F_LED off
attr Reset_Trigger_F2F_LED room FHEM2FHEM

Empfängerseite B

Code Auswählen Erweitern

define F2F_LED RPI_GPIO 6
attr F2F_LED devStateIcon on:10px-kreis-rot off:1px-spacer
attr F2F_LED direction output
attr F2F_LED room FHEM2FHEM

define RM_F2F_LED dummy
attr RM_F2F_LED room FHEM2FHEM
attr RM_F2F_LED setList on off


Auch bei FHEM2FHEM müssen die zu sendenden Ereignisse angetriggert werden.
Aber anders als bei ECMD müssen bei FHEM2FHEM auch die empfangenen Ereignisse über ein notify abgefangen und weitergegeben werden.

notify Triggerereignisse
Senderseite A

Code Auswählen Erweitern

define Reset_Trigger_F2F_LED notify Trigger_F2F_LED:on set Trigger_F2F_LED off
attr Reset_Trigger_F2F_LED room FHEM2FHEM

define set_RM_F2F_LED notify RM_F2F_LED:.* set RM_F2F_LED $EVENT
attr set_RM_F2F_LED room FHEM2FHEM

Empfängerseite B

Code Auswählen Erweitern

define set_RM_F2F_LED notify F2F_LED:.* set RM_F2F_LED $EVENT
attr set_RM_F2F_LED room FHEM2FHEM

define Set_F2F_LED notify Trigger_F2F_LED:on set F2F_LED on-for-timer 5
attr Set_F2F_LED room FHEM2FHEM



Steuern einer entfernten LED über MQTT:

MQTT basiert auf einem recht einfachen System, aller Informationsaustausch findet über einen sogenannten Broker (Makler, Vermittler) statt. Der MQTT-Brocker ist ein autark laufender Server. Hie kann z.B. Mosquitto genutzt werden.
Ich habe hierfür vorerst Mosquitto auf einem Raspberry installiert.

Installation Mosquitto-Broker
http://www.reddit.com/r/raspberry_pi/comments/2tbsj8/running_mosquitto_mqtt_broker_on_raspberry_pi/

Code Auswählen Erweitern


wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
rm mosquitto-repo.gpg.key

cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-repo.list
sudo apt-get update

sudo apt-get install mosquitto mosquitto-clients


Vom Prinzip her kann man am MQTT-Broker anmelden das man gerne Daten zur Verfügung stellen möchte.
Dies wird dem Broker mit einem PUBLISH (ich möchte etwas publizieren) mitgeteilt.
Wer Interesse an diesen Informationen hat kann beim Broker ein SUBSCRIBE eintragen (Abo anmelden).
(http://1.f.ix.de/developer/imgs/06/1/2/0/6/3/3/2/abb1-91e2bb4ffde20da8.jpeg)

Als Trockenübung kann können auf dem Broker-Raspberry zwei SSH-Konsolen geöffnet werden.
In der ersten Konsole trägt man sich für ein Abo ein:

Code Auswählen Erweitern

mosquitto_sub -d -t hello/world
In der zweiten Konsole kann nun publiziert werden:

Code Auswählen Erweitern

mosquitto_pub -d -t hello/world -m "Greetings from Terminal window 2"
Diese Nachricht sollte jetzt im ersten Terminal zu sehen sein.....

Der Broker läuft!

Unter FHEM erledigen die Module MQTT, MQTT_Bridge und MQTT_Device all diese schönen Sachen für uns.
MQTT stellt die Verbindung zum Broker her.
MQTT_Bridge ist die Brücke für ein bestehenden Device zum Broker.
MQTT_Device ist ein Device der auf Brokerinformationen zugreifen möchte, ein Dummy ist daher nicht mehr notwendig.

Zuerst stellen wir in beiden FHEM-Instanzen die Verbindung zum MQTT-Broker her:
TCP-Broker-Verbindung
Senderseite A

Code Auswählen Erweitern


define Broker_202 MQTT 192.168.1.202:1883
attr Broker_202 room MQTT

Empfängerseite B

Code Auswählen Erweitern


define Broker_202 MQTT 192.168.1.202:1883
attr Broker_202 room MQTT


Beide FHEM-Instanzen sollten jetzt eine Verbindung zum Broker haben.

Als nächstes benötigen wir einen MQTT_Device auf der steuernden Instanz A und eine MQTT_Bridge auf der Instanz mit der LED(GPIO).

MQTT_Device/_Bridge
Senderseite A

Code Auswählen Erweitern


define MQTT_Error_LED MQTT_DEVICE
attr MQTT_Error_LED IODev Broker_202
attr MQTT_Error_LED publishSet on off /Error_LED/state/set
attr MQTT_Error_LED room MQTT
attr MQTT_Error_LED stateFormat state
attr MQTT_Error_LED subscribeReading_state /Error_LED/state
attr MQTT_Error_LED userReadings _state


Rückmeldung der LED (GPIO) abonnieren

Code Auswählen Erweitern

attr MQTT_Error_LED subscribeReading_state /Error_LED/state
Set Kommando für die Steuerung der LED (GPIO) publizieren.

Code Auswählen Erweitern

attr MQTT_Error_LED publishSet on off /Error_LED/state/set

Empfängerseite B

Code Auswählen Erweitern


define MQTT_Error_LED MQTT_BRIDGE Error_LED
attr MQTT_Error_LED IODev Broker_202
attr MQTT_Error_LED publishState /Error_LED/state
attr MQTT_Error_LED room MQTT
attr MQTT_Error_LED stateFormat transmission-state
attr MQTT_Error_LED subscribeSet /Error_LED/state/set


Rückmeldung publizieren

Code Auswählen Erweitern

attr MQTT_Error_LED publishState /Error_LED/state
Steuerung abonnieren

Code Auswählen Erweitern

attr MQTT_Error_LED subscribeSet /Error_LED/state/set

Das war es schon! Und das Ganze ohne Schleifenproblem!
Der Pfad (/Error_LED/state) "Topic" genannt, kann frei gewält werden und bringt selbst komplexe Strukturen unter Kontrolle.


Das läuft soweit, vielleicht hat noch jemand Verbesserungsvorschläge.
Ich hoffe auch, dass der Beitrag jemandem den Start etwas vereinfacht.

Momentan ist MQTT für mich das Mittel der Wahl.
Gehirnknoten und Filter-Exzesse zum Vermeiden von Schleifen sind eigentlich modulbedingt ausgeschlossen.


Gruß
Pf@nne

[kvo1]

Danke für die gute Beschreibung.... Ich lese hier mal mit

[Thargor]

Ich bin auch sehr an den Erkenntnissen interessiert, da ich ähnliches vorhabe. ECMD hatte ich da noch gar nicht auf dem Plan. Daher schonmal: Vielen Dank!

[Pf@nne]

FHEM2FHEM ergänzt....

[justme1968]

schau dir mal das hier: http://forum.fhem.de/index.php/topic,23638.msg169368.html#msg169368 (und den zugehörigen post 6 beiträge darüber) an.

in dieser fhem2fhem basierten version wird statt des dummys ein readingProxy verwendet und so ein notify eingespart. das notify auf der gegenseite ist etwas anderes definiert und für mehr als ein device verwendbar.

gruss
andre

[John]

Da scheint mir eine Lösung via MQTT doch wesentlich einfacher und universeller.

Vorteile:
* du nutzt einen offenen Standard, der von vielen Tools direkt unterstützt wird
* wenn du neue Technologien, wie Node-Red nutzen willst, kannst die dies mit allen MQTT-Sensoren/Aktoren sofort nutzen
* du kannst auch 50 FHEM Instanzen mit den Infos des LED-Status "beglücken" oder diese die LED schalten lassen
* ...

Wer an MQTT einmal "gerochen" hat, will nichts anderes mehr.

John

[Pf@nne]

Moin Andre,

danke für den readingProxy Tipp, werde ich versuchen umzusetzen, ich werde aber erstmal in MQTT reinschauen.
Als Newbie stehe ich mit der FHEM/Perl-Syntax ziemlich auf Kriegsfuß, du hast nicht zufällig Lust und Zeit das o.g. Beispiel umzuschreiben? Ein ungetestetes Beipiel auf o.g. Basis würde langen. Ich versuche das dann nachzuvollziehen und würde es sauber einpflegen.

Gruß
Pf@nne

[Pf@nne]

Wer an MQTT einmal "gerochen" hat, will nichts anderes mehr.

Da könnte was dran sein!!

Ich habe mal einen Mosquitto-Broker auf einem Raspberry aufgemacht und local ein wenig "gespielt" sieht vielversprechend aus.
Leider scheitere ich beim definieren des MQTT-Clients auf meiner Synology-FHEM-Instanz.

Die pm´s sollten aktuell sein...

Code Auswählen Erweitern


-rw-r--r--    1 root     root        15683 Mar 15 19:01 00_MQTT.pm
-rw-r--r--    1 root     root          7475 Mar 15 19:01 10_MQTT_BRIDGE.pm
-rw-r--r--    1 root     root          8156 Mar 15 19:01 10_MQTT_DEVICE.pm


Code Auswählen Erweitern

define Broker_202 MQTT 192.168.1.202:1883
bringt folgenden Fehler:

Code Auswählen Erweitern

Cannot load module MQTT

?? Was mache ich schon wieder falsch?

EDIT:
Auf einer Raspberry-FHEM-Instanz funktioniert es....muss also an der Synology-FHEM-Instanz liegen.

[John]

Bei mir sieht das so aus

-rw-r--r-- 1 fhem dialout 15683 Nov 14 09:14 00_MQTT.pm
-rw-r--r-- 1 fhem dialout  7475 Nov 14 09:14 10_MQTT_BRIDGE.pm
-rw-r--r-- 1 fhem dialout  8156 Nov 14 09:14 10_MQTT_DEVICE.pm

Sind bei dir user und group korrekt eingestellt ?
root.root scheint verdächtig.

version liefert
# $Id: 00_MQTT.pm 6935 2014-11-09 20:35:34Z ntruchsess $
# $Id: 10_MQTT_BRIDGE.pm 6935 2014-11-09 20:35:34Z ntruchsess $
# $Id: 10_MQTT_DEVICE.pm 6935 2014-11-09 20:35:34Z ntruchsess $


John

[Pf@nne]

Moin John,

ich denke nicht, liegt aber daran, das ich im Grunde gar nicht so richtig weiß wie ich das auf der Synology-DS einstellen soll...

Kannst du mit dabei helfen....?

P.S.
Von Raspberry zu Raspberry klappt das publishen und subscriben schon prima.
Die Error_LED published über eine MQTT_Bridge und ein MQTT_Device auf einem Anderen Raspberry hat das _state subscribed....
Echt geil, und um längen übersichtlicher bis jetzt.... klasse Tipp!!

[schka17]

Kann es sein dass die notwendigen Perl Module auf der Synology fehlen?


Sent from my iPad using Tapatalk

[John]

Bei mir liefert der Befehl (ausgehend vom FHEM Verzeichnis)

Code Auswählen Erweitern

ls -la FHEM/lib/Net/MQTT
folgendes

Code Auswählen Erweitern

drwxrwxr-x 4 fhem dialout 4096 M�r  5 17:30 .
drwxrwxr-x 4 fhem dialout 4096 M�r  5 17:30 ..
-rw-rw-r-- 1 fhem dialout 6307 M�r  5 17:30 Constants.pm
drwxrwxr-x 3 fhem dialout 4096 M�r  5 17:30 Message
-rw-rw-r-- 1 fhem dialout 5874 M�r  5 17:30 Message.pm
drwxrwxr-x 6 fhem dialout 4096 M�r  5 17:30 .svn
-rw-rw-r-- 1 fhem dialout 2264 M�r  5 17:30 TopicStore.pm

Wie siehts bei dir aus ?

John

[Pf@nne]

Ich fürchte hier fehlt was in der Syno-FHEM-Instanz

Code Auswählen Erweitern


/volume1/@appstore/FHEM/share/fhem/FHEM/lib # find / -name "*MQTT*"
/volume1/@appstore/FHEM/share/fhem/FHEM/00_MQTT.pm
/volume1/@appstore/FHEM/share/fhem/FHEM/10_MQTT_BRIDGE.pm
/volume1/@appstore/FHEM/share/fhem/FHEM/10_MQTT_DEVICE.pm

mehr MQTT habe ich nicht....

Der Raspberry hat da mehr zu bieten:

Code Auswählen Erweitern


root@Raspberry202:~# find / -name "*MQTT*"
/opt/fhem/FHEM/10_MQTT_DEVICE.pm
/opt/fhem/FHEM/10_MQTT_BRIDGE.pm
/opt/fhem/FHEM/lib/Net/MQTT
/opt/fhem/FHEM/lib/Net/MQTT.pod
/opt/fhem/FHEM/00_MQTT.pm


Code Auswählen Erweitern


root@Raspberry202:/opt/fhem/FHEM/lib/Net# ls -la
total 16
drwxr-xr-x 3 fhem root 4096 Dec 28 14:25 .
drwxr-xr-x 7 fhem root 4096 Mar 16 18:42 ..
drwxr-xr-x 3 fhem root 4096 Dec 28 14:25 MQTT
-rw-r--r-- 1 fhem root 1078 Nov  9 14:16 MQTT.pod


[John]

die Quellen findest du hier
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/lib/Net/
John

[Pf@nne]

Läuft!

Code Auswählen Erweitern


2015-04-19 22:01:50 MQTT_DEVICE MQTT_Error_LED transmission-state: incoming publish received
2015-04-19 22:01:50 MQTT_DEVICE MQTT_Error_LED off
2015-04-19 22:01:51 MQTT_DEVICE MQTT_Error_LED transmission-state: incoming publish received
2015-04-19 22:01:51 MQTT_DEVICE MQTT_Error_LED on


Wahnsinn....jetzt fehlt nur noch das Senden eines Set´s... zum Steuern des fernen GPIOs.

Schon jetzt ist aber abzusehen, dass MQTT wohl die richtige Wahl ist.


Erstmal danke für die Unterstützung.

P.S. Ich habe die Files von meinem Raspberry einfach kopiert, wie hätte ich das auf der Konsole "einfach" auschecken können?