Kennt sich hier jemand gut mit MQTT aus? Ich habe hier jetzt eine Art Sensor mit einer Software, die ein paar "Messdaten" auf einen MQTT-Server schreibt. Da dachte ich mir, das ist doch eine gute Gelegenheit, sich mal mit MQTT zu beschäftigen, wollte ich schon immer mal machen. MQTT selbst ist ja nun kein Akt. Ich habe mosquitto auf meiner OpenSuse 15.4 installiert, die Daten kommen wie gewünscht an und können in textlicher Form mit mosquitto_sub "live" angezeigt werden. So weit, so gut. Jetzt hätte ich gerne aber die Daten als Grafik. Nicht unbedingt in Echtzeit, aber vielleicht doch etwas komfortabler als per Bash-Script ein CSV zu kreieren und mit LibreOffice zu öffnen und dann eine Grafik aus dem Sheet zu machen. :-) Da dachte ich mir, da gibt es doch bestimmt was fertiges. Erwartungsgemäß gibt es jede Menge Software für MQTT, aber die meiste empfinde ich als zu komplex. Ich will mir keine Home-Automation-Tools installieren, dessen Fähigkeiten ich zu 90% nicht nutze und auch keine komplexe Kette von Anwendungen. Wenn ich es dann doch mal versuchsweise mache, z.B. Grafana mit seinem MQTT-Datasource-Plugin, funktioniert es nicht und bringt nur Fehlermeldungen, die mich nicht weiter bringen. Andere Tools sind schon ein paar Jahre alt und irgendwelche Abhängigkeiten funktionieren nicht mehr. Ich suche einfach nur ein Tool, dem ich eingebe, zu welchem MQTT-Server es konnektieren soll, welches MQTT-Topic er visualisieren soll und dann noch den Zeitraum, den ich grade betrachten will. Die Eingaben gerne per GUI, als Switches auf der Kommandozeile wäre aber auch OK. Am liebsten wäre mir natürlich ein Open-Source-Tool. Man sollte meinen, dass es sowas geben müsste. Ich habe es aber noch nicht gefunden. Kennt jemand sowas? Dann wäre ich sehr dankbar. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
On 19.01.23 15:16, Manfred Haertel, DB3HM wrote:
Ich suche einfach nur ein Tool, dem ich eingebe, zu welchem MQTT-Server es konnektieren soll, welches MQTT-Topic er visualisieren soll und dann noch den Zeitraum, den ich grade betrachten will. Die Eingaben gerne per GUI, als Switches auf der Kommandozeile wäre aber auch OK. Am liebsten wäre mir natürlich ein Open-Source-Tool.
Du hast ja - glaube ich - ein Verständnisproblem. MQTT ist nur für den Datentransport zuständig, Du kannst also live zuschauen, es findet aber keine Speicherung der Daten statt. Hierfür kannst Du im Zweifel jede DB nehemen, Influx DB hat sich hier für Zeitreihen als besonders geeignet gezeigt. Dann brauchst Du ein Tool, das aug das MQTT Topic lauscht und die DB betankt -> Telegraf Grafana kann dann die InfluxDB visualisieren Viele Grüße Ulf
Ulf Volmer schrieb:
On 19.01.23 15:16, Manfred Haertel, DB3HM wrote:
Ich suche einfach nur ein Tool, dem ich eingebe, zu welchem MQTT-Server es konnektieren soll, welches MQTT-Topic er visualisieren soll und dann noch den Zeitraum, den ich grade betrachten will. Die Eingaben gerne per GUI, als Switches auf der Kommandozeile wäre aber auch OK. Am liebsten wäre mir natürlich ein Open-Source-Tool.
Du hast ja - glaube ich - ein Verständnisproblem. MQTT ist nur für den Datentransport zuständig, Du kannst also live zuschauen, es findet aber keine Speicherung der Daten statt.
Hierfür kannst Du im Zweifel jede DB nehemen, Influx DB hat sich hier für Zeitreihen als besonders geeignet gezeigt.
Dann brauchst Du ein Tool, das aug das MQTT Topic lauscht und die DB betankt -> Telegraf
Grafana kann dann die InfluxDB visualisieren
Ich hatte da nicht unbedingt ein Verständnisproblem, nur erst mal kein Verständis dafür :-), warum ich gleich DREI mir unbekannte Tools haben muss (wenn ich nicht auf die allumfassende Home-Automation-Lösung setzen will). Ich hätte halt erwartet, dass es eine Lösung "aus einem Guss" gibt. Hätte es ja auch fast gegeben, wenn das MQTT-Plugin von Grafana funktionieren würde. Tut es aber eben nicht (zumindest nicht richtig), auf github unter den Issues des Plugins schreiben mehrere Leute, das sie ähnliche Probleme haben wie ich. Auf der anderen Seite ist es auch nicht verkehrt, die Daten in einer Datenbank zu haben, um das Datenspeichern von der Visualisierung zu entkoppeln. Dann kann man auch manuelle Auswertungen per SQL machen. Und Grafana doch nutzen zu können, wäre auch schick, denn das Tool gefällt mir (und ist sogar bei OpenSuse dabei, wenn auch in einer uralten Version). Ich werde mir also im nächsten Schritt mal den Telegraf anschauen. Vielleicht kann ich ja auch mit einer DB arbeiten, die ich kenne. Sqlite würde mir ja schon reichen. Würde auch etwas die Komplexität insgesamt reduzieren. Also: Danke für den Tipp! -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Manfred Haertel, DB3HM schrieb:
Auf der anderen Seite ist es auch nicht verkehrt, die Daten in einer Datenbank zu haben, um das Datenspeichern von der Visualisierung zu entkoppeln. Dann kann man auch manuelle Auswertungen per SQL machen. Und Grafana doch nutzen zu können, wäre auch schick, denn das Tool gefällt mir (und ist sogar bei OpenSuse dabei, wenn auch in einer uralten Version).
Ich werde mir also im nächsten Schritt mal den Telegraf anschauen.
Vielleicht kann ich ja auch mit einer DB arbeiten, die ich kenne. Sqlite würde mir ja schon reichen. Würde auch etwas die Komplexität insgesamt reduzieren.
Der Telegraf ist ja auch schon wieder ein Monster, kann zwar mit Dutzenden von Input- und Output-Medien umgehen, darunter auch SQLite als Output. Aber ich will nicht ein riesengroßes Tool, was alles kann, von dem ich aber fast nichts nutze. Und die Influx Datenbank wäre das nächste Monster. Ah nä! Ist mir egal, dass man das "heute so macht", aber das ist mir viel zu komplex. Ich hab jetzt ein einfaches Tool namens mqtt2sql gefunden, was sogar funktioniert (was man bei weitem nicht von allen solchen Tools behaupten kann, im Gegenteil, fast nichts funktioniert richtig, komische "Welt" da bei MQTT) und noch aktiv gepflegt wird. Unterstützt SQLite und auch MySQL/MariaDB, falls mir mal SQLite nicht mehr reichen sollte wäre das ganz praktisch. Die Datenbankstruktur erscheint mir auch einfach und logisch. Mal schauen, wie ich mich weiter taste. Wenn ich die Daten vernünftig mit SQL wieder aus SQLite rausziehen kann, könnten auch einfachere Grafik-Tools reichen. Noch mal danke an Ulf für das Schubsen in die richtige Richtung (mit zwischen geschalteter DB). -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Manfred Haertel, DB3HM schrieb:
Mal schauen, wie ich mich weiter taste. Wenn ich die Daten vernünftig mit SQL wieder aus SQLite rausziehen kann, könnten auch einfachere Grafik-Tools reichen.
Ich hab noch mal Grafana ausprobiert, jetzt mit einer SQLite-Datensource. Auch die bringt nur irritierende Fehlermeldungen (angebliche Zugriffsprobleme auf die Datenbank-Datei sowie out of Memory). Gibt es denn eine Datensource, die in dem Tool funktioniert? Ich hab das Thema Grafana jetzt endgültig abgehakt. Ein nahezu triviales Script, was die Daten per SQL-Abfrage aus der SQLite-Datenbank rausholt und nach gnuplot pipet, funktioniert jedenfalls und reicht mir, wenn es noch fertig verfeinert ist. Gegenüber der "modernen" Lösung locker ein gutes halbes Gigabyte gespart. Bei "tradioneller" Installation. In den meisten Tutorials werden Container empfohlen. Gegenüber dieser Lösung habe ich sicherlich mehrere Gigabyte gespart. Schöne neue Welt. Aber nix für mich. Ich will was, was einfach nur funktioniert. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
On 20.01.23 12:34, Manfred Haertel, DB3HM wrote:
Mal schauen, wie ich mich weiter taste. Wenn ich die Daten vernünftig mit SQL wieder aus SQLite rausziehen kann, könnten auch einfachere Grafik-Tools reichen.
Ich hab noch mal Grafana ausprobiert, jetzt mit einer SQLite-Datensource. Auch die bringt nur irritierende Fehlermeldungen (angebliche Zugriffsprobleme auf die Datenbank-Datei sowie out of Memory). Gibt es denn eine Datensource, die in dem Tool funktioniert? Ich hab das Thema Grafana jetzt endgültig abgehakt.
Ich habe hier MySQL, Influx und Prometheus als Datasource definiert. Tut wie es soll. Zu sqlite kann ich nichts betragen. Viele Grüße Ulf
Hallo Ulf, Hallo Manfred, Am 20.01.23 um 13:31 schrieb Ulf Volmer:
On 20.01.23 12:34, Manfred Haertel, DB3HM wrote:
Mal schauen, wie ich mich weiter taste. Wenn ich die Daten vernünftig mit SQL wieder aus SQLite rausziehen kann, könnten auch einfachere Grafik-Tools reichen.
Ich hab noch mal Grafana ausprobiert, jetzt mit einer SQLite-Datensource. Auch die bringt nur irritierende Fehlermeldungen (angebliche Zugriffsprobleme auf die Datenbank-Datei sowie out of Memory). Gibt es denn eine Datensource, die in dem Tool funktioniert? Ich hab das Thema Grafana jetzt endgültig abgehakt.
Ich habe hier MySQL, Influx und Prometheus als Datasource definiert. Tut wie es soll. Zu sqlite kann ich nichts betragen.
Mit SQLite hatte ich in der Vergangenheit auch schon einmal Probleme. Damals hatte ich es für eine gute Idee gehalten SQLite als Datenbank für meine Owncloud-Umgebung zu nutzen. Und dann habe ich mich gewundert, dass ich häufig keine Verbindung hinbekommen habe. Dann habe ich mich etwas mit SQLite beschäftigt und bin darauf gestoßen, dass SQLite alle Zugriffe nur nacheinander abwickeln kann. SQLite ist in erster Linie für eingebettete Verwendung gedacht, wo nur ein Prozess die Daten schreibt und liest. Näheres findest Du auch hier: https://de.wikipedia.org/wiki/SQLite Das bedeutet, dass in Deinem Fall die Daten via MQTT angeliefert werden und Du dann ggf. Pech hast, dass die DB dauernd vom Datenlieferanten gesperrt ist. Umgedreht könnte es passieren, dass Du mit der Auswertungsanwendung gerade liest und der Datenlieferant nicht mehr an die DB kommt. Ich würde Dir daher dringend empfehlen für Dein Szenario eine andere DB zu nehmen, die auch parallele Zugriffe erlaubt. Sonst wirst Du nicht glücklich. Mein Favorit ist da PostgreSQL. Das ist auch aktuell und im Standard schon enthalten. Viel Erfolg Mark
Mark Wenzel schrieb:
Mit SQLite hatte ich in der Vergangenheit auch schon einmal Probleme. Damals hatte ich es für eine gute Idee gehalten SQLite als Datenbank für meine Owncloud-Umgebung zu nutzen. Und dann habe ich mich gewundert, dass ich häufig keine Verbindung hinbekommen habe. Dann habe ich mich etwas mit SQLite beschäftigt und bin darauf gestoßen, dass SQLite alle Zugriffe nur nacheinander abwickeln kann. SQLite ist in erster Linie für eingebettete Verwendung gedacht, wo nur ein Prozess die Daten schreibt und liest. Näheres findest Du auch hier: https://de.wikipedia.org/wiki/SQLite
Das bedeutet, dass in Deinem Fall die Daten via MQTT angeliefert werden und Du dann ggf. Pech hast, dass die DB dauernd vom Datenlieferanten gesperrt ist. Umgedreht könnte es passieren, dass Du mit der Auswertungsanwendung gerade liest und der Datenlieferant nicht mehr an die DB kommt. Ich würde Dir daher dringend empfehlen für Dein Szenario eine andere DB zu nehmen, die auch parallele Zugriffe erlaubt. Sonst wirst Du nicht glücklich.
Ich bin ja jetzt glücklich. Auch mit SQLite, aber ohne die modernen Monster-Tools. Und ich weiß, was ich tue. Die Beschränkung von SQLite ist nämlich die, dass zum Schreiben (kurzzeitig, für die Dauer des Schreibens) ein Lock auf die GESAMTE Datenbank gehalten wird und eben nicht so selektiv wie bei komplexeren Datenbanken. Siehe auch https://www.sqlite.org/faq.html#q5 Aber ich habe ja auch nur einen "Schreiber". Folglich funktioniert das Konstrukt in meiner eigenen "zurecht gebastelten" Umgebung. Dass es mit Grafana nicht funktioniert hat, muss also andere Gründe haben. Und nein, da SQLite völlig ausreichend ist und erwartungsgemäß problemlos funktioniert, will ich keine andere Datenbank. Ich setze hier SQLite auch noch für andere Dinge ein, für die es geeignet ist und da funktioniert es auch. Ich will nix komplexeresm, so lange ich es vermeiden kann. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
participants (3)
-
Manfred Haertel, DB3HM -
Mark Wenzel -
Ulf Volmer