NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@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: -
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 ;)
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 :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
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 :grinning: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 ...
-
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 :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
@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. :grin:
Rekord seit Script sind 4 °C
PS: :money_with_wings: ;)
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
Das ganze entstand aus diesem Thread.
Damit ist es möglich mit einem Linux-Client die Daten einer WLAN-Wetterstation und/oder mit Hilfe eines Gateways und Zusatzsensoren zu empfangen, aufzubereiten und im ioBroker zur Verfügung zu stellen. Optional können die Daten auch bei AWEKAS.at, OpenSenseMap, Windy und wetter.com zur Verfügung gestellt werden.
Mein Dank geht an @Latzi für das testen in der Entwicklungsphase und dessen Unterstützung bei der Verfassung der WiKi-Artikel.
Aktuelle Version auf GitHub:
Neue Versionen im Thread sind ab V2.15.0 (Juli 2022) unterschiedlich farblich gekennzeichnet:- Beta-Releases haben dann eine rote Versionsnummer
- stabile Releases haben dann eine grüne Versionsnummer
Projektseite (inkl. WiKi): https://sborg2014.github.io/WLAN-Wetterstation/
Da es sich um keinen Adapter handelt, ist dies eine "Vorschaltseite" von GitHub. Nicht das wer auf die Idee kommt von der URL im ioBroker installieren zu wollen ;)
Zum Download/WiKi geht es dann weiter per View on GitHubBisher geteste Stationen:
- BRESSER
- WLAN Farb-Wetter Center mit 5-in-1 Profi-Sensor V (1) @pandor
- WLAN Comfort Wetterstation mit 7-in-1 Profi-Sensor (1)
- ChiliTec Funk Wetterstation 12in1 @tege0
- DNT Weatherscreen PRO @Petersilie
- Ecowitt
- GW1000
- GW2000A
- GW3000A @MartyBr
- WS2910 @Nashra
- WS3800A @hoschi2007
- WS3900 @Mike77
- ELV WS980WiFi @sonystar
- Eurochron EFWS2900 @Latzi, @ilovegym, @SBorg (baugleich mit Ambient Weather WS-2902, Chilitec CTW-902, Sainlogic 10 in 1)
- Froggit
- Gateway/USB-Dongle DP1500/DP2000 @Boronsbruder
- HP1000SE Pro @Stormbringer
- WH3000 SE @ToxSox, @crunchip
- WH4000 SE @unltdnetworx, @Glasfaser, @Negalein, @Boronsbruder
- WH6000 Pro @Mugel80
- Renkforce WH2600
- Sainlogic
- Ventus W830 @CiroCool, @Rushmed
(1) Abfrage per DNS-Server wie bspw. PiHole oder dnsmasq
Bisher unterstütze Zusatzsensoren per Station oder mittels DP1500/DP2000/GW1000/GW2000A - Gateway:
- bis zu 8 Stück DP35/WN34 Wassertemperatur-Sensoren
- ein DP40/WH32 (bzw. WH26) Außentemperatur- und Luftfeuchtigkeitssensor
- bis zu 8 Stück DP50/WH31 Temperatur-/Luftfeuchtigkeit-Sensoren
- ein DP60/WH57 Blitzsensor
- bis zu 4 Stück DP70/WH55 Wasserleckage-Sensoren
- bis zu 16 Stück DP100/WH51 Bodenfeuchte-Sensoren
- bis zu 4 Stück DP200/WH43 PM2.5 Feinstaub-Sensoren
- ein DP250/WH45 5-In-1 CO2 / PM2.5 / PM10 / Temperatur / Luftfeuchte Innenraumsensor
- ein DP300/WS68 Solarunterstütztes Anemometer mit UV-Lichtsensor
- ein WH31 (bzw. WH25) Sensor
- ein WH40H Sensor
- ein WS80 Sensor
- ein WS90 "Wittboy" Sensor
- BRESSER (1)
- bis zu 4 Stück(2) BRESSER Thermo-/Hygro-Sensor 7 Kanal #7009999
Für den WFC01 hat @Rand nun hier und folgende ein kleines Javascript gebaut, um diesen auch auslesen zu können.
(1) nicht alle Bresser-Stationen unterstützen Zusatzsensoren! siehe hier
(2) durch das verwendete Wunderground-Protokoll limitiertDie mögliche Anzahl der Zusatzsensoren ist nicht durch das Skript begrenzt, sondern wird vom Display und/oder Gateway bestimmt.
Es besteht ferner auch die Möglichkeit Stationen (wie bspw. Sainlogic Profi Wlan Wetterstation FT0300) einzubinden die nicht per WS View[+] App konfiguriert werden können und nur ein Web-Interface bieten, dass keine Angabe eines eigenen Wetterdienst-Servers zulässt. Hierfür kann man den Umweg eines eigenen DNS-Servers wie dnsmasq oder Pi-hole gehen. Für Pi-hole hat @XxJooO freundlicherweise hier im Forum eine ausführliche Doku erstellt: klick mich
Wäre schön wenn sich weitere User mit entsprechenden Modellen melden bei denen es funktioniert (auch wenn es baugleiche sein sollten, so ist man sich wenigstens sicher ;) )
Update von einer Vorgängerversion (bei Nutzung per systemd):
Im Installationsverzeichnis
./ws_updater.shausführen.
Alternativ (falls die aktuell installierte Version kleiner als V2.12.0 ist): im Installationsverzeichnisbash <(curl -s https://raw.githubusercontent.com/SBorg2014/WLAN-Wetterstation/master/ws_updater.sh)ausführenUpdate von einer Vorgängerversion (bei Nutzung als cronjob):
Am besten das laufende Skript mit
pkill -9 wetterstation.shstoppen, wetterstation.sh und -.sub ersetzen (-.conf und -.js nur nach Aufforderung nötig; conf dann neu konfigurieren / js ersetzen und einmalig ausführen), dann entweder- direkt am Linux-Client
./wetterstation.sh & - oder per Putty oä.
nohup ./wetterstation.sh &(erzeugt dabei eine Datei nohup.out) - oder reboot des Systemes (Skript wird dann per cronjob wieder gestartet)
jeweils im Installationsverzeichnis ausführen. Sonst befindet sich ggf. noch das alte Skript im RAM und läuft munter bis zum nächsten Reboot weiter ;)
Beispiele einer grafischen Umsetzung:
@Glasfaser: View / zum Beitrag
@crunchip: Grafana / zum Beitrag
Wetterstation-Statistik (JS-Addon)
Statistikmodul als Javascript. Liefert diverse Statistiken:
Javascript für eine HTML-Tabelle vorheriger Monatswerte ( @liv-in-sky ) :
zum ThreadNeues Projekt PimpMyStation (14.11.2020)
Kein Support per PM/Chat !
PS: 💸 :blush:
-
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 :grinning:btw: "kalte Tage" funktioniert auch, gestern war der Spitzenwert nur 9.88 °C und ich habe einen bekommen...
-
@SBorg said in [Linux Shell-Skript] WLAN-Wetterstation:
Man, man, man, sind das Planungszeiträume
wenn man dann erst einen 10jahres schnitt haben will... :D
@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! ;)
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@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... :D
@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. :)
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix
Support us
383
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge