UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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:

...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:

(~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:

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 :

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:

Spoiler

mark@debian-baby-prox:~/WLAN Wetterstation$ sudo nc -lv -p 9999
[sudo] Passwort für mark:
listening on [any] 9999 ...
connect to [10.0.1.8] from ESP-CDD121.fritz.box [10.0.1.147] 37744
GET /weatherstation/updateweatherstation.php?ID=XXXX&PASSWORD=XXXX&indoortempf=76.6&tempf=93.4&dewptf=51.3&windchillf=93.4&indoorhumidity=38&humidity=24&windspeedmph=0.0&windgustmph=0.0&winddir=353&absbaromin=28.958&baromin=28.958&rainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.000&yearlyrainin=0.000&solarradiation=508.43&UV=4&dateutc=2020-06-24%2014:27:45&softwaretype=EasyWeatherV1.5.0&action=updateraw&realtime=1&rtfreq=5 HTTP/1.0
Host: 10.0.1.8
Accept:/
Connection: Close

[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.

Spoiler

[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 :)

[Stormbringer]

@SBorg Danke das wars ;-) Daten bekomme ich leider aber noch immer nicht rein. Habe oben schon einmal den Fehler "Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?" gefunden aber das "?" im Dateipfad von der App habe ich eigentlich drinnen. Die Stations IDs von App und Config sind auch gleich. Simple API Adapter beim Broker hat Port 8087. Trotzdem kommt:

Spoiler

mark@debian-baby-prox:~/WLAN Wetterstation$ ./wetterstation.sh --debug
io-frost-prox.fritz.box [10.1.1.2] 8087 (?) open
listening on [any] 9999 ...
no connection : Connection timed out

Messwerteblock:

Temperatur Innen : °C
Temperatur Aussen : °C
Taupunkt : °C
Chill-Faktor : °C
Luftfeuchte Innen : %
Luftfeuchte Aussen : %
Windgeschwindkeit : km/h
max. Windgeschwindkeit : km/h
Windrichtung : °
Windrichtung :
Luftdruck absolut : hPa
Luftdruck relativ : hPa
Regenrate : mm/h
Regenstatus :
Regen Tag : mm
Regen Woche : mm
Regen Monat : mm
Regen Jahr : mm
Sonnenstrahlung : W/m²
UV-Index :
Zeitstempel :
Firmware :

Datenstring für ioBroker:

DATA von Wetterstation:

Debug VAR:
Installationsverzeichnis: /home/mark/WLAN_Wetterstation
IPP: 10.1.1.2:8087 WS_PORT: 9999 WS_POLL: 30 PRE_DP: javascript.0.skripte.Wetterstation
Script-Version: V1.3.0 Config-Version: V1.3.0 Sub-Version: V1.3.0

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

code_text

[SBorg]

Hi,
sieht nach einem Netzwerk-/Routingfehler aus. Du hast den ioB mit SimpleAPI auf 10.1.1.3 Port 8087 konfiguriert. Den ruft das Script dann auch auf, bekommt aber eine andere IP zu Gesicht

o-frost-prox.fritz.box [10.1.1.2] 8087 (?) open

Dort wird wohl dein ioB nicht drauf laufen, deswegen auch o-frost-prox.fritz.box [10.1.1.2] 8087 (?) open, normal wäre bspw.

Connection to 192.168.1.30 8087 port [tcp/*] succeeded!

[Stormbringer]

@SBorg Die IP und der Port stimmen aber leider zu 100 %. Habe keine Ahnung wo er sich fritz.box da herzieht. Fritzbox wäre die IP Nummer 10.1.1.1

telnet Befehl auf dem Zwischen-Linux-Device bringt folgendes, wenn ich den Broker anpinge:

Spoiler

mark@debian-baby-prox:~/WLAN_Wetterstation$ telnet 10.1.1.2 8087
Trying 10.1.1.2...
Connected to 10.1.1.2.
Escape character is '^]'.

Wenn ich es richtig interpretiere ist doch dann die Verbindung ok oder? Kann es sein, dass er die ID von der Wetterstation nicht findet, weil ich nirgends was gefunden hab ein Passwort oder IP der WEtterstation in die Config einzugeben?