Hinweis: Schöne Alternative für Charts/Plots mit Grafana und DBLog (MySQL)

Begonnen von Thyraz, 08 Oktober 2017, 15:02:38

Vorheriges Thema - Nächstes Thema

kadettilac89

Zitat von: ch.eick am 03 Dezember 2020, 16:21:46
Das ist leer, wahrscheinlich braucht man das, wenn man etwas umkonfigurieren möchte.
genau, wollte sehen ob da ggf. was unnützes drin steht. Damit setzt du Parameter die vom Default abweichen.

ch.eick

Zitat von: kadettilac89 am 03 Dezember 2020, 18:45:32
genau, wollte sehen ob da ggf. was unnützes drin steht. Damit setzt du Parameter die vom Default abweichen.
Ich liebe Defaults ;-)

Aber jetzt fällt es mir wieder ein, MarieDB nach Deinem Link ist für ARM 64 und der RPI4 ist noch auf Debian 32 , wenn ich das so richtig im Kopf habe.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

kadettilac89

Zitat von: ch.eick am 03 Dezember 2020, 18:48:29
Ich liebe Defaults ;-)

Aber jetzt fällt es mir wieder ein, MarieDB nach Deinem Link ist für ARM 64 und der RPI4 ist noch auf Debian 32 , wenn ich das so richtig im Kopf habe.

dann bau mal zum test einen container für mariadb in docker-compose ein. Ich dachte RPI4 ist mittlerweile ARM64. Wenn die Architektur nicht passt dann kannst den Container nicht starten, da kommt dann eine Fehlermeldung beim Pull.

Wenn der Container aber erfolgreich startet passt es.

ch.eick

Zitat von: kadettilac89 am 03 Dezember 2020, 19:10:02
dann bau mal zum test einen container für mariadb in docker-compose ein. Ich dachte RPI4 ist mittlerweile ARM64. Wenn die Architektur nicht passt dann kannst den Container nicht starten, da kommt dann eine Fehlermeldung beim Pull.
Das Raspbian ist 32 Bit , aber es gibt ein neues Raspberry Pi OS 64 Bit.
Ich check das mal, aber das wird etwas dauern und gehört in einen anderen Thread.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

IcedEarth

Hi zusammen,

ich kann jetzt auf meinem RPI im Docker Grafana Grafen rendern. Wenn ich die wie im Wiki per weblink in FHEM einbinde, geschieht dies ja als blockierender Aufruf. Gibt es einen Weg dies non-blocking zu machen?

Viele Grüße

Thyraz

Grafana 7.4 bringt endlich interpolierte Line Charts mir der neuen Time series Visualisierung.
Meine Augen sind entzückt. :)

Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

freddykr

Hallo zusammen,

ich stehe grad mächtig auf dem Schlauch und vielleicht hat ja jemand eine Idee.
Ausgangssituation ist Grafana 7.4.1 mit einer MariaDB im Hintergrund mit den FHEM-Daten.
Mein Regenmesser schreibt mit ein Attribut "today" in die Datenbank, welches am Tag immer aufsummiert wird und am nächsten Tag wieder "0" ist.

Auszug aus der Datenbank:

SELECT *  FROM `history` WHERE `TIMESTAMP` BETWEEN '2021-02-01 00:00:00.000000' AND '2021-02-03 23:59:59.000000' AND `DEVICE` LIKE 'Regenmesser' AND `READING` LIKE 'today'


TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT
2021-02-01 00:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.114
2021-02-01 01:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.250
2021-02-01 02:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.250
2021-02-01 03:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.250
2021-02-01 04:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.250
2021-02-01 05:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.705
2021-02-01 06:30:00 Regenmesser CUL_TCM97001 rl_av_h today 1.167
2021-02-01 07:30:00 Regenmesser CUL_TCM97001 rl_av_h today 1.979
2021-02-01 08:30:00 Regenmesser CUL_TCM97001 rl_av_h today 2.500
2021-02-01 09:30:00 Regenmesser CUL_TCM97001 rl_av_h today 2.875
2021-02-01 10:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 11:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 12:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 13:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 14:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 15:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 16:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 17:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 18:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.000
2021-02-01 19:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.167
2021-02-01 20:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.250
2021-02-01 21:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.250
2021-02-01 22:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.250
2021-02-01 23:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.250
2021-02-02 00:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 01:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 02:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 03:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 04:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 05:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 06:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 07:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 08:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 09:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.000
2021-02-02 10:30:00 Regenmesser CUL_TCM97001 rl_av_h today 0.417
2021-02-02 11:30:00 Regenmesser CUL_TCM97001 rl_av_h today 1.562
2021-02-02 12:30:00 Regenmesser CUL_TCM97001 rl_av_h today 2.417
2021-02-02 13:30:00 Regenmesser CUL_TCM97001 rl_av_h today 3.654
2021-02-02 14:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 15:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 16:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 17:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 18:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 19:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 20:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 21:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 22:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.250
2021-02-02 23:30:00 Regenmesser CUL_TCM97001 rl_av_h today 4.192
2021-02-03 00:30:00 Regenmesser CUL_TCM97001 rl_av_h today 1.385
2021-02-03 01:30:00 Regenmesser CUL_TCM97001 rl_av_h today 2.000


Mein Ziel ist jetzt mit Grafana eine Übersicht des Regens der einzelnen Tag des letzten Monats herzustellen.
Prinzipiell funktioniert es auch, aber nur mit "avg(value)".
So sind aber natürlich die Werte absolut falsch, da er einen Durchschnitt des Tages annimmt.
SELECT
  $__timeGroupAlias(TIMESTAMP,$__interval),
  avg(VALUE) AS "Regen"
FROM history
WHERE
  DEVICE = 'Regenmesser' AND
  READING = 'today'
GROUP BY $__timeGroup(TIMESTAMP,$__interval)


Nutze ich "max(value)" kommt nur "No Data", obwohl Daten von der DB kommen (überprüft mit tcpdump). Wenn ich den Befehl im phpmyadmin direkt eingebe, kommen auch Ergebnisse.

Jemand eine Idee?
Viele Grüße,
Danilo

kadettilac89

Zitat von: freddykr am 13 Februar 2021, 13:45:16

Jemand eine Idee?

Ich würde mir ein Userreading anlegen. Userreading hat das Delta und keine Summe.

Logik:
1) Wert = current Reading - OldReading
2) Wenn Wert < 0 --> Tageswechsel --> Reading = current Reading
3) Wenn Wert > 0 --> Delta berechnen --> Reading = current Reading - oldReading

oldReadings --> Commandref / Forumsuche
https://fhem.de/commandref.html#oldreadings

Das ganze in eine in 99_myUtils auslagern.

Alternativ: max-Funktion in SQL. Das funktioniert aber nur wenn du immer auf Tageswerte arbeitest.

Dann hast du ein Userreading mit der Differenz zum letzten Wert den du ganz einfach in Grafana plotten kannst.

ch.eick

Zitat von: freddykr am 13 Februar 2021, 13:45:16
Jemand eine Idee?
Moin,
zu Begin des Folgetages mit einem DbRep maxValue den Wert in der Datenbank erstellen lassen.
Du kannst maxValue mit writeToDB verwenden und einen neuen Wert erstellen, die anderen bleiben dann erhalten.
Oder Du verwendest deleteOther, dann hat der Maxwert den selben Namen, alle anderen werden jedoch gelöscht. Hierbei solltest Du aber vorher erst mal mit Display arbeiten und überprüfen, ob der Maxwert nicht eventuell auch mal am nächsten Tag der Erste ist ;-) Dafür hatte ich mal ein SQL geschrieben, was das vorher korrigieren kann. Das DbRep kann Dir auch die ganzen alten Einträge für einen beliebigen Zeitraum bearbeiten.

Das mit Grafana habe ich auch schon mal festgestellt, dass da nicht alles so sauber ist.
Deshalb bereite ich die Daten vorher auf, was beim Anzeigen in Grafana auch immer wiederkehrende Berechnungen erspart.
Vor dem Löschen (deleteOther) wäre natürlich ein Backup schön, bis man weiß was man tut !
Und wie bereits geschrieben zuerst mit Display arbeiten, dann sieht man ob es die richtigen Datensätze sind.

Gruß
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

kadettilac89

Zitat von: ch.eick am 14 Februar 2021, 11:00:01
Moin,
zu Begin des Folgetages mit einem DbRep maxValue den Wert in der Datenbank erstellen lassen.
Du kannst maxValue mit writeToDB verwenden und einen neuen Wert erstellen, die anderen bleiben dann erhalten.
Oder Du verwendest deleteOther, dann hat der Maxwert den selben Namen, alle anderen werden jedoch gelöscht. Hierbei solltest Du aber vorher erst mal mit Display arbeiten und überprüfen, ob der Maxwert nicht eventuell auch mal am nächsten Tag der Erste ist ;-) Dafür hatte ich mal ein SQL geschrieben, was das vorher korrigieren kann. Das DbRep kann Dir auch die ganzen alten Einträge für einen beliebigen Zeitraum bearbeiten.

Das mit Grafana habe ich auch schon mal festgestellt, dass da nicht alles so sauber ist.
Deshalb bereite ich die Daten vorher auf, was beim Anzeigen in Grafana auch immer wiederkehrende Berechnungen erspart.
Vor dem Löschen (deleteOther) wäre natürlich ein Backup schön, bis man weiß was man tut !
Und wie bereits geschrieben zuerst mit Display arbeiten, dann sieht man ob es die richtigen Datensätze sind.

Gruß
   Christian

Workarounds ... wenn der TE damit leben kann

- Wert nur zum Tageswechsel - aktueller Tag fehlt
- Werte wieder Löschen ... späteres Reporting auf Stunden oder andere Zeiteinheiten nicht mehr möglich

Das mit Grafana habe ich auch schon mal festgestellt, dass da nicht alles so sauber ist.
- Beispiel?

ch.eick

Zitat von: kadettilac89 am 14 Februar 2021, 11:12:07
- Wert nur zum Tageswechsel - aktueller Tag fehlt
- Werte wieder Löschen ... späteres Reporting auf Stunden oder andere Zeiteinheiten nicht mehr möglich
Dann wäre writeToDB die Waffe der Wahl.
Oder das funktionierende SQL als sqlCmd.

Zitat
Das mit Grafana habe ich auch schon mal festgestellt, dass da nicht alles so sauber ist.
- Beispiel?
Das selbe wie bereits genannt. avg() okay max() geht nicht.

Ich stimme natürlich zu, dass es nur ein Workaround ist.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

kadettilac89

Es liegt nicht an Grafana sondern daran, dass die Datenbank die Werte als String speichert und diese erstmal ge-cast-et werden müssen.

Ein Beispiel aus diesem Thread etwas abgewandelt liefert bei mir jedenfalls Werte. Sinnhaftigkeit mal dahingestellt

SELECT
  UNIX_TIMESTAMP(TIMESTAMP) as time_sec,
  MAX(CONVERT(VALUE, double)) as value,
  "Temp" as metric
FROM history
WHERE READING="temperature" AND DEVICE="HMTempSensor4" AND $__timeFilter(TIMESTAMP)
GROUP BY UNIX_TIMESTAMP(TIMESTAMP) DIV 86400


Dennoch bin ich der Verfechter davon, schon zu Beginn die Daten sauber zu loggen statt später irgendwelche Verrenkungen zu machen.

freddykr

Sorry für meine späte Reaktion.
Im Endeffekt waren zwei Dinge das Problem:
1)  Zum Einen musste bei der Query "Format as" --> "Table" sein und nicht "Time Series". Dann nahm er auch "max(value)" an
2) Und dann natürlich noch die CONVERT-Funktion, wobei ich CAST genutzt habe: max(CAST(VALUE as DECIMAL(10,2))) AS "Niederschlag"

In allem "dämliche" Anfängerfehler... ;)
Viele Grüße,
Danilo

kadettilac89

noch ein Tip, prüfe ob die Werte richtig agregiert werden oder um 1/2 Stunden verschoben sind. Suche in diesem Thread nach Zeitzone findet mehrere betroffene User und Lösungen ... das Problem wurde schon öfter diskutiert.

TWART016

Mein Ziel ist es ein Diagramm per Telegram zu versenden. Vor 2 Wochen hatte ich das eingerichtet, was auch funktioniert hat.
wget "http://192.168.178.15:3000/render/d-solo/XHwDB77Gk/test2?orgId=1&panelId=4"
--2021-04-13 12:42:10--  http://192.168.178.15:3000/render/d-solo/XHwDB77Gk/test2?orgId=1&panelId=4
Connecting to 192.168.178.15:3000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34528 (34K) [image/png]
Saving to: 'test2?orgId=1&panelId=4'

test2?orgId=1&panelId=4                    100%[=====================================================================================>]  33,72K  --.-KB/s    in 0,001s

2021-04-13 12:42:17 (30,1 MB/s) - 'test2?orgId=1&panelId=4' saved [34528/34528]

root@docker:/home/user/test-grafana# ls
'test2?orgId=1&panelId=4'


Seit ein paar Tagen wir jedoch nur noch die HTML Datei heruntergeladen und nicht mehr die Grafik.

Auch mit dem curl Befehl und angelegtem API Key funktioniert es nicht
curl -H "Authorization: Bearer eyJrIjoiSko4Qk1CT1lxNDRyUE5hTUJivdfjkDSDLJSDMsdnsjkdehsyZXIiLCJpZCI6MX0=" http://192.168.178.15:3000/render/d-solo/XHwDB77Gk/test2?orgId=1&panelId=4

Ohne Login komme ich nicht mehr auf das Bild, ich meine vor 2 Wochen hat das noch funktioniert.

Ein Update wurde ich der Zeit auch gemacht, ich meine von einer frühen 7.X nach 7.5.3.

Grafana läuft in Docker auf einem NUC, ebenso der Renderer. Daher habe ich das mit dem Firefox wie im Wiki beschrieben nicht durchgeführt.