MQTT mit Mosquitto zur Messdatenübertragung vom Temp-Sensor zum SmartHome-System

Es gibt 3 Antworten in diesem Thema, welches 6.796 mal aufgerufen wurde. Der letzte Beitrag () ist von SolarEngel.

  • Ich bin schon längere Zeit am brüten, wie ich meine verschiedenen Datenquellen im ganzen Haus
    mit deren verschiedenen Datenformaten, neutral übers Netz zusammenbinden, überallhin transportieren kann
    und diese mehreren Anwendungen unabhängig, gleichzeitig zur Verfügung stellen kann
    und trotzdem beliebig erweiterbar für die Zukunft sein kann.
    Im ersten Schritt wird Heizraum mit Büro übers lokale Netz oder Wlan zur Messdatenübertragung mit MQTT verbunden.



    Message Queue Telemetry Transport (MQTT) ist ein offenes Nachrichten-Protokoll für Machine-to-Machine-Kommunikation (M2M).
    Das offene, lizenzfreie MQTT-Protokoll wurde bereits 1999 von IBM für die Satellitenkommunikation entwickelt
    und später in vielen industriellen Anwendungen eingesetzt. Inzwischen ist es standardisiert und MQTT gilt als ein Protokoll des Internet der Dinge.
    Es ist äußerst einfach zu implementieren, kennt drei unterschiedliche Dienstgüten (QoS) für Service-Optionen.
    Das MQTT-Protokoll ist heute schon in den meisten SmartHome-Sytemen wie FHEM, openHAB, ioBroker, Node-RED usw. integriert.


    Die Struktur in der das MQTT-Protokoll arbeitet, besteht aus der Datenquelle, die als Publisher bezeichnet wird,
    der Datensenke, dem Subscriber, und dem zwischengeschalteten Message-Broker, der für die Kommunikationssteuerung sorgt.
    Das Protokoll hat einen ereignisgesteuerten Ansatz. MQTT benutzt das Publish-Subscribe-Pattern.


    Das bedeutet, dass die Clients sich untereinander nicht kennen und einen zentralen Verteiler,
    einen sog. Broker, zur Kommunikation nutzen. Der Broker ist dafür zuständig,
    dass eine gesendete Nachricht alle interessierten Clients erreicht.


    Wenn ein Client sich zu einem Broker verbindet, teilt dieser dem Broker mit,
    für welche so genannten Topics er benachrichtigt werden möchte, also welche Topics er abonnieren möchte.
    Diesen Vorgang nennt man Subscribe.


    Wenn ein Client eine Nachricht sendet, muss dieser die Information mitsenden,
    an welches Topic diese Nachricht gesendet werden soll.
    Diesen Vorgang nennt man Publish.


    Diese Architektur ermöglicht es hochskalierbare Lösungen mit vielen Clients zu entwickeln,
    ohne dass Abhängigkeiten zwischen den teilnehmenden Clients entstehen.


    Topics: Jeder Client kann frei wählen, zu welchem Topic er publishen oder subscriben möchte.
    Topics sind frei wählbare Strings und können mittels „/“ hierarchisch aufgebaut werden.
    Topics-Beispiele wären „SolarEngel/A25“ und „SolarEngel/LC“.
    Das Root-Topic wäre hier „SolarEngel“, die untergeordneten Topics wären „A25“ und „LC“.


    Ein Client könnte entweder ein konkretes Kind-Topic abonnieren oder mittels einer Wildcard („#“)
    alle Kind-Topics eines Eltern-Topics abonnieren.
    Beispielsweise könnte er „SolarEngel/#“ abonnieren,
    was zur Folge hätte, dass er alle Nachrichten für „SolarEngel/A25“ und „SolarEngel/LC“ zugestellt bekommen würde.
    Bei den Topic-Namen wird zwischen Groß- und Kleinschreibung unterschieden.


    Warum MQTT? Ich habe mich für MQTT aus mehreren Gründen begeistern können.
    Einer davon ist, dass das Protokoll sehr leichtgewichtig ist und es ermöglicht, bandbreitenschonend Daten zu übertragen.
    Durch das Publish-Subscribe-Pattern von MQTT ist es ein Leichtes, diese Informationen an mehrere Datenkonsumenten zu verteilen,
    welche sich alle zu einem MQ MQTT Broker verbinden. Außerdem werden die Nachrichten durch die offene TCP-Verbindung,
    die jeder MQTT-Client zum Broker hält, direkt per Push an alle abonnierenden Clients versendet.


    Ein anderer interessanter Aspekt sind die verschiedenen Servicequalitäten (QoS) von MQTT. Obwohl MQTT auf TCP basiert,
    kann es bei Mobilfunknetzen zu Übertragungsproblemen kommen, welche durch Protokollmechanismen ausgeglichen werden.
    Die Zusicherung der Übertragung kann für jede Nachricht individuell angegeben werden.
    Level 0 bietet keinerlei Garantie, dass die Nachricht ankommt,
    bei Verwendung von Level 1 wird sichergestellt, dass diese mindestens einmal ankommt
    und bei Level 2, dass die Nachricht genau einmal ankommt.
    Durch die Verwendung von Level 2 bei der Übertragung zwischen SmartHome und dem Broker ist sichergestellt,
    dass alle Nachrichten auch wirklich ankommen.


    Der konkrete Aufbau und die Kommunikation in meinem Projekt zur Messdatenübertragung mit MQTT und Mosquitto
    wird mit mehreren python-scripts als Clients(python-script-A25, python-script-LC, python-script-UVR1611, python-script-KAMO-FWS usw.),
    dem freien SmartHome-System FHEM und mit dem Open Source Broker Mosquitto auf RASPI2(im Heizraum) und Cubitruck(im Büro)
    mit Raspian-Betriebssystem aufgebaut.


    Im lokalen Netz werde ich mit Level 0 arbeiten, d.h. ohne Garantie, dass die Nachricht ankommt.
    Mit einem zusätzlichen Client(python-script-DB) abonniere ich Nachrichten aller Topics und speichere sie in eine SQL-Datenbank(SQLite)
    und mache somit die Nachrichten nicht über das Protokoll persistent. Es gibt Clients für Android, Java, Perl, Python und Arduino usw.
    MQTT-Nachrichten an Topics senden und MQTT-Nachrichten abonnieren(empfangen) habe ich mit Android-App, perl-client,
    python-client und java-client getestet.

    Die ersten Tests sind vielversprechend. Auf den nachfolgenden Screenshots sieht man wie die Clients über das
    Versenden und Abonnieren von MQTT-Nachrichten miteinander kommunizieren.
    Dabei ist es ganz einfach möglich, andere Geräte(publisher) oder Abnehmer(subscriber) für die bereits vorhandenen Topics hinzuzufügen
    oder neue Daten mit neuen Topics über den Broker zu versenden, um auch andere Systeme,
    wie beispielsweise zum Testen eines zusätzlichen SmartHome-Systems oder zusätzliche Clients anzubinden und parallel mit Nachrichten zu versorgen.


    Desktop vom Raspi2 im Heizraum: 2 python-scripts als Client zum Empfang und senden von Nachrichten vom A25-Brenner


    Desktop vom Cubitruck im Büro: python-script als Client zum Empfang von Nachrichten


    Android Tablet: mit freier MQTT App zum Empfangen und senden von Nachrichten.

    Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44, BL-NET und CMI ;
    2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; zentrale Wasserenthärtung;

    PV 3,2 kWp EEG; PV-Insel 6 kWp mit Victron MultiPlus-II 48/5000/70-50 und 8 x PylonTech LiFePo4 Modul 48V 2,4 kWh US2000 mit BMS; Victron Cerbo-GX;

    Herkules SE 5000 DF DIESEL Elektrostart Stromerzeuger Generator 2x220V-1x380V, Dauerleistung 4.200 Watt, 11 Stunden Dauerbetrieb, Tankinhalt 13,3 l

  • Hallo,


    schick - ich bin nicht auf deinem informationstechnischen Niveau, aber wünschen würde ich mir sowas auch.
    Anfangsfrage dazu: wie bekomme ich denn Daten vom Brenner, oder noch besser die CAN-Daten einer UVR auf einen Raspi, so dass ich dass mit Python weiter verarbeiten kann? Wo steck ich das Kabel an und was liest die Datenpakete in nutzbarer Form aus?


    Grüße, Carsten

  • Hallo Carsten,


    meine UVR1611 ist über CAN-BUS mit dem BL-NET verbunden und hängt über diesen am lokalen Netz.
    Der Raspi hängt natürlich auch am lokalen Netz.
    Zum Auslesen auf dem Raspi verwende ich das Programm dl-aktuelle-datenx von Holger Römer.


    Link zur Homepage von d-logg-linux http://d-logg-linux.roemix.de


    In der Zip-Datei sind die lauffähigen Programme für den Raspi enthalten.


    Ich verwende die beiden nachfolgenden Aufrufe von dl-aktuelle-datenx mit diesen Parametern
    in einem script (perl.scrip oder php-script oder python-script) eingebettet,
    um die Daten von der UVR1611(BL-NET) periodisch auszulesen.
    Die ip-Adresse im i- Parameter sollte von deinem BL-NET verwendet werden.


    dl-aktuelle-datenx -i 192.168.08.15:40000 -t 0 -r 1 (für Datenrahmen1)
    dl-aktuelle-datenx -i 192.168.08.15:40000 -t 0 -r 2 (für Datenrahmen2)


    Die Daten werden im csv-Format auf dem Raspi ausgegeben und können weiterverarbeitet werden.


    Anbei ein Beispiel für ein perl-script (uvr1611fhem.pl) für den Raspi mit dem die Daten mit dl-aktuelle-datenx eingelesen werden
    und anschliessend per telnet an fhem geschickt werden.


    Gruß
    Jürgen


    Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44, BL-NET und CMI ;
    2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; zentrale Wasserenthärtung;

    PV 3,2 kWp EEG; PV-Insel 6 kWp mit Victron MultiPlus-II 48/5000/70-50 und 8 x PylonTech LiFePo4 Modul 48V 2,4 kWh US2000 mit BMS; Victron Cerbo-GX;

    Herkules SE 5000 DF DIESEL Elektrostart Stromerzeuger Generator 2x220V-1x380V, Dauerleistung 4.200 Watt, 11 Stunden Dauerbetrieb, Tankinhalt 13,3 l

  • Ich bin schon eine Weile mit MQTT am experimentieren, heute mit dem Projekt ESP8266 WLAN Messdatenübertragung der KAMO FWS-Daten zum Message-Broker Mosquitto einen Schritt weitergekommen.


    Mit dem NodeMCU-(ESP-12E-Modul mit CP2102 USB), einem sehr kleinen, preiswerten(7Euro) stromsparenden leistungsfähigen Mikrokontroller mit WLAN, bin ich auf Anhieb sehr gut zurecht gekommen,
    musste nicht viel umlernen, weil er sich auch mit der Arduino-IDE (Programmieroberfläche) leicht programmieren lässt.
    Die verschiedenen erhältlichen ESP8266-Module unterscheiden sich eigentlich nicht in der Programmierung, kann man ein Modul programmieren, kann man im Grunde alle programmieren.
    Weiterhin wurde die Programmierung erheblich vereinfacht, da jetzt auch die zwei Handshake-Leitungen per USB genutzt werden um das Board jederzeit per Arduino programmieren zu können.
    Das NodeMCU-Board hat noch zwei Taster (Reset und Flash), aber wenn man wie ich per Arduino IDE programmiert, braucht man den Flash Taster nicht nutzen.
    Die Software wird einfach per Arduino IDE mit einem Arduino Sketch überschrieben.
    Im Grunde braucht man nur das USB-Kabel einstecken und kann loslegen, es muss nichts mehr speziell für die Programmierung verkabelt werden, was die Sache sehr komfortabel für Programmierer macht.
    Achtet möglichst beim Kauf darauf, dass das Modul als USB-Wandler den Chip CP2102 verwendet,
    das hat nämlich den Vorteil dass Ihr unter neueren Betriebsystemen (Windows 7 / 8 / 10) keinen Treiber installieren müsst, da Windows diesen bereits besitzen sollte.


    Der ESP8266-Chip enthält eine 32-Bit CPU Tensilica Xtensa LX106 mit 80 MHz Taktfrequenz,
    1 MByte Programmspeicher und 96 KByte Datenspeicher sowie einen Flashspeicher von 4 MBytes.
    Bis zu 16 GPIO-Anschlüsse (GPIO = General Purpose IO)
    SPI- und I2C-Bus
    UART für Duplex-Betrieb, einen für reines Senden
    10-Bit-Analog-/Digitalwandler


    ESP8266-Module arbeiten mit 3,3V.
    5-V-Signale (z.B. Tx) zerlegt man per Spannungsteiler in zwei Komponenten mit 1,7 V und 3,3 V und führt die 3,3 V an den Eingang des ESP8266 (z.B. Rx).


    Meine Kamo-Frischwasserstation hat einen 5V TTL Datenausgang mit einer Geschwindigkeit von 19200 Baud und sendet in (standby) alle 15 Sekunden und wenn WW gezapft wird im 2 Sekundentakt eine Datenzeile.


    Fritzing Plan Kamo-Projekt



    Testaufbau auf dem Schreibtisch, mit Arduino-Uno als Test-Sender (5V TTL mit 19200 Baud)


    Einbau in KAMO Frischwasserstation, das kleine Experimentierboard wurde über der Steuerung befestigt.


    Kamo Frischwasserstation mit ESP8266



    ESP8266-Arduino-Sketch (Programm)



    Mit dem NodeMCU-(ESP8266) werden nachfolgende Message (Daten) Zeilen alle 15 Sekunden von der KAMO seriell über den UART im ESP8266 mit 19200 Baud eingelesen
    und über WLAN an den Message-Broker Mosquitto geschickt.



    d hh:mm:ss Tsoll T_WW_ T_Zir TPrVL TPufO TPrRL TPufM 01 02 03 04 05 06 07 08 09 10 l/min FB P1% P2% LS Anh RL Err
    Message arrived [kamod] 1 09:21:56 060,0 059,1 024,3 078,0 222,2 063,7 222,2 84 79 155 02 117 100 100 100 100 100 000,0 01 000 000 0 0 1 0
    Message arrived [kamod] 1 09:22:11 060,0 059,1 024,3 078,0 222,2 063,7 222,2 84 79 155 02 117 100 100 100 100 100 000,0 01 000 000 0 0 1 0
    ...


    Nun können diese Messages zeitgleich von allen an den Message-Broker Mosquitto
    connecteten Anwendungen mit dem topic kamod gelesen und weiterverarbeitet werden.



    Gruß
    Jürgen

    Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44, BL-NET und CMI ;
    2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; zentrale Wasserenthärtung;

    PV 3,2 kWp EEG; PV-Insel 6 kWp mit Victron MultiPlus-II 48/5000/70-50 und 8 x PylonTech LiFePo4 Modul 48V 2,4 kWh US2000 mit BMS; Victron Cerbo-GX;

    Herkules SE 5000 DF DIESEL Elektrostart Stromerzeuger Generator 2x220V-1x380V, Dauerleistung 4.200 Watt, 11 Stunden Dauerbetrieb, Tankinhalt 13,3 l

    Einmal editiert, zuletzt von SolarEngel ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!