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

[Glasfaser]

@ilovegym

Schöner Reim :grin:

@crunchip

SBorg hat ja geschrieben ..

natürlich auch nicht weiter verwunderlich, wenn du lt. Luftdruck eher "subtropisch" unterwegs warst

und jetzt .... sitzt ein Vogel auf dem Sensor :grinning: :sunglasses:

[kaybau]

Hallo @SBorg ,
noch ein Feature-Request für eine zukünftige Version:

• Tendenz der Luftfeuchte innen, wenn gelüftet wird . Steigend, Fallend, gleichbleibend. Daraus kann dann jeder seine Lüftungsgewohnheiten ableiten ;)

Hierbei bedarf es eines Vergleichs der absoluten Luftfeuchte.

VG,
Kay

[SBorg]

40 Jahre her und ich hatte nur eine drei im Deutschunterricht...
lange schön --> gefixt
--/kein Regen --> geändert

Ihr könnt Fehler/Verbesserungen gerne melden, die Änderung dauert nur einen Augenblick :)

@crunchip Ich hab lange gedebugt und kontrolliert, kein Fehler von mir, aber ich habe das auch öfters. Ich dachte zuerst ich schreibe da aus Versehen hinein, aber dann müsste es immer und bei jedem sein. Also alles geloggt was geht. Nix, die Werte werden einfach vom ioB gelöscht. Ich hege mal stark die Vermutung selbes Problem wie "Blockly wird nicht gespeichert...":disappointed_relieved:
Ich hoffe auf ein Update von was auch immer und dass der Fehler dann damit auch weg ist.

Bzgl. Sonnenscheindauer habe ich aber einen Denkfehler eingebaut: ich prüfe ob der Wert >= 120 W/m² ist. Ist dem so, addiere ich zur Sonnenscheindauer den Abfrageintervall (WS_POLL) dazu. Das würde auch funktionieren, wenn das Display nicht gelegentlich mal ein Datenpaket verschluckt und es immer im festen Intervall sendet. Dem ist aber nicht so...
Beispiel: Poll steht auf 16 Sekunden
Datenpaket kommt aber erst nach 20 Sekunden, es werden aber nur 16 Sek. hinzu addiert, Differenz 4 Sekunden
ein Datenpaket bleibt aus, es werden mit dem nächsten 16 Sek. hinzu addiert, Differenz 16 Sekunden...

Das dürfte sich auf den Tag ganz schön summieren :(

@kaybau Im Prinzip keine schlechte Idee, aber ist das noch Aufgabe der Wetterstation? Pauschal habe ich aber nichts dagegen, wenn mir einer erklärt wann/wie etc. der Trend berechnet wird oder wo man es nachlesen kann.

[crunchip]

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

Das dürfte sich auf den Tag ganz schön summieren

naja, zur Zeit nicht....scheint ja kaum die Sonne:grin:
aber ja, so wie du das erklärst, scheint was dran zu sein:ok_hand:

bezüglich den verschwundenen Werten korrigieren, wollte ich mal in den History Daten nachsehen, 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

@Glasfaser

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

sitzt ein Vogel auf dem Sensor

wäre ne Erklärung:grinning: aber nein, dem ist nicht so,
verstehe nur nicht warum relativ und absolut von jetzt auf dann so schlagartig auseinander liefen

[Glasfaser]

@crunchip

In deinem Screenshot von den Datenpunkten im Reiter INFO , fehlen einige Datenpunkte !?

z.b.

javascript.0.Wetterstation.Info.Letzte_Regenmenge
javascript.0.Wetterstation.Info.Letzter_Regen
.
javascript.0.Wetterstation.Info.Solarenergie_VorTag

usw ....

[crunchip]

@Glasfaser ich habe nicht die allerletzte version von git, deshalb habe ich diesen

Solarenergie_VorTag

noch nicht

[Glasfaser]

@crunchip

die fehlen doch auch .... oder sehe ich Sie nicht :sunglasses:

javascript.0.Wetterstation.Info.Letzte_Regenmenge
javascript.0.Wetterstation.Info.Letzter_Regen

[crunchip]

@Glasfaser die laufen doch unter Wetterstation.Regen_*
und nicht im Info Ordner

[Glasfaser]

@crunchip

.

[crunchip]

@Glasfaser ich weiss, diese sind auch neu dazu gekommen, hab nachgesehen, meine Version ist am 21.04 aufgespielt, da gab es diese Datenpunkte noch nicht und wurden auf wunsch, so weit ich mich erinnern kann, eingebaut
da aber Grafana Dashboard....also nicht zwangsläufig notwendig, deshalb hab ich noch nicht die allerneuste Version geladen
und bis vorgestern lief ja auch alles normal(exklusive meines Luftdrucks:grin: )

[Glasfaser]

@crunchip

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:

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