[Linux Shell-Skript] WLAN-Wetterstation

Glasfaser

ist ja gut ..... war mir nur aufgefallen

Dann wird mal Zeit ... ein Update zu machen ;)

SBorg

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

jedoch weiss ich nicht mehr wie man den Zeitraum angeben muss, früher ging da mal ein Fenster auf mit Kalenderauswahl, so wie bei Zeit,die Uhr

Ist mir eben erst beim probieren aufgefallen. Aber egal in welcher Schreibweise, ich bekomme immer die kpl. Liste angezeigt...

crunchip

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

immer die kpl. Liste angezeigt

aktuelle letzte Messung 10:44Uhr, blätter ich nach unten, geht es bis 10:20Uhr, aber nicht weiter
sobald ich irgendein Datum eingebe, egal in welchem Format, springt die Liste um 6Tage zurück(2020-06-11) , da kann ich dann den kompletten Tag blättern
6 Tage, da ich gestern das selbe probiert hatte(2020-06-10)

ich habe ein altes Youtube video gefunden, da war das noch so, aber auch in diesem Format funktioniert die Datumseingabe nicht

SBorg

@crunchip Ok, mit den 6 Tagen merk(t)e ich nicht, da ich diese Werte nur zwecks Backup für 3 Tage logge. Ist IMHO ein Bug, nur ist das Admin, JS-Controller...?
Bloß weil er Sep 05, 2018 dort anzeigt, heißt das leider nicht unbedingt das die Kalenderauswahl es auch so als Format "schickt". Wie schön sind doch Tooltips, aber eigentlich unnötig wenn man es per Kalender auswählen kann (oder auch nicht ;) ).
Aber leider auch keine Lösung für das ursächliche Problem, warum die Daten mehr oder minder willkürlich verschwinden.

crunchip

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

Aber leider auch keine Lösung für das ursächliche Problem

richtig, wäre trotzdem mal schön zu wissen, wie das funktionieren soll mit der Datumseingabe

Zum eigentlichen Problem kann ich mir nur "Netzwerkfehler" in irgendeiner Art und Weise vorstellen, da ich an meinem Netz/Wlan gebastelt hatte und die Station für ne gewisse Zeit nicht verbunden war.
Folge dessen, der "Berechnungsfehler" fehlende Daten, was auch immer.
Bin mir aber nicht mehr sicher, ob das genau zu dieser Zeit stattgefunden hat

SBorg

@crunchip Sollte trotzdem nicht sein, denn dafür speichere ich unter anderem auch die Werte in tempData ab. Es gibt eigentlich nur ein Szenario, dass der ioB/SimpleAPI genau dann beendet wird wenn das Skript seine Daten schreiben will. Das muss aber just in dem schreibenden Augenblick sein. Davor schreibt er es korrekt, danach kann er es nicht mehr schreiben, aber die vorherigen Werte stehen noch im Datenpunkt (man würde also genau ein Messintervall [oder eine Messwertreihe] verlieren). Diese Chance besteht aber. Wenn man daran denkt kann man den Service natürlich auch vorher sicherheitshalber per systemctl stop wetterstation anhalten. Sollte er trotzdem gerade schreiben wollen/schreibt gerade, führt er diesen noch korrekt vor Beendigung aus.

So "klein" ist die Abweichung der Sonnenscheindauer dann doch nicht. Gestern relativ schönes Wetter, heute stärker bewölkt:
Bild 1.png
...und das Stand 12:00 Uhr :kissing:
Ich warte heute noch mal ab, dann geht es voraussichtlich morgen auf GitHub und ist eigentlich sogar ready als 1.3 Release-Kandidat.

crunchip

@SBorg ja nur waren die Werte der tempData plötzlich leer
hab mir mal die history json(20200614) betrachtet, Sonnenschein und Solarenergie war der Wurm drin
Wetterdaten jedoch laufen/liefen aber korrekt weiter
irgendwie sieht das so aus, als wenn das zurücksetzen/berechnen nicht funktioniert hat

SBorg

@crunchip Ich kann dir zwar keine Lösung nennen, aber der Fehler scheint an deiner Umgebung zu liegen:

1592168453 = 14.06.2020 - 23:00:53
1592171910 = 14.06.2020 - 23:58:30

Das sind die Timestamps der zwei aufeinander folgenden LS. Da fehlt dir quasi eine Stunde, bzw. springt er einfach um 23:00 Uhr eine Stunde vor? Kein Wunder dass das Skript da "spinnt". Die LSs erzeugt aber dein ioB/System, nicht das Skript.
Ev. hast du ein Problem mit den Ländereinstellungen deines Systemes bzw. korrigiert dann der NTP (wenn du ihn nutzt) dann wieder die Systemuhr?

crunchip

@SBorg wäre ein Ansatz, jedoch, wenn das so wäre, müsste doch das Problem schon immer bestehen bzw hätte schon früher auftauchen müssen.

sollte eigentlich schon so passen

root@IoBroker:~# timedatectl
               Local time: Do 2020-06-18 13:23:08 CEST
           Universal time: Do 2020-06-18 11:23:08 UTC
                 RTC time: Do 2020-06-18 11:23:09
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

SBorg

@crunchip Stimmt und stimmt auch (leider ;) ). Nur will mir da nicht allzu viel einfallen. Selbst wenn ich jetzt extra Debug-Ausgaben einbaue, zeigen die auch nur den Sprung von 23:00 --> 23:58 Uhr, außer der History-Adapter hätte eine Stunde nichts geloggt und just in der Stunde ist auch das Skript "gestorben". Kannst du den Sprung ev. in anderen geloggten Zuständen nachvollziehen?

Wie schon gedacht, so gering war die Abweichung dann doch nicht:
Bild 1.png
(~5h waren bisher mein Spitzenwert, und der gestrige Solarertrag bescheinigt durchaus viele Wolken)

V1.3.0 Beta (RC) steht auf GitHub zum testen bereit

Für Nutzer der bisherigen 1.3.0 Beta genügt der Austausch der *.sub und ein systemctl restart wetterstation
Update von anderen Versionen kpl. Tausch, JS ausführen und *.conf konfigurieren.

Changelog:

# V1.3.0 / 19.06.2020 - + letztes Regenereignis und Regenmenge
#                       + Fehlermeldung bei falscher WS_ID / ID der Wetterstation
#                       + Sonnenscheindauer + Solarenergie vom Vortag
#                       ~ Änderung/Fix Sonnenscheindauer

crunchip

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

Kannst du den Sprung ev. in anderen geloggten Zuständen nachvollziehen?

ich logge nur die drei tempData Werte in der History, alles andere läuft in influx,
ansonsten ist mir auch nichts weiter aufgefallen

was ich nicht so ganz verstehe

Sonnenstunden zählte von 0 wieder los, für Heute/Woche/Monat/Jahr
Sonnenenergien zählte von 0 wieder los für Heute/Woche --- Monat und Jahr blieben aber leer

wer weiß was da los war, ...Verkettung eines unglücklich und ungünstig gefallenen Zufall´s
und dann kam noch Pech dazu....:face_with_rolling_eyes:
mal beobachten, zumindest wie es der Zufall so will, war es ein Wochenwechsel 14/15.06

Nashra

Moin, bei mir mit neuer 1.3.0 *.sub alles unauffällig

SBorg

@Nashra Danke für die Info :+1:
Die Nullstellung um Mitternacht funktioniert jetzt auch korrekt. Um 23:58 Uhr wurde zwar korrekt auf "0" resettet, dann hat er aber 2-3 Impulse gezählt und ab kurz nach Mitternacht dann ~1-3 Minuten Sonnenscheindauer attestiert... :upside_down_face:
...ja, macht den Bock jetzt auch nicht fett aber Fehler müssen auch nicht sein...

@crunchip Das ist zumindest in soweit einleuchtend, dass du alle Werte (Tag, Woche, Monat, Jahr) verloren hast. Da Tages- und Wochenwechsel an stand, wurden die korrekt auf "0" gesetzt und es kam zum Datensatz "0 0 [Nix/Leerzeichen] [Nix/Leerzeichen]". Wenn das Morgen (Wochenwechsel) ev. wieder auftritt, könnte es uU. ein Cronjob sein...

Ich warte jetzt noch 1-2 Tage ab, dann geht die 1.3.0 Beta (RC) als Release 8)

SBorg

Soeben die V1.3.0 auf GitHub released. Keine weiteren Änderungen seit V1.3.0 Beta (RC), Update also nicht unbedingt nötig falls man diese schon einsetzt.

Update von einer Vorgängerversion: alles ersetzen, JS ausführen (neue Datenpunkte), *.conf konfigurieren und mittels [sudo] systemctl restart wetterstation den Dienst neu starten.

Stormbringer

@SBorg Ich wollte es gerade mit einer froggit HP1000SE Pro probieren. Als Linux Device habe ich einen Intel NUC auf dem u. a. Deconz (Proxmo VM Debian) drauf läuft der es dann wieder zu einem anderen Intel Nuc wo der ioBroker (Proxmox VM Ubuntu) drauf läuft weitergeben sollte... Verbindung Deconz zu ioBroker hat eigentlich damals auf anhieb funktioniert.

Bei WU eingebunden ist die Wetterstation und zeigt auch brav die Werte an. Bei deiner Anleitung bin ich bis zu dem Ausführen im debug Modus gekommen.... Allerdings bringt er da in Endlosschleife nur:

Bildschirmfoto 2020-06-24 um 13.00.08.png

Ports habe ich schon 80, 9999 1026 ect. probiert... Leider ohne Erfolg.

Hast du vielleicht eine Ahnung woran das liegen könnte?

crunchip

@Stormbringer, mit Proxmox VM Debian hatte ich auch Probleme, konnte keine Daten empfangen. Irgendwo ganz weit oben in diesem Thread gab es die Lösung zu meinem Problem.

SBorg

Nein, glaube nicht, sieht nach einem neuen Problem aus. @crunchip bei dir hatte er Probleme mit dem Port/nc. Bei @Stormbringer macht mich Zeile 100 get_DATA.... stutzig. "get_Data" ist eine Funktion aus der *.sub und kann anscheinend nicht gelesen werden. Bevor er da aber hinkommt, hat er schon den Versionscheck erledigt, nur konnte er da die Datei noch lesen!?!
Funktioniert den ein ./wetterstation.sh -v :
Bild 1.png

Versuch dann mal angehängte Datei, da habe ich das "function" entfernt. Braucht Linux nicht, stört aber auch nicht, oder doch gerade bei deiner Installation... (und stand genau bei get_Data...)
wetterstation.sub

Stormbringer

@SBorg Wollt ich auch gerade schreiben, dass ich die Fehlerbehebung von crunchip schon probiert habe aber nicht weiter verfolgt habe, weil die Fehlermeldung anders aussieht.

Danke für die neue Datei aber da bringt er leider die selben Fehlermeldungen.

Falls es interessant ist, nc -lv -p bringt folgende Ergebnis:

Stormbringer

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

./wetterstation.sh -v

Hab jetzt mal als Spaß -v probiert da meckert er aber. LS habe ich auch noch ausgeführt damit man sieht, dass die Datei da ist.

SBorg

@Stormbringer Ich ahne das Problem...
Benenne bitte mal dein Verzeichnis in WLAN_Wetterstation oä. um. Ich vermute mal, dass das Leerzeichen im Verzeichnis stört. Hatte wohl noch keiner eines im Verzeichnis ;)

EDIT : liegt am Leerzeichen. Kannst auch von GitHub die V1.3.1 der wetterstation.sh zum testen laden, damit sollte es dann gehen :)

Community Forum

NEWS

[Linux Shell-Skript] WLAN-Wetterstation

V1.3.0 Beta (RC) steht auf GitHub zum testen bereit

V1.3.0 Beta (RC) steht auf GitHub zum testen bereit

Support us

389

32.4k

81.5k

1.3m