NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Danke - leider ist die Abweichung nicht konstant
Ist sie auch nicht. Bis ~14:00 Uhr ist der gap recht groß, dann bis ~19:00 Uhr relativ identisch und dann liegt er sogar darüber. Mit einem festen Wert kann man hier also nicht arbeiten. Vermutlich ist da ein Algorithmus dahinter der auch die Temperatur berücksichtigt.influx mag die Punkte in der Bezeichnung nicht. Man hätte natürlich auch mittels Alias arbeiten können, nur ist es jetzt zu spät, da alles auf der ioB-Syntax aufbaut.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich nehme an eine Umstellung der Solarenergie Werte auf ein einheitlichen Maß (Wh/m² oder kWh/m²) ist nachträglich eher schwer oder?
Eigentlich nicht, aber wegen der bereits seit Anbeginn gesammelten Daten verschiedener User nicht unbedingt sinnvoll. Persönlich gefällt mir ehrlich gesagt die Vereinheitlichung auch nicht gerade, denn der Tageswert ist im Gegensatz zum Jahreswert zu klein. Du hast also entweder eine schlechte Tagesauflösung, viele Nachkommastellen oder sehr große Zahlen.
Was aber wie üblich nicht heißen soll, dass ich für Änderungen nicht zugänglich wäre.
Ich habe es mittlerweile in einer Tabelle, da bei den Balkendiagrammen der Bezug fehlt ("was sind 100% Balkenlänge bei 12:10:23 ?") und er hier in kW, MW etc. umrechnet:
Du könntest aber zB. mittels des Alias-Managers die Umrechnung durchführen, oder dir eine "eigene" Shell-Skript Version erstellen. Änderungen wären zwar bei einem Update wieder weg, aber eine neue Version sehe ich aktuell nur noch bei neuen Sensoren
Die Umrechnung geschieht in der sub so um Zeile 500f:#Leistung berechnen SOL_TMP=$(echo "scale=3;${SOL_TMP}/(3600/${WS_POLL})" | bc -l) SOLARENERGIE_TAG=`echo "scale=3;${SOLARENERGIE_TAG}+${SOL_TMP}" | bc -l` SOLAR_WOCHE=`echo "scale=5;(${SOLAR_WOCHE}+${SOL_TMP})" | bc -l` SOLARENERGIE_WOCHE=`echo "scale=3;${SOLAR_WOCHE}/1000" | bc -l` #Umrechnung in kWh SOLAR_MONAT=`echo "scale=5;(${SOLAR_MONAT}+${SOL_TMP})" | bc -l` SOLARENERGIE_MONAT=`echo "scale=3;${SOLAR_MONAT}/1000" | bc -l` #Umrechnung in kWh SOLAR_JAHR=`echo "scale=5;(${SOLAR_JAHR}+${SOL_TMP})" | bc -l` SOLARENERGIE_JAHR=`echo "scale=3;${SOLAR_JAHR}/1000" | bc -l` #Umrechnung in kWh
Entweder änderst du den Tag hier nach dem Muster Woche/Monat/Jahr ab und teilst dann durch 1000 (=Wert dann in kWh), oder du löschst bei Woche/Monat/Jahr einfach
/1000
, dann hast du alle Werte in Wh. -
@SBorg
Ich habe noch eine Korrektur für deinen WINDCHILL.
Es fehlte noch die Prüfung auf die maximale gültige Temperatur von 10°C.wetterstation.sh
Zeile 214 altif (( $(bc -l <<< "${MESSWERTE[6]} > 5") )); then
Zeile 214 neu
if (( $(bc -l <<< "${MESSWERTE[6]} > 5") )) && (( $(bc -l <<< "${MESSWERTE[1]} < 10") )); then
Grüße
-
@boronsbruder Stimmt, da war doch noch was...
Danke -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Danke - leider ist die Abweichung nicht konstant
Ist sie auch nicht. Bis ~14:00 Uhr ist der gap recht groß, dann bis ~19:00 Uhr relativ identisch und dann liegt er sogar darüber. Mit einem festen Wert kann man hier also nicht arbeiten. Vermutlich ist da ein Algorithmus dahinter der auch die Temperatur berücksichtigt.
Fällt bei Deiner Station der relative und absolute Druck ohne Korrekturfaktor heraus? Oder woher kommen bei Dir die Werte?
Ich verstehe es nicht ganz, sorry, Wenn absoluter und relativer Druck doch über die Höhe und Temperaturdifferenz zu NN/15°C ermittelt werden, warum kann das dann schwanken?
Um ganz präzise zu sein müsste ich eigentlich auf einen 15°C Tag Zeitpunkt warten, und dann sollte nur noch die Höhendifferenz eine Rolle spielen.
Aber auch dann wäre das doch konstant und keine schwankende Kurve?
Und wenn es dann doch irgendwie eine Kurve sein muss, warum kann ich dann nur einen statischen Korrekturfaktor angeben?
Wahrscheinlich ist meine Erwartungshaltung wieder dem Preisgefüge nicht angemessen:pinflux mag die Punkte in der Bezeichnung nicht. Man hätte natürlich auch mittels Alias arbeiten können, nur ist es jetzt zu spät, da alles auf der ioB-Syntax aufbaut.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich nehme an eine Umstellung der Solarenergie Werte auf ein einheitlichen Maß (Wh/m² oder kWh/m²) ist nachträglich eher schwer oder?
Ich habe es mittlerweile in einer Tabelle, da bei den Balkendiagrammen der Bezug fehlt ("was sind 100% Balkenlänge bei 12:10:23 ?") und er hier in kW, MW etc. umrechnet:
Du könntest aber zB. mittels des Alias-Managers die Umrechnung durchführen, oder dir eine "eigene" Shell-Skript Version erstellen. Änderungen wären zwar bei einem Update wieder weg, aber eine neue Version sehe ich aktuell nur noch bei neuen SensorenUnd wie hast Du die Werte umgerechnet? In Grafana oder vorher? In Grafana klappt ja bei mir nicht... wenn das aber nur aufgrund des falschen Datentyps bei mir so ist, dann sollte ich wohl eher das korrigieren anstatt an den Symptomen rumzudoktern.
Tabelle ist auch nicht schlecht, wollte nur etwas was Platz spart, die vielen Felder waren mir etwas verschwenderisch:)
-
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Fällt bei Deiner Station der relative und absolute Druck ohne Korrekturfaktor heraus? Oder woher kommen bei Dir die Werte?
Ich habe nur in der VS-View-App beim Einrichten die Höhe der Station ÜNN angeben müssen. Dann kommen die Werte so vom Display und ich reiche sie 1:1 an den ioB weiter.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich verstehe es nicht ganz, sorry,...
Warum sorry, ich verstehe das auch nicht. Ich bin Elektroniker...
...also sorry von meiner Seite, ich kann dir da keine Erklärung geben. Wahrscheinlich wird aus der aktuellen Temperatur die Temperatur bei NN berechnet und daraus dann der aktuelle Druck?@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wahrscheinlich ist meine Erwartungshaltung wieder dem Preisgefüge nicht angemessen
Glaube ich nicht mal, nur darf man halt nicht unbedingt davon ausgehen, dass 21.3°C dann auch wirklich 21.3°C sind. Da ist die Drift der Sensoren dann halt doch vorhanden und dem Preis geschuldet.
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und wie hast Du die Werte umgerechnet? In Grafana oder vorher? In Grafana klappt ja bei mir nicht...
In Grafana und dann rechnet er per "Unit" von alleine um: 1.000 kWh --> 1 MWh
Mir gefallen die Balken zwar optisch auch besser, aber sie haben hier halt keine Aussagekraft. Der Jahreswert bestimmt dann die Skalierung der anderen Werte, außerdem wird der unabhängig vom Wert immer 100% anzeigen. Du hast ja keinen definierten Endwert (wie z.B. bei einem Tank der 1.000 Liter fasst) und somit keinen Bezugspunkt (außer du wüstest im Vorfeld schon den Jahresendwert ). -
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Fällt bei Deiner Station der relative und absolute Druck ohne Korrekturfaktor heraus? Oder woher kommen bei Dir die Werte?
Ich habe nur in der VS-View-App beim Einrichten die Höhe der Station ÜNN angeben müssen. Dann kommen die Werte so vom Display und ich reiche sie 1:1 an den ioB weiter.
Vielleicht ist das des Pudels Kern... ich gebe einen Offset in hPa unter Calibration an - vielleicht ist das die falsche Stelle?
Die Anleitung von Ecowitt verweist leider auf eine Seite die es nicht mehr gibt, daher habe ich gesucht und nichts anderes gefundenEdit - ok, scheint im GW nicht direkt zu gehen - https://www.wxforum.net/index.php?topic=38214.0
Aber so richtig verstehen wie ich es nun einstellen muss weiss ich immer noch nicht
das GHW lässt beim absoluten Wert nur negative Werte zu, was ja auch ok ist (wenn man nicht unter NN lebt) da der echte Druck ja immer niedriger ist als der bei NN.
Aber was ich dann für den rel. Wert setzen muss weiss ich immer noch nicht.
Wenn ich nichts eintrage dann ist der rel = abs (also auch um ~20 reduziert), also habe ich nun die 20 die abziehe wieder drauf gerechnet, aber damit bin ich immer noch 20 niedriger als der Flughafen Wert (der nur 10 höher sein sollte wg Höhendifferenz)... Alles seltsam@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und wie hast Du die Werte umgerechnet? In Grafana oder vorher? In Grafana klappt ja bei mir nicht...
In Grafana und dann rechnet er per "Unit" von alleine um: 1.000 kWh --> 1 MWh
Ah ok, das tut bei mir wg den Datentypen nicht. Dann muss ich da mal ran ...
Mir gefallen die Balken zwar optisch auch besser, aber sie haben hier halt keine Aussagekraft. Der Jahreswert bestimmt dann die Skalierung der anderen Werte, außerdem wird der unabhängig vom Wert immer 100% anzeigen. Du hast ja keinen definierten Endwert (wie z.B. bei einem Tank der 1.000 Liter fasst) und somit keinen Bezugspunkt (außer du wüstest im Vorfeld schon den Jahresendwert ).
Richtig, aber das ist doch bei der Solarenergie wo Du Balken hattest auch nicht anders, oder? Oder hast Du Die auch in Tabelle gewechselt inzwischen?
Hab Deine Grafana Seiten (wenn sie aktualisiert wurden) lange nicht mehr angeschaut da ich viel zu viel customised hab (weil ja ganz andere Sensoren), aber inzwischen habe ich gelernt das man auch einzelne Panels per Javascript einbauen kann (wenn ich es nicht verwechsele) , also sollte ich mal wieder schauenEine nette Spielerei (in meinem Fall) wäre es wenn man Solarstromausbeute vs verfügbarer Solarenergie charten würde (optional vs vorhergesagter Min/Max Ausbeute). Naja wenn ich mal sonst nichts zu tun hab (oder einen Rappel kriege)
-
@rand Ich baue auch öfters an Grafana, aber die Balken sind schon eine ganze Weile durch Tabellen ersetzt (bisserl runter scrollen):
https://github.com/SBorg2014/WLAN-Wetterstation/tree/master/Grafana Dashboard...und bevor noch einer fragt, nein, natürlich hatte ich im Vorjahr keinen Ertrag von 348 MWh
Das war nur zum testen, der Fusionsreaktor im Keller liefert eh nur im Gigawatt-Bereich... -
Da aktuell keine Fehler vorliegen, V2.7.0 goes final:
Neues Release 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
- ~ Fix Prüfung netcat-Version
- ~ Berechnung Windchill nur bis 11°C
Wie immer zu finden im GitHub
Wegen der neuen Datenpunkte (DP250/WH45-Sensor) muss auch wetterstation.js ersetzt und einmalig ausgeführt werden, zumindest sofern man diesen Sensor nutzen möchte.
Wie üblich wetterstation.sh, -.sub und ws_updater.sh austauschen, ws_updater.sh ausführen und mittelssudo systemctl restart wetterstation
den Service neu startenUpdate ist nicht unbedingt erforderlich, da zwei Punkte nur die Neu-Installation betreffen, ohne passenden Sensor ist auch der DP250/WH45-Teil eher uninteressant. Die Begrenzung des Windchills auf die (korrekten 10°C) wird auch den wenigsten auffallen, zumindest spüre ich nicht ob das jetzt gefühlte 10.4°C oder tatsächlich 10.7°C sind. Die Formel gilt aber nur ab Windgeschwindigkeiten von 5 km/h und bis kleiner 11°C und wird jetzt korrekt berücksichtigt
-
@sborg Hi, super, vielen Dank, genauso hat das Update hier auch funktioniert!
-
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
Die Formel gilt aber nur von 5°C bis ~10°C und wird jetzt korrekt berücksichtigt
Falsch!
Gilt bis max. 10°C und ab 5 km/h Windgeschwindigkeit
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Neues Release des Wetterstation WLAN-Skriptes auf GitHub V2.7.0
wiedermal will es nicht so wie ich möchte
wetterstation.sh & .sub ausgetauscht
./ws_updater.sh gestartetEs kommt nur
dietpi@DietPi:~$ cd /home/iobroker dietpi@DietPi:/home/iobroker$ ./ws_updater.sh 'bc' installiert: ✓ 'jq' installiert: ✓ Updater ist nur für Versionen ab V1.4.0 ! dietpi@DietPi:/home/iobroker$
.conf bleibt unverändert (ersichtlich am Dateidatum)
was mach ich wieder falsch?
-
@negalein Sorry, my fault
Habe es jetzt oben mal deutlicher geschrieben. Du musst auch den aktuellen ws_upsater.sh nutzen (also ebenfalls ersetzen).
Also Version 1.2.3 des Updaters zu Version 1.2.3 des Skriptes. Muss nämlich jetzt so aussehen (bei dir fehlt die Versionsausgabe = Updater auf 2.6.0 und der kann mit 2.7.0 noch nix anfangen):
-
@boronsbruder lt. Wiki nicht bis 10° sondern ca. 10°C. Da es eine Berechnung ist, auch wenn man bei 10.99 eher von 11 sprechen würde, sind es dann trotzdem noch immer 10. Runden darf man hier eigentlich auch nicht, denn sonst bewirkt eine Eingangsänderung von einem hundertstel (!) Grad eine Ausgangsänderung von einem Grad.
Irgendwo muss man halt die Grenze setzen. Das kann man nun sehen wie man will, aber mache ich es nun nach Schema A, sind wieder welche die es aber lieber nach Schema B wollen...
Aber im Grunde ist es eh nonsens, denn der Temperatursensor ist ungenau, der Windmesser ebenso, und wenn wir schon dabei sind, die Berechnung ist eigentlich auch nur gültig wenn der Wind 10 Meter über Grund (nicht in 10 Meter Höhe) gemessen wird. Wer hat schon einen 10m-Mast im Garten stehen und wie ich deswegen auch oben schon schrieb, wer wird auf der Haut fühlen ob das nun tatsächlich 10.4° oder 10.7° C sind... -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Sorry, my fault
Danke, läuft!
Nächste Frage/Problem!
Ich hab gerade das neue V8 Dashboard importiert.
2 DP kann ich nicht zuordnen. Magst du das Script hier zur Verfügung stellen?
Windrose:
Plugin ist installiert, bekomme aber im Dashboard einen Fehler.
Funktioniert plötzlich!
Aussentemperatur steht nur N/A, obwohl der DP passt.
Im alten Dashboard wird er angezeigt.
hier verwendest du ein paar Alias.
Auf was beziehen sich die? Dann könnte ich die orig. DP verwenden. Bin mit Alias auf Kriegsfuss. -
@negalein hehe, genau so hats mich beim letzten update auf die schnauze gehaun. die ws_updater.sh gehört auch raufgejubelt...
-
Man kann auch direkt den aktuellen Updater von GitHub nutzen (per Terminal):
bash <(curl -sLf https://raw.githubusercontent.com/SBorg2014/WLAN-Wetterstation/master/ws_updater.sh)
Es sei aber erwähnt, dass man hier die Kontrolle abgibt. Mit obiger Zeile führt ihr das entsprechende Skript einfach aus.
Das macht zwar auch jeder bei der ioB-Installation, ich möchte es dennoch erwähnen. Mir ist aber auch bewusst, dass wohl 99% der User eh die *.sh's und *.sub ausführen ohne dort jemals hineinzuschauen. Da macht es dann auch keinen Unterschied mehr ob man es direkt ausführt...
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Magst du das Script hier zur Verfügung stellen?
Nö
Ich habe mal paar Werte zur Veranschaulichung von mir drinnen gelassen. Es ermittelt Max_24h, Min_24h, Mean_24h, Median_24h, Max_1h, Min_1h und Mean_1h (vom Datenpunkt):/* ######################################################################################################## Berechnung von gleitendem Durchschnitt, Minimum und Maximum über einen Zeitraum von 1h und 24h Version 1.4.1 ######################################################################################################## Berechnet Min/Max, Durschschnitt und Median über die letzten 24h. Berechnet Min/Max, Durschschnitt über die letzte 1h. IDs aller benötigten Datenpunkte Als Array im Array mit folgendem Format: 1. original Datenpunktname 2. neuer Datenpunktname Beispiel: javascript.0.Status.Temperatur.Außen javascript.0.Status.Luftfeuchtigkeit.Außen 3. Beschreibung des Messwertes (zur Erzeugung neuer Datenpunkte) Beispliele: Temperatur Luftfeuchtigkeit 4. Einheit (zur Erzeugung neuer Datenpunkte) Beispiele: °C, %H Ist beliebig erweiterbar und für beliebige Werte nutzbar. */ "use strict"; const idData = [['javascript.0.Wetterstation.Innentemperatur','javascript.0.Statistik.Temperatur.Wohnzimmer','Temperatur','°C'], ['javascript.0.Temperaturen.Zimmer.Buero.Temp_Buero','javascript.0.Statistik.Temperatur.Buero','Temperatur','°C'], ['javascript.0.Wetterstation.Aussentemperatur','javascript.0.Statistik.Temperatur.Außen','Temperatur','°C'], ['javascript.0.Wetterstation.Innenfeuchtigkeit','javascript.0.Statistik.Luftfeuchtigkeit.Wohnzimmer','Luftfeuchtigkeit','%H']]; //Datenpunkt zur Speicherung aller internen Daten const dpData='javascript.0.Statistik.Statistic'; // ######################################################################################################## // Implementierung -- hier nichts mehr ändern // ######################################################################################################## // globale Konstanten const tc = 5; // Abtastrate in Minuten const statDataLength24 = Math.round((24 * 60) / tc); // Anzahl der Werte für 24h const statDataLength1 = Math.round(60 / tc); // Anzahl der Werte für stündlich // globale Variablen var listStatData; //interne Speicherung aller Werte //Funktion zum einmaligem initialisieren aller Datenpunkte function initializeStatData() { // Datenpunkt zur Speicherung der internen Werte erzeugen createState(dpData, 0, false, { name: "StatisticData", read: true, write: true, desc: 'Statistische Daten', type: 'string', def: '', role: 'json' }); //internes Array initialisieren var needInit = false; try { listStatData = JSON.parse(getState(dpData).val); } catch (ex) { needInit = true; } if (needInit || !listStatData || (listStatData.length < idData.length)) { listStatData = new Array(idData.length); } //logDebug('initializeStatData for', dpData, listStatData); for (var i = 0; i < idData.length; i++) { if (!listStatData[i]) { listStatData[i] = {}; } listStatData[i].value = idData[i][1]; listStatData[i].max24h = idData[i][1] + '.Max_24h'; listStatData[i].min24h = idData[i][1] + '.Min_24h'; listStatData[i].mean24h = idData[i][1] + '.Mean_24h'; listStatData[i].median24h = idData[i][1] + '.Median_24h'; listStatData[i].max1h = idData[i][1] + '.Max_1h'; listStatData[i].min1h = idData[i][1] + '.Min_1h'; listStatData[i].mean1h = idData[i][1] + '.Mean_1h'; createState(listStatData[i].value, 0, false, { name: idData[i][2], read: true, write: true, desc: idData[i][2]+ ' Aktueller Wert', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].max24h, 0, false, { name: 'Maximum_24h', read: true, write: true, desc: idData[i][2] + ' Maximum', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].min24h, 0, false, { name: 'Minimum_24h', read: true, write: true, desc: idData[i][2] + ' Minimum', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].mean24h, 0, false, { name: 'Mittelwert_24h', read: true, write: true, desc: idData[i][2] + ' Mittelwert', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].median24h, 0, false, { name: 'Median_24h', read: true, write: true, desc: idData[i][2] + ' Median', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].max1h, 0, false, { name: 'Maximum_1h', read: true, write: true, desc: idData[i][2] + ' Maximum', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].min1h, 0, false, { name: 'Minimum_1h', read: true, write: true, desc: idData[i][2] + ' Minimum', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); createState(listStatData[i].mean1h, 0, false, { name: 'Mittelwert_1h', read: true, write: true, desc: idData[i][2] + ' Mittelwert', type: 'number', def: 0, unit: idData[i][3], role: 'value' }); if (needInit || !listStatData[i].data || (listStatData[i].data.length != statDataLength24)) { listStatData[i].data = new Array(statDataLength24); // 1. Script start: Liste und String-Datenpunkt füllen var x = getState(idData[i][0]).val; for (var j = 0; j < statDataLength24; j++) { listStatData[i].data[j] = x; } //logDebug(listStatData[i], i); setStateDelayed(listStatData[i].value, x, false, 1000); setStateDelayed(listStatData[i].min24h, x, false, 1000); setStateDelayed(listStatData[i].max24h, x, false, 1000); setStateDelayed(listStatData[i].mean24h, x, false, 1000); setStateDelayed(listStatData[i].median24h, x, false, 1000); setStateDelayed(listStatData[i].min1h, x, false, 1000); setStateDelayed(listStatData[i].max1h, x, false, 1000); setStateDelayed(listStatData[i].mean1h, x, false, 1000); } } setState(dpData, JSON.stringify(listStatData)); } //Berechnung der Werte function calcStatData() { if (!listStatData || (idData.length != listStatData.length)) { initializeStatData(); } //logDebug('starting calcStatData'); for (var i = 0; i < idData.length; i++) { listStatData[i].data.pop(); //Remove the last element of an array var x = parseFloat(getState(idData[i][0]).val); listStatData[i].data.unshift(x); //Add new items to the beginning of an array setState(listStatData[i].value, x); var min = x; var max = x; var sum = 0.0; for (var j = 0; j < statDataLength24; j++) { var s = parseFloat(listStatData[i].data[j]); if (s < min) min = s; if (s > max) max = s; sum += s; if (j == (statDataLength1-1)) { setState(listStatData[i].min1h, min); setState(listStatData[i].max1h, max); setState(listStatData[i].mean1h, round(sum / statDataLength1, 2)); } } setState(listStatData[i].min24h, min); setState(listStatData[i].max24h, max); setState(listStatData[i].mean24h, round(sum / statDataLength24, 2)); setState(listStatData[i].median24h, getMedian(listStatData[i].data)); } setState(dpData, JSON.stringify(listStatData)); } function getMedian(args) { if (!args.length) {return 0} var numbers = args.slice(0).sort((a,b) => a - b); var middle = Math.floor(numbers.length / 2); var isEven = numbers.length % 2 === 0; return isEven ? (numbers[middle] + numbers[middle - 1]) / 2 : numbers[middle]; } /** * round a number * @param value to round * @param exp exponent to round * @returns the round number */ function round(value, exp) { if (typeof exp === 'undefined' || +exp === 0) return Math.round(value); value = +value; exp = +exp; if (isNaN(value) || !(typeof exp === 'number' && exp % 1 === 0)) return NaN; // Shift var values = value.toString().split('e'); value = Math.round(+(values[0] + 'e' + (values[1] ? (+values[1] + exp) : exp))); // Shift back values = value.toString().split('e'); return +(values[0] + 'e' + (values[1] ? (+values[1] - exp) : -exp)); } initializeStatData(); schedule('*/' + tc + ' * * * *', function () { calcStatData(); });
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Aussentemperatur steht nur N/A, obwohl der DP passt.
Im alten Dashboard wird er angezeigt.Stell mal bei "FROM" von "autogen" auf "default" um, dann sollte es funktionieren (lt. des diesbzgl. 2. Screenys).
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
hier verwendest du ein paar Alias.
Auf was beziehen sich die? Dann könnte ich die orig. DP verwenden. Bin mit Alias auf Kriegsfusshttps://forum.iobroker.net/post/654787
Das sind Übertragung an OSEM/Windy erfolgreich,
Batteriestatus Wettermast, Kommunikation OK (bzw. Fehler),
EasyWeather-Firmware up-to-date und versteckt das Bomm-Theme-PanelAlias' sind (oder waren, hab es mit der neuen Grafana-Version noch nicht probiert) nötig, da die DPs Boolean sind und Grafana damit nicht umgehen kann. Die Alias' setzen dann einfach false/true nach 0/1 um
-
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Danke - leider ist die Abweichung nicht konstant
Ist sie auch nicht. Bis ~14:00 Uhr ist der gap recht groß, dann bis ~19:00 Uhr relativ identisch und dann liegt er sogar darüber. Mit einem festen Wert kann man hier also nicht arbeiten. Vermutlich ist da ein Algorithmus dahinter der auch die Temperatur berücksichtigt.Nur der Vollständigkeit halber:
Ich glaube das liegt an den beiden unterschiedlichen Skalen...Ich habe jetzt einen statischen Wert eingetragen (basierend auf der Differenz zwischen meinem Absoluten Messwert und dem nächsten geeichten Messpunkt, [@Boronsbruder 's Vorschlag mit https://en.allmetsat.com/metar-taf/germany.php?icao=ETHL] umgerechnet mit https://rechneronline.de/barometer/hoehe.php auf meine Höhe und aktuelle Temperatur.
(Das ist zwar noch nicht wirklich richtig, da mein absoluter Wert rein rechnerisch ~1,5bar zu niedrig ist (für die Höhe/Temperaratur) aber das wird den Ungenauigkeiten geschuldet sein. Leider kann das GW keine positiven Korrekturwerte für den absoluten Druck - wer unter dem Meereslevel wohnt hat Pech gehabt...)Auch bei mir zeigt der Chart das es tageszeitliche "Unterschiede" gibt, die aber bei genauerem Hinsehen gar nicht vorhanden sind:
Detail - Chart identisch, Differenz von 11 bar (entspricht dem eingestellten Korrekturwert)
Detail - Chart unterschiedlich, Differenz von 11 bar
Zum Thema "erst mal kein weiteres Release" - Es gibt eine neues GW bei Ecowitt (GW1100) welches natürlich auch neue Sensoren unterstützt...
https://www.ecowitt.com/shop/goodsDetail/107
Es ersetzt das alte GW1000 scheinbar ab sofort... -
@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Zum Thema "erst mal kein weiteres Release"
Bezog sich auch mehr von meiner Seite aus, da ich aktuell nicht wüsste was noch hinein soll, zumindest habe ich nix mehr auf der Agenda. Bugs ausmerzen oder neue Sensoren sind da natürlich außen vor
Da die Gateways eh nicht unterschieden werden dürfte das neue auch keine Probleme bereiten und sollte auf Anhieb laufen. So zumindest die Theorie...Hmm, bei mir ist da schon ein Unterschied, wenn auch nur 1 hPa. Allerdings schwankt bei mir aktuell der Luftdruck ~3 hPa pro Tag, dann ist 1 hPa Unterschied doch schon recht viel (19 vs 20):
Sensortoleranz kann es nicht sein, ist ja nur einer. Aber die Temperatur lag da um ~4°C auseinander...? -
@sborg
die "ca. 10°C" kritisiere ich nicht, sondern deine "von 5°C".
Die Formel gilt auch bei -40°C, aber ab Windgeschwindigkeiten von mehr als 5 km/h. Unter 5 km/h können laut Wiki-Temperaturen über der realen Temperatur als Ergebnis entstehen. -
@boronsbruder Danke, jetzt hat es Klick gemacht. Ist/war aber nur ein reiner Typo-Fehler, im Skript ist es korrekt
Im Release-Thread geändert:
...Die Formel gilt aber nur ab Windgeschwindigkeiten von 5 km/h und bis kleiner 11°C und wird jetzt korrekt berücksichtigt...