[Linux Shell-Skript] WLAN-Wetterstation
-
@SBorg perfekt, ich hoffe nicht, dass wir -100 im Oktober 2020 bekommen... aber sieht soweit sehr gut aus
-
Hi,
gerade mal Influx, Grafana und das Statistik Script installiert.
Ist es immer noch ausreichend nur das loggen für diese DP's zu aktivieren?
Voraussetzung: laufendes WLAN-Wetterstation Shellscript, laufender Javascript-Adapter im ioBroker, laufende InfluxDB [inkl. logging der benötigten Datenpunkte "Aussentemperatur", "Wind_max" und "Regen_Tag"] -
@wendy2702 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ist es immer noch ausreichend nur das loggen für diese DP's zu aktivieren?
Jein
Wenn dir die 3 Werte reichen, dann schon.Ich hab viel mehr geloggt.
-
@Negalein Welche Werte benötigt denn das Script damit alles gefüllt wird?
-
@wendy2702 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Welche Werte benötigt denn das Script damit alles gefüllt wird?
welches meinst du?
Edit: sorry, erst jetzt gesehen, dass du das Statistik meinst.Das die Daten von der Station abholt, oder das für die Statistik?
Bei keinen der beiden musst du DP loggen.
Die DP werden automatisch erstellt (siehe Wiki von @SBorg)Loggen musst du nur für die Darstellung in Grafana, bzw. Flot.
-
@wendy2702 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
das Statistik Script installiert.
Ist es immer noch ausreichend nur das loggen für diese DP's zu aktivieren?Sorry, hab überlesen, dass du das Statistik meinst.
Ja, da reichen diese 3
-
@Negalein Danke
-
Sodele, neues von der Front.
[JSON] habe ich verworfen, da dass Blödsinn ist. Ich habe dann einen DP (der eine Bezeichnung hat) in dem dann die Bezeichnung und der Wert drin steht... Das habe ich ja schon mit dem "normalen" Datenpunkt.
Dafür kam [TAG] dazu:
Nicht über die Werte wundern, die sind stellenweise getürkt, da es hier bspw. Dauerregen hat, ich aber mal einen "Spezialpatch" für die Tag/Tage-Problematik probieren musste. Der "4. Oktober" beim [TAG]-Test ist ebenfalls falsch, kommt davon wenn man getDay/getDate verwechselt...Das Ganze wird natürlich wie üblich erst mit dem Start der neuen Funktion korrekt laufen und Änderungen am Template werden erst geschrieben wenn sich der Wert des DPs auch wirklich ändert. Deswegen steht bei mir zum Teil "...im Oktober..." und "... am 4. Oktober..."
Dann baue ich noch die beiden "Schnittchen" ( @ilovegym ) voraussichtlich heute ein, dann gübbet es morgen wieder was zu testen
-
Neue Beta-Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.3B_01
- + Rekordwerte
Wie immer zu finden im GitHub (wetterstation-statistik.js)
Beim Einsatz der Beta geht nichts kaputt oder verloren, nur sind die neuen Rekordwerte noch eher "suboptimal" bzw. experimentell. Neue User-Einstellungen beachten!Ich habe mal mit diversen Template-Vorlagen gespielt. Dabei kam noch [MONAT_ZAHL] und [MONAT_KURZ] dazu:
Allerdings wird man später um das ein oder andere Binding per "value-Werte" in der VIS nicht herum kommen.
Beispiel-Template: [WERT] am [TAG].[MONAT_ZAHL].[JAHR]
Ausgabe im DP (zB. Temperatur-Spitzenhöchstwert): 41.34 °C am 14.07.2020
Sähe bei der Trockenperiode aber blöd aus: 31 Tage am 15.05.2020...und gleich wieder ein neues Problemchen mit der Durchschnittstemperatur. Im Grunde ist die nur am 31.12. korrekt zu ermitteln wenn man auch die kpl. Jahreswerte hat. Da es jetzt eher kälter wird, sinkt natürlich die Durchschnittstemperatur überdurchschnittlich ab, da wir keine Werte von Januar - Oktober haben. Damit wird natürlich ein unrealistischer Temperatur-Jahresdurchschnitt-Minimal-Wert generiert (bei mir aktuell 7.9 °C), der natürlich weder die korrekte Durchschnittstemperatur von 2020 wieder spiegelt, noch wird der wohl bis zur nächsten Eiszeit jemals gebrochen werden können
Als Lösung sehe ich aktuell nur, diese Rekordwerte ausschließlich am 01.01. des Jahres zu berechnen und einmalig für das "Startjahr" dann am nächsten Ersten (bei uns also der 01.01.2021) die Werte auf -/+ 99.99 °C zu setzen, damit dann ab 01.01.2022 die Rekordwerte korrekt sind. Muss mal schauen ob ich das irgendwie automatisch hinbekomme. Man, man, man, sind das Planungszeiträume
btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
-
@SBorg Hi, richtig, die kompletten Rekordwerte kann man nur am 1.1. berechnen auf Grund den Vorjahreswerten.
Leider werden wir also noch bis zum 1.1.2022 warten muessen, um zu sehen, ob es wirklich klappt..
Man kann ja das Script mal zum testen starten, um zu sehen, ob Werte ermittelt werden, aber am 1.1. muss das Script dann neu berechnen ...
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
ist ja fast Badewetter.
Rekord seit Script sind 4 °C
-
PS:
-
@SBorg said in [Linux Shell-Skript] WLAN-Wetterstation:
Man, man, man, sind das Planungszeiträume
wenn man dann erst einen 10jahres schnitt haben will...
-
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
wenn man dann erst einen 10jahres schnitt haben will...
Ich werde mir einen DeLorean kaufen und mit Marty und Doc Brown einen Ausflug machen!
-
@Negalein ey, wo treffen wir uns? ich will mit! soweit ich weis bist du ja auch ausm ösi-land. da is es einfacher sich zu treffen...
-
@da_Woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
soweit ich weis bist du ja auch ausm ösi-land
Richtig! Bin im Innviertel. Schon fast ein Bayer. Schau da vom Fenster rüber.
-
@Negalein na das geht ja, ich kann fast nach ungarn pinkeln.
und, oh freude, wir können wieder rüber einkaufen! 30km grenzgänger... -
@Negalein, @ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Herzlichen Dank euch beiden
Brauch mal wieder eure Meinung:
Ich kann quasi das Installationsdatum aus dem Ordner-DP ziehen. Bei mir 12.09.2020
Egal wann nun ein User installiert, würde am 01.01. geprüft werden ob "aktuelles Jahr" = "Installationsjahr +1". Wäre bei uns allen am 01.01.2021 jetzt wahr --> dann resette den Durchschnitt (weil ja bei jedem der innerhalb eines Jahres beginnt das erste Jahr quasi "für die Füsse" ist). Am 01.01.2022 und spätere Jahre wäre es immer falsch und die Berechnung, Anzeige etc. würde erfolgen (und stimmen ). Soweit, so gut. Problem besteht aber wenn man bspw. 2 oder mehr Jahre schön Daten gesammelt hat und das System bspw. crasht. Backup einspielen und bis hierhin ist alles gut. Da sich jetzt aber quasi das Installationsdatum auf zB. 2022 geändert hat, würde der Durchschnitt wg. obiger Automatik dann aber wieder resettet werden (was aber unnötig wäre, da die Daten kpl. vorliegen).
Muss es der User von Hand machen (und eben auch daran denken) und ich schreibe es in die WiKi, ließt es wieder nur die Hälfte (weil das einfach alles zu lang/zu viel wird [geht mir auch so ]). Von der anderen Hälfte wird dann wieder kaum einer daran denken es am 01.01. per Hand korrekt zu resetten (weil das ja auch nur für Installationsjahr +1 gilt).Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
Ich auch.
Obwohl ich mich sicher zu denen zähle, die darauf vergessen! -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@Negalein, @ilovegym sagte in [[Linux Shell-Skript] .
Was wäre das kleinere Übel? Ich tendiere zur Automatik und im Fall des Backups dann eben Pech gehabt...
Automatisch ist immer gut
