MQTT Client und Broker für Raspberry

[Timm Thaler]

Ich sammle auf einem Raspberry Pi 3B Daten verschiedener Sensoren (nRF24 Sender, GPIO, RS232) mit mehreren kleinen Progrämmchen. Die Daten werden als csv-Dateien in ein virtuelles Verzeichnis geschrieben, von wo aus sie von anderen Progrämmchen (Web-CGI, Telegram Bot) abgefragt werden können.

Allerdings ist das a) etwas altbacken in der Vorgehensweise und b) kommt es immer mal zu Kollisionen mit den Schreib-Lesezugriffen auf die Dateien, was dann z.B. zum Absturz des Telegram Bots führt.

Nun möchte ich weitere Datenquellen / Sensoren zufügen und überlege, ob ich das System auf MQTT umstelle. Das heißt, ich lasse einen MQTT Broker laufen, und schicke dem die Daten von meinen Sensoren bzw. frage die Daten für die Webseite oder den Telegram Bot vom Broker ab.

Dazu müsste ich allerdings mehrere MQTT Clients* schreiben, die meine nRF24, GPIO, RS232 Datenquellen mit dem Broker verbinden. Gibt es dazu schon brauchbare Pascal-Projekte? Ich habe hier https://github.com/cutec-chris/TMQTTCli ... t/mqtt.pas was gefunden, aber das scheint ziemlich alt und unvollständig zu sein.

Und welchen MQTT Broker würdet ihr für den Raspi nehmen, er sollte ressourcenschonend sein?

*) Mehrere deswegen, damit z.B. die Abfrage der RS232 oder GPIOs problemlos weiterlaufen kann, wenn ich am nRF24-MQTT-Client rumfummle.

[af0815]

Schau dir mal folgendes an https://github.com/afriess/mqtt/tree/LessDepends . DIe habe ich im Einsatz. Das Less depends, bedeutet, das ich die Abhängigkeiten aufgelöst habe und die 'abhängigen' Pakete integriert habe. Ansonsten hast du einiges an IMHO unnötigen Balast zu installieren. Da wird wegen einer kleinen Abhängogkeit gleich ein ganzes Arsenal an anderen Komponenten installiert.

LNetVisual wird noch benötigt, ansonsten habe ich die Version auf RasPis ohne Probleme am Laufen.

Aktuell verwende ich fpc fixes32 und Lazarus fixes20. Damit geht es mal sicher.

LNet versorgt den MQTTClient mit Daten, das ist am Anfang ein wenig Tricky, aber wenn läuft, dann läuft es. Das Beispiel des Clients kann man nehmen, wenn man die Abhängigkeit nach bkutils löscht, das Paket mqttcompontslessdepend verwendet und bei lnet SSl ausschaltet. Dann läuft auch das.

Ansonsten kann man sich ja mal alle Abhängigkeiten zusammensuchen, dann geht auch das Beispiel.

[Timm Thaler]

Kann das auch MQTT-SN, also die Kurzform für Sensor Networks? Wobei das nicht so wichtig ist, der Raspi muss eh die nRF24 Daten umsetzen - ich überlege ob ich die im MQTT-SN Format versende statt wie bisher in selbstgestrickten ASCII-Strings. Aber wenn ich mal ESP einsetzen will, könnte das mit den SN-Protokoll interessant werden.

[af0815]

MQTT-SN sicher nicht. Ich bin zumindest nirgends darüber gestoplert.

[mschnell]

Für gemeinsame Zugriffe sind Datenbanken eigentlich der Standard.
Kann man auf dem RasPi z.B. SQLite laufen lassen und die Web-Zugriffe über ein (z.B.) PHP Script machen ?
-Michael

[Timm Thaler]

Ich hab am Anfang lange wegen Datenbanken gesucht, und bin letztlich drauf gekommen, dass das auch nur csv-Dateien sind, nur anders verwaltet.

Nein, der Hauptgrund gegen Datenbanken, vor allem gegen sowas wie RoundRobin auf dem Pi war, dass die Daten ständig neu an die gleichen Speicherstellen geschrieben werden, was bekanntlich der SD-Karte nicht zuträglich ist. Bei der csv wird immer nur eine Zeile angehängt, und die bereits geschriebenen Daten nicht mehr angefasst. Das betrifft natürlich nur geloggte Daten, nicht die im virtuellen Verzeichnis. Aber eine Datenbank mit virtuellem Verzeichnis scheint mir auch nicht sinnvoll.

Ein Punkt für MQTT gegenüber Datenbank wäre, dass ich von jedem Gerät drauf zugreifen kann, bsp. vom Smartphone per MQTT App. Und dass es sich einfach in eine Homeautomation einbinden läßt. Und ESP-Geräte direkt ihre Daten eintragen oder abfragen können. Das sind ja schon 3 Punkte...

[af0815]

Die Web DB kann kein Push.

MQTT hat schon seinen Sinn, wenn man sich ansieht was es kann. Es gibt mittlerweile Messgeräte, die über MQTT Daten liefern. Dies irgendwie mit PHP nachzubauen, brrr, weil die Messgeräte vom Kunden kann man nicht ändern.

[mschnell]

dass die Daten ständig neu an die gleichen Speicherstellen geschrieben werden, was bekanntlich der SD-Karte nicht zuträglich ist.

Das stimmt nicht (sondern nur für EProms). SD-Karten, USB-Sticks und SSDs machen intern "ware-Leveling". Damit ist es egal auf welche Adresse irgendwas geschrieben wird. Wenn man viele Daten schreibt, ist natürlich tzotzdem irgendwann ein Limit erreicht (das stark von der Größe des Mediums abhängt).

Ich würde sagen: entweder eine Datenbank aus der Schublade, oder alles - inklusive Satz-Sperren bei Zugriff von mehreren Seiten - selber programmieren.

(MQTT ist doch ein Protokoll und kein Datenspeicher Ich sehe da die Alternative MQTT vs Datenbank nicht.

-Michael

[Timm Thaler]

SD-Karten, USB-Sticks und SSDs machen intern "ware-Leveling". Damit ist es egal auf welche Adresse irgendwas geschrieben wird.

Ok, das war etwas vereinfacht ausgedrückt. Bei der Datenbank werden deutlich mehr Daten geschrieben. Zum Beispiel um Daten zu loggen, wird bei einer csv-Datei nur ans Ende der Datei was angehängt. Dabei wird der aktuelle Block verändert - und durch wear leveling eventuell an eine andere Stelle geschrieben - aber alle bisher beschriebenen vollen Blöcke werden nicht mehr angefasst. Bei einer Datenbank werden alle Daten immer wieder komplett neu geschrieben.

Oder flüchtige Daten, die werden zur Zeit bei mir in eine csv-Datei im Ram abgelegt, und alle paar Sekunden aktualisiert. Zum Beispiel holt ein Programm ein Bild von einer Webcam und legt es in den Ram, wo es dann an Webseiten die keinen direkten Zugriff auf die Webcam haben weitergeleitet wird. Mit einer Datenbank würde das ständig auf die SD-Karte geschrieben, und das sind zwar nur ein paar Mbyte, aber halt immer wieder.

MQTT ist doch ein Protokoll und kein Datenspeicher Ich sehe da die Alternative MQTT vs Datenbank nicht.

Der MQTT Broker ist ein Datenspeicher für flüchtige Daten. Der hält halt die Daten nicht auf der SD-Karte, sondern wie bei meiner bisherigen csv-Lösung im Speicher. Nur dass er die Daten besser verteilen kann als meine csv-Lösung, die halt immer mal abkackt wenn ein Programm gerade auf die Daten zugreifen will, die ein anderes Programm schreiben will.

Und der MQTT Broker wäre deutlich flexibler, weil ich einfach für neue Daten ein neues Topic anlege, bei der csv-Lösung muss ich immer alle abfragenden Programme anpassen, wenn ich an der Datenstruktur was ändere.

[mschnell]

Klar: Video in einer Datenbank ist ziemlich abstrus
Nur der Vollständigkeit halber: es gibt auch memory-basierte Datenbanken.
-Michael

[Timm Thaler]

Nur der Vollständigkeit halber: es gibt auch memory-basierte Datenbanken.

Zum Beispiel? Für den Raspi wird ja gern round-robin vorgeschlagen, weil die so schön datensparend ist, alte Daten werden regelmäßig überschrieben. Mir suspekt, denn beim Raspi ist ja nicht die schiere Datenmenge das Problem, sondern das häufige Schreiben.

Und sqlite auf Ramdisk umzubiegen, dazu hab ich auch nichts gefunden. Zumal ja nur ein Teil der Daten flüchtig sein soll, langfristig sollen schon Tageswerte und so gespeichert werden. Bei MQTT würde ich das dann halt so machen: Ein Programm holt sich regelmäßig die letzten Daten vom Broker und speichert die ab.

Video in einer Datenbank ist ziemlich abstrus

Da muss ich noch rausfinden, ob MQTT Bilder empfangen und weitergeben kann.

[af0815]

...Ein Programm holt sich regelmäßig die letzten Daten vom Broker und speichert die ab.
...Da muss ich noch rausfinden, ob MQTT Bilder empfangen und weitergeben kann.

Liefert dir die Daten verlässlich, aber mit später holen ist nichts mehr. Das musst du dann selbst zwischenspeichern. Der Broker ist ganz einfach ein (verlässlicher) Callback.

Bilder empfangen ist aufgrund der Datenmenge nicht wirklich zielführend auf MQTT. Da geht es um (relativ) leichtgewichtige REST (JSON oder XML) Kommunikation. Für Bilder nicht gedacht.

[Timm Thaler]

Liefert dir die Daten verlässlich, aber mit später holen ist nichts mehr.

Ist es nicht so, dass ich bei einem neuen Subscribe die zuletzt eingegangene Message für das Topic bekommen kann? Und die eine Zeitdauer hat, die sie gültig ist?

Also zum Beispiel: Wetterstation published Temperatur. Broker sendet Temperatur an alle Clients, die Wetterstation/Temperatur abboniert haben. Meldet sich jetzt der Telegram-Bot und abboniert Wetterstation/Temperatur, bekommt er die zuletzt gemeldete Temperatur geschickt. Meldet sich jetz der Logger und abboniert Wetterstation/#, bekommt er alle letzten Daten der Wetterstation.

Hab ich das falsch verstanden?

[af0815]

Kann ich dir nicht sagen ob du da falsch liegst. Bei meiner aktuellen Konfiguration ist es nicht so.

Da bekomme ich aber Daten fast im Sekundenrythmus von den Energiemessgeräten. Und die alte Messung ist für mich Schnee von gestern. Allerdings lässt sich sehr viel konfigurieren , sowohl am Client als auch am Server. Nachdem ich lokal nur Mosquitto verwende, ist es am Server auch etwas weniger.

Pingelig ist der Server mit den 'i am alive' Paketen, wenn die nicht pünktlich am Server ankommen, bist du draußen und das zu recht

[mschnell]

Zum Beispiel?

-> https://www.mcobject.com/in_memory_database/

-> https://de.wikipedia.org/wiki/In-Memory-Datenbank
Sagt, SQLite ud MySQL können auch als Memory-Datenbank eingerichtet werden -> https://www.sqlite.org/inmemorydb.html

-> http://www.memdb.com/MemDB/MemDBE.htm
-> http://www.delphigroups.info/2/6e/60976.html

Ich würde SQLite im ":memory:" Modus versuchen.

-Michael