Neues YouTube-Video: Visualisierung im Devices-Adapter

[Negalein]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

(*) Dann könnte man später auch die einzelnen Jahre miteinander vergleichen "2020 war im Durchschnitt 1.2°C wärmer als 2019..." usw.

Ja, das wäre ein sehr gutes Feature :)

[Nashra]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

(*) Dann könnte man später auch die einzelnen Jahre miteinander vergleichen "2020 war im Durchschnitt 1.2°C wärmer als 2019..." usw.

Sehr gute Idee

[SBorg]

Sodele, die V1.3.1 ist nun offiziell released
Update der Shell-Komponenten ist nicht notwendig, hier kam nur der fix für "Leerzeichen im Verzeichnisnamen" neu hinzu, damit bspw. auch /home/mein verzeichnisname hat leerzeichen/wetter funktioniert.

Die Wetterstation-Statistik.js sollte aber ersetzt werden, da hier zum letzten RC3 noch eine Änderung bzgl. der Regenmenge_Monat ("23.999999999999 l/m²") enthalten ist (aktuelle V0.1.0 im master-brunch ist mit der Release-Version identisch).
Die weitere Entwicklung des JS findet nun wieder im master-brunch statt.

[Negalein]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Update der Shell-Komponenten ist nicht notwendig

diese müssen nicht quasi upgedatet werden, wenn es schon die ganze Zeit läuft?

[SBorg]

@Negalein Jepp, die V1.3.1 ist nur für "Neulinge" interessant, und dann auch nur wenn sie Leerzeichen im Verzeichnisnamen haben. Sonst ist sie mit der V1.3.0 identisch. So ist jetzt aber auch das Statistik-Skript in der V1.3.1 und in späteren Releases enthalten :)

[SBorg]

Neue Version des Wetterstation-Statistik-Skriptes auf GitHub V0.1.1

• + AutoReset Jahresstatistik

Wie immer zu finden im GitHub (wetterstation-statistik.js)

Zu sehen ist so erst mal nichts, außer es funktioniert dann am 01.01.
In der Simulation lief es zumindest, allerdings sind das keine 19'er Daten, sondern nur die 12 Tage vom Oktober ;)

[Negalein]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

AutoReset Jahresstatistik

wie ist das nochmal?
Bei dir im Screenshot steht eine 2.
Das bewirkt dann, dass unter VorJahredie Jahresstatistik von allen Vorjahren aufscheint?
Also ab 2021 scheint 2020, ab 2022 dann 2020 und 2021, usw. auf.

[SBorg]

@Negalein Genau.
Wir haben den 01.01.2021...
Bei 0 passiert nichts und die Jahresstatistik läuft einfach weiter (dann wäre das aber keine Jahresstatistik mehr, sondern eine "ab Start des Skriptes" mit allen Werten).
Bei 1 würde die Jahresstatistik einfach auf "0" gesetzt. Die Werte von 2020 sind dann einfach weg.
2 enthält nun 1, nur zusätzlich werden die 2020er Werte unter "VorJahre.2020" als JSON-String gespeichert.

Ich wollte es eigentlich unter "Data" ablegen, habe mir da aber mit dem "AutoDelete_Data" den Weg etwas verbaut. Das würde dann auch die gespeicherten Jahresstatistiken löschen. Das zu unterbinden war mir dann mit zu viel Aufwand verbunden. Deswegen habe ich es in die Jahresstatistik verlagert, was ja auch ganz gut passt :)

IMO die beste Wahl ist also 2, aber das will ev. nicht jeder, deswegen die Konfigurationsmöglichkeit.

[SBorg]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

...sondern eine "ab Start des Skriptes" mit allen Werten

Hmm, dass wäre aber auch noch ein nettes Feature ala "Allzeitrekord"
Mir will nur gerade kein passender Name dafür einfallen: "Spitzenwerte", "[Allzeit]Rekord", "Rekordwerte", "Overall (IMHO sollte man aber bei deutsch bleiben und keinen Mischmasch mit dt. + engl. Bezeichnungen begehen)",...

Leider habe ich wohl die Regenmenge_Monat kaputt gepatcht, zumindest habe ich eine Klammer vergessen. Resultat:

Das wird auch mit jeder neuen Regenmenge wieder auftreten, selbst wenn ihr den Wert aus der Wetterstation (Monatswert minus ev. Tageswert) per Hand in den DP eintragt. Ich möchte den Fix aber erst mal testen. Mutige ( ;) ) können aber auch nach Number(Regenmenge_Monat).toFixed(2) suchen (Treffer ~ #163) und durch Number((Regenmenge_Monat).toFixed(2)) ersetzen.

[Negalein]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Rekordwerte

Mutige ( 😉 ) können aber auch nach Number(Regenmenge_Monat).toFixed(2) suchen (Treffer ~ #163) und durch Number((Regenmenge_Monat).toFixed(2)) ersetzen.

;) werde mich mal trauen

#159 wars
if (Max_Regenmenge > 0) {Regenmenge_Monat = getState(PRE_DP+'.aktueller_Monat.Regenmenge_Monat').val + Max_Regenmenge; setState(PRE_DP+'.aktueller_Monat.Regenmenge_Monat', Number((Regenmenge_Monat).toFixed(2)), true);}

[SBorg]

@Negalein Deswegen auch "~" da ich ev. paar mehr Leerzeilen habe, oder schon ein paar Codezeilen mehr. Wenn bei dir noch eine Zahl drin steht war es das auch schon, sonst halt

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Wert aus der Wetterstation (Monatswert minus ev. Tageswert) per Hand in den DP eintragt

"Rekord" gefällt mir auch am besten. Der "Temp.-Durchschnitt" müsste dann aber aus zwei DPs bestehen (Min/Max), etwas anderes ergäbe wohl keinen Sinn?

[Ein ehemaliger Benutzer]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

"Rekord" gefällt mir auch am besten. Der "Temp.-Durchschnitt" müsste dann aber aus zwei DPs bestehen (Min/Max), etwas anderes ergäbe wohl keinen Sinn?

Hi, yes, Rekord ist geil, ein Durchschnitt ist die quersumme aller Werte, da gibts kein Min oder Max.. sonst waere es ja kein Durchschnitt mehr.. :-)

Zeitliche Max und Min Werte sind gut, also MonatsMaxTemp, JahresMaxTemp, etc..

Rekord ist dann Zeitunabhaengig, solange, bis er gebrochen wird.

[Negalein]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

sonst halt

hab den Wert händisch eingetragen.
Müsste dann wieder passen.

Btw., bis jetzt hat es heute nicht geregnet. Deshalb konnte ich einfach den Monatswert nehmen.
Jetzt fängt es gerade zu schütten an. Soll ich dann um Mitternacht den Wert nochmal korrigieren?

[SBorg]

@ilovegym Beim Durchschnitt meinte ich zB. 2019 lag er bei 14.77°, 2020 bei 15.45°, 2021 bei 16.56°
Dann wäre bisher der "kühlste"/Min. Jahresdurchschnitt 2019 mit 14.77°, der "wärmste"/Max. 2021 mit 16.56°. So meine Vorstellung vom Durchschnitt.

...und ich sehe schon, mit dem Teil habe ich mir nen A*sch voll Arbeit eingehandelt...

@Negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Jetzt fängt es gerade zu schütten an. Soll ich dann um Mitternacht den Wert nochmal korrigieren?

Ne, dass sollte dann um 1:03 Uhr eigentllch wieder passen. Notfalls kannst du es ja auch morgen noch ändern.

Ich würde auch aktuell empfehlen am 31.10. sicherheitshalber mal eine Hardcopy mit den Monatswerten zu ziehen. Dann >können wir notfalls das JSON für den Oktober schnell per Hand anlegen, dann sind wenigstens die Oktoberdaten mal kpl. >und aktuell. Wäre schade wenn die flöten gingen.

[Negalein]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Ich würde auch aktuell empfehlen am 31.10. sicherheitshalber mal eine Hardcopy mit den Monatswerten zu ziehen. Dann >können wir notfalls das JSON für den Oktober schnell per Hand anlegen, dann sind wenigstens die Oktoberdaten mal kpl. >und aktuell. Wäre schade wenn die flöten gingen.

Da erinnerst uns noch ;)

...und ich sehe schon, mit dem Teil habe ich mir nen A*sch voll Arbeit eingehandelt...

Das glaub ich auch ;)

[Ein ehemaliger Benutzer]

@SBorg achso, die Jahresdurchschnittchen :-)
ja, ich glaub auch, so 'n Statistikkram geht ins unendliche...
Bis dahin und gut ist..

[SBorg]

@ilovegym frei nach Otto:
Frage: "Wie bringt man einen Ostfriesen zum bellen?"
Antwort: "Da vorne gibt es Freibier!"
"Wo, wo, wo, ...."

"...wo gibt es Schnittchen..."

Der fix bzgl. Regenmenge_Monat scheint zu funktionieren, zumindest hat er den neuen Regen ordnungsgemäß hinzu addiert und die vielen Nachkommastellen sind auch weg.

Für die "Rekordwerte" habe ich mir so meine Gedanken gemacht, bräuchte aber mal eure Meinung was genau im DP stehen soll? .Rekordwerte.Temperatur_Spitzenhoechstwert (zur Abgrenzung/leichteren Identifizierbarkeit extra etwas anders benannt), aber dann? Nur bspw. 42.14 und man muss sich ggf. das Datum oä. per Binding (was aber im Beispiel schon mit den Monatsnamen sehr schwierig wird) aus dem LC ziehen?
Ich hätte zB. dann gerne in der VIS so ähnlich stehen: 42.14 °C im Juli 2020
Auch wenn es wieder viel Arbeit bedeutet, könnte ich es mir als Template (zu konfigurieren im JS bei den Einstellungen) vorstellen:

REKORDWERTE_AUSGABEFORMAT="[WERT] im [MONAT] [JAHR]";

Da stellt sich dann aber "°C" als Problem dar, denn das darf ich nicht mit in das Template übernehmen. Sonst würde bspw. bei der Trockenperiode 43 °C im August 2020 stehen, obwohl es eigentlich 43 Tage im August 2020 lauten müsste. Das müsste sich aber über die "Unit" im DP handeln lassen, wenn auch kein Monat 43 Tage hat...

[Ein ehemaliger Benutzer]

@SBorg hoert sich sehr vernuenftig an, genau so !

[SBorg]

@ilovegym Dachte ich mir schon ^^

Hmm, um beim Beispiel zu bleiben, es wäre sogar möglich die 43 Tage zum berechnen zu nehmen: 43 Tage % 30 ergibt 1 (nennt sich modulo), d.h. ich ziehe "1" vom Monat ab, dann könnte ich sogar 43 Tage im Juli [ - | bis | / ](*) August 2020 realisieren...

(*)was auch immer

...und 61 Tage ergäbe dann "2", ergo 2 Monate abziehen = "Juni - August" und so weiter ;)

[Ein ehemaliger Benutzer]

@SBorg mach, wie du es am einfachsten machen kannst... :-)