[Linux Shell-Skript] WLAN-Wetterstation

[Langer]

@SBorg

Guten Morgen,

in der Wetter Statistik sind mir 2 Sachen aufgefallen, die ich nicht verstehe.

Vorweg, bin absoluter Neuling und daher weiß ich nicht ob ich da falsch liege!!

Rekordwerte.value.Regenmengemonat ist kleiner als Jahreswerte.Regenmengemonat
Rekordwerte.value.Regenmengemonat = 177.8 l/m²
Jahreswerte.Regenmengemonat = 253.2 l/m²

Jahreswerte.Gradtage_warmeTage = 25 Tage
Jahreswerte.Gradtage_Sommertage = 20 Tage
Jahreswerte.Gradtage_heisseTage = 6 Tage

muss dann Jahreswerte.Gradtage_warmeTage = 25 Tage nicht 26 Tage sein?
Meine Frage:

Wäre diese Darstellung nicht besser:
warmeTage = 6
Sommertage = 14
heisseTage = 6

Weil heisser Tag immer die Temperatur 20°C und 25°C enthält
und ein Sommertag immer 20°C enthält.

Habe die im Skript bei mir geändert und es funktioniert.

Dann noch folgendes:

Bei Data Monatsstatistik ist:

{"Tiefstwert":4.27,"Hoechstwert":33,"Temp_Durchschnitt":18.11,"Max_Windboe":38.46,"Max_Regenmenge":75.4,"Regenmenge_Monat":253.2,"warme_Tage":26,"Sommertage":12,"heisse_Tage":6,"Frost_Tage":0,"kalte_Tage":0,"Eistage":0,"sehr_kalte_Tage":0}

Wunsch:

{"Tiefstwert":4.27,“Tiefswert_Datum“:02062021,"Hoechstwert":33,“Hoechstwert_Datum“:20062021,"Temp_Durchschnitt":18.11,"Max_Windboe":38.46,“Max_Windboe_Datum“:30062021,"Max_Regenmenge":75.4,“Max_Regenmenge_Datum“:30062021,"Regenmenge_Monat":253.2,"warme_Tage":14,"Sommertage":6,"heisse_Tage":6,"Frost_Tage":0,"kalte_Tage":0,"Eistage":0,"sehr_kalte_Tage":0}

Bei Jahreswerte
Regenmengemonat
Regenmengetag
Temperatur Hoechstwert
Temperatur Tiefstwert
Trockenperiode
Windboe_Max
Jeweils das Datum mit ausgeben

aktueller_Monat den Tag bzw. Datum anhängen
wie bei Jahreswerte

Sollten meine Gedanken nicht machbar oder falsch sein "SORRY".

MfG
Wastl

[SBorg]

@langer Sorry, dauert bei mir im Moment einfach, null-komma-überhaupt-keine-Zeit...

Also...
#1: kann ich so nicht nachvollziehen, ist bei mir identisch. Anhand der Regenmenge hast du wohl auch schon einen Monatswechsel hinter dir (einiges wird nur am 01. des Monats berechnet)? Außer dass er ev. mal hängen geblieben ist fällt mir wenig dazu ein.

#2: Jepp, ist ein Fehler. Da ich es selbst nicht aktiv nutze wohl bisher noch keinem aufgefallen.
Die Darstellung wurde so eingangs von den Nutzern gewünscht, wobei ich allerdings hier auch für die Logik bin, dass bspw. ein heißer Tag auch immer ein Sommertag bzw. warmer Tag ist/war. Wer aber zB. nicht im JS (wg. Updates, fehlender Kenntnisse etc.) direkt ändern möchte, kann sich ja auch ein Blockly erstellen mit neuen DPs erstellen. Sind ja nur 2 Subtraktionen. Bei anderen Meinungen gerne Feedback. Wäre ja nicht so, dass es in Stein gemeißelt ist

...und hier darf jeder frei seine Gedanken, Ideen, Vorschläge, Kritik und Meinungen äußern, ich nehme nichts krumm oder persönlich, auch wenn der ein oder andere da zwischen den Zeilen etwas andere herausließt.

Deswegen von meiner Seite nur ein freundliches "Nein" zur allgemeinen Datumsthematik (zB. Data Monatsstatistik), weil das dann doppelt wäre. Jeder (also nicht nur auf dieses Projekt bezogen) Datenpunkt enthält immer zwei Timestamps: den sog. TS und LC. TS ist wann er das letzte mal aktualisiert wurde, LC wann der Wert sich das letzte mal änderte.
Wenn du also beim Monat zB. einen Tiefstwert von x.xx°C hast, zeigt der LC von alleine auf das Datum wann er geändert wurde.
Außer du willst natürlich mit den JSONs etwas anderes anstellen. Eigentlich sind die nur dazu da, dass ich jetzt aktuell Juli 2020 schnell einlesen kann, dann die Vorjahresmonatswerte anzeigen lassen kann und nicht jedes mal eine kpl. Auswertung des Monats durchführen muss (dauert auf einem PI bis zu 2 Minuten).

[Negalein]

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

Die Darstellung wurde so eingangs von den Nutzern gewünscht, wobei ich allerdings hier auch für die Logik bin, dass bspw. ein heißer Tag auch immer ein Sommertag bzw. warmer Tag ist/war.

Jep, war ich

wenn ein heißer Tag auch ein Sommertag bzw. warmer Tag ist, dann hat in der Statistik plötzlich der Monat 50 und mehr Tage.
ein heißer Tag würde dann zB 3x gerechnet werden.
ein Sommertag zB 2x

[Langer]

@sborg

Als erstes vielen Dank für die Antwort, trotz Deiner knapp bemessenen Zeit.

Ich bin und war in mehreren Foren, aber selten so ein super Forum gefunden wie hier, nochmals an allen meine herzlichen Dank!!!
Gerade für Neulinge ist es super, Fragen stellen zu können und zu 95% eine Antwort zu bekommen, ohne sich bei der Antwort blöde vorzukommen.

Wie Du gelesen hast, bin ich Neuling, daher meine Frage:

Was ist bitte "TS" und "LC" und wie bekomme ich diese Werte zu dem Datenpunkt??

Vorab vielen Dank für Deine Antwort.

MfG
Wastl

[SBorg]

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

Jep, war ich

So dunkel hatte ich es noch in Erinnerung, wollte nur niemand fälschlich bezichtigen (oder heißt das züchtigen..?!)

[SBorg]

@langer Leider hat es meine SSD mit allem zerbröselt und die Backups, naja...
Ein Großteil von 1.5 Jahren Arbeit sind nu wech...

Den TS und LC siehst du bspw. direkt in den Objekten (nicht an irgendwelchen Daten orientieren, mein Sys läuft nicht korrekt):

Wenn du dann bspw. in der VIS ein Widget nimmst

sieht es dann so aus:

Die Timestamps kann man dabei mit allem abfragen, wie obiges Beispiel in der VIS, per Javascript, Blockly, Binding, Node-RED...

Im Skript kann man die Funktion auch gelegentlich finden (".lc" damit wird die letzte Änderung des Datenpunkts ermittelt):

...new Date(getState(PRE_DP+'.Rekordwerte.value.'+DatenPunkt).lc).getFullYear());

[Langer]

@sborg

Danke für Deine schnelle Antwort.

Wenn ich mit der Maus über einen Datenpunkt stehe, sehe zB. "Zeitstempel 20.06.2021 01:03:001" und "Letzte Änderung 20.06.2021 01:03:001".

Das heißt doch, um den Tag des Ereignisses zu finden muß ich
...new Date(getState(PRE_DP+'.Rekordwerte.value.'+DatenPunkt).lc).getFullYear());
minus 1 Tag machen?

Danke nochmals.

MfG
Wastl

[SBorg]

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

Das heißt doch, um den Tag des Ereignisses zu finden muß ich
...new Date(getState(PRE_DP+'.Rekordwerte.value.'+DatenPunkt).lc).getFullYear());
minus 1 Tag machen?

Im Grunde ja, nur etwas anders als du wahrscheinlich gerade denkst?
".getFullYear()" ermittelt aus dem Datums-Objekt das vierstellige Jahr, mehr nicht.
Man muss auch nicht unbedingt einen Tag abziehen, es würden (wenn das Skript um 1:03 Uhr läuft) auch 63 Minuten genügen.
Timestamps (wie auch bei Unix) sind immer Sekunden seit dem 01.01.1970
Um also das Datum korrekt zu berechnen, sähe es so aus:

let Datum_xyz=new Date((getState(hier_Pfad_und_Datenpunktname).lc)-86400);

86400 = 60sek * 60min * 24h (oder eben ein Tag )

[Langer]

@sborg

Danke.
Werde mal damit arbeiten und versuchen eine Wetter-Statistik in VIS erstellen.

MfG
Wastl

[Negalein]

@SBorg

seit Admin 5 und JS-Controller 3.3.14 hab ich ua. diese Meldung im Log.

simple-api.0 2021-07-08 22:27:02.447	info	State value to set for "javascript.0.Wetterstation.Info.Hitzeindex" has to be type "number" but received type "string"

Liegt das am Script, am Simple-Api oder am Script-Adapter?
Weißt du das?

[SBorg]

@negalein Ist mitunter der JSC 3.3.x
Beim "Hitzeindex" gibt es entweder eine Zahl oder "Null" ("nichts"). Dabei wird anscheinend "Nichts" als String missinterpretiert und da meckert der neue JSC.
Stell mal beim Objekt den Zustandstyp auf gemischt um, sollte es eigentlich beheben:

[da_Woody]

@sborg danke für den tip! hat mich auch schon länger genervt... ab 20° ja kein prob, aber mit (null) nervig.

[SBorg]

Für Docker-Anwender gibt es nun Dank des GitHub-Users "dan1-de" eine Kurzanleitung zur Installation unter Docker mit passendem Composer-File

[SBorg]

Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.7.0

• + Bei bereits eingetragenem OSEM-User erfolgt Abbruch der OSEM-Registrierung
• + Unterstützung für DP250/WH45 Sensor

Wie immer zu finden im GitHub

Wegen der neuen Datenpunkte des DP250-/WH45-Sensors muss auch wetterstation.js ersetzt und einmalig ausgeführt werden.
Wie üblich wetterstation.sh und -.sub austauschen, ws-updater.sh ausführen (ggf. neuen Sensor eintragen) und mittels sudo systemctl restart wetterstation den Service neu starten

[Rand]

@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:

Wegen der neuen Datenpunkte des DP250-/WH45-Sensors muss auch wetterstation.js ersetzt und einmalig ausgeführt werden.

Super, danke, probiere ich.

Dazu ne Frage - hab letztens festgestellt das irgendwann um das letzte Update mein Jahres-Regenmengen-Datenpunkt in der DB auf 0 zurück gesetzt wurde...
kann das durch das Ausführen des .js passiert sein ?

[SBorg]

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

kann das durch das Ausführen des .js passiert sein ?

Nein.

Vielleicht mal wieder kurz was was eigentlich macht (für alle zum Verständnis, schließlich ließt wohl keiner bald 2.800 Post'):

• ws-updater.sh
  • füht nur Änderungen in der wetterstation.conf durch die bei Versionswechsel nötig sind.
  • Einstellungen werden dabei keine verändert
• wetterstation.js
  • legt lediglich im ioB die nötigen Datenpunkte an (um den Usern das händische [und fehleranfällige] Anlegen zu ersparen.)
  • Werte werden nicht verändert.
  • Es werden nur neue DPs angelegt, bestehende werden übersprungen (ist beim Javascript-Controller Standard so)

---

Für den Betrieb wird nur die wetterstation.sh, -.sub und -.conf benötigt.

---

GitHub:
firmware.version : enthält die aktuelle Version der EasyWeather-Firmware. Wird nur vom Statistik-Addon benutzt, um festzustellen ob es ggf. eine neue Version gibt (sofern im Skript aktiviert)

Als Zusatz "AddOn" schließlich noch wetterstation-statistik.js
Führt Auswertungen durch und legt eine Statistik an.

---

@Rand Zu deiner Eingangsfrage und meinem "Nein". Nur das Statistik-Skript setzt von sich aus Werte auf "0". Bei der Jahresregenmenge sollte das aber nur am 01.01. passieren, sofern du es überhaupt nutzt und auch nur die "kumulierte", denn die berechnet das Shell-Skript. Die, falls es deine Station kann, von der Station übertragene ist kpl. außen vor. Die nehme ich so wie sie von der Station kommt und "reiche" sie an den ioB durch, wie fast alle anderen Werte auch. "fast" weil bei einigen Werten noch eine Konvertierung stattfindet: F --> °C, mph --> km/h usw.
Ganz pauschal kann es also nichts mit einem reinen Update zu tun haben. Sollte natürlich trotzdem nicht sein. Da es aber anscheinend auch nur ein Einzelfehler (wie @Negalein 's -5.000 °C Temperaturproblem) ist, kann ich eigentlich ein prinzipielles Problem auch ausschließen. Da es bei dir wohl auch nicht regelmäßig auftritt wird das kaum zu finden/fixen sein (falls es von der Station kam kann ich eh nix mehr machen).
Wenn es die "kumulierte" ist: einfach den vorherigen Wert wieder eintragen. Das Shell-Skript ließt den dann wieder ein und addiert dann wieder neue Regenmengen dazu

[Rand]

@sborg

Super danke, dann lasse ich mal das Beta update laufen und schaue was passiert.

Der fehlerhafte Wert war der berechnete, nicht der aus der Station... hatte es in Influx korrigiert (über Export, drop, import), aber hab natürlich den IOBroker Wert nicht korrigiert

Jetzt ist wahrscheinlich Kraut und Rüben... im Augenblick zeigt er nur noch Tag/Woche im Grafana an... irgendwas ist wieder schief ...

seufz

Hm, jetzt wollte ich den Wert einfach im DP aktualisieren, aber das scheint ihm gar nicht zu gefallen?

Er übernimmt den Wert den ich gesetzt hab (374.3) nicht und markiert es lila - was sagt mir das?

Edit - scheinbar habe ich das Statistik Skript beim letzten mal nicht aktualisiert, es läuft noch 2.1 statt 2.2...
Hab ich jetzt mal aktualisiert...
Scheinbar sind aber nur sehr spärlich Daten in Grafana gelandet (i.e. diese Woche für Monat/Jahr nicht nichts, weswegen er natürlich mit last() für Tag oder Woche nichts anzeigen kann...
Inzwischen hat er auch den gesetzten DP für den Jahreswert übernommen, dann war Lila wohl für "noch nicht weggeschrieben" osä

Der DP250 sieht gut aus auf den ersten Blick,

Edit2 - jetzt hat sich das Problem mit dem kumulierten Jahreswert auch erledigt...
Hatte in der Influx einmal "javascript.0.Wetterstation.Regen_Jahr_kumuliert" und einmal javascript.0.Wetterstation.Regen_Jahr_kumuliert... (von meinen export import Versuchen)
Jetzt wollte ich "javascript.0.Wetterstation.Regen_Jahr_kumuliert" löschen weil es nervt, aber
drop SERIES from "javascript.0.Wetterstation.Regen_Jahr_kumuliert" hat die Series ohne "" gedroppt
Für die Series mit "" muss man drop SERIES from ""javascript.0.Wetterstation.Regen_Jahr_kumuliert"" nehmen... was ein $%/$§.

Zum Glück hatte ich die meisten Werte noch vom Export von letzter Woche (und am Ende ist ja der Jahreswert interessant, und der ist ja auch noch in der Station, aber trotzdem irgendwie nervig:( )

[Negalein]

@sborg

Hitzeindex ist seit gestern Vormittag leer
Die neueste Version läuft noch nicht .

[SBorg]

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

Inzwischen hat er auch den gesetzten DP für den Jahreswert übernommen, dann war Lila wohl für "noch nicht weggeschrieben" osä

Jepp. Da ich beim SimpleAPI-Adapter beim "Bulk-Update" (=schreiben mehrerer Werte gleichzeitig) kein ACK-Flag setzen kann/darf, sind die Werte "rot" (=unbestätigt). Erwischt man dann beim händischen setzen genau den falschen Augenblick (z.B. wenn der SimpleAPI auch gerade den Wert schreiben will), weiß der ioB nun nicht welcher Wert der richtige ist...

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

Der DP250 sieht gut aus auf den ersten Blick

...auch auf den 2.
Noch ein kleiner Fehler, ist auf GitHub bereits gefixt: stell noch in den Objekten beim PM25_24 die Rolle von "state" auf "value" um. Auswirkungen hat das so erst mal keine, ist nur syntaktisch einfach falsch (alle alten laufen eh noch auf "state").

Das droppen in Influx wird unter 2.0 einfacher, dann hat Influx eine GUI. Ich habe damit aber auch noch nicht getestet. so von wegen meiner defekten SSD + eh noch genügend Arbeit und der Influx-Adapter für 2.0 ist auch noch sehr rudimentär. For ME aktuell zu viele Baustellen

[SBorg]

@negalein Nö, funktioniert:

Ev. vergessen, dass er erst bei >20°C erzeugt wird ?
Lt. deinem Screeny "erzwingst" du alle 15 Minuten das Schreiben des Wertes:
06:12 Uhr
06:27 Uhr
....
09:21 Uhr (bis jetzt einfach <20°C + alle Werte im 15 Minutenraster)
09:22 Uhr dann 20.96°C (also genau nur eine Minute später und jetzt über 20°C = Index wird berechnet)
09:22:4x Uhr (~30 Sekunden später neuer Messwert der Station) Hitze-Index nun 21.1x°C

Sieht man auch an der Quelle ob "inlux" oder "simple-api". Bis 09:22 Uhr kam vom Skript nichts (Quelle: "erzwungener" Influx), da es einfach nicht über 20°C warm war. Danach (Quelle: simple-api") schickt das Skript den errechneten Index.