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

[SBorg]

@Negalein Moin, weil ich extra eine "Regenmenge" als neue Kategorie angelegt habe. Das funktioniert aber erst mit der 0.4.5, die dann aber leider das "Null"-Problem beim Übertrag der Werte hat

[crunchip]

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

Null"-Problem beim Übertrag der Werte hat

gibt es seit der Version 4.x
ich habe v 0.4.2, da 0.4.5 bei mir Probleme mit meinen angelegten Zählern verursachte und starte die Instanz kurz nach Mitternacht per cron neu, wegen den Null Werten

[jensfr]

Tolles Skript. Funktioniert super!

Darf ich mal ne Frage zum WH3000 SE stellen? Der zeigt bei mir sowas von spät an, dass es regnet. Hat noch jemand das Problem? Kann auch sein das es 2 std. leicht regnet u. es nicht angezeigt wird...

DAnke.

[Rushmed]

@jensfr Der geringste Wert den meine Station wahrnimmt sind 0,3 mm Niederschlag, wenn es nur leicht nieselt kann es schon dauern bis da etwas kommt.

[SteffenTM]

Nabend,
ich habe seit fast zwei Jahren eine Ventus W830 Wetterstation. Am Anfang hatte ich die Station über Wunderground registriert und über die API in der Instanz die Daten nach iobroker geholt. Hat ohne Problem funktioniert, nur finde ich es schizophren meine eigenen Daten um die halbe Welt zu schicken um sie wieder verwenden zu können. Nachdem ich auf die Möglichkeit mit dem Shell-Skript gestoßen bin habe ich das direkt implementiert. War genau das, was ich gesucht hatte. Seit März läuft das bei mir ohne jedes Problem. Müsste nur mal das Update machen. Läuft bei mir auf nem PI4 mit ner SSD als Datenspeicher.

[lemuba]

@SBorg

Hattest Du eigentlich schon Dein Testgelöt von Lucy/Ecowitt erhalten?
Wollte mal was bei Ecowitt ordern, aber die sind ja anscheinend noch immer im Lockdown/hinten dran mit sehr langen Lieferzeiten... Da kommt auch bald ein Sensor mit einem Wasserdichten Fühler. Wollte dann auch damit meinen Aldi Pool vielleicht etwas smarter machen. Vielleicht ordere ich dann auch den angehenden neuen Luftgütesensor mit CO2 Werten, etc.

Gruss,

Matthias

[lemuba]

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

Tolles Skript. Funktioniert super!

Darf ich mal ne Frage zum WH3000 SE stellen? Der zeigt bei mir sowas von spät an, dass es regnet. Hat noch jemand das Problem? Kann auch sein das es 2 std. leicht regnet u. es nicht angezeigt wird...

DAnke.

Jo, das ist so Konstruktionsbedingt. Der Löffel mit der 0.3mm Auflösung benötigt eben seine Zeit bis er auslöst... Bei leichtem Grissel verdunsten die Tröpfelchen im Trichter, bzw. werden gar nicht gezählt. Kannst den Trichter eventuell mit Teflon beschichten.

http://www.ecowitt.com/news/60.html

Aber definitiv kein Ersatz/Lösung für einen reinrassigen Regensensor der beim ersten Tropfen alarmiert. Beispiel:

https://www.homematic-ip.com/produkte/detail/homematic-ip-regensensor.html

Der Standard Regenmesser einer Wetterstation ist für Bauern und Gärtner Was der nicht erfasst, kommt auch nicht bei der Wurzel an, aber fast 32mm heute
https://www.fitzbek-wetter.de/pwsWDxx/PWS_index2.php

Gruss,
Matthias

[jensfr]

@Rushmed Danke. Die sollten es gewesen sein. Es war auch schon recht viel Wasser in der Schaufel drin. Muss das nochmal etwas beobachten....

[SBorg]

Lese ich immer gerne wenn es funktioniert und natürlich auch wenn es genutzt wird

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

Hattest Du eigentlich schon Dein Testgelöt von Lucy/Ecowitt erhalten?

Nö, Stand heute ist noch nichts eingetrudelt. Über "meinen" Zoll dauert es aktuell 3-4 Monate...
...auch wenn man es nicht unbedingt gerne lesen mag, aber ich habe derzeit sowieso noch 1.000 andere Baustellen. Ist im Grunde also auch nicht weiter tragisch

[Negalein]

Hallo @SBorg

Ich möchte gern so eine Statistik erstellen.
Mit Sourceanalytic geht zB Temperatur nicht.

Hast du eine Idee, wie man die Werte ähnlich Sourceanalytic speichern könnte?

[SBorg]

@Negalein Da ich ein Statistik-Fan bin: gefällt mir
Pauschal kann/könnte ich die Werte auch zur Verfügung, aber dazu wäre eigentlich eine DB geeigneter (wg. der anfallenden Datemenge; ich müsste zumindest für den aktuellen Monat immer alle Werte aktuell halten. Danach den abgelaufenen Monat in 13 neue Datenpunkte verschieben). Ad hoc müssten sich die Werte aber einfacher aus bspw. InfluxDB ziehen lassen.
Ich hatte da mal angefangen (nicht wundern, Wohnzimmer geht nicht mehr so ganz ) :

Das erweitert und am Monatsende die Werte in DPs geschrieben wären IMO der gangbarste Weg.

[Negalein]

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

Ad hoc müssten sich die Werte aber einfacher aus bspw. InfluxDB ziehen lassen.

Influx läuft bei mir bereits. Da könnt ich alle benötigten DP vom Script mal mitschreiben lassen.

Dann stehts bei mir aber schon an. Da bist für den weiteren Weg du meine Hilfe

[SBorg]

@Negalein Ich muss mal schauen was performanter in der Abfrage ist. Habe mal ein kleines JS "zusammen gehämmert" was die Daten per History (hab aber erst gegen Mittag mit dem sammeln begonnen) zieht:

Macht aktuell nur Min/Max/Durchschnitt und °C über 20°C?

Mir war schon klar, dass ich es machen "darf"
Daran liegt es auch nicht, nur ist es direkt über das Script viel zu Ressourcen fressend, dass geht per DB/History und JS performanter (und auch einfacher).
Dann muss ich mir noch was mit dem Datenmanagement und den Datenpunkten überlegen.

• Die Tagestemperaturen sollten so bleiben? Ein 31°C-Tag zählt zu >30 und zu >25 und zu >20 (ja, es war ja auch einer über 20/25°).
• soll(te) das 1x täglich (bspw. Mitternacht) aktualisiert werden? Die Datenmenge wären pro Datenpunkt 86400 / 16 = 5.600 DPs die sonst abgefragt werden müssen. Das sollte man nicht im Minutentakt ausführen ^^

[Negalein]

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

Mir war schon klar, dass ich es machen "darf"

kennst mich doch. Du bist da der King

Daran liegt es auch nicht, nur ist es direkt über das Script viel zu Ressourcen fressend, dass geht per DB/History und JS performanter (und auch einfacher).

kein Problem.

Die Tagestemperaturen sollten so bleiben? Ein 31°C-Tag zählt zu >30 und zu >25 und zu >20 (ja, es war ja auch einer über 20/25°).

genau. Am liebsten so wie am Screenshot. Auch mit den kalten Tagen

soll(te) das 1x täglich (bspw. Mitternacht) aktualisiert werden? Die Datenmenge wären pro Datenpunkt 86400 / 16 = 5.600 DPs die sonst abgefragt werden müssen. Das sollte man nicht im Minutentakt ausführen ^^

Ja, 1x am Tag sollte reichen. Geht eh nur um Tageswerte

[SBorg]

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

Auch mit den kalten Tagen

Das ist auch easy going und recht einfach umzusetzen, ich habe zum testen aber erst mal nur die 4 Werte genutzt.
Aber egal ob es dann per Influx oder History wird, die Anzahl der "warmen/kalten" Tage ist etwas tricky. Ich möchte eigentlich eine Einzelabfrage umgehen, d.h. zB. für August 19 wären das 31 Tage x 13 Messwerte x Anzahl der Messwerte...
Deswegen wird es wohl auf einen JSON-Datenpunkt hinauslaufen, der dann täglich um die entsprechenden Gradtage erhöht wird. Dann brauche ich die Vorjahresmonatsabfrage immer nur einmalig für den Monat ausführen.
...mal drüber schlafen

[Negalein]

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

mal drüber schlafen

Ich werde dich virtuell dabei unterstützen

[SBorg]

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

Ich werde dich virtuell dabei unterstützen

War auch teilweise erfolgreich, wenn auch mehr Fragen offen sind als ich derzeit Antworten habe. Die Werte ermitteln ist "easy peasy", aber die Statistik hat doch so ihre Fallstricke.
Zumindest läuft es aktuell auf InfluxDB hinaus, da es viele (auch wg. Grafana) eh am laufen haben. History produziert nur zusätzlich eine Menge an Daten, ist deutlich langsamer und ineffizient in der Abfrage zu handeln.
Ich hatte zwar zuvor schon eine tägliche Auswertung angedacht, dass muss aber nun so sein, denn eine monatliche Auswertung würde zu lange dauern. Bei einem Turnus von 16 Sekunden der Wetterstation haben wir ~ 5.600 Messwerte pro Tag pro Unit. Wir bräuchten also die Aussentemperaturwerte, Regenmenge und Windgeschwindigkeit. Eine Abfrage der Tageswerte dauert per Influx aber schon 2-3 Sekunden (die Ermittlung der div. Werte ist dabei so gut wie nicht messbar). Da ist die monatliche Abfrage nicht mehr zu handeln: 3 Sek x 3 Abfragen x 30 Tage = ~fast 5(!) Minuten...
...also täglich speichern, einlesen, addieren...
...und so nebenbei mal Gedanken gemacht, wie denn die DPs überhaupt aussehen müssen damit man die dynamisch in der VIS anzeigen kann...

btw: Fragen etc. zum eigentlichen Thread natürlich weiter gerne hier, aber IMHO sind die letzten Posts nicht OT, sondern gehören doch irgendwie zum Thema und es "dürfen" sich auch gerne mehr beteiligen

[SBorg]

@Negalein Dann mal ein erster Test. Neues JS anlegen (am besten in einer neuen Instanz, dann knallt es dir nicht im Fehlerfall den eigentlichen JS-Adapter weg. Sollte zwar nicht, aber man weiß ja nie... ) :

/* Wetterstation-Statistiken 
   (c)2020 by SBorg 
   V0.0.1 - 05.09.2020   erste Alpha + Min/Max/Durchschnitt/Temp über 20°?
   holt die Messwerte aus einer InfluxDB und erstellt eine Statistik
  ToDo: vieles ;)
  known issues: keine
*/

let werte = [];
let zeitstempel = new Date();
let start = new Date(zeitstempel.getFullYear(),zeitstempel.getMonth(),zeitstempel.getDate(),0,0,0);
start = start.getTime();
let end = new Date(zeitstempel.getFullYear(),zeitstempel.getMonth(),zeitstempel.getDate(),23,59,59);
end = end.getTime();

sendTo('influxdb.0', 'query', 'select * FROM "javascript.0.Wetterstation.Aussentemperatur" WHERE time >= ' + (start *1000000) + ' AND time <= ' + (end *1000000), function (result) {

    if (result.error) {
        console.error('Fehler: '+result.error);
    } else {
        //console.log('Rows: ' + JSON.stringify(result.result[0]));
        for (let i = 0; i < result.result[0].length; i++) {
        werte[i] = result.result[0][i].value;
        }
    }

 /*   const json = JSON.stringify(result.result[0][0]);
    const obj = JSON.parse(json);
    console.log(obj.ts);
    console.log(obj.value); */

    Math.sum = (...werte) => Array.prototype.reduce.call(werte,(a,b) => a+b);
    let Durchschnitt = (Math.sum(...werte)/werte.length).toFixed(2);
    if (Math.max(...werte) > 20) {console.log('Temperatur lag heute über 20°C');}
    console.log('Tiefstwert: ' + Math.min(...werte) + '°C');
    console.log('Höchstwert: ' + Math.max(...werte) + '°C');
    console.log('Durchschnitt: ' + Durchschnitt + '°C');
    console.log('Erster Messwert: ' + new Date(result.result[0][0].ts).toISOString() + ' ***' + result.result[0][0].value);
    console.log('Letzter Messwert: ' + new Date(result.result[0][werte.length-1].ts).toISOString() + ' ***' + result.result[0][werte.length-1].value);
    console.log('Anzahl Datensätze: ' + werte.length);
});

function timeConverter(UNIX_timestamp){
  let a = new Date(UNIX_timestamp);
  let months = ['Jan','Feb','Mär','Apr','Mai','Jun','Jul','Aug','Sep','Okt','Nov','Dez'];
  let year = a.getFullYear();
  let month = months[a.getMonth()];
  let date = a.getDate();
  let hour = a.getHours();
  let min = a.getMinutes();
  let sec = a.getSeconds();
  let time = pad(date) + '. ' + month + ' ' + year + ' ' + pad(hour) + ':' + pad(min) + ':' + pad(sec) ;
  return time;
}

function pad(n) {
    return n<10 ? '0'+n : n;
}

console.log('Daten ab ' + timeConverter(start));
console.log('Daten bis ' + timeConverter(end)); 

Anpassen musst du nur #16 ob dein Influx unter Instanz "0" läuft und den DP-Zweig für die Aussentemperatur.
Sollte dann so nach dem starten aussehen:

Interessieren würde mich dann

• allgemeine Laufzeit
• dein System (PI, bzw. CPU + RAM)
• sind die Werte plausibel
• speziell gegen ~23:5x Uhr
  • Laufzeit
  • Anzahl der Datensätze

Wenn der Ansatz so funktioniert werde ich zum "master-Branch" auf GitHub einen "Beta" anlegen, um dort dann das aktuelle JS vor zu halten.

[skokarl]

OT

nur für Euch zur Info, Montag Aldi Nord, allerdings nur Online, Gruß Bernd

[Glasfaser]

++++ inklusiv Support von @skokarl , der demnächst für Neulinge hier kommt ....