NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@sborg
Oh Mann, da hätte ich doch auch selbst drauf kommen können. Ich war in einem anderen Zusammenhang schon über Mehrfachwerte bei Flux-Abfragen gestolpert...Aber OK, der Reihe nach.
Ich habe beim Umstieg auf Influx 2.7 eine neue IOBroker DB "iobroker2/global" angelegt. Die alten "iobroker/global" und "iobroker/autogen wurden ja automatisch beim Influx-Umstieg migriert.
Im IOBroker habe ich dann im Influx-Adapter das Häkchen für "Verwende Tags, anstelle von Feldern,..." gesetzt, da es mir immer spanisch vorkam, dass die als Felder geschrieben wurden (passte nicht zu der Erklärung in der Influx-Doku).
Ich hatte auch die Hoffnung, dass das den Arbeitsspeicherhunger der Influx etwas bändigen könnte, an der Stelle hat es aber nicht geholfen, die gönnt sich immer noch 50% mehr als vor dem Umstieg die 1.8.x.
Dafür ist, nach umkopieren der alten "iobroker/global" in die neue "iobroker2/global" die Datenbank auf der SSD keine 1,6GB mehr groß sondern nur noch 600MB.Allerdings zum eigendlichen Problem:
Eine Abfrage in Flux liefert die Ergebnisse dann immer sortiert in "tables". Die Tables haben immer die identischen Werte der Tags gruppiert.
D.h. alles was an Tags q=0, ack=true, from=system.adapter.influxdb.0 hat landet in einem Table. Alles was q=0, ack=true, from=system.adapter.simple-api.0 im nächsten. Wenn q nicht gleich 0 oder ack=false gibt es weitere tables.Heißt, man muß diese Tables vor dem min/max/mean, bzw. generell vor dem Weiterverarbeiten, erstmal zusammenführen.
Das habe ich bei dem oben genannten "anderen Zusammenhang" durch ein zwischengeschaltetes:
|> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"])gemacht.
Was natürlich die Gefahr birgt, dass der Influx-Adapter in Zukunft mal weitere Tags einführt...Es ginge auch mit einem:
|> keep(columns: ["_value"]) |> sort(columns: ["_time"])dann ist die Ausgabe aber anders formatiert.
Beispiele:
Die Ursprungs-query aus der wetterstation.sub "influx_query()" Funktion liefert dieses Ergebnis:influx query 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> max()' Result: _result Table: keys: [_start, _stop, _field, _measurement, ack, from, q] _start:time _stop:time _field:string _measurement:string ack:string from:string q:string _time:time _value:float ------------------------------ ------------------------------ ---------------------- ------------------------------------------- ---------------------- ------------------------- ---------------------- ------------------------------ ---------------------------- 2023-08-19T11:50:41.246763433Z 2023-08-20T11:50:41.246763433Z value javascript.0.Wetterstation.Aussentemperatur true system.adapter.influxdb.0 0 2023-08-19T12:16:26.633000000Z 31.22 Table: keys: [_start, _stop, _field, _measurement, ack, from, q] _start:time _stop:time _field:string _measurement:string ack:string from:string q:string _time:time _value:float ------------------------------ ------------------------------ ---------------------- ------------------------------------------- ---------------------- --------------------------- ---------------------- ------------------------------ ---------------------------- 2023-08-19T11:50:41.246763433Z 2023-08-20T11:50:41.246763433Z value javascript.0.Wetterstation.Aussentemperatur true system.adapter.simple-api.0 0 2023-08-19T12:15:26.615000000Z 31.22Ergänzt mit dem "drop" und "sort" nur noch ein Table:
influx query 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"]) |> max()' Result: _result Table: keys: [_start, _stop, _field, _measurement] _start:time _stop:time _field:string _measurement:string _time:time _value:float ------------------------------ ------------------------------ ---------------------- ------------------------------------------- ------------------------------ ---------------------------- 2023-08-19T11:57:11.324077570Z 2023-08-20T11:57:11.324077570Z value javascript.0.Wetterstation.Aussentemperatur 2023-08-19T12:15:26.615000000Z 31.22Das sieht dann meiner Meinung nach so aus, wie dass, was Deine Abfrage liefert (hier an einer anderen meiner DBs, die keine Tags hat, probiert):
influx query 'from(bucket: "vito2/autogen") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "vito" and r._field == "TempAtp") |> max()' Result: _result Table: keys: [_start, _stop, _field, _measurement] _start:time _stop:time _field:string _measurement:string _time:time _value:float ------------------------------ ------------------------------ ---------------------- ---------------------- ------------------------------ ---------------------------- 2023-08-19T12:03:41.255250302Z 2023-08-20T12:03:41.255250302Z TempAtp vito 2023-08-19T12:35:00.000000000Z 28.6Nur zur Ergänzung: die Ausgabe mit dem "keep" sieht völlig anders (und viel übersichtlicher) aus:
influx query 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> keep(columns: ["_value"]) |> sort(columns: ["_time"]) |> max()' Result: _result Table: keys: [] _value:float ---------------------------- 31.22Was ich jetzt noch nicht ausprobiert habe ist, ob das Resultat identisch aussieht, wenn man anstatt der influx-cli zum Abfragen curl nimmt (wie in Deinem Script)?!
Und was ich so ad hoc auch nicht absehen kann: Ob ein Ergänzen der Query in der Funktion influx_query() um das "drop" und "sort" an anderer Stelle eine negative Auswirkung hat?!
NaJa, Versuch macht kluch... ich baue es mal in die .sub ein und teste mit --influx_test und --metsommer
Gruß
Hefo@SBorg
Schade, das war wohl zu einfach gedacht...pi@rpi-heizung:~/wetterstation $ ./wetterstation.sh --influx_test Testing InfluxDB... min/max Aussentemperatur 24h: 18.77°C 29.61°C pi@rpi-heizung:~/wetterstation $ ./wetterstation.sh --metsommer (standard_in) 12: illegal character: : (standard_in) 12: syntax error (standard_in) 12: illegal character: : Daten vom 01.06.2023 bis 31.08.2023 wurden ermittelt... Ø-Temperatur: °C Regenmenge : 20230831235959 l/m²Die min & max bekommt er so hin, den mean anscheinend nicht... (Regen ist klar, ist ja eine andere Abfrage im sub).
Warum auch immer ist die Sortierung der Felder eine andere bei mean als bei min/max und bei min/max ist auch noch der Zeitpunkt des min/max dabei:
curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"]) |> min()' ,result,table,_start,_stop,_time,_value,_field,_measurement ,_result,0,2023-08-19T19:04:42.48857557Z,2023-08-20T19:04:42.48857557Z,2023-08-20T02:08:35.984Z,18.77,value,javascript.0.Wetterstation.Aussentemperatur curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"]) |> mean()' ,result,table,_start,_stop,_field,_measurement,_value ,_result,0,2023-08-19T19:04:46.528387642Z,2023-08-20T19:04:46.528387642Z,value,javascript.0.Wetterstation.Aussentemperatur,23.941339648173376Mit dem "keep" wären beide Results gleich formatiert, nur halt etwas anders / kürzer als bis jetzt in Deinem Script:
curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> keep(columns: ["_value"]) |> sort(columns: ["_time"]) |> mean()' ,result,table,_value ,_result,0,23.941460117170056 curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> keep(columns: ["_value"]) |> sort(columns: ["_time"]) |> max()' ,result,table,_value ,_result,0,29.61Gruß
Hefo -
@SBorg
Schade, das war wohl zu einfach gedacht...pi@rpi-heizung:~/wetterstation $ ./wetterstation.sh --influx_test Testing InfluxDB... min/max Aussentemperatur 24h: 18.77°C 29.61°C pi@rpi-heizung:~/wetterstation $ ./wetterstation.sh --metsommer (standard_in) 12: illegal character: : (standard_in) 12: syntax error (standard_in) 12: illegal character: : Daten vom 01.06.2023 bis 31.08.2023 wurden ermittelt... Ø-Temperatur: °C Regenmenge : 20230831235959 l/m²Die min & max bekommt er so hin, den mean anscheinend nicht... (Regen ist klar, ist ja eine andere Abfrage im sub).
Warum auch immer ist die Sortierung der Felder eine andere bei mean als bei min/max und bei min/max ist auch noch der Zeitpunkt des min/max dabei:
curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"]) |> min()' ,result,table,_start,_stop,_time,_value,_field,_measurement ,_result,0,2023-08-19T19:04:42.48857557Z,2023-08-20T19:04:42.48857557Z,2023-08-20T02:08:35.984Z,18.77,value,javascript.0.Wetterstation.Aussentemperatur curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> drop(columns: ["ack", "from", "q"]) |> sort(columns: ["_time"]) |> mean()' ,result,table,_start,_stop,_field,_measurement,_value ,_result,0,2023-08-19T19:04:46.528387642Z,2023-08-20T19:04:46.528387642Z,value,javascript.0.Wetterstation.Aussentemperatur,23.941339648173376Mit dem "keep" wären beide Results gleich formatiert, nur halt etwas anders / kürzer als bis jetzt in Deinem Script:
curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> keep(columns: ["_value"]) |> sort(columns: ["_time"]) |> mean()' ,result,table,_value ,_result,0,23.941460117170056 curl -sk --request POST "1.2.3.4:8086/api/v2/query?org=HomeData" --header 'Content-Type: application/vnd.flux' --header 'Accept: application/csv' --header "Authorization: Token MeinToken==" --data 'from(bucket: "iobroker2/global") |> range(start: -1d, stop: now()) |> filter(fn: (r) => r._measurement == "javascript.0.Wetterstation.Aussentemperatur" and r._field == "value") |> keep(columns: ["_value"]) |> sort(columns: ["_time"]) |> max()' ,result,table,_value ,_result,0,29.61Gruß
Hefo@SBorg
So, ich glaube, jetzt klappt es...Die Funktionen influx_query und metsommer sehen bei mir jetzt so aus und liefern richtige Werte:
influx_query() { #1 Timerange start #2 Timerange stop #3 Measurement #4 min,max,mean IFS="," ii=0 local TMP_DATA=$(curl -sk --request POST "${INFLUX_WEB}://${INFLUX_API}/api/v2/query?org=${INFLUX_ORG}" --header 'Content-Type: application/vnd.flux' \ --header 'Accept: application/csv' --header "Authorization: Token ${INFLUX_TOKEN}" \ --data 'from(bucket: "'${INFLUX_BUCKET}'") |> range(start: '$1', stop: '$2') |> filter(fn: (r) => r._measurement == "'${PRE_DP}'.'$3'" and r._field == "value") |> keep(columns: ["_value", "_time"]) |> sort(columns: ["_time"]) |> '$4'()') local TDATA=(${TMP_DATA[*]}) echo ${TDATA[-1]}|tr -d '\t\r\n' unset TDATA unset TMP_DATA }Geändert nur die Zeilen 11 & 14 und ein paar Zeilen gelöscht.
metsommer() { if [ ! -z ${INFLUX_BUCKET} ]; then if [ $(date +%m) -ge "6" ] && [ $(date +%m) -le "8" ] || [ ! -z ${metsom_override} ]; then if [ $(date +%m) -le "5" ]; then echo -e "\n ${RE}Eine Berechnung der meteorologischen Sommerwerte kann für das aktuelle Jahr $(date +%Y) erst ab dem 01. Juni durchgeführt werden!${NO}\n";exit 1; fi local FLUXSTART=$(date +%Y-06-01)"T00:00:00Z" local FLUXENDE=$(date +%Y-08-31)"T23:59:59Z" MET_SOMMER_TEMP_AVG=$(influx_query "${FLUXSTART}" "${FLUXENDE}" "Aussentemperatur" "mean") if [ -z "${MET_SOMMER_TEMP_AVG}" ]; then SAPI "Single" "set/${DP_MET_SOMMER_TEMP}?value=99.99&ack=true" else MET_SOMMER_TEMP_AVG=$(round ${MET_SOMMER_TEMP_AVG} 2) SAPI "Single" "set/${DP_MET_SOMMER_TEMP}?value=${MET_SOMMER_TEMP_AVG}&ack=true" fi local TMP_REGEN=$(curl -sk --request POST "${INFLUX_WEB}://${INFLUX_API}/api/v2/query?org=${INFLUX_ORG}" --header 'Content-Type: application/vnd.flux' \ --header 'Accept: application/csv' --header "Authorization: Token ${INFLUX_TOKEN}" \ --data 'from(bucket: "'${INFLUX_BUCKET}'") |> range(start: '${FLUXSTART}', stop: '${FLUXENDE}') |> filter(fn: (r) => r._measurement == "'${PRE_DP}'.Regen_Tag" and r._field == "value") |> keep(columns: ["_value", "_time"]) |> sort(columns: ["_time"]) |> aggregateWindow(every: 1d, fn: max) |> sum()') local IFS="," local TDATA=(${TMP_REGEN[*]}) MET_REGEN=$(echo ${TDATA[-1]} | tr -cd [:digit:]\.) echo $MET_REGEN if [ -z "${MET_REGEN}" ]; then SAPI "Single" "set/${DP_MET_SOMMER_REGEN}?value=999.9&ack=true" else SAPI "Single" "set/${DP_MET_SOMMER_REGEN}?value=${MET_REGEN}&ack=true" fi if [ ! -z ${metsom_override} ]; then echo -e "\n Daten vom 01.06.$(date +%Y) bis 31.08.$(date +%Y) wurden ermittelt...\n" echo -e "\t Ø-Temperatur: ${GR}${MET_SOMMER_TEMP_AVG} °C${NO}" echo -e "\t Regenmenge : ${GR}${MET_REGEN} l/m²${NO}\n" fi unset metsom_override fi fi }Geändert nur die Zeilen 18 & 23
Ich lasse es mal ein paar Tage laufen und melde mich dann mit einem Ergebnis...
Gruß
Hefo -
@nhet sagte in [Linux Shell-Skript] WLAN-Wetterstation:
W/m²
Goggle findet:
Ambient Weather Support
Why Is The Lux To W / M^ 2 Conversion Factor 126.7?Da spielt nämlich ein Lichtspektrum rein...
Und die Stationen rechnen das auch nur um, weil sie Lux messen. siehe hierBei Ecowitts kann man auch umstellen, welche Einheit man möchte klux oder W/m2 oder Kfc (wobei ich nicht so auf Hähnchen stehe :rolling_on_the_floor_laughing: )
evtl auch bei BresserZitat aus der Bedienungsanleitung:
Hinweis: Die folgenden Details sind so aufgelistet wie sie auf dem Display angezeigt werden oder ablaufen. Lichtintensitätseinheit Klux, Kfc and W/m² Anzeigebereich 0 ~ 200Klux Auflösung Klux, Kfc und W/m² (2 Dezimalstelle -
@SBorg
So, ich glaube, jetzt klappt es...Die Funktionen influx_query und metsommer sehen bei mir jetzt so aus und liefern richtige Werte:
influx_query() { #1 Timerange start #2 Timerange stop #3 Measurement #4 min,max,mean IFS="," ii=0 local TMP_DATA=$(curl -sk --request POST "${INFLUX_WEB}://${INFLUX_API}/api/v2/query?org=${INFLUX_ORG}" --header 'Content-Type: application/vnd.flux' \ --header 'Accept: application/csv' --header "Authorization: Token ${INFLUX_TOKEN}" \ --data 'from(bucket: "'${INFLUX_BUCKET}'") |> range(start: '$1', stop: '$2') |> filter(fn: (r) => r._measurement == "'${PRE_DP}'.'$3'" and r._field == "value") |> keep(columns: ["_value", "_time"]) |> sort(columns: ["_time"]) |> '$4'()') local TDATA=(${TMP_DATA[*]}) echo ${TDATA[-1]}|tr -d '\t\r\n' unset TDATA unset TMP_DATA }Geändert nur die Zeilen 11 & 14 und ein paar Zeilen gelöscht.
metsommer() { if [ ! -z ${INFLUX_BUCKET} ]; then if [ $(date +%m) -ge "6" ] && [ $(date +%m) -le "8" ] || [ ! -z ${metsom_override} ]; then if [ $(date +%m) -le "5" ]; then echo -e "\n ${RE}Eine Berechnung der meteorologischen Sommerwerte kann für das aktuelle Jahr $(date +%Y) erst ab dem 01. Juni durchgeführt werden!${NO}\n";exit 1; fi local FLUXSTART=$(date +%Y-06-01)"T00:00:00Z" local FLUXENDE=$(date +%Y-08-31)"T23:59:59Z" MET_SOMMER_TEMP_AVG=$(influx_query "${FLUXSTART}" "${FLUXENDE}" "Aussentemperatur" "mean") if [ -z "${MET_SOMMER_TEMP_AVG}" ]; then SAPI "Single" "set/${DP_MET_SOMMER_TEMP}?value=99.99&ack=true" else MET_SOMMER_TEMP_AVG=$(round ${MET_SOMMER_TEMP_AVG} 2) SAPI "Single" "set/${DP_MET_SOMMER_TEMP}?value=${MET_SOMMER_TEMP_AVG}&ack=true" fi local TMP_REGEN=$(curl -sk --request POST "${INFLUX_WEB}://${INFLUX_API}/api/v2/query?org=${INFLUX_ORG}" --header 'Content-Type: application/vnd.flux' \ --header 'Accept: application/csv' --header "Authorization: Token ${INFLUX_TOKEN}" \ --data 'from(bucket: "'${INFLUX_BUCKET}'") |> range(start: '${FLUXSTART}', stop: '${FLUXENDE}') |> filter(fn: (r) => r._measurement == "'${PRE_DP}'.Regen_Tag" and r._field == "value") |> keep(columns: ["_value", "_time"]) |> sort(columns: ["_time"]) |> aggregateWindow(every: 1d, fn: max) |> sum()') local IFS="," local TDATA=(${TMP_REGEN[*]}) MET_REGEN=$(echo ${TDATA[-1]} | tr -cd [:digit:]\.) echo $MET_REGEN if [ -z "${MET_REGEN}" ]; then SAPI "Single" "set/${DP_MET_SOMMER_REGEN}?value=999.9&ack=true" else SAPI "Single" "set/${DP_MET_SOMMER_REGEN}?value=${MET_REGEN}&ack=true" fi if [ ! -z ${metsom_override} ]; then echo -e "\n Daten vom 01.06.$(date +%Y) bis 31.08.$(date +%Y) wurden ermittelt...\n" echo -e "\t Ø-Temperatur: ${GR}${MET_SOMMER_TEMP_AVG} °C${NO}" echo -e "\t Regenmenge : ${GR}${MET_REGEN} l/m²${NO}\n" fi unset metsom_override fi fi }Geändert nur die Zeilen 18 & 23
Ich lasse es mal ein paar Tage laufen und melde mich dann mit einem Ergebnis...
Gruß
Hefo@hefo
Na, da warst du aber fleißig :)Sieht soweit auch gut aus, nur den
echo $MET_REGEN
würde ich bald raus nehmen, da wir hier auf Betriebssystemebene sind und du dir sonst das Syslog mit den Regenwerten voll müllst.
-
@sborg Ich hab mich jetzt auch mal bei Awekas angemeldet und wollte mittesten. In der Config habe ich jetzt Benutzernamen und Passwort eingetragen und auf true gestellt. In den Datenpunkten im ioBroker sehe ich aber immer noch 'awekas_at = false'. Ich habs dann mal im --debug laufen lassen: hier sah ich dann beim "https://ws.awekas.at/weatherstation/updateweatherstation.php?ID=MeinUser&PASSWORD=&dateutc=2023..." das hier kein Password zu sehen ist. Ist das so richtig oder muss das Password irgendwie "behandelt" werden?
Was hat es denn mit der API auf sich? Und was genau soll der neue Adapter von Awekas machen? (Fragen über Fragen).
Host: Fujitsu Intel(R) Pentium(R) CPU G4560T, 32 GB RAM, Proxmox 8.x + lxc Ubuntu 22.04
ioBroker (8 GB RAM) Node.js: 20.19.1, NPM: 10.8.2, js-Controller: 7.0.6, Admin: 7.6.3
Wetterstation: Froggit WH3000SE V1.6.6 -
@sborg Ich hab mich jetzt auch mal bei Awekas angemeldet und wollte mittesten. In der Config habe ich jetzt Benutzernamen und Passwort eingetragen und auf true gestellt. In den Datenpunkten im ioBroker sehe ich aber immer noch 'awekas_at = false'. Ich habs dann mal im --debug laufen lassen: hier sah ich dann beim "https://ws.awekas.at/weatherstation/updateweatherstation.php?ID=MeinUser&PASSWORD=&dateutc=2023..." das hier kein Password zu sehen ist. Ist das so richtig oder muss das Password irgendwie "behandelt" werden?
Was hat es denn mit der API auf sich? Und was genau soll der neue Adapter von Awekas machen? (Fragen über Fragen).
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was hat es denn mit der API auf sich? Und was genau soll der neue Adapter von Awekas machen? (Fragen über Fragen).
Erstmal das einfache: der Adapter kann sich Wetterdaten von AWEKAS ziehen. Nützlich für Leute ohne Wetterstation die aber in ihrer Nähe eine haben die Daten an AWEKAS sendet ;)
Nein, das Passwort sollte da im Klartext stehen. Deine conf sieht wahrscheinlich so aus ?
############################################################################################# ### AWEKAS - Einstellungen (nur nötig falls AWEKAS benutzt werden soll) ### ############################################################################################# #AWEKAS aktivieren [true/false] / default: false use_awekas=false #AWEKAS Login Username und Passwort AWEKAS_USER= AWEKAS_PW= ############################################################################################# ### AWEKAS - Ende der Einstellungen ################################################### #############################################################################################...dann ev. Sonderzeichen "(?%#)" im Passwort? Das geht wg. der URL-Codierung dann in die Hose.
Da ist die API dann im Vorteil, denn hier wird das Passwort MD5 verschlüsselt. Damit ist es nicht mehr als Klartext und Sonderzeichen sind dann auch erlaubt. Die API hat dann für AWEKAS noch geringe Vorteile, für "uns", dass ich so ziemlich alles an Wetterdaten schicken kann was es gibt (also hauptsächlich Messwerte von Zusatzsensoren). Eine Schneehöhe kriegen wir halt aktuell nicht gemessen, aber es sind so aus dem Kopf heraus 126 mögliche Messwerte.
Aber immer optional, die API ist dann zwar bindend (hat aber sonst keinerlei Auswirkungen), man kann dann aber seine Zusatzwerte übertragen, muss aber nicht.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was hat es denn mit der API auf sich? Und was genau soll der neue Adapter von Awekas machen? (Fragen über Fragen).
Erstmal das einfache: der Adapter kann sich Wetterdaten von AWEKAS ziehen. Nützlich für Leute ohne Wetterstation die aber in ihrer Nähe eine haben die Daten an AWEKAS sendet ;)
Nein, das Passwort sollte da im Klartext stehen. Deine conf sieht wahrscheinlich so aus ?
############################################################################################# ### AWEKAS - Einstellungen (nur nötig falls AWEKAS benutzt werden soll) ### ############################################################################################# #AWEKAS aktivieren [true/false] / default: false use_awekas=false #AWEKAS Login Username und Passwort AWEKAS_USER= AWEKAS_PW= ############################################################################################# ### AWEKAS - Ende der Einstellungen ################################################### #############################################################################################...dann ev. Sonderzeichen "(?%#)" im Passwort? Das geht wg. der URL-Codierung dann in die Hose.
Da ist die API dann im Vorteil, denn hier wird das Passwort MD5 verschlüsselt. Damit ist es nicht mehr als Klartext und Sonderzeichen sind dann auch erlaubt. Die API hat dann für AWEKAS noch geringe Vorteile, für "uns", dass ich so ziemlich alles an Wetterdaten schicken kann was es gibt (also hauptsächlich Messwerte von Zusatzsensoren). Eine Schneehöhe kriegen wir halt aktuell nicht gemessen, aber es sind so aus dem Kopf heraus 126 mögliche Messwerte.
Aber immer optional, die API ist dann zwar bindend (hat aber sonst keinerlei Auswirkungen), man kann dann aber seine Zusatzwerte übertragen, muss aber nicht.@sborg So sieht die Config ohne Awekas aus - meine ist schon mit den richtigen Werten befüllt. Aber bei den Sonderzeichen wird wohl der Hase im Pfeffer liegen. Ich hab mich an die Vorgaben von Awekas gehalten
und natürlich auch Sonderzeichen drin. Kann ich das PW kaschieren oder soll ich versuchen das Password zu ändern?EDIT: ich antworte mal auf die letzte Frage: Ich hab das Password geändert (ohne Sonderzeichen) und schon wird der Datenpunkt Awekas_at true und die Daten sind auch auf dem Awekas-Dashboard sichtbar.
Super & Danke. -
@hefo
Na, da warst du aber fleißig :)Sieht soweit auch gut aus, nur den
echo $MET_REGEN
würde ich bald raus nehmen, da wir hier auf Betriebssystemebene sind und du dir sonst das Syslog mit den Regenwerten voll müllst.
@sborg danke für den Hinweis, ja, das war noch vom Testen drin...
Habe die Änderung jetzt ein paar Tage beobachtet und es sah jeden Abend passend aus. Insofern mache ich erstmal einen Haken dahinter.
Mein oben erwähntes Script zum Umkopieren der alten Daten mit Fields in eine neue Influx 2.7 mit Tags habe ich an den folgenden etwas älteren Thread angehangen, in dem schonmal danach gefragt wurde:
https://forum.iobroker.net/topic/46098/test-adapter-influxdb-2-0/286?_=1692988111319Gruß
Hefo -
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Was hat es denn mit der API auf sich? Und was genau soll der neue Adapter von Awekas machen? (Fragen über Fragen).
Erstmal das einfache: der Adapter kann sich Wetterdaten von AWEKAS ziehen. Nützlich für Leute ohne Wetterstation die aber in ihrer Nähe eine haben die Daten an AWEKAS sendet ;)
Nein, das Passwort sollte da im Klartext stehen. Deine conf sieht wahrscheinlich so aus ?
############################################################################################# ### AWEKAS - Einstellungen (nur nötig falls AWEKAS benutzt werden soll) ### ############################################################################################# #AWEKAS aktivieren [true/false] / default: false use_awekas=false #AWEKAS Login Username und Passwort AWEKAS_USER= AWEKAS_PW= ############################################################################################# ### AWEKAS - Ende der Einstellungen ################################################### #############################################################################################...dann ev. Sonderzeichen "(?%#)" im Passwort? Das geht wg. der URL-Codierung dann in die Hose.
Da ist die API dann im Vorteil, denn hier wird das Passwort MD5 verschlüsselt. Damit ist es nicht mehr als Klartext und Sonderzeichen sind dann auch erlaubt. Die API hat dann für AWEKAS noch geringe Vorteile, für "uns", dass ich so ziemlich alles an Wetterdaten schicken kann was es gibt (also hauptsächlich Messwerte von Zusatzsensoren). Eine Schneehöhe kriegen wir halt aktuell nicht gemessen, aber es sind so aus dem Kopf heraus 126 mögliche Messwerte.
Aber immer optional, die API ist dann zwar bindend (hat aber sonst keinerlei Auswirkungen), man kann dann aber seine Zusatzwerte übertragen, muss aber nicht.Hallo
Edit: hat sich von selber erledigt!
Meine Werte in0_userdata.0.Wetterstation.Regen_Jahr_kumuliertwerden seit heute Vormittag nicht mehr befüllt.
Hatten gut 15 Std. Stromausfall. :(
dietpi@DietPi:~$ sudo systemctl status wetterstation ● wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2023-08-27 15:19:29 CEST; 4min 45s ago Main PID: 6204 (wetterstation.s) Tasks: 3 (limit: 264) Memory: 3.5M CGroup: /system.slice/wetterstation.service ├─6204 /bin/bash /home/iobroker/wetterstation.sh └─8536 curl -s http://wow.metoffice.gov.uk/automaticreading?siteid=f6488701-411a-ee11-913a-201642ba599e&siteAuthenticationKey=290175&dateutc=2023-08-27+23:37:08&tempf=58.1&dewptf=57.83&softwaretype=EasyWeatherV1.6.5&humidity=99&win ddir=216&baromin=29.888&windspeedmph=0.9&dailyrainin=0.020&rainin=0.000 Aug 27 15:19:29 DietPi systemd[1]: Started Service für ioBroker Wetterstation. Aug 27 15:19:29 DietPi wetterstation.sh[6204]: Connection to 10.0.1.202 8087 port [tcp/*] succeeded!
-
Da keine offensichtlichen Fehler aufgetreten sind:
Neues Release des Wetterstation WLAN-Skriptes auf GitHub V3.2.0
- + Support für WeatherObservationsWebsite (WOW)
Wie immer zu finden im GitHub
Update-Routine von Vorgängerversion:
- aktuellen WS-Updater nutzen (Download falls älter als V2.12.1:
wget -O ws_updater.sh https://raw.githubusercontent.com/SBorg2014/WLAN-Wetterstation/master/ws_updater.sh) ./ws_updater.shim Installationsverzeichnis ausführen- Menüpunkt "4" wählen und die Fragen beantworten
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neuer Datenpunkt .Info.WOW); bei aktivierter Rest-API wird der Datenpunkt automatisch im ioB angelegt (1)
(1) es empfiehlt sich danach den Simple-API-Adapter neu zu starten (entweder per WebIF oder einfach
iob restart simple-api.0)
Update sollte durchgeführt werden, gerade wenn man AWEKAS (kein Tippfehler, hier gab es auch eine interne Änderung) nutzt oder man eben zukünftig WOW nutzen möchte.
Die Release-Version ist nicht mit dem letzten Beta-Release identisch! Betatester tauschen bitte die ".sh" und ".sub" aus und restarten den Service.
-
Da keine offensichtlichen Fehler aufgetreten sind:
Neues Release des Wetterstation WLAN-Skriptes auf GitHub V3.2.0
- + Support für WeatherObservationsWebsite (WOW)
Wie immer zu finden im GitHub
Update-Routine von Vorgängerversion:
- aktuellen WS-Updater nutzen (Download falls älter als V2.12.1:
wget -O ws_updater.sh https://raw.githubusercontent.com/SBorg2014/WLAN-Wetterstation/master/ws_updater.sh) ./ws_updater.shim Installationsverzeichnis ausführen- Menüpunkt "4" wählen und die Fragen beantworten
- wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (neuer Datenpunkt .Info.WOW); bei aktivierter Rest-API wird der Datenpunkt automatisch im ioB angelegt (1)
(1) es empfiehlt sich danach den Simple-API-Adapter neu zu starten (entweder per WebIF oder einfach
iob restart simple-api.0)
Update sollte durchgeführt werden, gerade wenn man AWEKAS (kein Tippfehler, hier gab es auch eine interne Änderung) nutzt oder man eben zukünftig WOW nutzen möchte.
Die Release-Version ist nicht mit dem letzten Beta-Release identisch! Betatester tauschen bitte die ".sh" und ".sub" aus und restarten den Service.
Hallo zusammen,
ich habe ein kleines Problem mit der Statistik. Und ich bin mir nicht sicher ob ich was falsch mache oder wo ich noch was suchen könnte.
Und zwar wir bei mir die Anzahl der Regentage falsch angezeigt. Diesen MOnat werden schon 6 Regentage angezeigt. Obwohl die letzten Tage kein Regen gefallen ist. In der InfluxDB sind auch keine Einträge.
Jetzt habe ich schon an verschiedenen Stellen geschaut.
Ein Thema ist mir aufgefallen und ich bin mir unsicher ob es damit zu tun hat. Wenn ich mir die Logs zu dem Statistik Script anschaue kommt als letzter Eintrag aus der Datenbank:{
"result": "_result",
"table": 0,
"_start": "2023-09-05T22:00:00Z",
"_stop": "2023-09-06T21:59:59Z",
"_time": "2023-09-06T21:53:38.247Z",
"_value": 16.7,
"_field": "value",
"_measurement": "0_userdata.0.wetter.wetterstation.Aussentemperatur",
"ts": 1694037218247
}Ich finde die Zeiten etwas komisch und warum kommt kein Eintrag mit dem Ergebnis Regen.Tag.
Kann mir hier jemand helfen ?Vielen Gruß
Michael
-
Ich habe einen neuen DP30 erworben und in meinen DP1500 eingebunden. Wird auch in WSView und Ecowitt angezeigt. Leider liefert dieser nur Temperatur und keine Luftfeuchte. Im Datastring wird er als DP50 interpretiert. Hier Auszug Datastring:
......totalrainin=32.862&temp1f=66.20&humidity1=68 &temp2f=74.84 &soilmoisture1=13......
Es wird kein humidity2 geliefert nur temp2f.
Kann man dieses eventuell noch einbauen? Bei mir ist es der CH2.
HW: Lenovo M920q (Proxmox, ioBroker, RaspMatic & Z2M), QNAP (Docker, Influx), Arduino Mega 2560 R3 (I2C DS18B20 + LED)
SW: CT IoBroker, VM RaspMatic(v3.79.6.20241122)
-
Hallo zusammen,
ich habe ein kleines Problem mit der Statistik. Und ich bin mir nicht sicher ob ich was falsch mache oder wo ich noch was suchen könnte.
Und zwar wir bei mir die Anzahl der Regentage falsch angezeigt. Diesen MOnat werden schon 6 Regentage angezeigt. Obwohl die letzten Tage kein Regen gefallen ist. In der InfluxDB sind auch keine Einträge.
Jetzt habe ich schon an verschiedenen Stellen geschaut.
Ein Thema ist mir aufgefallen und ich bin mir unsicher ob es damit zu tun hat. Wenn ich mir die Logs zu dem Statistik Script anschaue kommt als letzter Eintrag aus der Datenbank:{
"result": "_result",
"table": 0,
"_start": "2023-09-05T22:00:00Z",
"_stop": "2023-09-06T21:59:59Z",
"_time": "2023-09-06T21:53:38.247Z",
"_value": 16.7,
"_field": "value",
"_measurement": "0_userdata.0.wetter.wetterstation.Aussentemperatur",
"ts": 1694037218247
}Ich finde die Zeiten etwas komisch und warum kommt kein Eintrag mit dem Ergebnis Regen.Tag.
Kann mir hier jemand helfen ?Vielen Gruß
Michael
@mctom sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich finde die Zeiten etwas komisch
Das kommt schon hin. Influx ist in Zulu-Time (siehst du am "Z" im Zeitstempel). Sind aktuell zu uns -2h wg. Sommerzeit.
Damit wäre Zulu plus 2h UTC
- Start: 06.09.2023 um 0:00 Uhr
- Stop: 06.09.2023 um 23:59:59 Uhr
also genau ein ganzer Tag, nämlich der 06.09. ;)
Die Statistik macht nichts anderes als den Max-Wert der Regenmenge (der Stand addiert sich auf) des Tages aus der InfluxDB zu ermitteln. Bei größer "0" = Regentag und Gesamtregentage = alter Stand Regentage + 1
Leider der Satz den man nicht hören mag: das funktioniert soweit tadellos, ist ein lokales Problem bei dir... :innocent:
Vermutlich loggst du die Regenmenge nicht genau in das Bucket und/oder Instanz die du im Statistik-Script angegeben hast? -
@schittl sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Kann man dieses eventuell noch einbauen?
Wenn "man" nicht ich bin... :blush:
Jepp, mach ich, kann aber aktuell auch ein paar Tage dauern. Batteriestatus oä. liefert er nicht?
-
Ich habe einen neuen DP30 erworben und in meinen DP1500 eingebunden. Wird auch in WSView und Ecowitt angezeigt. Leider liefert dieser nur Temperatur und keine Luftfeuchte. Im Datastring wird er als DP50 interpretiert. Hier Auszug Datastring:
......totalrainin=32.862&temp1f=66.20&humidity1=68 &temp2f=74.84 &soilmoisture1=13......
Es wird kein humidity2 geliefert nur temp2f.
Kann man dieses eventuell noch einbauen? Bei mir ist es der CH2.
@schittl sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich habe einen neuen DP30 erworben
@schittl
Du weisst aber schon, dass der DP 30 nur ein Temperatursensor und kein Temp& Hum ist?7 Spezifikationen Energie: 2 x 1,5V AA Batterien (nicht im Lieferumfang enthalten) Frequenz: 868Mhz Temperaturbereich: -40°C – 50°C Auflösung: 0.1°C Genauigkeit: +/- 1°COder geht darum, dass er im Skript dann mit Luftfeuchte geführt wird?
-
@SBorg
Vielen Dank. Dein Script ist ansonsten so super und funktioniert seit paar Jahren zuverlässig. Auch wenn ab und zu neue Sensoren dazu kommen. Batteriewerte liefert er. Das ist auf jedenfall nicht eilig.@Boronsbruder
Das ist mir bekannt. Liefert nur Temperatur und Batterie.Im Ecowittportal werden die Daten korrekt angezeigt.
Danke für Eure Mühe.
HW: Lenovo M920q (Proxmox, ioBroker, RaspMatic & Z2M), QNAP (Docker, Influx), Arduino Mega 2560 R3 (I2C DS18B20 + LED)
SW: CT IoBroker, VM RaspMatic(v3.79.6.20241122)
-
@SBorg
Vielen Dank. Dein Script ist ansonsten so super und funktioniert seit paar Jahren zuverlässig. Auch wenn ab und zu neue Sensoren dazu kommen. Batteriewerte liefert er. Das ist auf jedenfall nicht eilig.@Boronsbruder
Das ist mir bekannt. Liefert nur Temperatur und Batterie.Im Ecowittportal werden die Daten korrekt angezeigt.
Danke für Eure Mühe.
@schittl sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Batteriewerte liefert er
Da bräuchte ich dann den Teil des Strings noch ;)
-
@schittl sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Batteriewerte liefert er
Da bräuchte ich dann den Teil des Strings noch ;)
@sborg
Ich vermute bei der Übertragung prüfst Du, ob Temp und Humi vorhanden sind im String. Das müsstest Du nur "aufweichen" und auch einzeln übertragen oder nur auch bei einer Temp.Im String sollte es dann genauso aus wie bei DP50 ;)
Ich komme leider erst am Freitag wieder dazu Dir den Data-String nochmals zu schicken :(
HW: Lenovo M920q (Proxmox, ioBroker, RaspMatic & Z2M), QNAP (Docker, Influx), Arduino Mega 2560 R3 (I2C DS18B20 + LED)
SW: CT IoBroker, VM RaspMatic(v3.79.6.20241122)
-
@sborg
Ich vermute bei der Übertragung prüfst Du, ob Temp und Humi vorhanden sind im String. Das müsstest Du nur "aufweichen" und auch einzeln übertragen oder nur auch bei einer Temp.Im String sollte es dann genauso aus wie bei DP50 ;)
Ich komme leider erst am Freitag wieder dazu Dir den Data-String nochmals zu schicken :(
@schittl sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich vermute bei der Übertragung prüfst Du, ob Temp und Humi vorhanden sind im String.
Nein :)
Anhand der Vorauswahl per "conf" wird dann selektiv geprüft. Sonst müsste ich bei jedem Datenpaket auf alle Sensoren prüfen. Viele (bspw. ich habe überhaupt keinen) haben aber nur wenige oder gar keine Zusatzsensoren.@schittl sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Im String sollte es dann genauso aus wie bei DP50
Dürfte eigentlich nicht, denn wenn du bspw. dann DP35 und DP50 hast, ließe sich nicht mehr unterscheiden welcher Sensor denn nun was ist. Der String geht ja so auch an andere Wetterdienste.
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation
Support us
874
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge