[Linux Shell-Skript] WLAN-Wetterstation
-
@Negalein Zuerst das übliche, ich bin weder Meteorologe, noch Statistiker, oder Informatiker...
Einiges habe ich belesen (so wie die Definition mit >120W/m² beim Sonnenschein) und einiges so wie ich es mir denke
Bei der Trockenperiode habe ich definiert, dass dies mal mindestens 2 Tage sein müssen. Ein Tag klingt bei mir irgendwie noch nicht nach einer Periode? Ev. liege ich ja auch falsch
Da die Statistik (auch aus Performance gründen) nur einmal am Tag ausgeführt wird, darf es also jetzt genau 2 Tage lang von Mitternacht (hier greift die Statistik, nicht der Ausführungszeitpunkt [default 1:03 Uhr] ist maßgeblich) bis Mitternacht keinen Regenpuls geben.
Ermittelt wird es hieraus:
Der muss also bei dir mindestens 2 Tage alt sein, damit auch mal ein Rekordwert angezeigt wird.
...und wie man hier gerade schön bei mir sieht: trotz strahlend blauem Himmel, keine einzige Wolke und Sonnenschein hat es mir eben die Periode zersemmelt. Der Trichter ist abgetaut und hat genau einen Puls ausgelöst
Das ließe sich jetzt nur durch einen echten, beheizten Regensenor vermeiden, denn der erkennt effizient Regen. Baue ich jetzt im Skript irgendeine Schwelle ein um das abzufangen, geht ev. ein Nieselregen wieder unter... -
@a200 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
aber sind die Angaben bei 0_userdata.0.Statistik.Wetter.Rekordwerte.Temperatur_Spitzentiefstwert korrekt?
Ich würde mal sagen ja. Kann ich dir aber morgen beantworten, denn heute Nacht waren es bei mir -6°C als neuer Tiefstwert.
Ich sehe im Diagramm leider so keine Uhrzeit, aber der neue Spitzenwert muss vor Mitternacht sein, denn nur bis dahin wird ausgewertet, nicht bis zur Laufzeit des JS (per default um 1:03 Uhr). War also der neue Spitzenwert bspw. um 0:33 Uhr, wird er erst morgen angezeigt, auch wenn das JS um 1:03 Uhr lief. -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Der muss also bei dir mindestens 2 Tage alt sein, damit auch mal ein Rekordwert angezeigt wird.
Da haben wir das Problem. Es zeigt den 3. 1. 2021 an.
Da müsste die Trockenperiode schon greifen.
-
Es wird auch eine Änderung geben müssen. Als ich wg. einer Neuerung beim googeln auf einen Fehler stieß. Die Bezeichnung "Chillfaktor" ist falsch, korrekt müsste es "gefühlte Temperatur" heißen. Könnte man jetzt einfach in Grafana etc. ändern...
Noppe, denn ich möchte noch den "echten" Chillfaktor und Hitzewelle haben. Das würde dann kollidieren
Ferner, soweit performant umsetzbar, soll das WLAN-Skript auch noch die min/max - Temperatur der letzten 24h liefern, also nicht "Gestern", sondern wirklich "JETZT minus 24 Stunden". -
@Negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Da haben wir das Problem. Es zeigt den 3. 1. 2021 an.
Da müsste die Trockenperiode schon greifen.Im Grunde ja, aber bis V0.1.? lief die Trockenperiode leider gar nicht mehr. Erst mit Update auf V0.1.9 (oder war es die 8er? Jedenfalls erst seit paar Tagen, zumindest später als der 03.01. bei dir) funktioniert das wieder korrekt, aber leider wie immer nicht rückwirkend.
So allmählich verliere ich auch den Überblick über die Änderungen in den Versionen bzgl. Skript, JS...
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
zumindest später als der 03.01. bei dir) funktioniert das wieder korrekt
Ah, ok! Dann ist das klar.
-
Darf ich mich auch reinhängen. Ich hab vor einigen Tagen die Version 2.1.0 eingebaut und nebenbei auch die schöne Vis ans laufen gebracht. Jetzt fällt mir bei näherer Betrachtung auf, dass verschiedene Datenpunkte nicht gefüllt werden. So z.B. Solarenergie_Monat -da steht nur die Maßeinheit- oder Sonnenschein_Jahr -hier steht 'write Sek.'. Hab ich da Bockmist gebaut?
LG Rainer -
Irgendwas stimmt hier nicht. 19,1 mm aus Station und 18,6mm aus dem Script.
Nein, heute hat es nicht geregnet.
Am 02.01.2021 stimmen beide Werte noch überein mit 1,4mm
Am 05.01.2021 sagt das Script 4,1mm, die Station 4,2mm
Am 06.01.2021 sagt das Script 9,5mm, die Station 9,7mm
Am 07.01.2021 sagt das Script 16,7mm, die Station 16,9mm
Am 09.01.2021 sagt das Script 17,4mm, die Station 17,8mm
Am 10.01.2021 sagt das Script 17,9mm, die Station 18,2mm
Am 11.01.2021 sagt das Script 18,6mm, die Station 19,1mm -
Heute sagt das Script 19,3 mm und die Station 19,1 mm.
-
@rene55 Meinst du jetzt direkt bei den Datenpunkten oder in der VIS?
-
@SBorg schon direkt in den Datenpunkten. Die VIS ist dann eine spätere Baustelle.
-
@sonystar und @a200
Ich mache es mal direkt in einem Post, da dass Bild für alle Probleme passt:
@a200 Der Rekordwert funktioniert, zumindest fast. Mein neuer Tiefstwert wurde korrekt eingetragen, nur der Zusatz "für 2020" ist falsch. Der sollte, unabhängig vom falschen Jahr, an der Stelle nicht auftauchen und müsste "im Januar 2021" lauten. Muss ich mal schauen...
@sonystar Ich weiß nicht wie das Display rechnet, zumindest hat es nur eine Nachkommastelle. Je nachdem wie die runden (auf, ab, korrekt, gar nicht, einfach eine Stelle abschneiden) kommt es hier immer zu Differenzen. An der Stelle addiere ich einfach Zahlen mit zwei Nachkommastellen, kein Hexenwerk und kann man eigentlich nicht viel falsch machen (siehe zB. dein erstes Pic: 19mm von der Station, die Einzelwerte von mir aufaddiert aber schon 19.1mm).
...und wie man gerade sieht, zickt auch stellenweise Javascript herum. Ich habe jetzt zwar nicht die Nullen gezählt, aber ich rechne oder bekomme bestimmt keine Angabe in femto, atto oder pico Litern. Muss ich also auch zwangsweise auf 2 Stellen kürzen...
Fazit: du wirst nie eine 100% Übereinstimmung von Station, WLAN-Skript und Statistik (die sowieso nicht wg. anderer Vorraussetzungen) erreichen können, außer alle hätten die gleichen Grundvoraussetzungen.Aber ganz allgemein: ich kann auch nicht all zu viel von einer Hobbystation im Preissegment <500,- € erwarten, zumal schon bei der Temperatur stellenweise eine Differenz von +/- 1°C, oder an anderer Stelle eine Drift von 5% . Ein "echter" Sensor kostet ein mehrfaches dessen. Da brauche ich mir offen gestanden auch keinerlei Gedanken mehr um Rundungsdifferenzen zu machen. Ich werde auch bestimmt nicht aus 5.4 + 4.6 etwas anderes als 10.0 machen, bloß weil China aus Kostengründen durch abschneiden (ist halt einfacher als eine Datenbank in der Elektronik zu führen) irgendwas daraus macht
...was aber nicht heißen soll offensichtliche Programmfehler nicht zu fixen -
Hallo, ich habe nach wie vor keine Daten bei der Sonnenscheindauer in Grafana und zusätzlich den Fehler not Executed". Im IOBroker habe ich mittlerweile Daten bei der Sonnenscheindauer.
Ich habe auch keine Daten Daten bei Temp. min. max. und seit neuestem auch keine Daten beim Niederschlag.
Ich habe das Update auf 2.1.0 gemacht und das Dashboard neu installiert. Leider keine Änderung.
Hast Du da eine Idee?
Danke!!
-
@rene55 said in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg schon direkt in den Datenpunkten. Die VIS ist dann eine spätere Baustelle.
Zwei Dinge:
- welche Station hast du genau?
- stoppe bitte mal (
sudo systemctl stop wetterstation) und poste dann bitte die Ausgabe von./wetterstation.sh --debugausgeführt im Installationsverzeichnis
-
@keksn said in [Linux Shell-Skript] WLAN-Wetterstation:
Hallo, ich habe nach wie vor keine Daten bei der Sonnenscheindauer in Grafana und zusätzlich den Fehler not Executed". Im IOBroker habe ich mittlerweile Daten bei der Sonnenscheindauer.
Ich habe auch keine Daten Daten bei Temp. min. max. und seit neuestem auch keine Daten beim Niederschlag.Temp min/max funktioniert nur wenn auch das Statistik-Addon läuft/benutzt wird, da die Station diese Werte nicht liefert.
Allgemeines Influx-/Grafana-Problem bei fehlenden Werten (gerade wenn man ganz "frisch/neu" anfängt: wenn man mittels des Javascripts die Objekte (oder DPs) angelegt hat, werden diese Initial mit Werten (meist "0") befüllt. Erst nach dem Anlegen kann ich jetzt aber auch das Influx-Logging aktivieren. Problem dabei, falls man "log changes only" aktiviert (was man aus Performance-/Platzgründen aber machen sollte), wird erst mit einer Änderung des Wertes (also ungleich "0" bei einem DP der mit "0" befüllt ist) das Logging gestartet. Vorher hat Influx nicht mal die Serie angelegt. Um auch spätere Lücken in Grafana zu vermeiden, sollte man immer ein Turnusmäßiges Schreiben erzwingen. Bspw. "3600" als Eintrag bei "log changes interval" erzwingt alle 3.600 Sekunden (= 1 Stunde
) unabhängig davon ob sich der Wert geändert hat, den aktuellen Wert in die Influx zu schreiben.
Weiterer Knackpunkt ist hier die Option "Automatic" (leider Default-Einstellung) bei speichern als. Oftmals wird dann eine Zahl (number) als Zeichenkette (string) missinterpretiert und die ganze Serie als String angelegt. Damit kommt Grafana später nicht mehr zu Recht. Hier hilft nur im Influx nachschauen ob die entsprechende Serie als "String" angelegt wurde. Falls ja, muss man dann zuerst im ioB auf "Zahl" umstellen und dann leider die gesamte Serie in Influx droppen. Nachträglich kann man eine Datenreihe in Influx nicht mehr von String --> Zahl konvertieren/ändern. -
@sborg
Ich habe eine Froggit WH3000 SE. Das Javascript läuft in einem Docker-Container. Dummerweise reagiert 'systemctl stop' (mit und ohne sudo) bei mir nicht. -
@rene55 said in [Linux Shell-Skript] WLAN-Wetterstation:
systemctl stop
du gibst aber noch den Namen des Services der gestoppt werden soll, oser?
-
@a200 Ja natürlich. Das script heißt auch 'wetterstation.sh' - und läuft und läuft und läuft. Oder gibt es da noch einen Trick (=Wissenslücke) für mich? Ich arbeite im Portainer und als Fehlermeldung bekomme ich:
bash: systemctl: command not found. -
@rene55 said in [Linux Shell-Skript] WLAN-Wetterstation:
systemctl
mit sudo davor? die Fehlermeldung besagt dass systemctl nicht gefunden werden kann.
-
@a200 Leider geht's auch damit nicht:
bash-5.0# sudo systemctl stop wetterstation bash: sudo: command not found.
