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

[SBorg]

Und weiter gehts...:

Sind natürlich keine August-Werte, sondern die vom aktuellen Monat, aber wir haben ja noch nichts vom Vormonat ;)
Mehr Werte wird es erst mal während der Testphase wohl nicht geben (die sollten aber korrekt/aktuell sein), da ich sonst bei einem (Denk-)Fehler einfach zu viel ändern muss. So sind es wenigstens nur drei Werte...
Der "August" wird nur heute (8.09.) mittels des Skriptes angelegt. Dies geschieht dann zukünftig am Monatsanfang, aber den haben wir aktuell ja nicht und wer will schon so lange warten...:innocent:

Sonst #94 abändern:

if (zeitstempel.getDate() == 8) { // Jobs Monatserster...

Hier wäre die "8" durch den aktuellen Tag des Monats zu ersetzen, dann läuft es auch an diesem Tag.

[Negalein]

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

Sonst #94 abändern:
if (zeitstempel.getDate() == 8) { // Jobs Monatserster...

Zeile 94 schaut bei mir so aus:
console.log('Letzter Messwert: ' + new Date(result.result[0][temps.length-1].ts).toISOString() + ' ***' + result.result[0][temps.length-1].value);

Kann das stimmen, dass diese Zeile geändert werden muss?

---

Edit: gerade gesehen, dass auf Git schon die aktuelle Beta liegt!

[SBorg]

@Negalein Habe ich vergessen zu erwähnen ;)
Aktuell grübele ich gerade über die Vorjahreswerte:

Die sehen zwar schön befüllt aus (+ werden bzw. würden sie auch schon), allerdings sind sie nicht korrekt. Der Grund ist auch recht einfach, denn ich sammele erst seit Mai (? glaube ich...) Daten, kann also vom Sep. 2019 noch gar nichts haben.
Was sollte da nach eurer Meinung vorläufig stehen bis man Daten hat? Der Typ ist number, also kein "--", "n.a.", "xx" etc.
Ein unsinniger Wert zum besseren erkennen wie bspw. -99, pauschal 0,...
...oder einfach überhaupt nichts (habe ich noch nicht probiert ob das bei Number geht...)

Wenn keine weiteren Fehler auftreten wäre es sogar witzigerweise für die drei Werte fertig. Dann beginnt die Fleißarbeit die anderen Messwerte einzupflegen :blush:

*EDIT* Ach ja, warum eigentlich Data-Datenpunkt? Naja, eine kleine "Datenbank" ist es dann doch geworden. Ich speichere die aktuellen Monatswerte in einem JSON-String, dann brauche ich in einem Jahr keine Monatsauswertung mehr auszuführen. Da es auch nur 12 Strings pro Jahr sind, könnte man relativ schnell auch eine Jahresstatistik anfertigen...:innocent:

[Negalein]

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

Was sollte da nach eurer Meinung vorläufig stehen bis man Daten hat?

zB 99999 :)

[SBorg]

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

zB 99999 :)

Habe ich jetzt so übernommen :)
"Nichts" geht nicht, da wg. des Typs Number dann automatisch "0" eingesetzt wird.
Neue Version auf GitHub V0.0.1 Beta :

Damit alles bei Null startet den kpl. Statistik-Zweig vorher löschen. Beim Start legt das Skript dann die Ordnerstruktur an, befüllt den VorJahres-Monat mit 99999 (außer jemand sammelt per Influx schon seit Sep. 2019 Daten. Solange gibt es das WLAN-Skript aber noch nicht), legt "Data" an (der bleibt so "leer" bis zum nächsten Monatsersten, dann befinden sich dort darunter die gespeicherten Monatsauswertungen) und der Aktuelle Monat wird befüllt. Echte Werte gibt es dann um 1:03 Uhr (default), da ich immer bis Mitternacht warten muss bis alle Daten des Tages vorliegen.
Deswegen auch die komischen Werte mit -100, 0, 100 °C

• der Höchstwert des letzten Tages wird wohl immer über -100 °C liegen (+ damit aktualisiert)
• der Durchschnitt liegt entweder tatsächlich bei 0 °C, dann stimmt er zufällig, oder er wird eben mit dem korrekten aktualisiert
• der Tiefstwert des letzten Tages wird wohl immer unter 100 °C liegen (+ damit aktualisiert)

Also Skript nach dem Starten auch laufen lassen. Es sollte dann für den aktuellen Monat die drei Werte korrekt erfassen.
Soweit möglich möchte ich dann daran auch nichts mehr ändern und die weiteren dann zusätzlich hinzufügen. Somit könnten für den September 2020 alle Daten vorliegen, wenn auch noch nicht durchgängig. Ab Oktober 2020 hätte ich dann aber gerne komplett...:grin: :innocent:

Den Scheduler würde ich nicht zu nah an Mitternacht verschieben. Falls ihr im Influx viele Datenwerte im RAM vor dem schreiben vorhaltet, kann es sonst sein, dass er noch nicht alle Messwerte aus dem RAM auch in die InfluxDB geschrieben hat. Da die Werte vom Vortag immer von 0:00 Uhr bis 23:59:59 Uhr gelesen werden, ist es egal wann sie am nächsten Tag gelesen werden. Ihr könnt im Scheduler auch bspw. 6:00 Uhr eintragen. Funktioniert genauso, nur habt ihr die Statistik dann eben erst ab 6:00 Uhr aktuell vorliegen ;)

[Negalein]

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

Neue Version auf GitHub V0.0.1 Beta :

läuft :)

Dann warte ich jetzt mal auf 1:03 Uhr :grin:

[SBorg]

Neue Version auf GitHub V0.0.1 Beta

• + Windböe
• + max. Regenmenge pro Tag (mangels Regen ungetestet ;) )

Damit sind jetzt alle drei Messwertereihen (Temperatur, Wind und Regen) auch im Einsatz, falls sich wer fragt warum es gerade die Messwerte aktuell geworden sind.
...und aus aktuellem Anlass folgen jetzt > 2x °C - Tage :grin:

btw: Ich werde jetzt auch anfangen die Versions-Nummern zu erhöhen, denn eigentlich sollte bis dato jetzt alles funktionieren.

[Negalein]

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

Neue Version auf GitHub V0.0.1 Beta

läuft wie immer sofort :)

[SBorg]

Neue Version auf GitHub V0.0.2 Beta

• + warme Tage über 20°
• + Sommertage über 25°
• + heiße Tage über 30°

Sieht alles wie erwartet aus: Höchstwert ist gestiegen, Tiefstwert gefallen, Durchschnitt hat sich auch geändert, kein Wind und Regen...
...und somit bei gestrigem neuen Spitzenwert seit Aufzeichnung von 28.11°C auch "warme- + Sommertage" korrekt :)

...und ich erwähne es hier zur Sicherheit nochmals (da viele probieren, aber nicht posten): es genügt aktuell völlig das JS-Skript stoppen, mittels C&P die neue Version einzufügen (ggf. konfigurieren), speichern und das JS zu starten. Bereits gesammelte Werte bleiben erhalten, ggf. neue DPs werden zusätzlich angelegt. Die neuen Werte, sofern es welche gibt, stehen dann nach dem Schedule-Zeitpunkt (default 1:03 Uhr nachts) zur Verfügung.

*EDIT* noch vergessen: die Gradtage vom Vorjahresmonat funktionieren aktuell nicht. Hat zwar eh noch keiner Daten dafür, aber dass ist etwas komplizierter, deswegen aktuell noch nicht umgesetzt. Mir ist aber schon eine performante Lösung eingefallen :grin:

[Negalein]

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

Neue Version auf GitHub V0.0.2 Beta

• warme Tage über 20°
• Sommertage über 25°
• heiße Tage über 30°

:+1:

[SBorg]

...und funktioniert...
...immer noch kein Regen aber mit +1 bei den "Hot Days" sieht es wohl gut aus :slightly_smiling_face:

[Negalein]

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

aber mit +1 bei den "Hot Days" sieht es wohl gut aus

er zählt aber erst seit Start des Scripts?
Oder holt es sich die Daten schon am Anfang September?

PS: es gibt ja aktuell aktueller_Monat.
Ist es möglich in den Objekten auch die vergangenen Monate anzuzeigen?
Also zB aktuelles Jahr.Jänner, ...
und Vorjahr.Jänner...

[SBorg]

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

er zählt aber erst seit Start des Scripts?

Jepp. Machen die Adapter aber ebenfalls, da dass rückwirkend aufwändig ist (gibt es Daten, sind diese vollständig,...) und meist eine nicht zu unterschätzende Systemlast mit sich bringt.
Wenn man also aktuell angefangen hat (oder später mal im Monat anfängt), wird der aktuelle Monat noch Lücken enthalten. Ab (bzw. bis) Oktober 2020 möchte ich dann aber soweit sein, dass man alle Werte durchgehend hat.

Die vergangen Monate werden dann unter dem aktuell noch leerem DP "Data" erscheinen:
Ordner Jahr - Ordner Monat (zweistellig), also bspw. wenn alles klappt am 1. Oktober ab 1:03 Uhr: ...Data.2020.09
Darunter liegt dann ein DP mit einem JSON, welcher alle Monatswerte des Septembers 2020 enthält (oder genauer die gesammelten Werte).
Das wird dann im September 2021 automatisch gelesen und somit die Vorjahresmonatsabfrage umgangen (die ist nun mal System lastig + warum soll ich die Monatsauswertung nochmals durchführen wenn doch alle Daten bereits ein Jahr zuvor schon ermittelt wurden :) ? ) die dann ebenfalls am 1.10. um 1:03 Uhr läuft und versucht die Daten für den Oktober 2019 zu ermitteln (was aber mangels Daten fehlschlagen wird/sollte).

[Negalein]

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

Jepp.

Kein Problem. Weiß bescheid.

Die vergangen Monate werden dann unter dem aktuell noch leerem DP "Data" erscheinen:

sehr gut!
Mein Cousin ist schon neidisch. Er macht alles händisch mit Excel.

[SBorg]

Neue Version auf GitHub V0.0.3 Beta

• + kalte Tage (Höchsttemperatur unter 10°)
• + Frosttage (Tiefsttemperatur unter 10°)

Die 30°C auch geknackt = heiße Tage funktioniert auch.
Mangels aktueller Wetterlage fehlt nur noch Regen und die beiden neuen Gradtage ;)

[SBorg]

Mist wenn man sich verließt. Mir kam das gleich irgendwie unlogisch beim programmieren vor ...
Frosttage sollte natürlich unter 0°C sein. Wird mit der neuen Version gefixt, sorry :(

[Ein ehemaliger Benutzer]

@SBorg ach naja, Frosttage ... hoffentlich kommen keine.. ;-)

[Negalein]

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

Die 30°C auch geknackt = heiße Tage funktioniert auch.

Ja, hat einwandfrei funktioniert.

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

@SBorg ach naja, Frosttage ... hoffentlich kommen keine.. ;-)

ganz deiner Meinung. Dann bekomm ich schneller das Glasfaser :grin:

[SBorg]

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

@SBorg ach naja, Frosttage ... hoffentlich kommen keine.. ;-)

Bin ich bei dir/euch, aber er würde ja schon bei einer Temperatur von 9.99°C oder kleiner einen "Frosttag" detektieren ;)

---

Neue Version des Wetterstation-Statistik-Skriptes auf GitHub V0.0.4 Beta

• ~ fix Frosttage (Tiefsttemperatur unter 0°)
• + Eistage (Max. unter 0°C) / Sehr kalte Tage (Min. unter -10°C)

Beim Update von der V0.0.3 Beta sollten beide Datenpunkte "Frosttage" gelöscht werden (oder man ändert in der Beschreibung die 10° in 0° ab). Diese werden beim Start der V0.0.4 Beta dann korrekt neu angelegt.

Das wären dann erst mal alle Gradtage. Die nächste Version wird sich dann den Gradtagen des Vor-Jahres widmen. Aktuell steht da zwar schon 99999, wirklich ausgewertet wird aber derzeit nichts. Immerhin könnten die Ersten Daten ab Januar 2020 (Startpunkt des Shell-Skriptes) gesammelt haben. Ist dann eher ein "unter-der-haube"-Release, man sieht offenkundig so nichts.

[SBorg]

Neue Version des Wetterstation-Statistik-Skriptes auf GitHub V0.0.5 Beta

• + Gradtage VorJahr

Ist so erst mal nichts zu sehen. Wenn dann aber ggf. ab Januar 2021 die ersten von Euch Vorjahres-Daten haben, sollten dann auch die 99999-Dummywerte verschwinden.
In der Simulation mit Daten aus August 2020 sah es zumindest schon mal gut aus :) :