[Linux Shell-Skript] WLAN-Wetterstation

[wendy2702]

@a200 OK. Danke.

Aktuell nur die normale WS vorhanden.

[SBorg]

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

@SBorg
Neueste Version 2.2.0 eingebaut und läuft. Danke dafür. Und natürlich aufs Ecowitt-Protokoll umgestellt. Auf die nächste Version, in der 'allerdings schon der Min-/Max-Wert der letzten 24h geplant' ist, warte ich gerne noch - also keine Hetze.

Das war eigentlich sogar fertig, mittlerweile ist es in der Tonne gelandet. 2 Tage Arbeit "für die Katz". Das sind halt die Dinge die man zum Schluss nicht sieht. Wie sagte mal einer so schön beim fehlgeschlagenen Versuch #426: Das waren keine 426 Fehlschläge, sondern 426 Lösungen wie es nicht geht...

Mein "Fehler" war recht trivial. Funktionieren tut es, solange der "Skript-Rechner" derselbe ist auf dem auch die InfluxDB läuft. Was aber wenn dem nicht so ist...?
...und ja, man wird dafür eine InfluxDB brauchen. Werden die meisten eh schon zumindest wg. Grafana haben.

[amiethaner]

@sborg
wenns was zu testen gäbe, mein iob, influx und grafana ist je n eigener Docker

[SBorg]

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

Hallo @SBorg ,

ist das so gewollt dass der Wert "Rekordwerte - Regenmengemonat" immer einen Tag nach dem Wert "aktueller Monat - Regenmenge_monat" berechnet wird? Müsste doch, da erster Monat, beides immer identisch sein oder?

Gewollt nicht unbedingt, aber dem System, Timing, Umständen... geschuldet.
Die beiden Werte werden auch unterschiedlich sein, denn der eine wird einfach von der Station gelesen (inkl. der Rundungsdifferenzen), der Rekordwert von mir anhand der täglichen Regenmengen berechnet (simple Addition). Da kommt dann leider die Statistik durch, denn für den (ggf. neuen) Rekordwert brauche ich ja den alten Wert. Da die addierte Regenmenge aber von Gestern ist (ich brauche halt die Regenmenge des (oder eines) gesamten Tages), ist der alte Wert von Vorgestern. Somit habe ich nicht den Statistikversatz von 0-24h je nachdem wann man sich die Statistik anschaut (die Werte sind ja immer nur bis 23:59:59 berücksichtigt), sondern einen Tag mehr.
Eigentlich müsste ich den Monatsrekordwert bis zum folgenden Monatsersten unterdrücken, aber ich fand einfach einen "verschleppten" Rekord (um besagten einen Tag) schöner als gar keinen. Nächsten Monat wird es schon weniger auffallen, da sich der Rekordwert nur noch ändert wenn ein neuer Spitzenwert erreicht wird. Das wird mit jedem mal später im Monat werden (oder auch gar nicht wenn es im Monat weniger geregnet hat als der Rekordwert), bis er gar nicht mehr geknackt wird.

[SBorg]

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

@sborg
wenns was zu testen gäbe, mein iob, influx und grafana ist je n eigener Docker

Danke für das Angebot. Zu testen gibt es eigentlich immer die Version auf GitHub im Branch "master". Die hat Beta-Status und kann Fehler enthalten, läuft aber meist schon recht stabil. Je mehr aber testen, desto eher fallen halt auch Fehler auf.

Die aktuelle V2.3.0 (oder andere) sind reine Developer-Versionen. Die enthalten in dem frühen Stadium meist noch sog. hardcoded Programmzeilen. Sprich da wird zB. explizit auf meine IP des ioB zugegriffen, was in der Beta-Version dann bspw. durch die Konfiguration geschieht. Aktuell steht da zB. mein Influx-Username und -Password im Klartext drin...
Da kann so keiner testen (und die möchte ich auch für mich behalten)

[Rene55]

@sborg
Ich hab ja für fast alles nen eigenen Container. Grafana & Influx in einem, das Script in einem anderen. Von Daher warte ich auch gerne noch die 4xx te Lösung ab. Nur blöd, wenn man soviel Zeit reinsteckt und hinterher war's das nicht. Dewegen möchte ich nochmals Mut zusprechen und ganz deutlich DANKE sagen.

[da_Woody]

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

derselbe ist auf dem auch die InfluxDB läuft

das latürnich nix gut. wie bei vielen auch bei mir VM ioBroker, VM Influx/Grafana

[SBorg]

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

@sborg
Ich hab ja für fast alles nen eigenen Container. Grafana & Influx in einem, das Script in einem anderen. Von Daher warte ich auch gerne noch die 4xx te Lösung ab. Nur blöd, wenn man soviel Zeit reinsteckt und hinterher war's das nicht. Dewegen möchte ich nochmals Mut zusprechen und ganz deutlich DANKE sagen.

Ich sehe fast alles immer positiv. Durch Fehler lernt man ja auch
...und weil es so schön ist:

Lüppt
Da dies allerdings vom WLAN-Skript getriggert wird und wohl keiner im 30 Sekundenraster (oder wie oft ihr die Daten vom Display empfangt) die Werte braucht (es braucht zwar kaum Ressourcen auf dem Influx-Client, aber wenig ist halt auch nicht nichts), lasse ich sie nur im 15 Minutenraster generieren (also xx:00, xx:15,...xx:45 Uhr).
Dafür lohnt aber aktuell noch kein neues Release, wenigstens noch einen Sensor mit dazu packen

Wer wollte denn Zugriff auf "PimpMyStation"? Bitte hier oder per Chat die Wünsche mitteilen, ich editiere es dann hinein. Ich musste leider schon öfters bei Google-Spreadsheets die Erfahrung machen, dass mehrere Köche doch den Brei verderben. Ich habe es auch schon öfters mal zerschossen, ist halt EXCEL ähnlich, aber halt kein EXCEL...
...und wegen Zeitmangels aktuell hier nichts Neues

[Rene55]

@sborg
Was muss ich tun, damit es auch bei mir 'lüppt'?

[SBorg]

@rene55 Auf die kommende V2.3.0 warten

Hat mal wer eine Aufstellung über alle Zusatzsensoren? Ich bräuchte

• Bezeichnung (DP50, DP100, DP60)
• was der Sensor eigentlich kann
• am idealsten wäre natürlich der --data/--debug String
• maximal mögliche Anzahl der Sensoren

Bezeichnung	Beschreibung	Datenstring	max. Anzahl
DP50 / WH31A	Temperatur + Luftfeuchte	---	8
DP60	Blitzsensor	&lightning_time=1611479261&lightning_num=16&lightning=12 &wh57batt=5	1
DP100	Bodenfeuchte	---	8
DP200	PM2.5 Feinstaub	&pm25_ch1=29.0&pm25_avg_24h_ch1=22.0&pm25batt1=5	4

[a200]

@sborg
for Gateway DP1500/GW1000:
humidityin
tempinc

soil moisture sensors DP100/WH51:
soilbatt1..8 (battery in volt)
soilmoisture1..8

for Multi-Temp/Hum-sensors DP50/WH31:
batt1..8 (battery-Status; 1 = Alarm, 0 = ok)
humidity1..8
temp1..8c

for PM-sensors DP200/WH41/WH43:
pm25_avg_24h_ch1..4
pm25_ch1..4
pm25batt1..4 (Battery-Status; 5 = max)
pm25_AQI_ch1..4
pm25_AQI_avg_24h_ch1..4
pm25_AQIlvl_ch1..4 (Level 1..6)
pm25_AQIlvl_avg_24h_ch1..4 (Level 1..6)

Status/Activity/Tracker:
running (1 = startet, 0 = stopped)
loxtime (Loxone-time)
wswarning (weather station does not send data)
sensorwarning (mandatory sensor is missing)
batterywarning (Battery-warning)
stormwarning (Stormwarning)
tswarning (Thunderstorm-warning)
updatewarning (Firmware-update available)

for lightning sensor WH57/DP60:
lightning (distance last lightning in km)
lightning_time (time of last lightning Unixtime)
lightning_loxtime (time of last lightning Loxone-time)
lightning_num (count of lightnings)
wh57batt (Battery-Status; 5 = max)

for soil/water-temp-sensor WH34:
tf_chNc (temperature in °C; N=1..8)
tf_battN (battery; N=1..8)

Quelle: (Hier)

[XxJooO]

@a200 und @SBorg und alle anderen Freunde der gepflegten Wetterdokumentation,

inzwischen habe ich das Übermittlungsproblem der Regenwerte meiner Sainlogic FT 0300 mit Einlöten einer besseren Antenne lösen können. Das verbaute Dingen ist ner Kugelschreiberfeder ähnlich oder auf deutsch: Schrott...

Wie auch immer werden nun Werte übermittelt. Allerdings fällt mir auf, dass einige DPs ungefüllt bleiben:

In Ermangelung ausreichender JS-Kenntnisse kann ich leider das Script nicht verstehen. Werden bei Euren Stationen die fehlenden Werte von der Station übermittelt oder werden sie berechnet? Wenn sie übermittelt werden, dann schreibe ich mir zur Selbstberechnung ein Skript in Blockly, da ich die Werte ganz spannend finde. Ich möchte eben nur ausschließen, dass bei mir mit dem Skript was nicht stimmt. Bei mir wird in der Wallbox die Tagesmenge aufsummiert und am Ende des Tages der Wert auf 0 gesetzt. Man kann der Box wohl auch Monats- und sonstige Werte entlocken. Ich zweifle aber, dass die übermittelt werden.

Ansonsten auch von mir definitiv Daumen hoch und weiter so, erwarte mit Freude die nächste Version

[christian90]

ich hätte hier noch den DATA String von einer Froggit HP1000SE mit 2x DP50, 3x DP100 und DP 60. Vieleicht hilft es ja noch.

DATA von Wetterstation:
PASSKEY=xxxxxxx&stationtype=EasyWeatherV1.5.6&dateutc=2021-01-27+17:52:13&tempinf=41.0&humidityin=75&baromrelin=29.723&baromabsin=29.723&tempf=38.3&humidity=93&winddir=228&winddir_avg10m=232&windspeedmph=1.8&windspdmph_avg10m=2.2&windgustmph=3.4&maxdailygust=4.5&rainratein=0.000&eventrainin=0.012&hourlyrainin=0.012&dailyrainin=0.020&weeklyrainin=0.209&monthlyrainin=1.866&yearlyrainin=1.866&solarradiation=0.00&uv=0&temp1f=39.4&humidity1=66&temp2f=53.2&humidity2=54&soilmoisture1=42&soilmoisture2=63&soilmoisture3=60&lightning_num=0&lightning_time=&lightning=&wh65batt=0&wh25batt=0&batt1=0&batt2=0&soilbatt1=1.5&soilbatt2=1.5&soilbatt3=1.5&wh57batt=5&freq=868M&model=HP1000SE-PRO_Pro_V1.6.9

[HerrKlaus]

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

Ich hatte es nur kurz zum probieren aktiviert. Der ganze Unterschied im Skript ist tatsächlich nur der Aufruf von HTTP vs. HTTPS. Mehr Änderungen waren dafür auch nicht nötig. Versuch mal vom Terminal:

curl https://_hier_ip_und_:port_/set/javascript.0.Wetterstation.Regenstatus?value=Weltuntergang&ack=true&user=&pass=

Hab ich gemacht. Problem konnte ich eingrenzen, da curl mir folgendes mitgeteilt hat:

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

-> Ich verwende selbst erstellte Zertifikate. Scheinbar mag curl die nicht.

Hatte auch die Standard ioB Zertifikate versucht. Leicht modifizierte Rückmeldung von curl:

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

Also auch nix. Dann etwas im Web gelesen. Man könnte die Option -k bei curl verwenden. Dann läuft auch dein Beispiel von oben durch. Aber laut curl Hilfe bedeutet das dann ja: -k, --insecure Allow insecure server connections when using SSL.
Glaube da kann man dann auch auf HTTPS verzichten, wenn curl eh alles zulässt.

Es scheint allerdings eine Wissenschaft zu sein, curl taugliche Zertifikate zu erstellen.

[SBorg]

@a200 Danke
Da scheinen aber einige Daten nicht mitgesendet zu werden (lt. der vorliegenden Strings).
Ich habe jetzt mal den DP60 hinzugefügt. Ich habe zwar keinen, aber wenn morgen alles noch rund läuft und nichts mehr dazwischen kommt, gibt es dann die V2.3.0:

Auch wenn nur einer möglich ist, habe ich die Nummerierung beibehalten. Einheitlich und man weiß ja nie was ev. noch kommt.
Den "Zeitpunkt" habe ich als Unix-Timestamp (in Nanosekunden) gesetzt. Ist zwar im Admin-Panel so dann nicht zu lesen, aber wer will schon die Daten sich immer im Admin anschauen? So ist man aber in der VIS per Widget etc. völlig frei in der Gestaltung wie es aussehen soll.

[SBorg]

@xxjooo Das ist quer Beet. Am einfachsten siehst du es eigentlich in der Wiki. Da steht was vom Skript kommt. Protokoll #9 ist auch noch nicht fertig und gänzlich zu Ende getestet.
Poste doch mal einen aktuellen String von dir ./wetterstation.sh --data
Falls in dem Rohstring allerdings nicht die aktuelle Regenmenge drin steht wird es eng. Die wird für so ziemlich alle Berechnungen die mit Regen zu tun haben benötigt.

[SBorg]

@herrklaus So in etwa hatte ich es mir schon gedacht, denn HTTPS hatte ich eigentlich getestet. Wenn es derselbe Rechner ist (also Skript und ioB) oder diese im selben Netzwerk sind (eins von beiden trifft bestimmt zu), ist HTTPS aber eh unnötig. Wenn schon einer in deinem Netzwerk ist, dann kann er auch meinetwegen noch die Kommunikation abhören. Denn die Wetterdaten sind super geheim, bzw. so geheim, dass die Station sie eh öffentlich und unverschlüsselt auf 868MHz funkt.

Ins WWW ist das was anderes. Da ist HTTPS auf jeden Fall vorzuziehen.

Du kannst natürlich auch den Simple-RESTful zumindest mit User + Passwort sichern.
Mit etwas Aufwand kann man auch letsencrypt-Zertifikate nutzen. Die sind signiert und werden auch akzeptiert. Ich nutze certbot zum erzeugen/erneuern. Das wird dann hier aber OT

[Rand]

@sborg

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

Den "Zeitpunkt" habe ich als Unix-Timestamp (in Nanosekunden) gesetzt. Ist zwar im Admin-Panel so dann nicht zu lesen, aber wer will schon die Daten sich immer im Admin anschauen? So ist man aber in der VIS per Widget etc. völlig frei in der Gestaltung wie es aussehen soll.

Willst Du nicht trozdem einen konvertierten DP dazu nehmen? Dann kann man wenigstens in der Admin Konsole gleich was erkennen und muss nicht erst konvertieren...
Klar kann ich das auch selbst notfalls, aber ist natürlich out of the box viel bequemer

[SBorg]

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

Willst Du nicht trozdem einen konvertierten DP dazu nehmen? Dann kann man wenigstens in der Admin Konsole gleich was erkennen und muss nicht erst konvertieren...

Brauch(s)t du/es nicht
Du kannst auch einfach die "Rolle" auf datetime umstellen, dann siehst du auch im Admin-Panel die Uhrzeit/Datum, trotzdem verbleibt der "state" als Unix-Timestamp.

[Rand]

@sborg
Nett... sehe es gibt noch viel zu lernen Danke