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
define ECMD_RxD telnet 8001 global
attr ECMD_RxD room ECMD
TCP-ECMD-Client A
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
define ECMD_RxD telnet 8000 global
attr ECMD_RxD room ECMD
TCP-ECMD-Client B
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
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
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
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)
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
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)
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
define FHEM_A FHEM2FHEM 192.168.1.4:7072 LOG:.*(Trigger_F2F).*
attr FHEM_A room FHEM2FHEM
Senderseite A
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
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
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
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
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/ (http://www.reddit.com/r/raspberry_pi/comments/2tbsj8/running_mosquitto_mqtt_broker_on_raspberry_pi/)
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:
mosquitto_sub -d -t hello/world
In der zweiten Konsole kann nun publiziert werden:
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
define Broker_202 MQTT 192.168.1.202:1883
attr Broker_202 room MQTT
Empfängerseite B
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
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
attr MQTT_Error_LED subscribeReading_state /Error_LED/state
Set Kommando für die Steuerung der LED (GPIO) publizieren.
attr MQTT_Error_LED publishSet on off /Error_LED/state/set
Empfängerseite B
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
attr MQTT_Error_LED publishState /Error_LED/state
Steuerung abonnieren
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
Danke für die gute Beschreibung.... Ich lese hier mal mit ;)
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!
FHEM2FHEM ergänzt....
schau dir mal das hier: http://forum.fhem.de/index.php/topic,23638.msg169368.html#msg169368 (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
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
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
ZitatWer 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...
-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
define Broker_202 MQTT 192.168.1.202:1883bringt folgenden Fehler:
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.
Bei mir sieht das so aus
Zitat-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
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!!
Kann es sein dass die notwendigen Perl Module auf der Synology fehlen?
Sent from my iPad using Tapatalk
Bei mir liefert der Befehl (ausgehend vom FHEM Verzeichnis)
ls -la FHEM/lib/Net/MQTT
folgendes
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
Ich fürchte hier fehlt was in der Syno-FHEM-Instanz
/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:
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
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
die Quellen findest du hier
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/lib/Net/ (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/lib/Net/)
John
Läuft!
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?
MQTT ergänzt.....
MQTT-Spy ist absolut überragend als MQTT-Client
http://kamilfb.github.io/mqtt-spy/ (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 (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 (http://forum.fhem.de/index.php/topic,35800.msg281297.html#msg281297)
Wer das Match wohl gewinnt ?
John
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
Die 1:1 Verbindung klappt ja schon ganz gut.. ;D
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" ?
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
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
Hat schon jemand eine Lösung für MQTT und Raspberry GPIO gefunden?
Ich stehe grade an derselben Stelle ratlos...
Moin,
was genau meinst du mit MQTT und GPIO?
Ich sehe da momentan keinen Zusammenhang?
Beschreibe mal was du vorhast.
Gruß
Pf@nne
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
Funktioniert nun! Ich poste mal die Config später!
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
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.
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:
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:
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 :-[
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 !
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!)
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!
define MQTT_Broker_loki MQTT <ip>:1883
attr MQTT_Broker_loki room MQTT
Auf dem Sender (Bei dir Heizungsraum):
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.
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.
Plus 1 für MQTT. Meine Erfahrungen sind auch sehr gut!
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:
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:
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):
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...