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

[Negalein]

@SBorg @crunchip

Ihr seit Grafana-Gurus. ;)

Ihr wisst hier sicher Bescheid.
Was muss ich einstellen, um diese durchgehenden Linien normal zu machen?

[Boronsbruder]

@rushmed
Hast du das Skript über systemctl bzw init neugestartet?

Was sagen die logs von influx?
Standardmässig sollte ja die html-Anfragen geloggt werden.

Aug 11 10:15:07 ZEROSERVER influxd[1153]: [httpd] 127.0.0.1 - wetter [11/Aug/2021:10:15:07 +0200] "GET /query?db=iobroker&epoch=s&p=%5BREDACTED%5D&pretty=true&q=SELECT+min%28value%29+FROM+%220_userdata.0.Wetterstation.Aussentemperatur%22+WHERE+time+%3E%3D+now%28%29+-+1d&u=wetter HTTP/1.1" 200 524 "-" "curl/7.52.1" 3d709813-fa7c-11eb-9f3f-002590fc87b2 3926
Aug 11 10:15:07 ZEROSERVER influxd[1153]: ts=2021-08-11T08:15:07.877575Z lvl=info msg="Executing query" log_id=0VD_yEp0000 service=query query="SELECT max(value) FROM iobroker.autogen.\"0_userdata.0.Wetterstation.Aussentemperatur\" WHERE time >= now() - 1d"

So ähnlich sollten die Anfragen aussehen

[da_Woody]

@negalein bin mir nicht sicher, aber denk mal, daß beide right-y und mit max current arbeiten, die sich behindern.
versuch mal Wind auf der left-y...

[Rushmed]

@boronsbruder Hab die Nullen wieder entfernt, nen anderen DB Nutzer eingestellt und einmal das Script im Debug laufen lassen und jetzt gehts. Keine Ahnung was da los war.
Danke

[Boronsbruder]

@rushmed
Vielleicht hatte der Benutzer keine Rechte für die Datenbank?

Ja, wenns jetzt läuft ;)

[crunchip]

@negalein bei mir ist das so eingetragen

[Negalein]

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

bei mir ist das so eingetragen

funktioniert heute wieder. Schätze da hatte sich was verschluckt!

[SBorg]

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

@sborg

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 Fehlermeldungen :rolling_on_the_floor_laughing:

Mö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 :grin:

[Rushmed]

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.

[SBorg]

@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...

[Rushmed]

@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:

[SBorg]

@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...:upside_down_face: :innocent: :grinning: ).

[Rushmed]

@sborg Fett, danke.
Ich habs aktualisiert und werde ein Auge drauf haben.

[Negalein]

@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! :grin:

[Boronsbruder]

Guten Morgen!
Weil ich ja sonst nix zu tun hätte...:man-facepalming:
Ich hab heute mal versucht die Authentifizierung und HTTPS zu aktivieren...

1. 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:

2. 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 :fearful:
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? :rolling_on_the_floor_laughing:

Schönen Sonntag ;)

P.S: war noch die Version 2.7.0

[Rene55]

@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.

[SBorg]

@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.

[Nashra]

@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?

[Boronsbruder]

@sborg
Genauso habe ich das bisher auch gesehen.
Aber, wenn da was drin ist, spiel ich damit rum und nerve alle bis es funktioniert :rolling_on_the_floor_laughing:

\"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 mit

curl -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 ;)

[Negalein]

@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).