ich kämpfe mich gerade durch influxdb und grafana. Man kommt zwar schnell zu einem ersten Ergebnis, aber dann wird es auch sehr schnell sehr zäh.
Seit gestern abend kämpfe ich damit, dass ich mir aus den Leistungswerten des Zählers die Tagesmenge an negativem Strom aufzeigen möchte.
1
SELECT CUMULATIVE_SUM(mean) * -1 AS sum
2
FROM (
3
SELECT MEAN("value") AS mean
4
FROM "Leistung (aktuell)"
5
WHERE "value" < 0
6
GROUP BY time(60m) fill(0)
7
)
Das tut zwar, was es soll, aber es fängt nicht bei 0 an (einerseits), und rechnet den Verbrauchswert zusammen im eingestellten Anzeigeinterval (andererseits).
Zumindest möchte ich dei Messwerte auf "Today so far" einschränken, was ja in den Anzeigenfiltern geht, aber scheinbar mit der influxql unmöglich scheint.
Die Funktion "today()" gibt es in der influxql nicht.
Ich hab mir die Finger wund gesucht, aber komme zu keinem Ergebnis. Ich kann aber auch nicht glauben, dass ich der erste bin, der etwas derart profanes umsetzen will.
Dann installier dir Influx und Grafana eben unter Windows.
Wird nicht weniger Gefrickel.
Von Influx lass ich die Finger nachdem die inzwischen gefühlt die fünfte Query-Sprache rausgebracht haben. Jede komplett anders und inkompatibel zur vorherigen...
Von Influx lass ich die Finger nachdem die inzwischen gefühlt die fünfte
Query-Sprache rausgebracht haben. Jede komplett anders und inkompatibel
zur vorherigen...
Zumal man alle mächtigen RDBMS heutzutage problemlos dazu bringen kann, das zu leisten, was Influx verspricht. Und das, ohne sich mit ständig neuen Abfragesprachen beschäftigen zu müssen.
Aber natürlich muss man sich mit dem jeweils verwendeten RDBMS beschäftigen. Das aber eben nur einmal. Danach kümmert sich das RDBMS selber um die Anpassungen, wenn es neue Versionen gibt (falls Optimierungen der Queries nötig werden). Die Anwenderseite, also insbesondere auch die Queries bleiben gleich.
Today so far gibt es tatsächlich leider nicht. Hab ich auch versucht.
Lösung: bastel dir eigene Zähler in zb node-red die dann nur die zahl deiner wahl aufs dashoard sendet über last. so rechne ich auch die % autarkie aus und ähnliche dinge
Mein Gott, in jeder üblichen RDBMS drückt man das halt (sinngemäß) mit der Bedingung aus: Datensatz-Zeitstempel >= Datum(Jetzt).
Hängt natürlich vom RDBMS ab, wie genau das zu formulieren ist, aber wenn's einmal formuliert ist, wird es auch in zehn Jahren noch die erwarteten Ergebnisse liefern.
Dann installier dir Influx und Grafana eben unter Windows.
Wird nicht weniger Gefrickel.
Von Influx lass ich die Finger nachdem die inzwischen gefühlt die fünfte
Query-Sprache rausgebracht haben. Jede komplett anders und inkompatibel
zur vorherigen...
...zumal das auf PostgreSQL aufbauende Timescaledb nach meinen Erfahrungen auch eine viel bessere Performance hat -- und man kann natürlich die ganze riesige Bandbreite dessen (weiter)nutzen, die PostgreSQL bietet.
Hab's aufgegeben. Das ganze Linux Zeug ist und bleibt immer irgendwie
eine ziemliche Frickelei. Schade.
Tut mir leid da widersprechen zu muessen, aber ich bin schon sehr frueh auf Linux umgestiegen, gleich damals als es nur 2-4Disketten gab. Also hab ich nun ueber 30Jahre Erfahrung damit. Es gibt nix bessers als Linux obwohl auch ich da durchaus was kritisiere wenn notwendig!
Aber Influx und ganz besonders Telegraf ist der Bodensatz der Programmierkunst. Selten hab ich etwas schlimmer zusammengebasteltes und so mies dokumentiertes gesehen. Das ist einfach eine Schande ohne gleichen. So zufrieden ich sonst mit Linux bin, aber bei dem Zeug bekomme ich Schaum vor dem Mund.
Aber Influx und ganz besonders Telegraf ist der Bodensatz der
Programmierkunst. Selten hab ich etwas schlimmer zusammengebasteltes und
so mies dokumentiertes gesehen.
Also Influx ist, wie ich finde, sehr gut dokumentiert!
Bei Telegraf stimme ich dir, in punkto Doku, teilweise zu. Aber trotzdem finde ich das Ding, bezogen auf das Anwendungsgebiet, genial und erspart oft das Schreiben von eigenen Programmen oder irgendwelchen Flowes in NodeRed o.ä..
Bei Telegraf stimme ich dir, in punkto Doku, teilweise zu. Aber trotzdem
finde ich das Ding, bezogen auf das Anwendungsgebiet, genial und erspart
oft das Schreiben von eigenen Programmen oder irgendwelchen Flowes in
NodeRed
Ne, ich hatte irgendwann die Nase voll und pipe alles durch ein
C++ programm das ich selber geschrieben habe. Das ist einfacher!
Ich frage mich auch was den TO dazu bringt, so eine exotische DB engine
zu verwenden.
InfluxDB und Prometheus sind die meistgenutzten Backends für Grafana, und wenn das so viele benutzen, muß es doch die beste Lösung sein.
Was ist an MySQL oder PostgreSQL so schlecht?
Naja, die haben einen anderen Fokus, in diesem Zusammenhang insbesondere die relationale Transaktionssicherheit, das drückt auf Ressourcen und Performanz. Für den Anwendungsfall eines Write-Append-Log, bei dem relationale Sicherheit keine Rolle spielt, sind Zeitseriendatenbanken, für analytische Anwendungen sind Columnar Stores (oder hybride) meistens besser geeignet. Nichtsdestotrotz läßt sich PostgreSQL ja mit einem hybriden Columnar Store aufrüsten, nämlich Timescale [1], so daß man das Beste aus beiden Welten erhält.
Ich frage mich auch was den TO dazu bringt, so eine exotische DB engine
zu verwenden.
Ganz einfach. Ich will Daten von meinem Tasmota Lesekopf visualisieren.
Was macht man also? Man googelt. Dann stolpert man über tausend Seiten und Youtube Videos, die entweder ioBroker oder Home Assistant empfehlen und dann ist man im Rabbit Hole, und bekommt gesagt, dass man die Daten per MQTT an ioBroker schicken soll, und der soll das dann an InfluxDB schicken und dort soll sich Grafana dann das Zeug holen.
Und ehe man sich versieht, hat man sich diese halbgaren Krücken an die Backe labern lassen und stellt fest, dass das alles doch irgendwie ziemlicher Murks ist.
Warum ich das Kasperle-Theater überhaupt mache?
Weil ich wissen will, wieviel Stom-Überschuss meine kleine 1,7kWp Solar macht, wieviel Strom jeden Tag ins Netz geht und was mir ein 2 kWh Akku bringen würde. Ob's sich jemals rentiert, ist für mich zweitrangig, aber ich möchte keinen Speicher hinstellen, der niemals voll wird.
Also brauche ich jetzt Daten und Fakten und die wollte ich mir halt auf diesem Weg für unseren Anwendungsfall beschaffen.
Im zweiten Schritt soll das Ding dann natürlich auch dafür tauglich sein, den Wechselrichter und/oder Akku zu steuern. Denn auch wenn wir "nurnoch" 32ct. pro kWh bezahlen, ist das immernoch weit mehr, als die 0 ct., die ich für die Einspeisung bekomme, nur um dann kurz danach wieder zu beziehen.
Jetzt merke ich, dass selbst ein Pi5 mit InfluxDB und Grafana an seine Leistungsgrenze kommt und bin regelrecht enttäuscht davon, wie etwas überall so hochgelobt werden kann, wenn es dann doch so mies ist.
Und ehe man sich versieht, hat man sich diese halbgaren Krücken an die
Backe labern lassen und stellt fest, dass das alles doch irgendwie
ziemlicher Murks ist.
Jetzt merke ich, dass selbst ein Pi5 mit InfluxDB und Grafana an seine
Leistungsgrenze kommt und bin regelrecht enttäuscht davon
Performance kannst du jetzt aber nicht meinen, oder hast du belastbare Zahlen. Mein "Telegraf-Influx-Grafana-Schrott" läuft hervorragend auf einem RPi4, auf dem auch noch anderes Zeugs läuft (sogar eine MariaDB ;-)).
Was macht man also? Man googelt. Dann stolpert man über tausend Seiten
und Youtube Videos, die entweder ioBroker oder Home Assistant empfehlen
und dann ist man im Rabbit Hole, und bekommt gesagt, dass man die Daten
per MQTT an ioBroker schicken soll, und der soll das dann an InfluxDB
schicken und dort soll sich Grafana dann das Zeug holen.
Und ehe man sich versieht, hat man sich diese halbgaren Krücken an die
Backe labern lassen und stellt fest, dass das alles doch irgendwie
ziemlicher Murks ist.
Wenn man das richtig macht, funktioniert das zweifellos sehr zuverlässig und wird...
Jetzt merke ich, dass selbst ein Pi5 mit InfluxDB und Grafana an seine
Leistungsgrenze kommt und bin regelrecht enttäuscht davon, wie etwas
überall so hochgelobt werden kann, wenn es dann doch so mies ist.
... sicherlich weder einen RasPi 3, und erst Recht nicht einen RasPi 4 oder 5, an seine Grenzen bringen. Da Dein Urteil allerdings schon festzustehen scheint und ich außerdem den Eindruck habe, daß Du mit Linux ähnlich inkompatibel bist wie mit mir, sollten wir uns Analysen und Lösungsansätze lieber sparen. Viel Erfolg beim Erarbeiten Deiner windowsbasierten Lösung.
Wie macht mit influxql die Abfrage der Daten des gleichen
Tages
Problem: Wann fängt ein Tag an? -> Zeitzone setzen.
Läuft so bei mir in "Flux", sammelt die Bezug/Einspeise-Summen pro Tag über den letzten Monat ($timespan).
Aber aus den Zählerständen, deshalb die "difference()"
Performance kannst du jetzt aber nicht meinen, oder hast du belastbare
Zahlen.
Meinst Du den Lüfter vom PI, der hochdreht, während Firefox mit 15
offenen Tabs auf dem PI5 mit 4GB noch funktioniert?
...ein "hochdrehender Lüfter" ist keine belastbare Zahl...; na dann erzähle mal, warum du meinst, dass der "hochdrehende Lüfter" von Influx/Telegraf verursacht wird...
...mit Flux oder mit FluxQl?
Siehe auch den einen Kommentar in dem Bug-Report ;-)
InfluxQL, wie im Ausgangsbeitrag geschrieben.
Martin S. schrieb:
Performance kannst du jetzt aber nicht meinen, oder hast du belastbare
Zahlen.
Meinst Du den Lüfter vom PI, der hochdreht, während Firefox mit 15
offenen Tabs auf dem PI5 mit 4GB noch funktioniert?
...ein "hochdrehender Lüfter" ist keine belastbare Zahl...; na dann
erzähle mal, warum du meinst, dass der "hochdrehende Lüfter" von
Influx/Telegraf verursacht wird...
Nicht influx, sondern von Grafana. Das knüppelt mit den paar Anzeigen schon ordentlich aus.
Martin S. schrieb:
Ja, dann sag mal, wieso today() mit influxql nicht funktioniert?
...weil es nicht für FluxQL implementiert wurde oder hast du dies in den
entsprechenden Abschnitten der Doku so gelesen!
Genau. Aber warum nicht? Wie kann ein so wichtiger Befehl nicht implementiert sein?
Nicht influx, sondern von Grafana. Das knüppelt mit den paar Anzeigen
schon ordentlich aus.
Bei wieviel Panels pro Dashboard (bei dem er "ordentlich" ausknüppelt)?
Bei wieviel Datenpunkten pro Panel auf dem Dashboard im gewählten Zeitintervall?
Mit welchen Aggregatfunktionen werden die Daten in den Panels pro Anzeigeinterval zusammengefasst?
Und, aus deinen Bemerkungen höre ich raus, dass du alles (auch den Browser, mit dem du Dashboards des Grafana-Servers anzeigst; und damit incl. X-Umgebung, Desktop-Manager etc.) auf einem RPi betreibst. Kann man machen, sollte sich aber dann nicht beschweren, warum der Lüfter anspringt. Influx/Telegraf/Grafana(-Server) wird es höchstwahrscheinlich nicht sein...!
Gut dann wechsle ich zu Flux. Mal sehen, was das für einen Unterschied
macht.
Auch wenn es zur InfluxDB drölfzig Empfehlungen und Tutorials im Netz gibt, ist nicht ganz klar, wie sich das in Zukunft entwickeln wird. Die aktuelle Version 3 gibt es nur als "InfluxDB Core" mit deutlichen Einschränkungen. Wikipedia [1] berichtet dementsprechend, daß die neuen OpenSource-Angebote "limitiert" und keine vollständige Zeitseriendatenbank sei.
Mein ganz persönlicher Eindruck ist, daß die Investoren von InfluxDB jetzt langsam gerne einen ROI realisieren wollen und das OpenSource-Modell dafür keinen ausreichenden Gewinn abwirft. Auf den Webseiten von Influxdata wird möglicherweise deswegen sehr nachdrücklich dafür geworben, die Cloud- oder Managed-Angebote zu nutzen.
Ich ganz persönlich würde daher zumindest aktuell bei Neuentwicklungen nicht (mehr) auf InfluxDB setzen, sondern entweder auf die PostgreSQL-Erweiterung TimescaleDB setzen -- die den Vorzug hätte, daß vorhandene Kenntnisse in SQL und / oder PostgreSQL weiter genutzt werden können, und trotzdem Grafana für die Visualisierung weiterverwendet werden kann -- oder auf eine Kombination von Elasticsearch + Kibana oder OpenSearch + OpenSearch-Dashboards setzen.
