[Linux Shell-Skript] WLAN-Wetterstation

[a200]

@Negalein ok jetzt sollte es mit:

sudo /home/iobroker/wetterstation.sh --debug

gehen

[Negalein]

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

sudo /home/iobroker/wetterstation.sh --debug

dietpi@DietPi:~$ sudo /home/iobroker/wetterstation.sh --debug
Connection to 10.0.1.200 8087 port [tcp/*] succeeded!
Listening on [0.0.0.0] (family 2, port 1080)


Messwerteblock:


Nicht alle Werte werden unterstützt (abhängig vom Modell der Wetterstation und dem verwendeten Protokoll)!

Temperatur Innen        :  °C
Temperatur Aussen       :  °C
Taupunkt                :  °C
Chill-Faktor            :  °C
Luftfeuchte Innen       :  %
Luftfeuchte Aussen      :  %
Windgeschwindkeit       :  km/h
Windböengeschwindkeit   :  km/h
max. Windböe            :  km/h
Windrichtung            :  °
Windrichtung            :
Luftdruck absolut       :  hPa
Luftdruck relativ       :  hPa
Regenrate               :  mm/h
Regenstatus             :
Regen seit Regenbeginn  :  mm
Regen Stunde            :  mm
Regen Tag               :  mm
Regen Woche             :  mm
Regen Monat             :  mm
Regen Jahr              :  mm
Regen Gesamt            :  mm
Sonnenstrahlung         :  W/m²
UV-Index                :
Zeitstempel             :
Firmware                :
Batteriestand:          :
Gateway-Modell          :

Zusatzsensoren: keine


Datenstring für ioBroker:



DATA von Wetterstation:



Debug VAR:
Installationsverzeichnis: /home/iobroker
IPP: 10.0.1.200:8087    WS_PORT: 1080           WS_POLL: 16             PRE_DP: javascript.0.Wetterstation
WEB: HTTP               WS_PROT: Wunderground   DP50/100: 0 | 0
Script-Version: V2.0.0  Config-Version: V2.0.0  Sub-Version: V2.0.0

Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?

[Negalein]

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

gehen

es steht zwar Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?,
aber die DP sind wieder aktuell!

[a200]

@Negalein ok. dein Cronjob steuert jetzt. Jetzt müssten alle 2 min deine Werte aktualisiert werden. Problem gelöst?!

Was für ein Updateintervall hast du in der WS-App stehen?

[Negalein]

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

ok. dein Cronjob steuert jetzt. Jetzt müssten alle 2 min deine Werte aktualisiert werden.

alle 30 Sek.

Problem gelöst?!

Ja, danke dir

Was für ein Updateintervall hast du in der WS-App stehen?

16 Sek.

[a200]

@Negalein dann viel Spaß noch. Und schön alle Probleme melden, denn nur so können wir die Skripte verbessern.

[sonystar]

@SBorg
Die Werte ändern sich auch täglich. Ich kann mir nur schwer vorstellen, dass zufälligerweise jeden Tag die aktuelle Monatsdurchschnittstemperatur immer der Durchschnittstemperatur vom Vortag entspricht.

[SBorg]

@sonystar Danke, jetzt habe ich es auch kapiert
Jepp, die müssen gleich sein. Nicht weil sie es sollen, sondern weil ich auf zwei unterschiedliche Arten das Gleiche berechne...
Immerhin komme ich auf das selbe Ergebnis

Aber Späßken beiseite, ich habe da eine "Kleinigkeit" übersehen. Die Monatswerte zur Berechnung sind in Wirklichkeit nur die Vortageswerte. Deswegen müssen zumindest beide Berechnungen identisch sein. Leider ist es letztendlich dann doch keine Kleinigkeit, aber ich denke schon eine Lösung dafür parat zu haben. Denn jeden Tag zig tausend Datensätze abzugrasen macht nur auf einem performanten System Spaß: mein 16GB, 3.4GHz Quadcore vs. 3er PI = 5 Sekunden zu ~ 2 Minuten Verarbeitungszeit...

[sonystar]

@SBorg Kann man dafür nicht mit einem temporären Datenpunkt arbeiten? Jeden Tag wird die Durchschnittstemp des Vortages in einem Datenpunkt hinzuaddiert. Diesen temporären Datenpunkt dann einfach durch die aktuelle Tageszahl im Monat teilen = aktuelle Durchschnittstemp im Monat.

Aber so einfach wie ich es mir vorstelle ist es wahrscheinlich nicht.

[SBorg]

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

Kann man dafür nicht mit einem temporären Datenpunkt arbeiten?

Könnte man, ist aber nicht mal nötig
Die Berechnung des Tagesdurchschnittes bleibt gleich, denn der funktioniert: alle Werte des Tages addieren und durch die Anzahl teilen.
Meistens (wie auch in diesem JS) nutzt man nur den "state" (=Wert )eines Objekts. Das Zauberwort ist hier Objekts, denn das enthält wesentlich mehr als nur den Wert. ZB. "die letzte Änderung", "die letzte Aktualisierung", "Maßeinheit" ... und auch den "vorherigen Wert". Ich muss also nur den vorherigen Wert (=Vorvortag) + aktuellen Wert (=Vortag) addieren und durch 2 Teilen = korrekter Monatsdurchschnitt

[sonystar]

@SBorg

Also das verstehe ich nicht. Wenn ich deinen Beitrag richtig verstanden habe meinst du diese Rechnung:

Korrekter Monatsdurchschnitt wären hier 4,67. Nach deiner Rechnung komme ich dann aber nur auf 4,275.

[SBorg]

@sonystar Gut nochmal darüber gesprochen zu haben
Deine Beispielrechnung "meiner" Berechnungsmethode stimmt so aber auch nicht (ergäbe ~4.4°)

Beispielreihe: 2, 4, 6
Mittelwert: (2+4+6)/3 = 4
"Meine_was_auch_immer": (2+4)/2 = 3; (3+6)/2 = 4.5 [also +0.5 Differenz zum Mittelwert]

Interessant wenn man nun die Beispielreihe ändert: 6, 4, 2
Mittelwert: (6+4+2)/3 = 4
"Meine_was_auch_immer": (6+4)/2 = 5; (5+2)/2 = 3.5 [also -0.5 Differenz zum Mittelwert]

In Relation zum Mittelwert ergibt dies also eher eine Trendberechnung.
Bleibt also leider doch nur der Umweg über einen Hilfsdatenpunkt der die bisherigen Tagesdurchschnitte des Monats enthält...
...auch nicht einfacher wäre wohl die Tagesdurchschnitte per History/Influx für x Tage zu loggen und diese auszuwerten.
Muss ich mir noch mal in Ruhe überlegen.

[Latzi]

@SBorg
das Geheimnis ist der gewichtete Mittelwert, man benötigt die Anzahl der Tage aus der der bisherige Mittelwert berechnet wurde.
Zu deinem Beispiel:
Mittelwert aus 2 + 4 = 3, somit nun Anzahl 2 im Mittelwert
Mit (3.2+6.1)/3=4 stimmt der Mittelwert und das gilt auch bei 6, 4, 2:
(6.1+4.1)/2=5
(5.2+2.1)/3=4!
Also benötigt man "nur" die Anzahl der Tage aus die der vergangene Mittelwert besteht und alles ist gut
PS: Der "." soll das Multiplikationszeichen darstellen

[SBorg]

@Latzi Komplizierter würde es ja nie werden, da ich ja immer nur mit 2 Werten rechne. Der 1. wäre dann ja bereits vom Vortag korrekt berechnet, den 2. habe ich aktuell ermittelt, bleibt also: (2*bisheriger Wert + aktueller Wert)/3 = neuer aktueller Durchschnitt

*EDIT* Ok, verstanden, geht auch nicht ohne Anzahl der bisherigen Werte (die wir im Grunde nicht haben )

[Latzi]

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

bleibt also: (2*bisheriger Wert + aktueller Wert)/3 = neuer aktueller Durchschnitt

Nicht ganz.

Gedankenexperiment:
9 Tage lang 0°C, danach 1 Tag 10°C

Nach deiner Rechnung wäre der Mittelwert nach dem 10°C Tag = (0 +10)/3 = 3,33°C, tatsächlich aber 1°C

[SBorg]

@Latzi Nö (ich hatte es oben kurz danach noch editiert)
(0*9+10)/10 = 1°C
Ich nehme jetzt einfach kurzerhand als Anzahl den Monatstag. Stimmt zwar nicht wenn einer bspw. heute nur 18 Werte hatte oder später im Monat anfing, aber im Grunde kann er auch nie bei fehlenden Werten richtig sein. Wie aussagefähig soll der Wert sein wenn man zB. nur 15 Werte des Monats hat? Dann stimmt natürlich die Berechnung überhaupt nicht, aber selbst bei korrekter Berechnung wären es nach wie vor nur die Daten eines halben Monats, die bestimmt wenig mit den echten Werten zu tun hat...

[sonystar]

@SBorg
Könnte man da nicht einfach täglich einen Zähler um 1 erhöhen? Das wäre dann unabhängig von der Tageszahl im Monat.

[sonystar]

@SBorg Wenn du dann eh nochmal am Statistikscript arbeitest, könntest du da noch die max. Windböe und max. Regenmenge pro Tag/Monat in die Jahreswerte und Rokordwerte ergänzen? Die Eistage, Frosttage usw. für das ganze Jahr wären bestimmt auch interessant.

[SBorg]

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

@SBorg
Könnte man da nicht einfach täglich einen Zähler um 1 erhöhen? Das wäre dann unabhängig von der Tageszahl im Monat.

Jein, denn das löst das Hauptproblem nicht. Den Zähler müsste ich auch "überwachen" (wenn Skript nicht läuft, wenn es mehrmals am Tage gestartet wurde trotzdem nur 1x zählen, wenn es zum Monats-Reset nicht läuft...).
Es gibt aber nur zwei Möglichkeiten:

1. du hast alle Tage bis heute (21.) {ggf. fehlen mittendrin mal paar Messwerte, macht den Bock aber nicht fett}
2. dir fehlt ein- oder mehrere Tage

Bei 1. addiere ich also deine 21 Tagesdurchschnittswerte und teile sie durch den Monatstag 21 = korrekter Monatsdurchschnitt
Bei 2. addiere ich also deine 20 (weil dir ein ganzer! Tag fehlt) Tagesdurchschnittswerte und teile sie durch den Monatstag 21 = nicht korrekter Monatsdurchschnitt

Aber "mal Butter bei de Fisch". Der 2. Fall ist zwar falsch berechnet, aber selbst wenn ich nun korrekt durch 20 teilen würde, stimmt der Monatsdurchschnitt doch sowieso immer noch nicht, denn dir fehlen die Messwerte eines ganzen Tages.
Was nutzt es brav die monatlichen Ausgaben täglich mit 10€ zu notieren, dann aber ggf. genau den Tag auszulassen an dem du für 80€ tanken warst? Sprich, egal wie ich im obigen Beispiel bei Fall #2 teile, es wird nie stimmen

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

...bestimmt auch interessant.

Bestimmt, dann müsste mir aber auch noch wer mehr Zeit spendieren. Da sieht es auf absehbare Zeit düster aus.

[SBorg]

Mini-Weihnachtsgeschenk :

Neue Version des Wetterstation-Statistik-Addons auf GitHub V0.1.3B_05

• ~ Fix für Jahres- und Monats-Durchschnittstemperatur

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

Da es allerdings auf den Vorwerten basiert, stimmt zwar die Berechnung, nur wird der Wert falsch sein. Korrekt sollte es dann ab dem 01.01.2021 laufen.

Falls wir uns nicht mehr "sehen": Frohes Fest euch allen und euren Liebsten