NEWS
NodeRED Logging mit InfluxDB 2.0
-
Hallo zusammen,
ich würde gerne meine Heizung die über Mqtt sendet über NodeRED aufbereiten damit mit InfluxDB geloggt werden kann, und später dann für Grafana verwendet werden kann.Habe nun die einzelnen mqttin nodes angelegt und die Werte sehe ich dann auch in der Debug Ausgabe. Nun will ich diese über ein funktion Node so aufbereiten das alles unter z.B. measuremt HargassnerHSV läuft. Wie kann ich das ganze über eine function Node realisieren? Oder brauch ich für jedes mqttin eine extra function und auch influxdb Note?
-
@michisa86888
Ich glaube kaum, dass dir hier jemand direkt helfen kann, wenn du nicht offenlegst, wie der Payload aussieht.Abgesehen davon würde ich die zu loggenden Daten einfach in manuell angelegte Datenpunkte schreiben und mit dem influxdb Adapter wegschreiben. Das finde ich einfacher und weniger fehleranfällig. Außerdem hast du die DP gleich parat, wenn du auf dieser Basis noch andere Dinge automatisieren willst.
-
@michisa86888 Ich verstehe nicht warum Du wieder function Nodes verwenden willst. Ich versteh es einfach nicht, man will doch nicht alles codieren?
Es geht doch erst mal darum, wie Du Deine Daten aufbereiten willst. Wenn Du keine Tags verwenden willst, dann schreibst Du doch einfach ein Objekt in die InfluxDB Node.
Also schau - wie Du das aufbauen willst und versuche function Nodes wenn immer möglich zu vermeiden, sonst kannst ja gleich codieren.
Wenn Du nur fields brauchst, musst doch nur ein Objekt schreiben:
Wenn Du tags mit haben willst, dann halt ein Array mit 2 Objekten (einmal fields und einmal tags).
Ist also in meinen Augen vollständiger Schwachsinn hier mit einer function Node zu arbeiten.
Im Prinzip musst du doch nur die payload auf den Feldnamen verschieben.
Wenn Du aus dem mqtt-topic automatisiert den Feldnamen extrahieren kannst, dann langt natürlich eine Change Node. Function Nodes hier zu nutzen ist einfach nur ....
Du willst ja nicht ein Objekt mit allen Feldern haben, sondern die Daten so loggen wie sie reinkommen.
Wenn Du unbedingt codieren willst mit function Nodes - dann musst halt mit einem switch und dem topic alles codieren:
Ich finde es halt nur
switch (msg.topic) { case "Außentemp": // code block msg.payload = { "aussentemp": msg.payload } break; case "Boilertemp": // code block msg.payload = {"boilertemp" : msg.payload} break; } return msg;
================================================
Wenn man die End-Topics aus dem MQTT direkt als Feldnamen verwenden kann, dann kann man das auch alles mit einer Change Node realisieren:
-
@mickym
Sorry das ich jetzt mal ganz blöd frage:Filter 1 ist = _measurment (sagen wir mal, "Quelle")
Filter 2 ist = _field (Namen der Temperaturen)so ich würde aber gerne noch 1 bis 2 filterwörter in die Nachricht einabuen?
Wie müsste das dann ausehen?Würde gerne den wert zb, in diesen FIlter schreiben:
"ms/sec" + "," + "Info=" + "log1" + "," + "Ort=" + "Dach" + "," + "Gerät=" + "" + " " + "L3=" + l3 + " " + time
der L3 wert wäre dann also in: Field _measurment: ms/sec -> Field Info: log1 -> Field Ort: Dach -> Field Gerät: L3
Hoffe ich habe mich so einigermassen verständlich asugedrückt
-
@mike1976 Ehrlich gesagt - verstehe ich nicht was Du meinst oder was Du willst - und ob Du das Prinzip verstanden hast.
Wenn Du Ausgaben filtern willst, dann musst Du dich mit der Flux Sprache ab Version 2 - da bin ich ganz schlecht. Kannst Du aber ggf. die Syntax aus der GUI ermitteln.
Ansonsten definierst Du das measurement in der Node selbst. Du kannst dann in dem measurement - je nachdem wieviel unterschiedliche Arten Du misst - das designen. Du könntest zwar 2 Felder verwenden - aber eigentlich würde man ggf. besser designen - nur die Temperatur und den Ort.
Also überleg Dir alle Felder die mit jeder Nachricht kommen und nutze lieber Tags für den Ort. Time ist unsinnig, weil diese ja in einer Influx-DB automatisch enthalten ist.
Wenn ein Gerät zum Beipsiel temperatur und luftfeuchtigkeit misst, dann hast Du als Felder Luftfeuchtigkeit und Temperatur, als Tag zum Beispiel den Ort.
Die Filter in der GUI sind missverständlich.
Measurement - ist vielmehr die Art der Messung und der Typ des Gerätes
Field = Felder die von einem Gerät kommen
Tag = frei definierbar - könnte Dein Ort sein, woher das Gerät kommt.Das ganze wird dann über 2 Arrays wie beschrieben definiert. Felder sind also Messungen, Tags haben beschreibenden Charakter. Hier ein Beispiel:
measurement = ist quasi Deine Tabelle
field = sind Spalten/Felder in der Tabelle - hier Temperatur, Luftfeuchtigkeit
tag = Raum (frei beschreibbar) um Messungen zu gruppieren. -
@mickym
hm... Also die Filter machen mich fertig
measurement sollte doch eigentlich die Mess/Einheit sein.Okay habe gerade dein Beispiel gestestet, kommt so ca. hin.
measurement ist eindeutig 2 deutigIch logge auf einem Anderen Pi werte (auch mit Node-red) da schreibe sie aber in eine Textdatei, diese importiere ich 1x täglich per telegraf in Influx.
Da habe ich mir die Textdatei (Syntax) so zusammen gebaut:"ms/sec" + "," + "Info=" + "log1" + "," + "Ort=" + "Dach" + "," + "Gerät=" + "" + " " + "L3=" + l3 + " "
da legt Influx Brav die Filter so an, dachte mit Node-Red direkt bringe ich das auch rüber.
Wollte es bei diesem Pi direkt Testen mit der Influx-node (wegen echtzeit log)
Aber mit deinem Vorschlag/Lösung kann ich zur not auch leben.Danke für deine schnelle Antwort.
LGBezüglich Timestamp, da hast natürlich recht, war noch vom Testen drinn.
Bin noch beim Testen um die Optimale Lösung zu finden.
-
@mike1976 Wie gesagt - ist einfacher - wenn Du Deine Textdatei postest bzw. die Daten um einen vernünftigen Vorschlag zu machen.
-
@mickym
so sieht es mit der Textdatei aus:man sieht dann auch schön die Beschriftung in dem Graph.
so sieht die datei aus:
Leistung Zuhaus Tag-2024-02-12.txtHoffe es ist jetzt besser verstädlich.
-
@mike1976 Na bei dem Gesamt bin ich mir nicht sicher. Aber ich denke ich würde wohl bei dieser Konstellation,
w,Info=1min,Ort=Zuhause,Standort=VerteilerEG L3=156.2 1707692455004000000 w,Info=1min,Ort=Zuhause,Standort=VerteilerEG L2=5 1707692460008000000 w,Info=1min,Ort=Zuhause,Standort=VerteilerEG L1=132.2 1707692460008000000 w,Info=1min,Ort=Zuhause,Standort=VerteilerEG gesammt=293.4 1707692460008000000
wenn nur gesammt, L1-L3 und was dahinter steht ist wohl ein timestamp und kann ignoriert werden - die anderen Teile würde ich als tags verwenden. Ich probiere mal einen kleinen Flow- um das mit einer InjectNode zu simulieren.
-
@mickym
den timestamp brauche ich ja nur in der textdatei damit influx weis wann der wert geloggt wurde.
Das Format des timestamp ist in diesem fall "ns" da influx standart bei text file import "ns" hat.Habe jetzt mal folgende funktin getestet:
msg.topic="InfluxData" let l1=global.get('leistung_l1') let l2=global.get('leistung_l2') let l3=global.get('leistung_l3') let gesammt=global.get('leistung') let time=global.get('timestamp') msg.payload= [ { "L1": l1, "L2": l2, "L3": l3, "Gesammt": gesammt }, { "Info": "1min", "Ort": "Zuhause", "Standort": "VerteilerEG" }] return msg;
Ergebins:
Kommt der Sache Schon sehr nahe
Danke für deinen Denk anstoß
LG
-
@mike1976 Genau - das sollte es sein nur ist ja Dein l1, l2 etc. in unterschiedl. Datensätzen - ich werde mal was versuchen ohne function nodes.
Schau mal, ob Dir der Flow hilft:
hier ist der Link zum Ausprobieren von JSONATA: https://try.jsonata.org/1Ec_JbVT_
mit Deinen Daten aus der CSV Node:Evetuell musst Du dann die Influx Batch Node verwenden, wenn Du den timestamp mit geben willst.
Dann muss allerdings das Objekt komplexer dargestellt werden. Bin mir nicht sicher aber ich ändere den Flow nochmal mit dem timestamp für die Batchverarbeitung.
-
So hier mal ein Flow um Deine Textdaten mit Übernahme der Timestamps via Batch Node (die braucht man wohl, um den Timestamp zu übernehmen)
Hier der Flow:
Wichtig ist, dass Du bei Dein Timestamp mit der Einheit in der Node stimmt also bei Dir anscheinend Nanosekunden:Und hier zum Import:
Es sieht jedenfalls so aus, als ob der timestamp damit übernommen wird:
Der Vollständigkeit nochmal das JSONATA zum Spielen: https://try.jsonata.org/vg-2ha01s
Das mit dem leeren Standort ist im Exportcode bereits korrigiert
-
@mickym
Hallo, sorry erst jetzt wieder Zeit gehabt.Vielen Dank für dein Test Flow.
Leider ist anscheinend bei der Kommunikation was danebengegangen.Ich lese nicht die Textdatei ein, die wird separat gespeichert. Das war nur ein Muster wie Influx die daten annimmt.
Ich schreiben die Werte jetzt, sowie du im oberen Post von mir sehen kannst, in der Funtkion, direkt von einer Globalen Variable in Flux rein.
Aber alles gut, mit der Funktion geht es eigentlich genau so wie ich das haben will.
Wieso bist du eigentlich so gegen die Funktion-Node?
-
@mike1976 sagte in NodeRED Logging mit InfluxDB 2.0:
Wieso bist du eigentlich so gegen die Funktion-Node?
Weil Du im Prinzip einen kompletten Flow in Javascript in eine function Node packen kannst und du damit den Sinn von Node Red der grafischen Programmierung mit seinen Debugging Möglichkeiten ad absurdum führst. Viel Spaß bei Debuggen in einer Function Node. Außerdem ist JSONATA so genial - dass Du damit ein Viertel des Codes brauchst, den Du mit Javascript brauchst.
Es gibt bestimmte Funktionen, wie den NodeKontext, das nutzen externen NodeJS Module oder asynchrone Verarbeitung für die man function Nodes braucht und es sinnvoll ist, diese zu nutzen. Alles andere geht mit Standardnodes einfacher, kürzer insbesondere mit der genialen JSONATA implementierung.