[Linux Shell-Skript] WLAN-Wetterstation

[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?

[Neuschwansteini]

@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

[Neuschwansteini]

@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...

[Neuschwansteini]

@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

[Neuschwansteini]

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

[Negalein]

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

Ich hätte zB. dann gerne in der VIS so ähnlich stehen: 42.14 °C im Juli 2020

Ja, das wäre schön, wenn du es so hinbekommst.

[SBorg]

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

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

Ich hätte zB. dann gerne in der VIS so ähnlich stehen: 42.14 °C im Juli 2020

Ja, das wäre schön, wenn du es so hinbekommst.

Zu spät

Nach dem 1. Schedule steht dann auch eine korrekte Temperatur drin. "value" enthält die reinen Werte. Hätte man dann auch einfach im Template per "[WERT]" erhalten, ich muss aber die bisherigen Spitzenwerte sowieso speichern.
Wie im obigen Entwurf funktioniert schon [WERT], [MONAT] und [JAHR]. Implementieren möchte ich noch [JSON]. Dann einfach mal sehen was ggf. noch fehlt/gewünscht.

[Neuschwansteini]

@SBorg perfekt, ich hoffe nicht, dass wir -100 im Oktober 2020 bekommen... aber sieht soweit sehr gut aus

[wendy2702]

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"]

[Negalein]

@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.

[wendy2702]

@Negalein Welche Werte benötigt denn das Script damit alles gefüllt wird?

[Negalein]

@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.

[Negalein]

@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

[wendy2702]

@Negalein Danke

[SBorg]

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