Hallo zusammen,
im folgenden Beiträgen möchte ich gerne vorstellen, wie man sich ein Monitoring System mit Node-Red - MQTT - InfluxDB und Grafana aufbaut. Bei mir läuft das alles auf Raspberry PIs und einem Strato Server (1-2€/ Monat).
Aufgebaut werden soll das wie folgt:
1. Sensoren (Shelly, Homematic, etc)
2. Anbindung an das Hirn zur Datenaufbereitung mittels MQTT (Broker, Raspberry Pi, DietPI)
3. Node-Red zur Datenaufbereitung (Raspberry PI, DietPI)
4. Speicherung der Daten in InfluxDB
5. Darstellung via Grafana
Gruß Lukas
Finde ich interessant. Wenn man eine Nulleinspeisung oder (finde ich eigentlich noch interessanter, da ohne teure Batterie) eine intelligente Steuerung seiner Verbraucher realisieren will, ist ja das Messen, Daten loggen und darstellen der richtige Anfang für eine Anlagenplanung. :thumbup:
Ich bin leider immer noch nicht dazu gekommen, das Mal schön zu schreiben. Folgt. Aber in den nächsten Tagen... Dann gibt es endlich Input.
Sehr gerne, das Thema interessiert mich auch brennend :thumbup:
Bei uns in dem Bereich PV geht es am meisten darum Ströme, Spannungen, Leistungen und Energie zu messen und aufzuzeichnen. Daher belasse ich es mal auch bei den Messgrößen. Es ist klar, dass man alles Mögliche messen kann. Bei mir zu Hause kommen durch das Smart Home noch Temperatur, Luftfeuchtigkeit, Positionen von Schrittmotoren für die Heizung, Positionen von Schalter und Taster und weitere Werte hinzu.
Es wird um folgende Geräte gehen, die alle bei mir in Benutzung sind:
Homematic:
Persönlich habe ich zur Strommessung mit dem Bauteil „Homematic Hutschienen-Schaltaktor mit Leistungsmessung HM-ES-PMSw1-DR“angefangen. Der Schaltaktor kann recht simpel in die Homematic Welt eingebunden werden, kann 16A dauerhaft messen und schalten und arbeitet mit 230 V Wechselspannung an den Eingängen sowie Ausgängen. Ist gibt noch andere Aktoren von Homematic, nur können diese entweder nicht mit 230 Vac oder mit einer Last von 16 A arbeiten und diese auch messen.
Warum der? Ich habe beim Smart Home mit Homematic gestartet und wolle erst einmal in der Welt von Homematic bleiben. Für 44,95 € (4.11.2022) als Bausatz finde ich das Gerät nicht gerade billig, aber auch bei weiten nicht zu teuer.
Vorteile:
Nachteil:
Des Weiteren nutze ich noch Shellys (1, 1PM, 2.5, i3, EM, 3EM)
Shellys sind teilweise kleine Geräte die genau in eine Unterputzdose hinter einen Schalter/Taster etc. passen und somit nachträglich das Haus smart machen können. Sie werden über das W-Lan direkt mit in das Netz gebunden. Die Geräte werden entweder direkt über eine Weboberfläche verwalten, in eine App mit eingebunden oder es wird via MQTT kommuniziert. Es gibt aber noch mehr Möglichkeiten mit den Shelly zu kommunizieren (CoIoT, http, Bluetooth, …)
Alle bis auf den Shelly i3, haben einen oder zwei schaltbare Ausgänge. Der Ausgang ist beliebig programmierbar und kann unabhängig von den Schalteingängen über Software gesteuert werden. Besonders ist der Ausgang vom Shelly 1. Dieser ist als „Dry contact“ ausgeführt. Die Kontakte I und O sind galvanisch vom Rest des Shelly getrennt. Somit kann der Shelly mit 12 Vdc, 24 Vdc oder 230 Vac betrieben werden und der Ausgang unabhängig davon 12 Vdc, 24 Vdc oder 230 Vac schalten. Dies ist sehr nützlich beim Betrieb von Klingeldrückern, Gongs usw. die teilweise nur mit Schutzkleinspannung betrieben werden dürfen oder können.
Die Shelly EM und 3EM sind richtige Energy Meter und sind für das messen von großen Strömen (50 A / 120 A) gebaut. Durch die externen Stromsensoren mit geteiltem Kern, können diese Nachträglich im Betrieb eingebaut werden, ohne den Stromkreis unterbrechen zu müssen. Dies ist bei allen anderen genannten Shellys der Fall. Diese messen den Strom über eine interne Schaltung. Des Weiteren behalten sich die EM-Varianten die Zählerstände für die geflossene Energie bei einem Stromausfall. Dies machen die anderen (Shelly 1 – i3) nicht. Mit einer vernünftigen Wartung der Anlage, lässt sich dieses Problem aber umgehen.
Vorteil:
Nachteil:
Fazit:
Wer Platinen nicht selber bauen will oder sich mit der Programmierung von Microchips auseinander setzen will, für den ist Homematic und Shelly eine gute Alternative. Kaufen, (zusammen bauen), anschließen und in Betrieb nehmen. Fertig!
Wer schon Homematic hat und in der Welt bleiben will, den kann ich den „Hutschienen-Schaltaktor mit Leistungsmessung HM-ES-PMSw1-DR“ empfehlen. Er ist im Bausatz einfach aufzubauen und kann als Kenner vom Homematic easy mit in das System eingebunden werden.
Wer nicht auf Homematic steht oder es sehr preiswert haben will, greift zu Shellys. Für ein richtiges Energy Meter von 3 Phasen ist klar der Shelly 3EM die richtige Wahl. Solche 3 phasigen Strommesser sind eigentlich wesentlich teurer. Für 1 phasige Anwendung ist der Shelly 1PM für 16 A oder Shelly 2.5 für 10 A.
Klar ersetzen die Geräte keine Hardware für Profis, aber das für unseren Bereich auch garnicht gefordert.
Ich würde gerne eine Überlegung beisteuern.
Die Kombination aus Node-Red/MQTT/Grafana habe ich seit Jahren für die Hausautomation im Einsatz. Von InfluxDB bin ich allerdings wieder abgekommen (jetzt: MySQL), weil ich die normalen SQL-Abfrageroutinen nutzen wollte. (Das ist bzw. war mit Influx nicht so ganz einfach, da es den Schwerpunkt auf Zeitreihen hat.)
Meine Tabelle hat also die Struktur | ID | Zeitstempel | Werteliste.... (sehr breit)
Seither lege ich alle Werte, die ich irgendwo erfasse, zunächst in Node-Red mit global.set(Name, Wert) ab und speichere in festen Zeitintervallen (bei mir: 1 Minunte) die Werte ab, die dazu aus den abgelegten Variablen gelesen werden. In einer zentralen Node setze ich das insert-Statement zusammen und übergebe es an die Node, die MySQL direkt anspricht.
Für besondere Zwecke (meist nur temporär zum debuggen) schreibe ich Werte zusätzlich mit geringerem Zeitabstand (z.B. 15 Sekunden) in eine weitere Tabelle, um Tendenzen schnell erkennen zu können.
Viele Grüße, H.
@stillerbastler Läuft diese Lösung noch stabil und performant auch nach inzwischen nem guten halben Jahr?
Die Lösung mit Influx hätte gegenüber der MySQL Umsetzung schon diverse Vorteile:
- Spaltenbasierte Speicherung: Wenn ein Sensor/Messwert dazukommt ist das bei influx kein Problem. In deiner SQL Tabelle müsstest Du ja jedes Mal eine Spalte hinzufügen, was die Tabelle extrem breit macht und ggf. viele NULL Felder erzeugt. Zudem musst du für alle Sensorwerte dasselbe zeitliche Raster verwenden, was oft nicht gewünscht sein dürfte (Temperaturen oder SOC Füllstände sind träger als aktuelle Leistungswerte).
- Automatische Retention Policies: In Influx kann man einfach hinterlegen, dass man Werte nach 2 Jahren z.B. pro Tag aggregiert speichern möchte (Wen interessieren die Minuten-Messwerte von vor 2 Jahren?). Das wird in SQL ein ziemlicher Aufwand.
- Integrierte Aggregationsfunktionen, z.B. gleitende Mittelwerte sind für Influx ein Klacks; in MySQL tust dich da ziemlich schwer
- Abfrage-Performance bleibt konstant mit zunehmender Speichermenge, während die SQL Datenbank in der Regel mit jedem zusätzlichen Datensatz länger nach den richtigen Zeilen suchen muss.
- ...
Um es anders zu sagen: Für dieselbe "Abfrage- und Speicherleistung" brauchst Du mit Influx weniger Ressourcen, hast aber nicht die Flexibilität einer SQL Datenbank. Aber brauchst Du die SQL-Funktionen überhaupt? Lassen sich nicht auch Zustände ("Schalter offen/geschlossen", "Betriebsmodus A|B|C|..." etc) nicht auch in Zahlenwerten abbilden, die man einfach mit Labels mappen kann?
@fallenlordi - Du hast Recht, die SQL-Lösung hat sich im Rückblick nicht bewährt.
Wesentliche Schwierigkeiten sind tatsächlich das Zufügen von Spalten an Tabellen (Timeout im Frontend) mit vielen Datensätzen und die nachlassende Performance bei immer längeren Tabellen. Um die Sache handhabbar zu halten, lösche ich "zu alte" Daten aus den Tabellen.
Mein ursprünglicher Ansatz, die Fehlersuche zu erleichtern, weil SQL-Abfragen verwendet werden können, ist kaum zum Tragen gekommen. Im Notfall könnte ich die Daten für eine Fehlersuche auch aus den parallel gespeicherten und tageweise abgelegten vollständigen MQTT-Protokollen herausziehen. Bisschen Aufwand, aber es sind alle Daten vorhanden.
Ich danke daher für die Anregung und werde zumindest probeweise mal eine Influx-Instanz aufsetzen. (Läuft bei mir alles in Docker auf Linux, ist also kein nennenswerter Aufwand.)
VG StillerBastler
Okay, Wenn du doch den Mittelweg gehen möchtest könntest du auch deine SQL Tabellenstruktur in ein Long-Format ändern, z.B. mit folgenden Spalten:
ID (PK AI) | Sensor | Datum | Messwert
Sensor kann einfachheitshalber ein Textfeld sein oder - besser - Du erstellst eine zweite Tabelle mit der Form sensorId | sensor-Bezeichnung und referenzierst darauf (Normalisierungsschritt).
Das hätte den Vorteil, dass Du die Tabellenstruktur selbst nicht anpassen musst bei neuen Sensoren und dass die Zeitpunkte der Messwertserfassung unabhängig voneinander sind.
Für kurze Abfragezeiten wäre dann ein Suchindex auf die Spalten Sensor + Datum praktisch, damit sollte das System auch ne Weile performant laufen.
Aber klar, ne Influx tut sich da schon deutlich leichter.
Wie siehts allgemein aus - wir sind hier ja im Wiki. Sollen wir hier mal Datenverarbeitungsketten aufzeigen? Eventuell wäre es auch gut, auf fertige (aber auch geschlossene) Systeme hinzuweisen und trotzdem hier zu zeigen, wie man so eine Datenverarbeitungskette auch DIY aufsetzen kann.
Ich verwende TimescaleDB ist ein Offset für Postgresql. Läuft bei mir seit ca. 5 Monaten ohne Probleme.
Eine eigene Lösung würde ich dafür nicht bauen. Da kann man viel Zeit drin versenken.
Das ganze hab ich in Home Assistant integriert und Timescale wird als Wertespeicher verwendet.
Mit Influx konnte ich mich nicht anfreunden da die Query-Language und das Setup doch eine steile Lernkurve hat
Ich verwende TimescaleDB ist ein Offset für Postgresql. Läuft bei mir seit ca. 5 Monaten ohne Probleme.
Eine eigene Lösung würde ich dafür nicht bauen. Da kann man viel Zeit drin versenken.
Das ganze hab ich in Home Assistant integriert und Timescale wird als Wertespeicher verwendet.
Mit Influx konnte ich mich nicht anfreunden da die Query-Language und das Setup doch eine steile Lernkurve hat
Ja gut, Timescale vereint ja das beste aus beiden Welten: Zeitbasierte Datenbank mit SQL Syntax und Abfragemöglichkeiten.
Mir persönlich ist die Influx QL auch etwas ungriffig, zumal sich die Abfragesprache von V1.x auf 2.x extrem geändert hat. Für die meisten Anwendungsfälle kann man die Abfragen aber Grafana|Openhab|nodeRed etc überlassen. Ich kenne nicht viele use cases, bei denen eigene Abfragen wirklich notwendig sind.
Wie bist du zufrieden mit der TimescaleDB? Wir wollten das mal im großen Kontext einer kommerziellen Datenanalyseplattform einsetzen, da wäre das meine erste Wahl gewesen. Habe aber den Eindruck, dass sich da ein raspberry Pi im privaten SOHO Umfeld schwer tut weil recht schwergewichtig?
@fallenlordi Ich hab das alles auf einem RockPi von Radax laufen, der ist vergleichbar mit einen Raspi 4. Performance Probleme hab ich keine. Dort läuft:
- Home Assistant
- Postgresql mit Timescale
- Pi Hole
- Grafana
Auf eine Raspi habe ich noch ein Venus OS mit Mosquitto laufen. Von dort hole ich mir dann die Daten aus der Victron Welt für HA. In HA habe ich +100 Sensoren laufen. Für Temperatur, Stromzähler, Multiplus 2, Huawei Solar Wechselrichter, JK BMS, ...
Hallo zusammen,
ich hänge mit hier mal mit dran. Vorweg…ich hab keine Ahnung von Linux. Aber mit einem YT-Tutorial und ChatGPT hab ich auch eine Datenerfassung hinbekommen.
- Tasmota auf Shelly(Leistungmessung BWWP) und Wemos (Temperaturerfassung im Haus und Heizung)
- Moskito Broker (geht aber mittlerweile auch ohne, dank tasmota)
- NodeRed
- InfluxDB
- Grafana
Läuft soweit…jetzt möchte ich meinen MP2 einbinden.
Im Multiplus2 GX (kein ext. Cerbo) habe ich MQTT aktiviert. Es kommen auch Daten angeflogen wenn ich mit MQTT-Explorer schauen.
Dann habe ich in NodeRed das Plugin für victron runtergeladen. Aber egal welches „Icon“ ich reinziehe, es kommt immer direkt „There are no dc source services available. Please check that a dc source is connected or try a different node.” Bevor ich überhaupt irgendwas eintrage.
Was mache ich falsch….wo fehlt noch was?
Schöne Grüße
Mino
Dann habe ich in NodeRed das Plugin für victron runtergeladen. Aber egal welches „Icon“ ich reinziehe, es kommt immer direkt „There are no dc source services available. Please check that a dc source is connected or try a different node.” Bevor ich überhaupt irgendwas eintrage.
Hmm also die Plugins, die ich mit den Suchwörtern "node-red" und "victron" finde scheinen nicht über MQTT mit den Victrons zu kommunizieren, sondern über eine Ethernet-Verbindung / DBUS. Und um letzteres zu aktivieren musst du einige Hürden nehmen, die auch diverse Sicherheitslücken in deine Installation reißen (Root-Access etc).
Wenn Du die Infos in MQTT beobachten kannst, kannst sehr sicher mit den standard-Knoten von node-Red für jeden Kanal in MQTT einen entsprechenden Statusknoten definieren und damit dann agieren. Oder über wie viele Sensoren reden wir?
Ich wollte in Grafana eben die Basics darstellen...SoC, PV-Leistung und noch 1...2 andere.
Ich hab jetzt auf dem victron in NodeRed über die "System" Box mir die Daten geholt die ich brauche und dann per MQTT weitergeleitet.
In NodeRed auf dem Pi hole ich die wieder ab, dann habe ich alles an einem Punkt zum Verschieben in InfluxDB.
Mino