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

[Negalein]

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

delete from "javascript.0.Wetterstation.Aussentemperatur" where time =1572614953000000000

Danke
hab 8 Einträge gelöscht

Den bisherigen Rekordwert solltest du dann in der Statistik unter "Data" in den JSONs finden (kriege ich gerade aus dem Kopf nicht so ganz hin). Dann einfach die Werte mit bspw. -15.57 eintragen .

In der JSON vom April hab ich den Wert korrigiert (dank Grafana leicht herauszufinden).
Aber wie oder wann ändern sich die Werte zB in 0_userdata.0.Statistik.Wetter.Rekordwerte.Temperatur_Spitzentiefstwert?

und beim Template halt "-15.57 °C im Februar 2021"

welches Template?

Kannst auch in der Influx nachschauen (ungetestet):

funktionierte nicht (getestet)

select min(value) from "javascript.0.Wetterstation.Aussentemperatur ERR: error parsing query: found javascript.0.Wetterstation.Aussentemperatur, expected identifier at line 1, char 23

---

Edit: hab jetzt die 3 Werte händisch eingetragen. Sind nun rot. Ist das normal?

[Boronsbruder]

@SBorg
mich hat das Statistikskript beim Monatswechsel angewarnt (das fällt bei Euch wahrscheinlich nicht mehr auf, da ihr schon länger als ein Jahr loggt)

2021-07-01 01:03:00.046 - warn: javascript.0 (21792) States system pmessage messagebox.system.adapter.javascript.0 {"command":"query","message":{"result":[[],[],[]],"ts":1625094180045,"error":null},"from":"system.adapter.influxdb.0","callback":{"message":"select * FROM \"0_userdata.0.Wetterstation.Aussentemperatur\" WHERE time >= 1593554400000000000 AND time <= 1596232799000000000; select * FROM \"0_userdata.0.Wetterstation.Wind_max\" WHERE time >= 1593554400000000000 AND time <= 1596232799000000000; select * FROM \"0_userdata.0.Wetterstation.Regen_Tag\" WHERE time >= 1593554400000000000 AND time <= 1596232799000000000","id":54,"ack":true,"time":1625094180008},"_id":24065089} temps is not defined
2021-07-01 01:03:00.049 - warn: javascript.0 (21792) ReferenceError: temps is not defined
at Object.cb (script.js.common.Wetterstation_Statistik:401:21)
at change (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5467:71)
at Immediate._onImmediate (/opt/iobroker/node_modules/@iobroker/db-states-redis/lib/states/statesInRedisClient.js:234:37)
at processImmediate (internal/timers.js:461:21)

hab jetzt mal in Zeile 350 ein

    let temps = [], wind = [], regen = [];

reingepackt, weil er im Skripteditor von Iobroker

                    temps.length=0;
                    temps[0]=99999; 
                    wind.length=0;
                    wind[0]=99999;
                    regen.length=0;
                    regen[0]=99999;

(Zeile 401-406) bemängelt hat (not defined).

[SBorg]

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

funktionierte nicht (getestet)

Gegentest

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

welches Template?

Wie die Rekordwerte angezeigt werden: [WERT] im [MONAT] [JAHR] (hast du aber schon gemacht, aber das ist ein Template, da du über die verschiedenen Parameter das Aussehen der Ausgabe selbst bestimmen kannst).

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

Edit: hab jetzt die 3 Werte händisch eingetragen. Sind nun rot. Ist das normal?

Jepp, wenn du beim manuellen setzen das ACK-Flag nicht setzt ("Bestätigt") bleiben die rot. Das hat an der Stelle aber keine Bewandtnis, da hier kein Adapter dahinter steht der es ev. brauchen würde, um zu prüfen ob bspw.. ein anderer Adapter den Wert bestätigt.

[SBorg]

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

(das fällt bei Euch wahrscheinlich nicht mehr auf, da ihr schon länger als ein Jahr loggt)

Ja, da kommt er nur hin wenn unter einem Jahr noch nichts geloggt wurde. Irgendwie muss da aber auch was gewesen sein (kann mich nur nicht mehr erinnern was), denn in der nächsten Version ist es schon enthalten:

//Abfrage der Influx-Datenbank
        let start, end, result = [], temps = [], wind = [], regen = [];

[Langer]

@SBorg

Guten Morgen,

in der Wetter Statistik sind mir 2 Sachen aufgefallen, die ich nicht verstehe.

Vorweg, bin absoluter Neuling und daher weiß ich nicht ob ich da falsch liege!!

Rekordwerte.value.Regenmengemonat ist kleiner als Jahreswerte.Regenmengemonat
Rekordwerte.value.Regenmengemonat = 177.8 l/m²
Jahreswerte.Regenmengemonat = 253.2 l/m²

Jahreswerte.Gradtage_warmeTage = 25 Tage
Jahreswerte.Gradtage_Sommertage = 20 Tage
Jahreswerte.Gradtage_heisseTage = 6 Tage

muss dann Jahreswerte.Gradtage_warmeTage = 25 Tage nicht 26 Tage sein?
Meine Frage:

Wäre diese Darstellung nicht besser:
warmeTage = 6
Sommertage = 14
heisseTage = 6

Weil heisser Tag immer die Temperatur 20°C und 25°C enthält
und ein Sommertag immer 20°C enthält.

Habe die im Skript bei mir geändert und es funktioniert.

Dann noch folgendes:

Bei Data Monatsstatistik ist:

{"Tiefstwert":4.27,"Hoechstwert":33,"Temp_Durchschnitt":18.11,"Max_Windboe":38.46,"Max_Regenmenge":75.4,"Regenmenge_Monat":253.2,"warme_Tage":26,"Sommertage":12,"heisse_Tage":6,"Frost_Tage":0,"kalte_Tage":0,"Eistage":0,"sehr_kalte_Tage":0}

Wunsch:

{"Tiefstwert":4.27,“Tiefswert_Datum“:02062021,"Hoechstwert":33,“Hoechstwert_Datum“:20062021,"Temp_Durchschnitt":18.11,"Max_Windboe":38.46,“Max_Windboe_Datum“:30062021,"Max_Regenmenge":75.4,“Max_Regenmenge_Datum“:30062021,"Regenmenge_Monat":253.2,"warme_Tage":14,"Sommertage":6,"heisse_Tage":6,"Frost_Tage":0,"kalte_Tage":0,"Eistage":0,"sehr_kalte_Tage":0}

Bei Jahreswerte
Regenmengemonat
Regenmengetag
Temperatur Hoechstwert
Temperatur Tiefstwert
Trockenperiode
Windboe_Max
Jeweils das Datum mit ausgeben

aktueller_Monat den Tag bzw. Datum anhängen
wie bei Jahreswerte

Sollten meine Gedanken nicht machbar oder falsch sein "SORRY".

MfG
Wastl

[SBorg]

@langer Sorry, dauert bei mir im Moment einfach, null-komma-überhaupt-keine-Zeit...

Also...
#1: kann ich so nicht nachvollziehen, ist bei mir identisch. Anhand der Regenmenge hast du wohl auch schon einen Monatswechsel hinter dir (einiges wird nur am 01. des Monats berechnet)? Außer dass er ev. mal hängen geblieben ist fällt mir wenig dazu ein.

#2: Jepp, ist ein Fehler. Da ich es selbst nicht aktiv nutze wohl bisher noch keinem aufgefallen.
Die Darstellung wurde so eingangs von den Nutzern gewünscht, wobei ich allerdings hier auch für die Logik bin, dass bspw. ein heißer Tag auch immer ein Sommertag bzw. warmer Tag ist/war. Wer aber zB. nicht im JS (wg. Updates, fehlender Kenntnisse etc.) direkt ändern möchte, kann sich ja auch ein Blockly erstellen mit neuen DPs erstellen. Sind ja nur 2 Subtraktionen. Bei anderen Meinungen gerne Feedback. Wäre ja nicht so, dass es in Stein gemeißelt ist

...und hier darf jeder frei seine Gedanken, Ideen, Vorschläge, Kritik und Meinungen äußern, ich nehme nichts krumm oder persönlich, auch wenn der ein oder andere da zwischen den Zeilen etwas andere herausließt.

Deswegen von meiner Seite nur ein freundliches "Nein" zur allgemeinen Datumsthematik (zB. Data Monatsstatistik), weil das dann doppelt wäre. Jeder (also nicht nur auf dieses Projekt bezogen) Datenpunkt enthält immer zwei Timestamps: den sog. TS und LC. TS ist wann er das letzte mal aktualisiert wurde, LC wann der Wert sich das letzte mal änderte.
Wenn du also beim Monat zB. einen Tiefstwert von x.xx°C hast, zeigt der LC von alleine auf das Datum wann er geändert wurde.
Außer du willst natürlich mit den JSONs etwas anderes anstellen. Eigentlich sind die nur dazu da, dass ich jetzt aktuell Juli 2020 schnell einlesen kann, dann die Vorjahresmonatswerte anzeigen lassen kann und nicht jedes mal eine kpl. Auswertung des Monats durchführen muss (dauert auf einem PI bis zu 2 Minuten).

[Negalein]

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

Die Darstellung wurde so eingangs von den Nutzern gewünscht, wobei ich allerdings hier auch für die Logik bin, dass bspw. ein heißer Tag auch immer ein Sommertag bzw. warmer Tag ist/war.

Jep, war ich

wenn ein heißer Tag auch ein Sommertag bzw. warmer Tag ist, dann hat in der Statistik plötzlich der Monat 50 und mehr Tage.
ein heißer Tag würde dann zB 3x gerechnet werden.
ein Sommertag zB 2x

[Langer]

@sborg

Als erstes vielen Dank für die Antwort, trotz Deiner knapp bemessenen Zeit.

Ich bin und war in mehreren Foren, aber selten so ein super Forum gefunden wie hier, nochmals an allen meine herzlichen Dank!!!
Gerade für Neulinge ist es super, Fragen stellen zu können und zu 95% eine Antwort zu bekommen, ohne sich bei der Antwort blöde vorzukommen.

Wie Du gelesen hast, bin ich Neuling, daher meine Frage:

Was ist bitte "TS" und "LC" und wie bekomme ich diese Werte zu dem Datenpunkt??

Vorab vielen Dank für Deine Antwort.

MfG
Wastl

[SBorg]

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

Jep, war ich

So dunkel hatte ich es noch in Erinnerung, wollte nur niemand fälschlich bezichtigen (oder heißt das züchtigen..?!)

[SBorg]

@langer Leider hat es meine SSD mit allem zerbröselt und die Backups, naja...
Ein Großteil von 1.5 Jahren Arbeit sind nu wech...

Den TS und LC siehst du bspw. direkt in den Objekten (nicht an irgendwelchen Daten orientieren, mein Sys läuft nicht korrekt):

Wenn du dann bspw. in der VIS ein Widget nimmst

sieht es dann so aus:

Die Timestamps kann man dabei mit allem abfragen, wie obiges Beispiel in der VIS, per Javascript, Blockly, Binding, Node-RED...

Im Skript kann man die Funktion auch gelegentlich finden (".lc" damit wird die letzte Änderung des Datenpunkts ermittelt):

...new Date(getState(PRE_DP+'.Rekordwerte.value.'+DatenPunkt).lc).getFullYear());

[Langer]

@sborg

Danke für Deine schnelle Antwort.

Wenn ich mit der Maus über einen Datenpunkt stehe, sehe zB. "Zeitstempel 20.06.2021 01:03:001" und "Letzte Änderung 20.06.2021 01:03:001".

Das heißt doch, um den Tag des Ereignisses zu finden muß ich
...new Date(getState(PRE_DP+'.Rekordwerte.value.'+DatenPunkt).lc).getFullYear());
minus 1 Tag machen?

Danke nochmals.

MfG
Wastl

[SBorg]

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

Das heißt doch, um den Tag des Ereignisses zu finden muß ich
...new Date(getState(PRE_DP+'.Rekordwerte.value.'+DatenPunkt).lc).getFullYear());
minus 1 Tag machen?

Im Grunde ja, nur etwas anders als du wahrscheinlich gerade denkst?
".getFullYear()" ermittelt aus dem Datums-Objekt das vierstellige Jahr, mehr nicht.
Man muss auch nicht unbedingt einen Tag abziehen, es würden (wenn das Skript um 1:03 Uhr läuft) auch 63 Minuten genügen.
Timestamps (wie auch bei Unix) sind immer Sekunden seit dem 01.01.1970
Um also das Datum korrekt zu berechnen, sähe es so aus:

let Datum_xyz=new Date((getState(hier_Pfad_und_Datenpunktname).lc)-86400);

86400 = 60sek * 60min * 24h (oder eben ein Tag )

[Langer]

@sborg

Danke.
Werde mal damit arbeiten und versuchen eine Wetter-Statistik in VIS erstellen.

MfG
Wastl

[Negalein]

@SBorg

seit Admin 5 und JS-Controller 3.3.14 hab ich ua. diese Meldung im Log.

simple-api.0 2021-07-08 22:27:02.447	info	State value to set for "javascript.0.Wetterstation.Info.Hitzeindex" has to be type "number" but received type "string"

Liegt das am Script, am Simple-Api oder am Script-Adapter?
Weißt du das?

[SBorg]

@negalein Ist mitunter der JSC 3.3.x
Beim "Hitzeindex" gibt es entweder eine Zahl oder "Null" ("nichts"). Dabei wird anscheinend "Nichts" als String missinterpretiert und da meckert der neue JSC.
Stell mal beim Objekt den Zustandstyp auf gemischt um, sollte es eigentlich beheben:

[da_Woody]

@sborg danke für den tip! hat mich auch schon länger genervt... ab 20° ja kein prob, aber mit (null) nervig.

[SBorg]

Für Docker-Anwender gibt es nun Dank des GitHub-Users "dan1-de" eine Kurzanleitung zur Installation unter Docker mit passendem Composer-File

[SBorg]

Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.7.0

• + Bei bereits eingetragenem OSEM-User erfolgt Abbruch der OSEM-Registrierung
• + Unterstützung für DP250/WH45 Sensor

Wie immer zu finden im GitHub

Wegen der neuen Datenpunkte des DP250-/WH45-Sensors muss auch wetterstation.js ersetzt und einmalig ausgeführt werden.
Wie üblich wetterstation.sh und -.sub austauschen, ws-updater.sh ausführen (ggf. neuen Sensor eintragen) und mittels sudo systemctl restart wetterstation den Service neu starten

[Rand]

@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:

Wegen der neuen Datenpunkte des DP250-/WH45-Sensors muss auch wetterstation.js ersetzt und einmalig ausgeführt werden.

Super, danke, probiere ich.

Dazu ne Frage - hab letztens festgestellt das irgendwann um das letzte Update mein Jahres-Regenmengen-Datenpunkt in der DB auf 0 zurück gesetzt wurde...
kann das durch das Ausführen des .js passiert sein ?

[SBorg]

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

kann das durch das Ausführen des .js passiert sein ?

Nein.

Vielleicht mal wieder kurz was was eigentlich macht (für alle zum Verständnis, schließlich ließt wohl keiner bald 2.800 Post'):

• ws-updater.sh
  • füht nur Änderungen in der wetterstation.conf durch die bei Versionswechsel nötig sind.
  • Einstellungen werden dabei keine verändert
• wetterstation.js
  • legt lediglich im ioB die nötigen Datenpunkte an (um den Usern das händische [und fehleranfällige] Anlegen zu ersparen.)
  • Werte werden nicht verändert.
  • Es werden nur neue DPs angelegt, bestehende werden übersprungen (ist beim Javascript-Controller Standard so)

---

Für den Betrieb wird nur die wetterstation.sh, -.sub und -.conf benötigt.

---

GitHub:
firmware.version : enthält die aktuelle Version der EasyWeather-Firmware. Wird nur vom Statistik-Addon benutzt, um festzustellen ob es ggf. eine neue Version gibt (sofern im Skript aktiviert)

Als Zusatz "AddOn" schließlich noch wetterstation-statistik.js
Führt Auswertungen durch und legt eine Statistik an.

---

@Rand Zu deiner Eingangsfrage und meinem "Nein". Nur das Statistik-Skript setzt von sich aus Werte auf "0". Bei der Jahresregenmenge sollte das aber nur am 01.01. passieren, sofern du es überhaupt nutzt und auch nur die "kumulierte", denn die berechnet das Shell-Skript. Die, falls es deine Station kann, von der Station übertragene ist kpl. außen vor. Die nehme ich so wie sie von der Station kommt und "reiche" sie an den ioB durch, wie fast alle anderen Werte auch. "fast" weil bei einigen Werten noch eine Konvertierung stattfindet: F --> °C, mph --> km/h usw.
Ganz pauschal kann es also nichts mit einem reinen Update zu tun haben. Sollte natürlich trotzdem nicht sein. Da es aber anscheinend auch nur ein Einzelfehler (wie @Negalein 's -5.000 °C Temperaturproblem) ist, kann ich eigentlich ein prinzipielles Problem auch ausschließen. Da es bei dir wohl auch nicht regelmäßig auftritt wird das kaum zu finden/fixen sein (falls es von der Station kam kann ich eh nix mehr machen).
Wenn es die "kumulierte" ist: einfach den vorherigen Wert wieder eintragen. Das Shell-Skript ließt den dann wieder ein und addiert dann wieder neue Regenmengen dazu