Beispiel: Loxone mit node-red auf rPi 3, influxDB und grafana (Visu)

[Xenobiologist]

Was schreibst du denn alles weg? Ich speichere alle Temperaturveränderungen aller Räume, Wind, Luftfeuchtigkeit usw. über 50 Werte teilweise bei jeder Veränderung.
Meine DB ist 21 MB groß. Werte für 2 Jahre.

[kerrick]

Also ich vermute, das hat nicht direkt mit der DB Größe bzw den Nutzdaten zu tun. Der schreibt ja regelmäßig seine Werte auf Platte und dadurch kommt dann der hohe I/O Wert zustande.
Ich betreibe das als Docker Container und kann mit `docker stats` den "Block I/O" anzeigen lassen. Ich habe den NodeRed als Input zur Zeit deaktiviert, so dass InfluxDB eigentlich nur idle-t bzw. in seine "_internal" Datenbank schreibt.
Die aktuellen I/O Werte sind "24GB / 14.7GB" und der Container läuft seit 5 Wochen.
Die Datenbanken sind 74MB (Loxone, wächst derzeit nicht) und 55MB (_internal).

[jodelkoenig]

So. Ich habe mich noch ein wenig eingelesen (siehe Dokumentation von influxDB). Ziemlich abstrakt, das Ganze

Für ein Hardware-Sizing unterscheidet InfluxDB den Bedarf wie folgt:

Load = low:

• bei < 5.000 (!) field writes pro Sekunde;
• < 5 moderate Queries pro Sekunde;
• bei < 100.000 unique series ...
  
  DAS ist schon eine Hausnummer

Load = moderate:

• bei < 250.000 (!) field writes pro Sekunde;
• < 25 moderate Queries pro Sekunde;
• bei < 1.000.000 unique series ...
  
  DAS ist noch mehr eine Hausnummer

Was bedeutet das jetzt?

• Kein Haus schreibt pro Sekunde genug Werte, um auch nur annähernd Last für LOW zu erzeugen.
• 5 Abfragen pro Sekunde, kann sein, aber der nächste Sprung wäre bei 25 (und damit moderate), also für unseren Anwendungszweck auch noch genug.
• Bleiben die "unique series":

Eine "unique series" entsteht aus der Kombination von Measurements / tag sets / retention policies; fields spielen bei der Ermittlung der series keine Rolle (!).

Grob kann man sagen (kann zu "overestimation" führen; siehe Doku):

Anzahl Measurements * Anzahl Tag-1-Values * ... * Anzahl Tag-n-Values * Anzahl gewählter retention policies = Anzahl "unique series"

Aus der Praxis ... ich schreibe alles in

• ein Measurement: "Haus", also eine Tabelle = 1 Stck.
• nutze etwa 20 verschiedene Fields = irrelevant für Ermittlung Anzahl "unique series"
• habe 3 Tags
  • room = 13 Stck.
  • category = 7 Stck.
  • device = 64 Stck.
• nutze zur Zeit die Standard retention policy = 1 Stck.

Daraus ergibt sich als Anzahl "unique series": 1 * 13 * 7 * 64 * 1 = 5.824. Was wiederum locker im Bereich LOW liegt.

Und was ist mit der Anzahl fields?

Diskussionen über die maximale Anzahl von Fields wurden bei 500 und mehr geführt. Ich habe es dann nicht weiter betrachtet und kann mir an dieser Stelle nicht vorstellen, auch nur annähernd in einen kritischen Bereich zu kommen.

Bottom line für mich:

Also aus Performance-Sicht mache ich mir jetzt keine Sorge mehr. Meine Queries laufen darüber hinaus nicht über Fields (die nicht indiziert wären), sondern über Tags (die indiziert werden); von daher Performance-Sensitive

Bleibt zwar ggf. die zuvor beschriebene I/O-Last, die eine SD unnütz stressen könnte. Letzteres spielt bei meinem Setup aber keine Rolle.

[ThatRed]

Hallo!

Ich bekomme leider keine Daten in Grafana angezeigt, es wird immer nur "Expected response data to be array, got undefined" angezeigt.

Wenn ich mir die Daten über Chronograf anzeigen lasse, funktioniert es. Dort werden die Abfragen auch mehr oder weniger fast von selbst zusammengebaut.

Nach dem Einrichten der Datenbank in Grafana, wird die Konfiguration gespeichert er und sagt, das die Quelle in Ordnung ist.

Ich habe mir das aktuelle Loxberry Image installiert, auf 2.0.0.3 aktualisiert und die Docker und InfNodGra Plug-Ins verwendet. (Die funktionieren aber nur nach Anpassungen...)

Die Containerversionen sind nun die aktuellsten (latest):

Docker Version: 19.03.5
Portainer: 1.22.2
InfluxDB shell Version: 1.7.9
Grafana v6.5.1 (1763a0f)
Chronograf Version: 1.7.14

Wo muss ich da ansetzen, meine Fähingkeiten sind leider nur begrenzt?

Danke.

Edit: Fehler gefunden:

Die Datenquelle muss folgendermaßen angelegt werden:

URL: http://IP-Loxberry:8086
Access: Server (default)

(Ich hatte das "http://" nicht vor die Loxberry IP gesetzt und Browser ausgewählt...)

[svethi]

Hi Leute,

nachdem ich lange hier mitgelesen habe und mir letztens (nach Jahren) die SD im MS kaputt gegangen ist, habe ich mich jetzt endlich mal damit befasst und schon ein paar Sachen abgelegt.
Hier wurde ja auch schon gesagt, dass man auch die alten Daten einspielen kann. Wie gehe ich da am Besten vor? Vom Anlegen der Daten und Dashboardbau habe ich ja jetzt schon Daten drin. Im MS werden die ja aber auch noch aufgezeichnet. Wenn ich jetzt noch zusätzlich die alten Daten einspiele, kommt es ja dann zu Überschneidungen. Wenn ich aber im MiniServer die die Statistik abschalte, dann habe ich es schon erlebt, dass auch gleich die vorhandenen Statisktiken gelöscht werden.

[svethi]

Hi Leute,

ich habe nunmal das Script von Programie mal ausprobiert. Musste dies zwar noch etwas anpassen, doch jetzt läuft es. In den Beispielen wurden auch Tags angelegt, was ich dann auch benutzt habe. Dies funktioniert auch richtig. Wenn ich allerdings mit dem influxdb Node Daten schreibe, bekomme ich es nicht hin Tags zu schreiben. Nach der Anleitung soll das payload dann so:

[{
 "Wert“: msg.payload
},
{
 "room“: "myRoom"
}]

aussehen um das Tag room mit dem Wert myRoom zu füllen. Ein Blick in die Datenbank zeigt allerdings, dass room nicht als Tag, sondern als weiteres Field angelegt wird. Wie gibt man denn Tags wirklich an. Ein Beispiel für die Batch-Node wäre:

[{
 measurement: "Temperatur“,
 fields: {
  "Wert": msg.payload
 },
 tags: {
  "room": "myRoom"
 }
}]

Diese funktioniert aber mit dem output-Node nicht.

[svethi]

Okay, war mein Fehler. Das field room kam durch das kopieren der Daten von einer DB in die andere zustande. Dort muss wirklich unbedingt GROUP BY * angegeben werden.

[stan2449]

Hallo, ich bin heute etwas mit Node Red angefangen. Die Werte kommen von Loxone nach Node Red und dann in Influxdb.
Wollte die Temperaturwerte in Grafana anzeigen, was auch zum grössten Teil passt.
Jetzt aber zu mein Problem. Wenn sich die Temperatur nicht ändert bekomme ich keine werte in die DB,
kann ich irgendwie die Werte auch wenn sie sich nicht geändert haben, trotzdem jede 5 min in die DB schreiben?

Danke voraus

[svethi]

Brauchst Du nicht schreiben. In Deiner InfluxDB Abfrag gibst Du bei Fill previous an.

[stan2449]

Meinst du so?

[svethi]

Ja, sieht ganz so aus.

[stan2449]

Fill lineal sieht einbissen schöner aus. wäre es den möglich jede Stunde ein Wert in die DB zu schreiben wenn kein wert kam?

z.B wie bei Iobroker

[svethi]

Mag vielleicht schöner aussehen, ist aber falsch. Loxone übermittelt den Wert wenn er sich ändert. Kommt kein Wert rein, hat er sich also auch nicht geändert. Ist also so wie vorher (previous). Wenn Du damit aber glücklicher bist, dann nimm linear :-)
Über NodeRed müsste es jedenfalls gehen. Wert zwischenspeichern und per Stundenimpuls an die DB senden.

[maxw]

So, hier mal mein Beispiel - na ja bzw. Daten meiner Anwendung

Anzahl aufgezeichneter Messwerte für

• Energie (Strombezug gesamt, Bezug Wärmepumpe, Lieferung Wärmepumpe): 3.276.738
• Temperatur (Außen, EG, OG, Technikraum, Solequelle, Vorlauf, Rücklauf, Warmwasser) 714.276
• Temperatur im Fußbodenaufbau (Schotter, Isolierung, Bodenplatte, Estrich): 531.673

In den Temperaturmessungen fehlt wir noch die KWL, die muss ich mal dazu bauen.

Warum es bei Energie so viel mehr Werte gibt, kommt daher weil fast jeder Messwert anders ist, während sich Temperaturen nur langsam ändern.

Wie viele Messwerte hab ihr schon von eurem Smart Home :-)

Liebe Grüße, Max
Max

[Xenobiologist]

Fill lineal sieht einbissen schöner aus. wäre es den möglich jede Stunde ein Wert in die DB zu schreiben wenn kein wert kam?

z.B wie bei Iobroker

Du kannst natürlich auch immer einen webservice node nutzen und dann per zeitgesteuertem Trigger alle x (s,m,h) den Werte holen und wegschreiben.

[Gast]

Guten Morgen Kollegen!

Ich entschuldige mich für die Fehler - ich übersetze die Nachricht mit Google Übersetzer,

Ich habe das folgende Problem beim Sammeln von Daten in der InfluxDb-Datenbank - möglicherweise ist jemand auf einen solchen Fall gestoßen.

Die InfluxDB-Datenbank sammelt Daten von Loxone über Node-Red
Das Programm in Node-Red ist trivial (Foto 1) - wir speichern Daten von vier Sensoren;
Das Problem besteht darin, die Position in InfluxDB zu speichern (Daten von zwei Sensoren) - Beispiel in Foto 2:
- Zeile 339 tritt auf, wenn das Node-Red-Programm bereitgestellt wird.
- Zeile 340 wurde von Node-Red gespeichert - nur eine Zeile gefüllt (erste Spalte);
- Zeile 342 wurde von Node-Red gespeichert - nur eine Zeile gefüllt (zweite Spalte);
- Zeile 358 führt die erneute Bereitstellung in Node-Red durch.

Warum überträgt Node-Red nicht alle Daten und füllt alle Zellen?
Temperaturwerte ändern sich langsam - das ist kein großes Problem.
Aber ich würde gerne den Grund wissen.

----

Good morning Colleagues!

I apologize for the language faults - I translate the message using Google Translator,

I have the following problem with collecting data in the InfluxDb database - maybe someone met with such a case.

The InfluxDB database collects data from Loxone via Node-Red
The program in Node-Red is trivial (photo 1) - we save data from four sensors;
The problem is in saving the position in InfluxDB (data from two sensors) - example in photo 2:
- line 339 occurs when Deploy the Node-Red program;
- row 340 was saved by Node-Red - only one row filled (first column);
- row 342 was saved by Node-Red - only one row filled (second column);
- line 358 performs Deploy again in Node-Red;

Why does Node-Red not transfer all data and fill all cells?
Temperature values change slowly - this is not a big problem.
But I would like to know the reason.