NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Rekordwerte
:+1:
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);}@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?
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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?
@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 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?
@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 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.
@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... :grin:
@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.
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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... :grin:
@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.
@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 ;)
-
@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... :grin:
@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.
-
@SBorg achso, die Jahresdurchschnittchen :-)
ja, ich glaub auch, so 'n Statistikkram geht ins unendliche...
Bis dahin und gut ist..@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..." :innocent:
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.14und 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...
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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..." :innocent:
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.14und 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...
-
@SBorg hoert sich sehr vernuenftig an, genau so !
@ilovegym Dachte ich mir schon ^^
Hmm, um beim Beispiel zu bleiben, es wäre sogar möglich die
43 Tagezum 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 ;)
-
@ilovegym Dachte ich mir schon ^^
Hmm, um beim Beispiel zu bleiben, es wäre sogar möglich die
43 Tagezum 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 ;)
@SBorg mach, wie du es am einfachsten machen kannst... :-)
-
@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..." :innocent:
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.14und 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...
@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.
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@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.
@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 :grin:
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. -
@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 :grin:
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.@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"]Bitte keine Fragen per PN, die gehören ins Forum!
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
-
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.
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@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 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.
-
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:
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
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@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
-
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 :grin:
Support us
851
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge