[Linux Shell-Skript] WLAN-Wetterstation
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@negalein Es genügt unter Debian/Ubuntu:
echo "deb https://packages.grafana.com/enterprise/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.listDamit werden die "stable"-Releases mit ins Repo übernommen und beim normalen Update mittels update/upgrade dann auch geupdated.
Willst du das irgendwann mal nicht mehr, einfach die Datei/etc/apt/sources.list.d/grafana.listlöschen, oder wenn du z.B. auch Betas möchtest, dann einfach innerhalb der Datei stable durch beta ersetzen
Habe mich jetzt auch getraut Grafana auf die aktuelle Version zu heben, hat super geklappt, danke @sborg
Ein kleines Problem habe ich aber jetzt, einige Codes werden nicht mehr umgesetzt
Bekomme das einfach nicht mehr hin, was mache ich falsch? -
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich hab nur lauter Mehrzeiler im Netz gefunden.
Da wird dann immer noch der Key mit installiert. Da Grafana aber schon seit etlicher Zeit in der offiziellen Debian/Ubuntu Repo gelistet ist, braucht man das nicht mehr. Man kann natürlich auch auf ein Update via Original-Repo warten, dass dauert aber meist ein halbes Jahr bis da eine Stable von der Grafana-Seite auftaucht...
Das ist ein Problem mit den Original-Panels von Grafana. Die scheinen pauschal ANSI-/HTML-Code zu verweigern.
Mit dem Update von Grafana wurde auch das "Blendstat"-Plugin disabelt, welches ich im Original-Dashboard nutze, da es u.a. auch ANSI/HTML kann. Das hat er dann mit dem normalen "Stat"-Panel ersetzt.
Musst also ggf. "Blendstat" wieder nachinstallieren und dann auf das Panel umstellen.
Blendstat: https://grafana.com/grafana/plugins/farski-blendstat-panel/
Hier zwar keine Windrichtung, aber Pfeil für die Luftdrucktendenz
-
@sborg danke für den Hinweis. Blendstat hatte ich nicht mehr auf dem Schirm
obwohl ich alle Plugins upgedatet hatte. Jetzt alles wieder ok, Danke
-
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
Noch ein kleiner Fehler, ist auf GitHub bereits gefixt: stell noch in den Objekten beim PM25_24 die Rolle von "state" auf "value" um. Auswirkungen hat das so erst mal keine, ist nur syntaktisch einfach falsch (alle alten laufen eh noch auf "state").
Was hat denn das für eine Auswirkung? Das man ggf in Grafana mit State nicht rechnen kann?
Wollte gerade die Solarenergie Werte (die bei mir alle als State in ioBroker sind) in Grafana vereinheitlichen (sie werden teils als Wh und teils als kWh gesammelt) und in ein Bar Chart packen (à la Sonnenscheindauer) um Platz zu sparen, aber sobald ich eine math() Umrechnung reinsetze bekommt er keine Werte mehr...Kann das am State liegen? Kann ich das einfach in iobroker ändern und Influx kapiert das? Oder ist das dann wieder export/drop/import?
Danke
-
Kommando zurück, es läuft doch nicht alles wie es soll
Also in Blendstat alles neu eingetragen
aber mal zeigt er die Richtung an, mal nicht, obwohl sich die Daten ändern.Dann noch bei letzte Messung mit Haken bzw Kreuz wenn es nicht stimmt
(altes Bild)
werden nur Zahlen angezeigt. Verstehe nur nicht woher er die holt denn
in dem DP von ioBroker steht entweder 20 oder 90.
Die Einträge in der Datenbank mal komplet gelöscht aber sobald sich was ändert
kommen wieder diese Zahlen.
Werde einfach nicht schlau daraus
-
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was hat denn das für eine Auswirkung? Das man ggf in Grafana mit State nicht rechnen kann?
Unter gewissen Umständen, ja. Ein "state" ist eigentlich ein Zustand wie bspw. "auf, zu, offen...", ein "value" ein Wert wie "10 [Liter], 3.3 [°C]...."
Deswegen kann dann der Influx-Adapter ggf. bei Nutzung der "Automatik" auch eine Zahl als String miss interpretieren (denke ich zumindest) und dann eine Zahlenreihe als Textserie anlegen. Ob das Grafana dann stört kann ich dir leider nicht beantworten, aber du kannst dir ja mal unter Influx den FieldKey anschauen ob er da fälschlicherweise wieder String ist. Sollte es Number sein, liegt es zumindest mal nicht daran. -
@nashra Fangen wir hinten mit dem "einfachen" an: javascript.0.Wetterstattion_Kommunikationsfehler_InfluxDB gibt es nicht, bzw. ist der nicht von mir. Den erzeugt du selbst mittels JS, Blockly, NodeRED....
Da klemmt dann anscheinend etwasIch liebe (nicht ironisch) Hardcopys, sagt meist mehr als 1.000 Worte. Dein Problem ist beim Query zu sehen: MD=100 Interval = 15m
Wenn man Probleme mit Werten, Darstellung etc. hat ist die beste Anlaufstelle der "Query Inspector":
Zuerst mal checken ob die Abfrage überhaupt Werte liefert:
Tut sie, also mal die Daten prüfen (mit deinen Einstellungen 100 DPs und 15m):
Also ändert sich deine Anzeige in Grafana genau alle 15 Minuten einmal... -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@nashra Fangen wir hinten mit dem "einfachen" an: javascript.0.Wetterstattion_Kommunikationsfehler_InfluxDB gibt es nicht, bzw. ist der nicht von mir. Den erzeugt du selbst mittels JS, Blockly, NodeRED....
Da klemmt dann anscheinend etwasNö, Blockly ändert nur wenn Komm.Fehler auf true geht, dann wird der Wert in 90 geändert, bei false 20.
Die Daten kommen auch rein bei Grafana
Nur warum er mir da so Zahlen wie 75 oder 55 usw. reinsetzt ist mir schleiherhaft.
Bei 90 soll er den grünen Haken anzeigen und bei 20 das rote Kreuz
Bei der alten Version von Grafana hat das alles einwandfrei funktioniert
Irgendwas übersehe ich wohl, bleibe dran und probiere weiterIch liebe (nicht ironisch) Hardcopys, sagt meist mehr als 1.000 Worte. Dein Problem ist beim Query zu sehen: MD=100 Interval = 15m
Wenn man Probleme mit Werten, Darstellung etc. hat ist die beste Anlaufstelle der "Query Inspector":
Zuerst mal checken ob die Abfrage überhaupt Werte liefert:Werte werden geliefert, hab diese Einstellung schlichtweg übersehen
Asche über mein Haupt 
Trotzdem Danke für die ausführliche (nicht ironische) Erklärung
-
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was hat denn das für eine Auswirkung? Das man ggf in Grafana mit State nicht rechnen kann?
Unter gewissen Umständen, ja. Ein "state" ist eigentlich ein Zustand wie bspw. "auf, zu, offen...", ein "value" ein Wert wie "10 [Liter], 3.3 [°C]...."
Deswegen kann dann der Influx-Adapter ggf. bei Nutzung der "Automatik" auch eine Zahl als String miss interpretieren (denke ich zumindest) und dann eine Zahlenreihe als Textserie anlegen. Ob das Grafana dann stört kann ich dir leider nicht beantworten, aber du kannst dir ja mal unter Influx den FieldKey anschauen ob er da fälschlicherweise wieder String ist. Sollte es Number sein, liegt es zumindest mal nicht daran.Grafana hatte den Wert als String.... weil der Influx Adapter den Wert als String hat... warum auch immer. Alle "normalen" waren auf String, alle "als Text" auf Automatik.
Klar, das er damit nicht Rechnen mag, danke für den Pointer:)1.Welche Auswirkung hat das das in Influx wenn ich das umgestellt habe? Muss ich die alten Daten droppen/konvertieren?
Interessanterweise habe ich schon zwei Datentypen in Influx für value ...> show field keys from "javascript.0.Wetterstation.Info.Solarenergie_Jahr" name: javascript.0.Wetterstation.Info.Solarenergie_Jahr fieldKey fieldType -------- --------- ack boolean from string q float value float value string- Bei den "als Text" Variablen fehlen Woche, letztes Jahr und Gestern - nur bei mir?
Edit -
Und nochmal ne Frage zu Luftdruck - relativ vs absolut.
Das GW misst den absoluten Druck (also den echten aktuellen Druck am Aufstellort) nehme ich an, der relative (ion Bezug zu NN) wird errechnet.
Bei mir sind die Werte immer gleich da ich vergessen habe den Korrekturfaktor einzutragen (für meine Höhe).Jetzt wollte ich das nachholen, bin aber nicht sicher was ich wirklich eintragen muss...
Normal Null - 15° Standard Lufdruck sind ja 1013,25
Wenn ich jetzt sage ich bin 200m hoch (und wir die Temperatur mal ignorieren), dann ist mein "normal" Luftdruck 989,46 laut https://rechneronline.de/physik/luftdruck-hoehe.phpMuss ich dann im relativen Sensor die Differenz (989,46-1013,25=-23,79) als Korrekturwert eintragen?
-
@rand
Such dir am besten eine geeichte Station in der Nähe, wie zum Beispiel eine Station des DWD oder eines Flugplatzes (METAR-TAF) und berechne die Differenz aus dem aktuell gemessenen absoluten Luftdruck deiner Station und dem relativen der geeichten Station.Der absolute Luftdruck ist normalerweiser niedriger als der relative, da der Luftdruck ja mit der Höhe abnimmt. Also 23,79 und nicht -23,79 eintragen (aus deinem Beispiel).
-
@nashra sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Nur warum er mir da so Zahlen wie 75 oder 55 usw. reinsetzt ist mir schleiherhaft.
Aus Influx bzw. der Query ist es zumindest nicht, da sind die Daten noch i.O.
Was macht aber Grafana daraus (Anzeige von Data)? Es kann sein, dass er ohne "Group By" in der neuen Grafana-Version einen Gleitwert/Mittelwert/Durchschnitt bildet. -
@rand Bis eben wusste ich nicht, dass Influx auch zwei FieldKeys bei value akzeptiert. Ich war der Meinung, dass wäre ein "entweder - oder". Zumindest kann das auf Dauer nicht gut sein und ich würde es korrigieren.
Da ich keine Ahnung habe was er da wann schickt, kann es das übliche Problem geben "kann nicht damit rechnen/abfragen" weil es String und nicht Number ist etc.@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Bei den "als Text" Variablen fehlen Woche, letztes Jahr und Gestern - nur bei mir?
Zumindest bei mir sind sie da und aktuell, würde also behaupten: ja (was aber nicht erklärt warum)
GW habe ich keins, kann also schlecht was dazu sagen (außer mich @Boronsbruder anschließen). Bei der Station musste ich nur meine Standorthöhe in Meter ÜNN angeben, meine ich zumindest. Aber lange her, graue Zellen und so...
-
@boronsbruder said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand
Such dir am besten eine geeichte Station in der Nähe, wie zum Beispiel eine Station des DWD oder eines Flugplatzes (METAR-TAF) und berechne die Differenz aus dem aktuell gemessenen absoluten Luftdruck deiner Station und dem relativen der geeichten Station.Der absolute Luftdruck ist normalerweiser niedriger als der relative, da der Luftdruck ja mit der Höhe abnimmt. Also 23,79 und nicht -23,79 eintragen (aus deinem Beispiel).
Danke - leider ist die Abweichung nicht konstant - hatte es am Sonntag eingetragen (Abweichung ca 10 mbar) und heute kontrolliert - mein korrigierter Wert ist heute nochmals 10mbar zu niedrig, d.h. die Abweichung ist gerade eher bei 20mbar statt der 10 vom Sonntag.
Vielleicht ist das doch sehr viel stärker vom aktuellen Wetter abhängig (Temp & Feuchte - jetzt regnerisch, Sonntag warm/trocken) als ich das erwartet hätte, hab natürlich nie die exakt gleichen Werte... Dazu kommt natürlich noch die ~30km Entfernung, der Höhenunterschied und die Lage des Flughafens.Ich denke ich trage mal den rechnerischen Wer ein (positiv, danke;)) und schaue wie es sich dann verhält.
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand Bis eben wusste ich nicht, dass Influx auch zwei FieldKeys bei value akzeptiert. Ich war der Meinung, dass wäre ein "entweder - oder". Zumindest kann das auf Dauer nicht gut sein und ich würde es korrigieren.
Da ich keine Ahnung habe was er da wann schickt, kann es das übliche Problem geben "kann nicht damit rechnen/abfragen" weil es String und nicht Number ist etc.Ok, schauen wir mal was passiert, es ist doch recht nervig die Daten wieder zu importieren... vlt stelle ich mich nur doof an aber die CLI jammert immer bei javascript.0.xyz rum aber wenn ich Quotes nehme legt er neue Datenpunkt an statt den String nur als quoted zu betrachten (zu mindestens war das bei mir so als ich die Jahresregenwerte bearbeiten wollte
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Bei den "als Text" Variablen fehlen Woche, letztes Jahr und Gestern - nur bei mir?
Zumindest bei mir sind sie da und aktuell, würde also behaupten: ja (was aber nicht erklärt warum)
Also im aktuellen JS ist zu mindestens _Woche_Text vorhanden, vorJahr und vorTag allerdings nicht. Seltsam das er das nicht angelegt hat als ich die Tage aktualisiert habe, wegen
Ich nehme an eine Umstellung der Solarenergie Werte auf ein einheitlichen Maß (Wh/m² oder kWh/m²) ist nachträglich eher schwer oder?
Hätte den Vorteil das man alle Werte einheitlich behandeln kann und Grafana die "Umrechnung" überlassen kann - ist natürlich für Deine Vis nicht wichtig da einzelne Felder, in meinem Versuch sie in eines zu packen jedoch etwas... unvorteilhaft (da ich auch damit nicht rechnen kann weil String)
-
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Danke - leider ist die Abweichung nicht konstant
Ist sie auch nicht. Bis ~14:00 Uhr ist der gap recht groß, dann bis ~19:00 Uhr relativ identisch und dann liegt er sogar darüber. Mit einem festen Wert kann man hier also nicht arbeiten. Vermutlich ist da ein Algorithmus dahinter der auch die Temperatur berücksichtigt.influx mag die Punkte in der Bezeichnung nicht. Man hätte natürlich auch mittels Alias arbeiten können, nur ist es jetzt zu spät, da alles auf der ioB-Syntax aufbaut.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich nehme an eine Umstellung der Solarenergie Werte auf ein einheitlichen Maß (Wh/m² oder kWh/m²) ist nachträglich eher schwer oder?
Eigentlich nicht, aber wegen der bereits seit Anbeginn gesammelten Daten verschiedener User nicht unbedingt sinnvoll. Persönlich gefällt mir ehrlich gesagt die Vereinheitlichung auch nicht gerade, denn der Tageswert ist im Gegensatz zum Jahreswert zu klein. Du hast also entweder eine schlechte Tagesauflösung, viele Nachkommastellen oder sehr große Zahlen.
Was aber wie üblich nicht heißen soll, dass ich für Änderungen nicht zugänglich wäre.
Ich habe es mittlerweile in einer Tabelle, da bei den Balkendiagrammen der Bezug fehlt ("was sind 100% Balkenlänge bei 12:10:23 ?") und er hier in kW, MW etc. umrechnet:
Du könntest aber zB. mittels des Alias-Managers die Umrechnung durchführen, oder dir eine "eigene" Shell-Skript Version erstellen. Änderungen wären zwar bei einem Update wieder weg, aber eine neue Version sehe ich aktuell nur noch bei neuen Sensoren
Die Umrechnung geschieht in der sub so um Zeile 500f:#Leistung berechnen SOL_TMP=$(echo "scale=3;${SOL_TMP}/(3600/${WS_POLL})" | bc -l) SOLARENERGIE_TAG=`echo "scale=3;${SOLARENERGIE_TAG}+${SOL_TMP}" | bc -l` SOLAR_WOCHE=`echo "scale=5;(${SOLAR_WOCHE}+${SOL_TMP})" | bc -l` SOLARENERGIE_WOCHE=`echo "scale=3;${SOLAR_WOCHE}/1000" | bc -l` #Umrechnung in kWh SOLAR_MONAT=`echo "scale=5;(${SOLAR_MONAT}+${SOL_TMP})" | bc -l` SOLARENERGIE_MONAT=`echo "scale=3;${SOLAR_MONAT}/1000" | bc -l` #Umrechnung in kWh SOLAR_JAHR=`echo "scale=5;(${SOLAR_JAHR}+${SOL_TMP})" | bc -l` SOLARENERGIE_JAHR=`echo "scale=3;${SOLAR_JAHR}/1000" | bc -l` #Umrechnung in kWhEntweder änderst du den Tag hier nach dem Muster Woche/Monat/Jahr ab und teilst dann durch 1000 (=Wert dann in kWh), oder du löschst bei Woche/Monat/Jahr einfach
/1000, dann hast du alle Werte in Wh. -
@SBorg
Ich habe noch eine Korrektur für deinen WINDCHILL.
Es fehlte noch die Prüfung auf die maximale gültige Temperatur von 10°C.wetterstation.sh
Zeile 214 altif (( $(bc -l <<< "${MESSWERTE[6]} > 5") )); thenZeile 214 neu
if (( $(bc -l <<< "${MESSWERTE[6]} > 5") )) && (( $(bc -l <<< "${MESSWERTE[1]} < 10") )); thenGrüße
-
@boronsbruder Stimmt, da war doch noch was...
Danke -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Danke - leider ist die Abweichung nicht konstant
Ist sie auch nicht. Bis ~14:00 Uhr ist der gap recht groß, dann bis ~19:00 Uhr relativ identisch und dann liegt er sogar darüber. Mit einem festen Wert kann man hier also nicht arbeiten. Vermutlich ist da ein Algorithmus dahinter der auch die Temperatur berücksichtigt.
Fällt bei Deiner Station der relative und absolute Druck ohne Korrekturfaktor heraus? Oder woher kommen bei Dir die Werte?
Ich verstehe es nicht ganz, sorry, Wenn absoluter und relativer Druck doch über die Höhe und Temperaturdifferenz zu NN/15°C ermittelt werden, warum kann das dann schwanken?
Um ganz präzise zu sein müsste ich eigentlich auf einen 15°C Tag Zeitpunkt warten, und dann sollte nur noch die Höhendifferenz eine Rolle spielen.
Aber auch dann wäre das doch konstant und keine schwankende Kurve?
Und wenn es dann doch irgendwie eine Kurve sein muss, warum kann ich dann nur einen statischen Korrekturfaktor angeben?
Wahrscheinlich ist meine Erwartungshaltung wieder dem Preisgefüge nicht angemessen:pinflux mag die Punkte in der Bezeichnung nicht. Man hätte natürlich auch mittels Alias arbeiten können, nur ist es jetzt zu spät, da alles auf der ioB-Syntax aufbaut.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich nehme an eine Umstellung der Solarenergie Werte auf ein einheitlichen Maß (Wh/m² oder kWh/m²) ist nachträglich eher schwer oder?
Ich habe es mittlerweile in einer Tabelle, da bei den Balkendiagrammen der Bezug fehlt ("was sind 100% Balkenlänge bei 12:10:23 ?") und er hier in kW, MW etc. umrechnet:
Du könntest aber zB. mittels des Alias-Managers die Umrechnung durchführen, oder dir eine "eigene" Shell-Skript Version erstellen. Änderungen wären zwar bei einem Update wieder weg, aber eine neue Version sehe ich aktuell nur noch bei neuen SensorenUnd wie hast Du die Werte umgerechnet? In Grafana oder vorher? In Grafana klappt ja bei mir nicht... wenn das aber nur aufgrund des falschen Datentyps bei mir so ist, dann sollte ich wohl eher das korrigieren anstatt an den Symptomen rumzudoktern.
Tabelle ist auch nicht schlecht, wollte nur etwas was Platz spart, die vielen Felder waren mir etwas verschwenderisch:)
-
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Fällt bei Deiner Station der relative und absolute Druck ohne Korrekturfaktor heraus? Oder woher kommen bei Dir die Werte?
Ich habe nur in der VS-View-App beim Einrichten die Höhe der Station ÜNN angeben müssen. Dann kommen die Werte so vom Display und ich reiche sie 1:1 an den ioB weiter.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich verstehe es nicht ganz, sorry,...
Warum sorry, ich verstehe das auch nicht. Ich bin Elektroniker...
...also sorry von meiner Seite, ich kann dir da keine Erklärung geben. Wahrscheinlich wird aus der aktuellen Temperatur die Temperatur bei NN berechnet und daraus dann der aktuelle Druck?@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wahrscheinlich ist meine Erwartungshaltung wieder dem Preisgefüge nicht angemessen
Glaube ich nicht mal, nur darf man halt nicht unbedingt davon ausgehen, dass 21.3°C dann auch wirklich 21.3°C sind. Da ist die Drift der Sensoren dann halt doch vorhanden und dem Preis geschuldet.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und wie hast Du die Werte umgerechnet? In Grafana oder vorher? In Grafana klappt ja bei mir nicht...
In Grafana und dann rechnet er per "Unit" von alleine um: 1.000 kWh --> 1 MWh
Mir gefallen die Balken zwar optisch auch besser, aber sie haben hier halt keine Aussagekraft. Der Jahreswert bestimmt dann die Skalierung der anderen Werte, außerdem wird der unabhängig vom Wert immer 100% anzeigen. Du hast ja keinen definierten Endwert (wie z.B. bei einem Tank der 1.000 Liter fasst) und somit keinen Bezugspunkt (außer du wüstest im Vorfeld schon den Jahresendwert
). -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Fällt bei Deiner Station der relative und absolute Druck ohne Korrekturfaktor heraus? Oder woher kommen bei Dir die Werte?
Ich habe nur in der VS-View-App beim Einrichten die Höhe der Station ÜNN angeben müssen. Dann kommen die Werte so vom Display und ich reiche sie 1:1 an den ioB weiter.
Vielleicht ist das des Pudels Kern... ich gebe einen Offset in hPa unter Calibration an - vielleicht ist das die falsche Stelle?
Die Anleitung von Ecowitt verweist leider auf eine Seite die es nicht mehr gibt, daher habe ich gesucht und nichts anderes gefundenEdit - ok, scheint im GW nicht direkt zu gehen - https://www.wxforum.net/index.php?topic=38214.0
Aber so richtig verstehen wie ich es nun einstellen muss weiss ich immer noch nicht
das GHW lässt beim absoluten Wert nur negative Werte zu, was ja auch ok ist (wenn man nicht unter NN lebt) da der echte Druck ja immer niedriger ist als der bei NN.
Aber was ich dann für den rel. Wert setzen muss weiss ich immer noch nicht.
Wenn ich nichts eintrage dann ist der rel = abs (also auch um ~20 reduziert), also habe ich nun die 20 die abziehe wieder drauf gerechnet, aber damit bin ich immer noch 20 niedriger als der Flughafen Wert (der nur 10 höher sein sollte wg Höhendifferenz)... Alles seltsam
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und wie hast Du die Werte umgerechnet? In Grafana oder vorher? In Grafana klappt ja bei mir nicht...
In Grafana und dann rechnet er per "Unit" von alleine um: 1.000 kWh --> 1 MWh
Ah ok, das tut bei mir wg den Datentypen nicht. Dann muss ich da mal ran ...
Mir gefallen die Balken zwar optisch auch besser, aber sie haben hier halt keine Aussagekraft. Der Jahreswert bestimmt dann die Skalierung der anderen Werte, außerdem wird der unabhängig vom Wert immer 100% anzeigen. Du hast ja keinen definierten Endwert (wie z.B. bei einem Tank der 1.000 Liter fasst) und somit keinen Bezugspunkt (außer du wüstest im Vorfeld schon den Jahresendwert
).Richtig, aber das ist doch bei der Solarenergie wo Du Balken hattest auch nicht anders, oder? Oder hast Du Die auch in Tabelle gewechselt inzwischen?
Hab Deine Grafana Seiten (wenn sie aktualisiert wurden) lange nicht mehr angeschaut da ich viel zu viel customised hab (weil ja ganz andere Sensoren), aber inzwischen habe ich gelernt das man auch einzelne Panels per Javascript einbauen kann (wenn ich es nicht verwechsele) , also sollte ich mal wieder schauen
Eine nette Spielerei (in meinem Fall) wäre es wenn man Solarstromausbeute vs verfügbarer Solarenergie charten würde (optional vs vorhergesagter Min/Max Ausbeute). Naja wenn ich mal sonst nichts zu tun hab (oder einen Rappel kriege)
-
@rand Ich baue auch öfters an Grafana, aber die Balken sind schon eine ganze Weile durch Tabellen ersetzt (bisserl runter scrollen):
https://github.com/SBorg2014/WLAN-Wetterstation/tree/master/Grafana Dashboard...und bevor noch einer fragt, nein, natürlich hatte ich im Vorjahr keinen Ertrag von 348 MWh
Das war nur zum testen, der Fusionsreaktor im Keller liefert eh nur im Gigawatt-Bereich...
