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

[Rushmed]

Die Werte sind eingetragen aber die DPs werden nicht befüllt, auch nicht zur Viertelstunde oder muss ich länger warten?

#InfluxDB-Konfiguration / ohne InfluxDB alles leer lassen
  #IP und Port der API [xxx.xxx.xxx.xxx:xxxxx]
   INFLUX_API=192.168.178.020:08086
  #Name, User und Passwort der InfluxDB-Datenbank
   INFLUX_DB=ioBroker_db
   INFLUX_USER=User
   INFLUX_PASSWORD=Pass

Muss ich bei INFLUX_API die vorgegebene Anzahl von stellen mit Nullen auffüllen so wie abgebildet?

[Negalein]

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

Die Werte sind eingetragen aber die DPs werden nicht befüllt

Port ist so bei dir richtig?
INFLUX_API=192.168.178.020:08086

[Rushmed]

@negalein Das ist ja meine Frage. Der Port ist 8086.
Soll ich den jetzt mit ner Null auffüllen um

#IP und Port der API [xxx.xxx.xxx.xxx:xxxxx]

zu entsprechen?

Ging übrigens beides nicht.

[Negalein]

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

Soll ich den jetzt mit ner Null auffüllen

Nein, wie kommst du darauf?

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