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

[SBorg]

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

wie sehen bei dir die Alias aus (true wird 1, false wird 0), bzw. wie wandle ich mit einem Alias true in 0, usw.?

Ganz, ganz schwerer Voodoo :joy:

val ? 1 : 0

wo holst du dir die Daten von 0_userdata.0.VIS.Wetter.Regenvorschauher?

Aus dem Weatherunderground-Adapter mittels Skript:

/* Wunderground Regen
Abfrage des Weatherunderground Adapters im Bereich Vorhersage,
wann der nächste Regen erwartet wird.

Findet in den forecastHourly-Datenpunkt den ersten Regen-Eintrag
Ausgabe in Text ("kein Regen", "X Stunden (X% [Wahrscheinlichkeit])")

http://forum.iobroker.net/viewtopic.php?f=21&t=3447#p31858


01.08.2016 erstellt von Pix unter Nutzung des obigen Skriptes
28.06.2017 Korrekturen
12.07.2017 Fehler abfangen und Typ Variable auf String geändert
06.03.2019 Code optimiert
           berücksichtigt Niederschlag in der aktuellen Stunde (Stunde 0)
11.06.2019 auf neue Datenpunkte angepasst für weatherground-Adapter (getestet V3.0.11)
04.08.2019 geändert für Wunderground Adapter 3.1.1
08.03.2021 Codeoptimierungen @SBorg

*/


const vorstd = 36;                                       // Vorschau in Stunden (Weatherunderground bietet neuerdings bis 36h Vorschau), kann hier auch kleiner sein
const idRegen = "0_userdata.0.VIS.Wetter.Regenvorschau"; // Ziel-Datenpunkt
const wunder_inst = "weatherunderground.0.";             // Weatherground-Adapter Instanz
const logging = false;

createState(idRegen, "kein Regen", { name: "Regenvorschau", type: "string", role: "text" });
 

function berechneZeit() {
    if (logging) log("Berechne Dauer in Stunden bis zum nächsten Regen");
    let data=0, pop=0;
    for (let i=0; i<vorstd; i++) {
        data = getState(wunder_inst + "forecastHourly." + i + "h.precipitation").val;
        if (data > 0) {   
            pop = getState(wunder_inst + "forecastHourly." + i + "h.precipitationChance").val;
            if (logging) log("Regeneintrag gefunden bei " + i + "h " + data + "mm");
            if (i == 0) { // wenn jetzt Regen
                if (logging) log("In dieser Stunde werden " + data + "mm Regen erwartet (Wahrscheinlichkeit " + pop + "%)");
                setState(idRegen, "jetzt (" + pop + "%)", true);
            } else {
                if (logging) log("In " + i + " Stunden werden " + data + "mm Regen erwartet (Wahrscheinlichkeit " + pop + "%)");
                if (i==1) { setState(idRegen, "1 Stunde (" + pop + "%)", true); } else { setState(idRegen, i + " Stunden (" + pop + "%)", true); }
            }
            i=vorstd-1; // beim ersten Auftreten der Regenwahrscheinlichkeit über 0 abbrechen
        } 
        if ((i == vorstd-1) && (pop == 0)) {
            setState(idRegen, "Kein Regen erwartet (" + pop + "%)", true);
            if (logging) log("Kein Regen erwartet (" + pop + "%)");
        }
    }
}
 
// bei jeglicher Aktualisierung von Weatherunderground Berechnung starten
 
on({
    id: /^weatherunderground\.[0-9]+\.forecast.*\.[0-9]+h\.precipitation$/,  // forecastHourly, forecastDaily, forecast
    change: "any"
}, berechneZeit);
 
// bei Skriptstart
berechneZeit();

[G.Hawk]

@sborg
Hallo Danke für deine Antwort.
Ich habe alles geprüft und es ist alles richtig.
Interessant war dass nach einem Reboot einmal die Daten geholt wurden und dann nicht mehr.
Dann habe ich probiert ein update vom Rasberry zu machen und habe Fehler bezüglich der Schlüssel von Influx und Grafana bekommen.
Den Influx update Fehler konnte ich beseitigen. Grafana noch nicht.
Aber nach der Update Aktion läuft alles wieder.
Ich weiß nur nicht woran es nun lag.

Gruß

[viper4iob]

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

@viper4iob
@latzi
Na dann:
12:38:16.606 info javascript.0 (3146202) script.js.common.test_influx: Fertig! Rows: 137548 Dauer: 3061 ms

Waren das alle measurements über 24h?

EDIT:
Bei mir sah es über alle Measurements der letzten 24h so aus:
script.js.Test.Test3: Fertig! Rows: 130968 Dauer: 11482 ms
Nur Außentemperatur so:
script.js.Test.Test3: Fertig! Rows: 1972 Dauer: 102 ms

Ein Wert geht eigentlich noch recht schnell.
Wenn man im iobroker in den Objekten bei der Außentemperatur auf die benutzerdefinierten Einstellungen geht (das Zahnrad) und die Verlaufsdaten der letzten 24h anschauen will, dann warte ich da etwa 10 sek bis die da sind.
Wenn der Influx Adapter auf V1.x läuft, dauert das nicht mal eine Sekunde.
Und auch wenn man den EChart Adapter benutzt, dauert der Aufbau eines Graphen im V2.x Modus mehrere Sekunden.
Irgendwo ist da also noch der Wurm drin mit dem Influx Adapter.

[Boronsbruder]

@viper4iob
ja

let Startzeit = new Date();

sendTo('influxdb.1', 'query', 'from(bucket: "wetter") |> range(start: -24h)', function (result) {

    if (result.error) {

        console.error(result.error);

    } else {

        let Endezeit = new Date();

        // show result

         console.log('Fertig! Rows: ' + JSON.stringify(result.result[0].length) +' Dauer: ' + (Endezeit.getTime()-Startzeit.getTime()) + ' ms');

    }

});

Und bei mir laufen gerade 4 Influx-Instanzen 1x v1 und 3x v2 parallel

Edit:
Hab das mit den Verlaufsdaten AUSSENTEMPERATUR mal getestet und für die Daten vom 01.01.2021 - 05.02.2023 --> 9 sek -- letzte 24h 4 sek...

[viper4iob]

@boronsbruder
Hab meine Werte oben eingefügt.
Über alle Werte dauert es bei mir zwar deutlich länger, aber ein einzelner Wert geht generell gesehen noch recht schnell und erklärt nicht, warum der Abruf der Verlaufsdaten so lange dauert (Erklärung siehe oben) .
Vielleicht kannst du mal checken, wie lange das bei dir dauert.

[Boronsbruder]

@viper4iob
siehe oben :D

[viper4iob]

@boronsbruder
Wenn du den Zeitraum umstellst, geht der Aufruf schneller.
Stell ihn mal auf 24h, geh aus den Einstellungen raus und wieder rein, dann dauert es wahrscheinlich auch die 9 sek.
Der erste Aufruf dauert irgendwie gefühlt immer gleich lang, als würden die erst mal alles abfragen und dann nochmal die Zeitspanne auf die Einstellung eingrenzen.
Aber im Prinzip ist es mir an der Stelle wurscht, soll nur zeigen, dass da im Vergleich zu v1.x ein Performance Problem zu sein scheint.
Mein Problem ist eigentlich, das im v2.x Modus auch Graphen vom ECharts Adapter pro Graph jetzt mehrere Sekunden Ladezeit haben und das nervt gewaltig.
Bin deshalb aktuell dabei, diese Graphen in Grafana nachzubauen und die dann als iFrame in jarvis statt den ECharts zu embedden.
Solange muss ich noch auf v1.x bleiben.

[Boronsbruder]

@viper4iob
Bei Neu-Aufruf dauert es schon ewig, bis die 2 Felder von 1.1.1970 auf die richtigen Daten umspringen.
Aber das gehört dann nicht hier in den Wetterstation-Thread ;)

[viper4iob]

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

@viper4iob
Bei Neu-Aufruf dauert es schon ewig, bis die 2 Felder von 1.1.1970 auf die richtigen Daten umspringen.
Aber das gehört dann nicht hier in den Wetterstation-Thread ;)

Da stimme ich zu, der Kreis schließt sich, da ich dadurch aktuell auch nicht auf das neue Wetterstatistik-Skript gehen kann.
Mir ging es eigentlich nur mal darum, ob das ein allgemeines Problem mit dem Influx-Adapter ist, oder nur ich ein selbst verursachtes Problem habe. Da ich nicht der Einzige bin, scheint es ersteres zu sein.

[viper4iob]

Mal ne Frage:
Kann es sein, dass Awekas mittlerweile den Upload der Luftdruck-Werte korrekt annimmt und ich das verpennt habe?

Es gab ja das Problem, dass die nur den absoluten Luftdruck angenommen hatten und man musste dann dort einen Korrektur-Wert angeben, um auf den relativen Luftdruck zu kommen. Bei mir ist dieser 37,5.
Nun wurde mir am 01.03. von Awekas der Upload für den Luftdrucksensor deaktiviert, weil ein Wert von 1057 hPa übertragen wurde, der natürlich überhaupt nicht hinhaut.
Ich habe gerade die Historie gecheckt, an dem Tag lag der relative Luftdruck um die 1020 hPa am Nachmittag.
Der Korrektur-Wert wurde also statt auf den absoluten jetzt auf den relativen Luftdruck aufaddiert.
Das würde im Umkehrschluß bedeuten, dass jetzt der relative Luftdruck korrekt übertragen wird und man den Korrektur-Wert entfernen kann.

UPDATE:
Ich habe den Korrektur-Wert entfernt, so dass er quasi 0 ist, dann von Awekas die Deaktivierung aufheben lassen und jetzt passt der Wert, auch ohne Korrektur.

[Nashra]

Moin @SBorg , nachdem ich vor 2 Tagen alles umgestellt habe auf die V3 ist mir heute
in der VIS aufgefallen das der Wert für min.Temperatur nicht stimmt bzw.
nicht richtig angezeigt wird.

Der Datenpunkt von 0_userdata.0.Wetterstation.Info.Temp_Aussen_Heute_min

Sieht so aus das die Daten von 0_userdata.0.Wetterstation.Info.Temp_Aussen_Heute_max
auch in 0_userdata.0.Wetterstation.Info.Temp_Aussen_Heute_min geschrieben werden.
In beiden sind die selben Uhrzeiten und die gleichen Werten vorhanden.

[Quarkmax]

@nashra
in diesen Fehler bin ich auch gerannt. Schau mal in der wetterstation.conf ober dort dieser Eintrag

  #Protokoll (HTTP oder HTTPS) / default: HTTP
   INFLUX_WEB=HTTP

vorhanden ist. Der hat bei mir gefehlt. Warum? - konnte ich nicht verifizieren. Dann kamen die Werte korrekt.

[Nashra]

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

@nashra
in diesen Fehler bin ich auch gerannt. Schau mal in der wetterstation.conf ober dort dieser Eintrag

  #Protokoll (HTTP oder HTTPS) / default: HTTP
   INFLUX_WEB=HTTP

vorhanden ist. Der hat bei mir gefehlt. Warum? - konnte ich nicht verifizieren. Dann kamen die Werte korrekt.

Eintrag ist vorhanden

[SBorg]

@viper4iob Ich sende beides, also relativ und absolut. Da sie "normaler weise" den kpl. WU-String bekommen und ich für "unseren Teil" nicht wusste was sie nun genau wollen, dachte ich "kann ja nicht schaden beides zu schicken, wenn sie per offiziellem Weg eh beides bekommen..." :)

Bei mir steht noch ein Korrekturfaktor drin, allerdings nicht der den ich eingetragen hatte. Multipliziert mit acht komme ich aber auf den für meinen Wohnort korrekten ÜNN...

[SBorg]

@nashra Sieht nach keiner korrekten Verbindung zur InfluxDB aus (aus der werden die Werte ermittelt). Initial wird immer der 1. Wert nach Mitternacht für den Tag benutzt damit bis zur 1. Abfrage des Tages (0:15 Uhr) wenigstens mal etwas drin steht. Somit ist der gelesene Wert für min/max/avg bis ~ 0:15 Uhr identisch (logo, mit einem Messwert kann man schlecht min/max/avg ermitteln [bzw. sind die halt identisch]). Dann erfolgt die Abfrage und es gibt Werte für min/max/avg.

Da die bei dir gleich sind/bleiben, kann er wohl nix aus der InfluxDB lesen.
Ich habe eben mal eine neue Version hochgeladen, mit der man nun die InfluxDB-Konnektivität prüfen kann.

Einfach von GitHub die wetterstation.sh und -.sub ersetzen (restart des Service ist nicht erforderlich), dann im Installationsverzeichnis nacheinander ausführen (das mit dem . muss so ;) ) :

• . ./wetterstation.conf
• . ./wetterstation.sub
• minmax24h DEBUG

Falls das dann nicht in etwa so aussieht

musst du alles bzgl. Influx noch mal checken, Bucket, Token, Instanz, Organisation etc.

[Rushmed]

@sborg Bei mir siehts dann so aus:

pi@Smartazamba:~/Wetterstation $ . ./wetterstation.conf
pi@Smartazamba:~/Wetterstation $ . ./wetterstation.sub
pi@Smartazamba:~/Wetterstation $ minmax24h DEBUG
jq: error (at <stdin>:0): Cannot iterate over null (null)
jq: error (at <stdin>:0): Cannot iterate over null (null)

Also funktioniert wohl meine Influxverbindung nicht?

Bucket, Token und Organisation hab ich geprüft. Die stimmen, wobei ich Bucket und Instanz in Klarschrift angegeben habe. Die Influx_API stimmt auch. Habe alles aus meinen InfluxDB Instanzeinstellungen kopiert.

[Nashra]

@sborg
also bei mir kommt das raus

und das es Probleme mit dem auslesen der Daten gibt kann ich mir ehrlich gesagt nicht vorstellen,
da alle anderen Werte korrekt angezeigt werden. Nur bei diesen Beiden ist was faul.

Für mich sieht es so aus als wenn die Daten schon falsch an die Datenbank geliefert werden.
Kann mich natürlich auch täuschen, du bist der ScriptWetterGott :grinning:

Achja, Bucket, Token usw. alles OK.

[SBorg]

@rushmed Zumindest ist nun eindeutig, dass das so bei dir nicht funktionieren kann.
Was mir aber überhaupt nicht einleuchtet (der eigentliche Fehler schon): an der Stelle wird überhaupt kein "jq" (JSON-Parser) verwendet.

Ich habe es eben noch mal getestet, nun ist mein Minwert auf 9.22°C gefallen, funktioniert also...
Wenn du die Shell noch offen hast, frag mal die Influx direkt ab (sonst nochmal die beiden Zeilen vorher mit conf/sh ausführen:
 influx_query "-1d" "now()" "Aussentemperatur" "min"

[SBorg]

@nashra Sagen wir es mal so, der Debug zeigt, dass er nichts auslesen kann. Auch wenn die Daten falsch kämen, müsste er sie zumindest auslesen können ;)
Stimmt denn bspw. in Grafana deine aktuelle Außentemperatur, denn auf diesem einen Messwert fußt alles andere.
Wie sehen denn die RAW-Werte aus und wie loggst du (alles oder nur Änderung) ?

Du kannst den Aufruf mit dem "influx_query" übrigens auch testen. Anstelle von "min" auch gerne "max" oder "mean", "-1d" heißt aktuelle Zeit minus 1 Tag. Man kann auch den Zeitraum bspw. durch "-7d" auf eine Woche erweitern.

[Nashra]

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

@nashra Sagen wir es mal so, der Debug zeigt, dass er nichts auslesen kann. Auch wenn die Daten falsch kämen, müsste er sie zumindest auslesen können ;)
Stimmt denn bspw. in Grafana deine aktuelle Außentemperatur, denn auf diesem einen Messwert fußt alles andere.

Ja der Messwert für die Außentemperatur stimmt. Habe einige Stationen in der Nähe, selbe Werte.

Wie sehen denn die RAW-Werte aus und wie loggst du (alles oder nur Änderung) ?

es wird alles geloggt.

Du kannst den Aufruf mit dem "influx_query" übrigens auch testen. Anstelle von "min" auch gerne "max" oder "mean", "-1d" heißt aktuelle Zeit minus 1 Tag. Man kann auch den Zeitraum bspw. durch "-7d" auf eine Woche erweitern.

Habe ich schon probiert, da passiert gar nichts d.h. keine Ausgabe.