GPIO-LED fernsteuern - FHEM2FHEM vs ECMD vs MQTT

Pf@nne · 20 April 2015, 21:35:45

MQTT ergänzt.....

John · 20 April 2015, 21:54:36

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 · 20 April 2015, 22:19:48

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 · 23 April 2015, 18:08:04

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


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 · 25 April 2015, 09:37:16

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 · 04 Juni 2015, 14:10:38

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

Ich stehe grade an derselben Stelle ratlos...

Pf@nne · 05 Juni 2015, 20:10:56

Moin,

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

Beschreibe mal was du vorhast.

Gruß
Pf@nne

bgewehr · 05 Juni 2015, 20:13:47

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 · 09 Juni 2015, 06:46:14

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

rretsiem · 28 April 2016, 19:46:53

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


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


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


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


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 · 28 April 2016, 23:04:16

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 · 29 April 2016, 10:22:22

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


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


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

Auf dem Sender (Bei dir Heizungsraum):

Code Auswählen


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


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 · 29 April 2016, 10:23:47

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

Thomas41587 · 27 September 2019, 14:48:48

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

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

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

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...