NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Vielleicht möchtest du in deiner Anleitung noch anmerken, dass die Influxdb genutzt wird, die auch im Iobroker benutzt wird...
Es gibt so Trottel (ich), die legen erst eine neue Database an und wundern sich über FehlermeldungenMöchten schon, aber die liebe Zeit
Ich würde nämlich auch gerne noch darauf eingehen wie man bspw. das Logging am sinnvollsten konfiguriert etc.
...aber einen 08/15-Satz kann ich trotzdem schon mal in die WiKi ballern -
Hallo,
ich hab ein kleines Problem mit Solarenergie_Tag.
Hatte Anfang des Montas einige Probleme mit meinem System, die ich schlussendlich nur durch ein ioBroker Restore und Neuinstallation von Influx lösen konnte. Irgendwann so um die Zeit hab ich das Wetterskript noch auf 2.7 gebracht. Das war aber noch vor dem offiziellen Release.
Jetzt zu meinem Problem:
Wetterstation.0.Info.Solarenergie_Tag bringt seit meiner Wiederhestellerei utopische Werte.
Das ist gut das Dreifache von den erwarteten Werten.
Die Werte von Wetterstation.0.Sonnenstrahlung scheinen plausibel:
Edit: Welche Poll Intervalle nutzt ihr denn?
Ich hatte seit anfang immer 16 s. Dann ham ich kürzlich mal auf 60 s umgestellt. Jetzt bin ich seit gestern auf 30 s und die Werte sehen wieder plausibel aus. -
@rushmed sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich hatte seit anfang immer 16 s. Dann ham ich kürzlich mal auf 60 s umgestellt. Jetzt bin ich seit gestern auf 30 s
Wollte ich gerade schreiben. Ich brauche die Werte "über Zeit", nur so lässt sich die Leistung (Wattstunden ) berechnen. Da die Station aber keinen eigenen verwertbaren Zeitstempel hat und ich nicht das eingestellte Sende-Intervall des Nutzers kenne, muss ich einen festen Wert wissen. Entweder misst man selbst die Zeit zwischen zwei Datenpaketen, oder gibt zum Beispiel in der WS-View-App fest 30 Sekunden vor (man kann zwar auch 16 Sekunden einstellen, aber meine Station interessiert dies nicht, schneller als 30 Sekunden sendet sie nicht).
Jetzt muss man halt in der *.conf den Poll-Interval auf die oben eingestellten/ermittelten 30 Sekunden einstellen.
Nun kommt ein Wert: 500 Watt (der gilt aber nur jetzt + was ist mit den restlichen 29 Sekunden)
der nächste Wert x (wir nehmen jetzt mal 30) Sekunden später: 600 Watt...und nu? Wir bilden halt ein Mittel: (500 + 600) / 2 = 550 Watt für 30 Sekunden oder 4,583 Wh
Das ist nicht gerade ideal und ich hab schon mit Timern etc. experimentiert, aber bisher noch keine richtig zufriedenstellende Lösung gefunden. Das Problem sind die bewölkten Tage mit vielen Änderungen. Dann geht ohne den festen Poll-Interval zu viel an Daten verloren.
Wenn einer eine Idee hat... -
@sborg Ich logge seit Anfang an meine Messintervalle.
Die Grafik ist stellvertretend für die gesamte Zeit seit meinem Messbeginn.
Hier nochmal über die letzten drei Wochen, wobei links 16 s bis etwas 30.7., dann 60 s bis gestern und ab da 30 s voreingestellte Poll Zeit in der View App und in der Conf.
Die leeren Bereiche sind nur Inaktivität meines Systems und habe nicht zwingend etwas mit Intervallwechseln zu tun.
Ich sehe daraus nicht dass die Änderung des Poll Intervalls irgendeinen Einfluss hat.Hat sonst noch jemand seine Messitervalle gecheckt?
Wenn das Script die Zeit des Letzten Messpunkts kennt könnte man doch jeweils die letzte gemessene Leistung mit mit dem Abstand der Messpunkte [h] multiplizieren und dann weiter aufaddieren. Das ware nicht perfekt aber würde bei so variablen Messintervallen sicher helfen.
Hier nochma die Grafik der letzten 21 Tage mit moving average 100 zur besseren Veranschaulichung:
-
@rushmed Es macht schon einen Unterschied. Das Skript mag zwar im xx Sekundenraster (ich sag jetzt mal fix für alles folgende 30 Sekunden, ist aber +/- x Sekunden variabel ) die Daten empfangen und auswerten, die Berechnung des Solarertrages fand aber fix anhand des eingestellten Poll-Intervalles statt:
SOL_TMP=$(echo "scale=3;${SOL_TMP}/(3600/${WS_POLL})" | bc -l)
- Poll auf 60 Sekunden eingestellt: 3600/60 = 1/60 Stunde
- Poll auf 30 Sekunden eingestellt: 3600/30 = 1/120 Stunde
Heißt 1 Minute xx Watt oder eine halbe Minute lagen xx Watt vor, obwohl es immer nur 30 Sekunden waren!
Die Lösung war jetzt nach längerer Zeit mal neutral von außen betrachtet recht simpel. Paar Zeilen Code-Änderungen und ca. eine handvoll Zeilen neuer Code, eine zusätzliche RRD-Database,...
Problem mit fixem Intervall gefixt.
Es ist völlig egal ob valide Zeitstempel vorliegen, ich brauche ja nur die Zeitdifferenz zwischen zwei Paketen. Ob das in China, auf dem Mond, in Australien oder sonst wo läuft, eine Messung (genauer zwei) wird immer xx Sekunden als Ergebnis bringen, egal wo, oder nach welcher Zeitzone ich das starte.
Ich habe jetzt einen "Fail" von 5 Minuten eingebaut. Falls innerhalb von 5 Minuten kein Paket mehr kommt (bei Wolken etc. kommt trotzdem eins, nur halt bspw. mit x Watt oder im extrem mit 0 Watt, aber es kommt eins), wird davon ausgegangen, dass der letzte Messwert zumindest die Länge des Poll-Intervalls an lag.
Wie man sieht schwankt das Intervall bei mir innerhalb kurzer Zeit von 24-33 Sekunden
Deswegen dürfte der neue (nun genauere) auch eine heftige +/- - Abweichung der bisherigen Werte bedingen. Also nicht wundern.
Einfach V2.8.0 *.sh und *.sub von GitHub tauschen und Service neu starten. *.conf und Updater sind hier nicht nötig.
Ein echtes Announce zum Beta-Test der V2.8.0 folgt erst mit der neuen Funktion (ja, ja, ich habe doch wieder was auf der Agenda... ). -
@sborg Fett, danke.
Ich habs aktualisiert und werde ein Auge drauf haben. -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ja, ja, ich habe doch wieder was auf der Agenda
sowas freut mich! Immer fleißig am arbeiten und grübeln!
Hab die neue 2.8.0 gleich mal aufgespielt!
-
Guten Morgen!
Weil ich ja sonst nix zu tun hätte...
Ich hab heute mal versucht die Authentifizierung und HTTPS zu aktivieren...- Weil ich nur ein selbstsigniertes Zertifikat benutze, hab ich die .sub beim "Senden an IOB" um den Flag "-k" (benutze https auch bei Zertifikatsproblemen) erweitert
Resultat: Funktioniert
Ohne: Meldung ->curl: (60) SSL certificate problem: unable to get local issuer certificate
Soweit so gut...
Und dann ging es los:
- Authentifizerung an
Debugausgabe von dem wetterstation.sh
{"error":"authentication failed. Please write \"https://192.168.116.246:8087?user=UserName&pass=Password\""}
Also, manuell im Browser die Api getestet mit
https://192.168.116.246:8087/help?user=USERNAME&pass=PASSWORT
Resultat: funktionert
Wenn man aber die Anfrage (zusammengesetzt wie es die .sub macht) absetzt, kommt die Fehlermeldung:curl --insecure --data "user=USERNAME&pass=PASSWORT" https://192.168.116.246:8087/help {"error":"authentication failed. Please write \"https://192.168.116.246:8087?user=UserName&pass=Password\""}
und dann war ich noch ganz pervers und hab noch HTTP mit Authentifizierung gestestet
Damit kommt das Wetterstation-Skript gar nicht zurecht(standard_in) 1: illegal character: : (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: syntax error (standard_in) 1: illegal character: P (standard_in) 1: syntax error
Aber das ist ja nicht von Belang, da Username und Passwort unverschlüsselt zu senden gleichzusetzen mit "ohne Authenifizierung" wäre...
Ist das mit dem HTTPS bei euch auch so?
Oder ist das Problem mal wieder zwischen Tastatur und Stuhl?Schönen Sonntag
P.S: war noch die Version 2.7.0
-
@boronsbruder Ich hatte auch mal versucht, SimpleAPI mit User und Passwort zu "schützen". Dann kamen keine Daten mehr an. Ist wohl auch schon ein bisschen her (Version 2.4 oder so). Hatte nur noch keine Muße (Traute) gehabt, mich mal daran zu setzen.
-
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
sowas freut mich! Immer fleißig am arbeiten und grübeln!
Die Idee kam mir letztens, die Umsetzung ging recht zügig und der Test sieht derzeit auch gut aus:
bzgl. HTTP/S & Co.: habe ich ehrlich gesagt nie ausprobiert. Mein System ist von Außen nicht zugänglich und wer es da geschafft hat trotzdem in mein Netzwerk einzudringen, für den ist der Rest auch easy going. Aber was hat er davon? Mir einen falschen Temperaturwert unter zu jubeln? Selbst wenn ich einen Nuky oä. hätte und er könnte damit eine Tur öffnen, wer glaubt denn ernsthaft dass sich jemand diese Mühe macht? Schraubendreher und Fenster aufhebeln oder einfach einschlagen geht viel schneller...
Trotzdem sollte man natürlich jedweden Schutz anbieten/ausnutzen. Ich habe leider keine Ressourcen mehr für ein Testsystem frei und teste alles in meiner Produktiv-Umgebung. Da kann ich jetzt aber nicht mal "spaßeshalber" die Authentifizierung einfach so einschalten, um mal am Skript zu probieren. Muss mal schauen ob man mit einer 2. Instanz und einem separaten Port was machen kann.
\"https://192.168.116.246:8087?user=UserName&pass=Password\"
Wird nicht immer funktionieren. Bei Sonderzeichen, Leerzeichen etc. steigt er da aus...
Ein Versuch wäre die Parameter einzeln zu senden:
curl -G --insecure --data-urlencode "user=USERNAME" --data-urlencode "pass=PASSWORT" https://192.168.116.246:8087/help
Falls noch wer testen möchte
Änderungen, wenn es dann funktioniert, nehme ich selbstverständlich gerne in die 2.8.0 mit auf. -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
sowas freut mich! Immer fleißig am arbeiten und grübeln!
Die Idee kam mir letztens, die Umsetzung ging recht zügig und der Test sieht derzeit auch gut aus:
Wow, das sieht aber fein aus. Womit haste du denn das gemacht, Grafana oder Widgets?
-
@sborg
Genauso habe ich das bisher auch gesehen.
Aber, wenn da was drin ist, spiel ich damit rum und nerve alle bis es funktioniert\"https://192.168.116.246:8087?user=UserName&pass=Password\"
..ist ja auch nur der "Tipp" der als Fehlermeldung vom Simple-Api zurückkommt.
Das mit dem HTTPS ist eine Großbaustelle...
der -"G " funktioniert, z.B. in Zeile 229 und 231 .sub)
curl -G -k --data "$IOB_DATA&user=${AUTH_USER}&pass=${AUTH_PASS}&prettyPrint" ${WEB}://${IPP}/setBulk
Dann geht es aber los mit Berechtigungsfehlern beim Schreiben der States, weil der Benutzer nicht "admin" war, sondern nur in der Benutzergruppe, was er aber nur angezeigt hat, wenn man einen einzelnen Wert geschrieben hat...
z.B mitcurl -G -k --data-urlencode "user=USERNAME" --data-urlencode "pass=PASSWORT" --data "0_userdata.0.Wetterstation.Innentemperatur=27.50&prettyPrint" https://192.168.116.246:8086/setBulk
So hat er bei mir über console wenigstens den Wert geschrieben...
In Zeile 170 und 174 in der .sub zickt er aber auch noch rum bei den "getPlains" z.B.
Mit Zeile 170
retval=$(curl -G -k --data "user=${AUTH_USER}&pass=${AUTH_PASS}" ${WEB}://${IPP}/${2})
und Zeile 174
curl -G -k --data "${3}&user=${AUTH_USER}&pass=${AUTH_PASS}" ${WEB}://${IPP}/${2}
hab ich jetzt wenigstens mal Daten zurückbekommen (wurden aber nicht in die States geschrieben) und nur ohne ">/dev/null 2>&1" am Ende
So und weil ich nicht wirklich der Skripter bin, und schon gar nicht der Shell-Skripter, raucht mir jetzt derart der Kopf, dass ich für heute alles wieder auf Anfang setze und aufgebe
Vielleicht helfen ja meine Ansätze
Schönen Sonntag noch -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Die Idee kam mir letztens, die Umsetzung ging recht zügig und der Test sieht derzeit auch gut aus:
Cool
ist das mit VIS?
Ich hätte ja eine ganz perverse Idee!
Die Daten (eventuell fertige html) mit was weiß ich auf einen externen Webserver speichern um dort eine öffentlich zugängliche Website zu haben.
Aktualisierung alle x Minuten/Sekunden (dazu müsste die FTP-Verbindung dauernd offen bleiben bei alle x-Sekunden). -
@nashra sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Womit haste du denn das gemacht, Grafana oder Widgets?
Weder VIS, noch Grafana oder Widget. Das ist eine Änderung/Ergänzung im Skript und die Grafik kommt nicht von mir. Wer weiß was es ist kann sich ein Gummibärchen abholen
Wind geht auch, und da es heute Nacht ev. regnen soll könnte morgen jeder testen der will:
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
..ist ja auch nur der "Tipp" der als Fehlermeldung vom Simple-Api zurückkommt.
Ich weiß, der taugt aber nur bedingt
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
raucht mir jetzt derart der Kopf, dass ich für heute alles wieder auf Anfang setze und aufgebe
Vielleicht helfen ja meine Ansätze
Schönen Sonntag nochKenne ich, da erzählst du mir nix neues, und dito, auch wenn er jetzt rum ist
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ich hätte ja eine ganz perverse Idee!
Nicht mal unbedingt, habe ich nur aus Zeitgründen verschoben und weil ich keine gescheite Seite hinbekomme. Grafik/Design ist nun mal nicht meins...
...und als Betreiber einer öffentlichen Web-Site steht man auch immer mit einem Bein schon im Knast oder vor der nächsten Abmahnung. -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wer weiß was es ist kann sich ein Gummibärchen abholen
Eine weiße Seite mit Grafiken!
Bekomm ich jetzt Gummibärchen?Nicht mal unbedingt, habe ich nur aus Zeitgründen verschoben und weil ich keine gescheite Seite hinbekomme. Grafik/Design ist nun mal nicht meins...
Wow, da freu ich mich jetzt schon. Grafikdesign ist leider auch nicht meins. Aber ich kenn da jemanden, der ist mega gut. Da könnten wir bestimmt was machen.
und als Betreiber einer öffentlichen Web-Site steht man auch immer mit einem Bein schon im Knast oder vor der nächsten Abmahnung
Nö, eigentlich nicht, wenn man DSGVO und Cookie einhält.
Ich hab mehrere Seiten. Sind alle ok.
Wenn's soweit ist, kannst dich diesbezüglich melden. -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@nashra sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Womit haste du denn das gemacht, Grafana oder Widgets?
Weder VIS, noch Grafana oder Widget. Das ist eine Änderung/Ergänzung im Skript und die Grafik kommt nicht von mir. Wer weiß was es ist kann sich ein Gummibärchen abholen
Wind geht auch, und da es heute Nacht ev. regnen soll könnte morgen jeder testen der will:
Und hat es geregnet, dann würde ich gerne testen
-
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Bekomm ich jetzt Gummibärchen?
Der Versuch wäre schon eins Wert, aber die Lösung... nennen wir es mal suboptimal...
bzgl. Web-Site: Danke, aber ich stell ja nix online. Muss/müsste dann jeder für sich selber entscheiden. Technik ja, Grafik wird bei mir nur "nett" ("nett" ist die kleine Schwester von Sch...e)@nashra sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und hat es geregnet, dann würde ich gerne testen
Alles abgesagt
...aber Test folgt gleich in eigenem Announce -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Alles abgesagt
hättest mir gestern geben müssen. Hat geschüttet!!
-
Nicht zu 100% mangels Regen ausgetestet, aber schlimmstenfalls meldet er nur keine Regenmenge (sollte aber funktionieren)
Neues Beta-Release des Wetterstation WLAN-Skriptes auf GitHub V2.8.0
- ~ Änderung am Messverfahren der Solarenergie (festes Poll-Intervall --> Zeitstempel)
- + Support für wetter.com
Wie immer zu finden im GitHub
Wie üblich wetterstation.sh, -.sub und ws_updater.sh austauschen, ws_updater.sh ausführen. wetterstation.js muss ebenfalls ersetzt und einmalig ausgeführt werden (neuer Datenpunkt "Info.wetter_com"). Dann mittels
sudo systemctl restart wetterstation
den Service neu startenInstallationshinweis: https://github.com/SBorg2014/WLAN-Wetterstation/wiki/Installation---wetter.com-(optional)
(...
und gebt mir noch einen Augenblick, während ich hier gerade poste, fällt mir auf, dass ich den Upload auf GitHub vergessen habe... -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ws_updater.sh austauschen
da steht noch
UPDATE_VER=V2.7.0
und gebt mir noch einen Augenblick, während ich hier gerade poste, fällt mir auf, dass ich den Upload auf GitHub vergessen habe
gerade erst gesehn