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?

[Pf@nne]

MQTT ergänzt.....

[John]

MQTT-Spy ist absolut überragend als MQTT-Client
http://kamilfb.github.io/mqtt-spy/

Node-Red ist ein Wiring-Tool, das man sich ansehen muss (natürlich unterstützt es MQTT)
http://forum.fhem.de/index.php/topic,35599.msg279427.html#msg279427

Freeboard läuft mit MQTT
http://forum.fhem.de/index.php/topic,35800.msg281297.html#msg281297

Wer das Match wohl gewinnt ?

John

[Pf@nne]

Das Rennen ist entschieden, MQTT macht sich wirklich gut....
Die Links schaue ich mir mal an....

Kannst du den MQTT - TEIL mal auf groben Unfug hin querlesen?

Gruß
PF@NNE

[Pf@nne]

Die 1:1 Verbindung klappt ja schon ganz gut..

Wenn ich es richtig verstanden habe MQTT-BRIDGE immer mit einem real existierenden Device verbunden.
Daher musss für jeden Device eine eigene BRIDGE angelegt werden.

Ist dem so?

Wie verhält es sich mit dem MQTT_DEVICE?
Kann ein MQTT_DEVICE mehrere readings unterschiedlicher BRIDGEes"subscriben" ?

Code Auswählen Erweitern


attr MQTT_Error_LED subscribeReading_state /Error_LED1/state
attr MQTT_Error_LED subscribeReading_state /Error_LED2/state


Warum gibt es im WebIF-Dropdown nur ein "subcribeReading_.*", ich habe das dann händisch in ein "subcribeReading_state" geändert, weil ich sonst nichts lesen konnte.
Mache ich da noch was verkehrt?

Ich hoffe ihr könnt mir helfen.

Gruß
Pf@nne

[schka17]

Zur ersten Frage, MQTT_DEVICE subscribed zu einem Topic, dabei wird das IO device zum Broker verwendet, sollte also möglich sein in einem Device unterschiedliche Topics zu subscriben, habe ich aber noch nicht ausprobiert, ist für meine Anwendungen nicht denkbar da sich dann die Namen der Readings gleichen würden, ich denke das geht dann nicht.

Zur zweiten Frage, du kannst auch mit dem attr autosubscribereadings die readings automatisch anlegen lassen. Klarerweise kann es im Dropdown nur wildcards geben, ist ja noch nicht bekannt welche Topics subscribed werden sollen.


Sent from my iPad using Tapatalk

[bgewehr]

Hat schon jemand eine Lösung für MQTT und Raspberry GPIO gefunden?

Ich stehe grade an derselben Stelle ratlos...

[Pf@nne]

Moin,

was genau meinst du mit MQTT und GPIO?
Ich sehe da momentan keinen Zusammenhang?

Beschreibe mal was du vorhast.

Gruß
Pf@nne

[bgewehr]

MQTT wird verwendet, um die LAN Kommunikation zu machen. Da aber die Raspberry GPIO geschaltet werden sollen, braucht es noch einen MQTT Client, der bei entspr. Messages den Status der PINs setzt oder auf Statuswechsel eines PINs eine Message sendet. Dies tut der MQTT-GPIO-Monitor von Sumnerboy aus GitHub. Aber leider mal wieder nicht problemlos, ich bekomme da Connection refused Fehler bei der Verbindung zu mosquitto.

https://github.com/sumnerboy12/mqtt-gpio-monitor/issues/3

[bgewehr]

Funktioniert nun! Ich poste mal die Config später!

[rretsiem]

Hallo,

Altes Thema, ich weiß hat mir aber sehr dabei geholfen eine Entscheidung zu treffen wie ich den 2. rPi im Dachboden für den Stromzähler mit meinem "Haupt-FHEM" verbinde.
Ich hatte das nämlich erst mit Fhem2Fhem gelöst aber das ist im Vergleich zu MQTT viel zu kompliziert. Mittlerweile sprechen die beiden Pis nur noch via MQTT miteinander und tauschen Events aus. Im Moment nur in eine Richtung vom Dachboden zum primären aber das klappt so was von zuverlässig, dass ich das hier einfach mal los werden muss.

Wer noch etwas Input benötigt:

Dachboden Pi (metis) mit OBIS Modul sendet Events an den MQTT Broker (Ebenfalls auf dem Haupt-FHEM Pi (loki) am laufen):

Einmal zum Broker connecten mit dem MQTT Modul

Code Auswählen Erweitern


Internals:
   DEF        loki:1883
   DeviceName loki:1883
   FD         4
   NAME       MQTT_Broker_loki
   NOTIFYDEV  global
   NR         21
   NTFY_ORDER 50-MQTT_Broker_loki
   PARTIAL
   STATE      opened
   TYPE       MQTT
   buf
   msgid      1
   ping_received 1
   timeout    60
   Readings:
     2016-04-28 19:38:59   connection      active
     2016-04-28 19:27:59   state           opened
   Messages:


Und einmal die "Bridge" die von einem FHEM Device (powerMeter) Nachrichten an den Broker schickt.

Code Auswählen Erweitern


Internals:
   DEF        powerMeter
   IODev      MQTT_Broker_loki
   NAME       MQTT_PowerMeter
   NOTIFYDEV  powerMeter
   NR         22
   NTFY_ORDER 50-MQTT_PowerMeter
   STATE      outgoing publish sent
   TYPE       MQTT_BRIDGE
   qos        0
   retain     0
   Readings:
     2016-04-28 19:36:38   transmission-state outgoing publish sent
   Publishreadings:
     power      /PowerMeter/power
     zaehlerStand /PowerMeter/zaehlerStand
   subscribe:
   subscribeExpr:
Attributes:
   IODev      MQTT_Broker_loki
   publishReading_power /PowerMeter/power
   publishReading_zaehlerStand /PowerMeter/zaehlerStand
   room       MQTT
   stateFormat transmission-state


Auf dem primären FHEM auf dem auch "mosquitto" als MQTT Broker läuft:

Code Auswählen Erweitern


Internals:
   DEF        loki:1883
   DeviceName loki:1883
   FD         5
   NAME       MQTT_Broker_loki
   NOTIFYDEV  global
   NR         248
   NTFY_ORDER 50-MQTT_Broker_loki
   PARTIAL
   STATE      opened
   TYPE       MQTT
   buf
   msgid      8
   ping_received 1
   timeout    60
   Readings:
     2016-04-28 19:38:28   connection      active
     2016-04-26 16:42:10   state           opened
   Messages:
Attributes:
   room       Ressourcen


Und schließlich noch ein MQTT_Device (MQTT_PowerMeter) welches wie ein "normales" Device angesprochen wird und die Readings liefert:

Code Auswählen Erweitern


Internals:
   CHANGED
   IODev      MQTT_Broker_loki
   NAME       MQTT_PowerMeter
   NR         249
   STATE      6.8394 kWh / Gesamt: 73.187 kWh
   TYPE       MQTT_DEVICE
   qos        0
   retain     0
   Readings:
     2016-04-28 19:42:14   costsDay        1.33231512 €
     2016-04-28 19:42:14   power           172.7
     2016-04-28 19:42:14   statPowerDay    Min: 64.5 Avg: 365.1 Max: 3844.2
     2016-04-27 23:59:55   statPowerDayLast Min: 63.5 Avg: 273.5 Max: 4121.9
     2016-04-28 19:42:14   statPowerMonth  Min: 63.5 Avg: 322.7 Max: 4340.9 (since: 2016-04-25_13:22:56 )
     2016-04-28 19:42:14   statPowerYear   Min: 63.5 Avg: 322.7 Max: 4340.9 (since: 2016-04-25_13:22:56 )
     2016-04-28 19:42:14   statZaehlerStand Hour: 0.5933 Day: 6.8394 Month: 20.0619 Year: 20.0619 (since: 2016-04-26 )
     2016-04-28 19:42:14   statZaehlerStandDay 6.8394
     2016-04-27 23:59:55   statZaehlerStandDayLast 6.3928
     2016-04-28 18:59:55   statZaehlerStandLast Hour: 0.2323 Day: 6.3928 Month: - Year: -
     2016-04-28 19:42:14   statZaehlerStandMonth 20.0619
     2016-04-28 19:42:14   transmission-state incoming publish received
     2016-04-28 19:42:14   zaehlerStand    73.187
   Helper:
     _98_statistics statPowerMeter
   Message_ids:
   Sets:
   subscribe:
     /PowerMeter/power
     /PowerMeter/zaehlerStand
   subscribeExpr:
     ^\/PowerMeter\/power$
     ^\/PowerMeter\/zaehlerStand$
   Subscribereadings:
     /PowerMeter/power power
     /PowerMeter/zaehlerStand zaehlerStand
Attributes:
   IODev      MQTT_Broker_loki
   event-min-interval zaehlerStand:300,statZaehlerStandDay:3600,statZaehlerStandMonth:7200
   event-on-update-reading power,statZaehlerStandDay,zaehlerStand,statZaehlerStandDayLast
   group      Strom
   room       Dachboden,Wohnung
   stateFormat statZaehlerStandDay kWh / Gesamt: zaehlerStand kWh
   subscribeReading_power /PowerMeter/power
   subscribeReading_zaehlerStand /PowerMeter/zaehlerStand


Auf dem Device kann ich dann mit Logfiles, Graphen usw. Alles tun was ich auch auf einem richtigen Device mache.

Funktioniert klasse!
Die CPU-Last ist nicht angestiegen dadurch und der Netzwerk-Traffic hält sich Dank der Effizienz durch MQTT absolut in Grenzen. Der Momentanverbrauch und Zählerstand aus den Readings wird alle 5 Sekunden durch einen Event direkt übermittelt.


Edit: Hatte erst vor das in die Code-Snippets Abteilung zu packen aber habe mich nicht getraut 

[kvo1]

Hallo rretsiem,
Danke das Du dies hier vorstellst, genau das habe ich auch noch vor und wollte das eigentlich wie Du über F2F realisieren.
Ich habe im Keller einen RPI an der Heizung und den Haupt-Fhem-Server ist 2 Etagen höher.

Könntest Du mal genauer beschreiben, was man wie und wo genau installieren muß und ggf. der Teil (Define ...etc) aus der konfig posten

Wäre toll, dann muß ich nicht bei Null anfangen !

[rretsiem]

Klar kann ich das machen, im ersten Post auf der Seite steht eigentlich schon das meiste.
Hier nochmal zusammengefasst:

Mosquitto MQTT Broker auf deinem "Haupt-Server" installieren (Achtung ich nutze Debian Jessie, daher die .list anpassen, falls du Wheezy nutzt!)

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-jessie.list
sudo apt-get update

sudo apt-get install mosquitto mosquitto-clients


Das dauert je nach Pi ein wenig (auf dem rPi 3 gehts flott).
Danach ist dein MQTT Broker mit der IP des Servers auf Port 1883 erreichbar.

Der Rest in FHEM:

Anlegen eines Broker IODevs auf beiden FHEM Instanzen!

Code Auswählen Erweitern


define MQTT_Broker_loki MQTT <ip>:1883
attr MQTT_Broker_loki room MQTT



Auf dem Sender (Bei dir Heizungsraum):

Code Auswählen Erweitern


define MQTT_PowerMeter MQTT_BRIDGE powerMeter
attr MQTT_PowerMeter IODev MQTT_Broker_loki
attr MQTT_PowerMeter publishReading_power /PowerMeter/power
attr MQTT_PowerMeter publishReading_zaehlerStand /PowerMeter/zaehlerStand


"powerMeter" ist das FHEM Device welches die Events eigentlich erzeugt, bei mir halt ein powerMeter welches den Stromzähler liest.
Mit den publishReading_<ReadingName> /PowerMeter/power kannst du dir schöne Strukturen aufbauen, ein
publishReading_Oelstand /Keller/Heizung/Oelstand
wäre da denkbar wenn du ein Reading Oelstand am FHEM device hast.
Du kannst da beliebig viele Readings hinterlegen. Ich habe noch mittels event-on-update-reading auf dem FHEM device die Events eingeschränkt auf die die ich auch via MQTT übertragen möchte um unnötig Traffic/Last zu erzeugen auf dem alten rPi (Model B).

Wichtig ist halt zu verstehen, dass du pro FHEM Device welches du via MQTT publishen möchtest ein MQTT_BRIDGE Device benötigst mit den entsprechenden Readings via publishReading_*

Das wars auf dem Sender schon.

Auf dem Primären Server: (den MQT Broker von oben nicht vergessen!)

Anlegen eines "Pseudo PowerMeter Devices" als MQTT Device welches die Readings später erhält.

Code Auswählen Erweitern


define MQTT_PowerMeter MQTT_DEVICE
attr MQTT_PowerMeter IODev MQTT_Broker_loki
attr MQTT_PowerMeter group Strom
attr MQTT_PowerMeter room Dachboden,Wohnung
attr MQTT_PowerMeter subscribeReading_power /PowerMeter/power
attr MQTT_PowerMeter subscribeReading_zaehlerStand /PowerMeter/zaehlerStand


Hier ähnlich wie auf der Sender-Seite, via subscribeReading_<ReadingName> /PowerMeter/power erhalte ich ein Reading power am Device MQTT_PowerMeter. Die Struktur habe ich oben ja schon kurz erklärt.

Auf dem Device kannst du nun alle Schandtaten anstellen die du auch mit einem "normalen" FHEM Device anstellen kannst, also FileLog anhängen, Events/Notify/DoIfs usw.
Sobald vom MQTT Sender eine Nachricht via publish geschickt wird erhält der Empfänger diese und schreibt sie in das entsprechende Reading.

Ich habe das im Moment eben nur in eine Richtung laufen aber dafür überwache ich den Zählerstand und ebenfalls (gleiches Vorgehen) via SYSMON bekomme ich die CPU Temperatur, den Load auf meinem primären FHEM-Server gepusht. Was ich im Moment nicht mache ist auch in die gegengesetzte Richtung etwas schicken, weil ich dafür keinen Anwendungsfall habe (im Moment!)

Wenn du noch Fragen hast, einfach melden.

Evtl. Sollte ich doch ein eigenes Topic eröffnen dafür.

[bgewehr]

Plus 1 für MQTT. Meine Erfahrungen sind auch sehr gut!

[Thomas41587]

Hallo zusammen,
ich würde diesen schon etwas älteren Thread mal ausgraben, da ich vor einem ähnlichen Problem stehe.
Die Beispiele wie im Thread geschrieben (dummy LED-device steuern) funktionierte auf anhieb.
Aber jetzt stehe ich vor der Herausforderung, dass ein I2C Gerät geschalten werden soll, welches (leider) viele readings hat. Und genau diese bekomme ich nicht geschalten geht das überhaupt mit dem beschrieben Weg? Oder muss ich hier explizite set-Befehle angeben (nur wo?)

Mein I2C device:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        0x41
   FUUID      5d8c59e3-f33f-1e1e-91e8-86b8c4a2c745b433
   Frequency  82.5 Hz
   I2C_Address 65
   IODev      RPII2C_1
   NAME       I2C_PCA9685_esszimmer
   NR         21
   RPII2C_1_SENDSTAT Ok
   STATE      Ok
   TYPE       I2C_PCA9685
   READINGS:
     2019-09-27 09:49:33   Port00          4095
     2019-09-27 09:49:33   Port01          4095
     2019-09-27 09:49:33   Port02          4095
     2019-09-27 09:49:33   Port03          4095
     2019-09-27 09:49:33   Port04          4095
     2019-09-27 09:49:33   Port05          4095
     2019-09-27 09:49:33   Port06          4095
     2019-09-27 09:49:33   Port07          4095
     2019-09-27 09:49:33   Port08          4095
     2019-09-27 09:49:33   Port09          4095
     2019-09-27 09:49:33   Port10          4095
     2019-09-27 09:49:33   Port11          4095
     2019-09-27 09:49:33   Port12          4095
     2019-09-27 09:49:33   Port13          4095
     2019-09-27 09:49:33   Port14          4095
     2019-09-27 09:49:33   Port15          4095
     2019-09-27 09:50:27   Port_d00        0
     2019-09-27 09:50:27   Port_d01        0
     2019-09-27 09:50:27   Port_d02        0
     2019-09-27 09:50:27   Port_d03        0
     2019-09-27 09:50:27   Port_d04        0
     2019-09-27 09:50:27   Port_d05        0
     2019-09-27 09:50:27   Port_d06        0
     2019-09-27 09:50:27   Port_d07        0
     2019-09-27 09:50:27   Port_d08        0
     2019-09-27 09:50:27   Port_d09        0
     2019-09-27 09:50:27   Port_d10        0
     2019-09-27 09:50:27   Port_d11        0
     2019-09-27 09:50:27   Port_d12        0
     2019-09-27 09:50:27   Port_d13        0
     2019-09-27 09:50:27   Port_d14        0
     2019-09-27 09:50:27   Port_d15        0
     2019-09-27 09:52:19   state           Ok
   confregs:
     ALLCALLADR 224
     PRESCALE   73
     SUBADR1    226
     SUBADR2    228
     SUBADR3    232
     modereg1   32
     modereg2   16
Attributes:
   IODev      RPII2C_1
   OnStartup  0=off,1=on,2=off,3=off
   modereg2   INVRT
   prescale   73
   room       MQTT

Die Bridge:

Code Auswählen Erweitern

defmod MQTT_I2C_PCA9685_esszimmer MQTT_BRIDGE I2C_PCA9685_esszimmer
attr MQTT_I2C_PCA9685_esszimmer IODev MQTT_server
attr MQTT_I2C_PCA9685_esszimmer publishState /I2C_PCA9685_esszimmer/Port00
attr MQTT_I2C_PCA9685_esszimmer room MQTT
attr MQTT_I2C_PCA9685_esszimmer stateFormat transmission-state
attr MQTT_I2C_PCA9685_esszimmer subscribeSet /I2C_PCA9685_esszimmer/Port00/set

Und das Device (auf der Haupt-FHEM Instanz):

Code Auswählen Erweitern

defmod MQTT_I2C_PCA9685_esszimmer MQTT_DEVICE
attr MQTT_I2C_PCA9685_esszimmer IODev MQTT_server
attr MQTT_I2C_PCA9685_esszimmer publishSet on off /I2C_PCA9685_esszimmer/Port00/set
attr MQTT_I2C_PCA9685_esszimmer room MQTT
attr MQTT_I2C_PCA9685_esszimmer stateFormat state
attr MQTT_I2C_PCA9685_esszimmer subscribeReading_state /I2C_PCA9685_esszimmer/Port00
attr MQTT_I2C_PCA9685_esszimmer userReadings _Port00

Schalte ich von der Haupt-FHEM Instanz, so passiert auch etwas (ich kan on/off schalten) aber das I2C Gerät ändert seinen Port00 nicht (set I2C_PCA9685_esszimmer Port00 on funktioniert natürlich, wenn ich es manuell ausführe).

Ich bin hier ein wenig ratlos und wäre für Hilfe dankbar...