[Linux Shell-Skript] WLAN-Wetterstation

[SBorg]

@boronsbruder
IMO ein Bug im Simple-API (ev. soll es auch so sein) aber der kriegt von neu angelegten DPs während der Laufzeit nichts mit. Eigentlich schreibe ich es immer dazu, habe ich aber diesmal vergessen. Jaja, das Alter...

Die FT0300 werden automatisch erkannt, also kein Fehler in deiner Config. Da sie mit den neueren FW-Version des 2000er Gateways an den Bezeichnern geschraubt haben, schau mal in deinem Datenstring ob da nun eins von beiden, oder gar beides drin steht:

temp1f=
humidity1=

Dann ist logisch warum er einen FT0300 erkennt, müsste ich dann auch noch fixen

[Boronsbruder]

@sborg

temp1f=89.24&humidity1=51

Das ist der DP50

[SBorg]

@boronsbruder
Danke, kommt davon wenn man einen PR auf GitHub annimmt und es mangels Hardware nicht testen kann. Der Bug existiert dann bereits seit 08. Februar 2023, ist nur keinem aufgefallen. Geht auch nur im Debug-Modus und wenn man gleichzeitig DP50/100 Sensoren hat. Birgt aber kein echtes Problem während der Runtime, nur "Schönheitsfehler" beim Debug. Soll aber trotzdem nicht sein
Tausche mal bitte in der "wetterstation.sh" so bei Zeile ~#322 den Block

     ### zusätzliche Sainlogic oder Curconsa Sensoren, Station FT0300 ###########################
      if [[ ${MESSWERTERAWIN[$i]} == temp1f=* ]]
        then MESSWERTE[28]=$(echo ${MESSWERTERAWIN[$i]}|cut -d"=" -f2); convertFtoC 28; fi
      if [[ ${MESSWERTERAWIN[$i]} == humidity1=* ]]
        then MESSWERTE[29]=$(echo ${MESSWERTERAWIN[$i]}|cut -d"=" -f2); fi
     ### zusätzliche Sainlogic oder Curconsa Sensoren, Station FT0300 ################## ENDE ###

mit diesem aus, dann sollte beim Debug Ruhe sein

     ### zusätzliche Sainlogic oder Curconsa Sensoren, Station FT0300 ###########################
     if [ "${ANZAHL_DP50}" -eq "0" ] || [ "${ANZAHL_DP100}" -eq "0" ]; then
      if [[ ${MESSWERTERAWIN[$i]} == temp1f=* ]]
        then MESSWERTE[28]=$(echo ${MESSWERTERAWIN[$i]}|cut -d"=" -f2); convertFtoC 28; fi
      if [[ ${MESSWERTERAWIN[$i]} == humidity1=* ]]
        then MESSWERTE[29]=$(echo ${MESSWERTERAWIN[$i]}|cut -d"=" -f2); fi
     fi
     ### zusätzliche Sainlogic oder Curconsa Sensoren, Station FT0300 ################## ENDE ###

[Boronsbruder]

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

 if [ "${ANZAHL_DP50}" -eq "0" ] || [ "${ANZAHL_DP100}" -eq "0" ]; then                                                                    

funktionert. Kein Gemecker mehr im Debug

[SBorg]

@boronsbruder
Merci, kommt dann in die nächste Version. Extra dafür eine neue Version publishen lohnt irgendwie nicht

[Rushmed]

@sborg Bei mir wird seit letztem Freitag 0_userdata.0.Wetterstation.Info.Solarenergie_Tag und 0_userdata.0.Wetterstation.Info.Sonnenschein_Tag_Text nicht mehr zuverlässig zurückgesetzt.
In der Nacht musste ich den Server mehrmals neu starten, vermutl. hat sich da etwas verschluckt.
Ich habe 0_userdata.0.Wetterstation.Info.Solarenergie_Tag mittels 0_userdata.0.Wetterstation.tempData.Solarenergie jetzt schon dreimal repariert, damit zumindest die aktuellen Werte wieder stimmen.

Per Updater kann ich nicht einfach drüberbügeln. Ich würde als nächstes versuchen die .sh und die .sub im Verzeichnes mit den Dateien von Github zu überschreiben. Ist es da sinnvoll vorher 0_userdata.0.Wetterstation.tempData.Solarenergie und zu leeren oder irgendwie anders vorzubereiten?

Scriptversion 3.4

[SBorg]

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

In der Nacht musste ich den Server mehrmals neu starten, vermutl. hat sich da etwas verschluckt.

Wenn das gegen 23:58 Uhr war dann ja, da laufen die Mitternachtjobs die dafür verantwortlich sind.
Das dürfte aber nur die Tageswerte betreffen, die summieren sich dann einfach auf (also "gestern" + "heute" steht dann bei "heute"). Mit dem nächsten Lauf um 23:58 Uhr sollte er dann die Tageswerte auf "0" setzen und die doppelten Tageswerte auf Woche, Monat und Jahr aufrechnen.

Beim händischen Eingriff in die Routine bzw. Datenpunkte muss man allerdings folgendes wissen/beachten:
Eingriffe in die Datenpunkte dürfen nur bei deaktiviertem Skript erfolgen!
Grund ist folgender: die Werte liegen alle im RAM des Rechners (performanter, weniger Schreib-/Lesezugriffe im System). Kommt nun ein Datenpaket von der Station wird zum Wert im RAM der neue Wert hinzuaddiert und in "tempData" als Backup angelegt und in den entsprechenden Datenpunkt geschrieben.
"tempData" wird hier nicht weiter benutzt, da kann man also zur Laufzeit reinschreiben was man will, mit dem nächsten Datenpaket wird das wieder überbügelt. Selbes gilt für den normalen Datenpunkt.
"tempData" wird nur beim Start des Skriptes einmalig gelesen, damit man den letzten Stand vor Fehler, Reboot, Absturz... wieder hat, denn sonst wären auch die Wochen, Monats und Jahreswerte über die Wupper (es liegt halt alles im RAM).
Also wenn nötig Skript stoppen, den/die Daten unter tempData editieren und Skript starten. Dann baut er darauf die weiteren Werte wieder auf.

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

Per Updater kann ich nicht einfach drüberbügeln. Ich würde als nächstes versuchen die .sh und die .sub im Verzeichnes mit den Dateien von Github zu überschreiben. Ist es da sinnvoll vorher 0_userdata.0.Wetterstation.tempData.Solarenergie und zu leeren oder irgendwie anders vorzubereiten?

Brauchst du eigentlich nicht versuchen, dann müsste die sh/sub schon einen Fehler haben damit das dein Problem fixt. Ich vermute dein Grund liegt wie oben geschildert, du hast zwar Werte editiert/kopiert, aber dabei das Skript laufen lassen.
Der Updater macht im Grunde auch nichts anderes, der lädt die aktuelle Version von GitHub und kopiert die einfach über deine Installation drüber. Nur patcht er dann auch die conf auf die neue Version, damit man nicht jedesmal dort alles neu eintragen muss.
...und wenn du in tempData alles auf "0" setzt, fängst du wirklich wieder bei "0" an. Deine bisherigen Daten wird er dir dann mit dem nächsten Datenpaket auf "0 + aktuellem Wert der Station" ersetzen.

Auch wenn tempData erst mal harmlos aussieht, hier liegen die aktuellen Tages-, Wochen-, Monats- und Jahreswerte. Sind die weg, steht alles auf "0". Ich habe es bereits etliche Male erwähnt und nutze die Gelegenheit hier nochmals, die Datenpunkte habt ihr ja hoffenlich per bspw. BackitUp gesichert, einfacher ist aber die drei DPs per History-Adapter zu sichern. Ich nehme hier sicherheitshalber drei Tage. Da kann man im Fall der Fälle relativ einfach an den letzten korrekten Datensatz herankommen ohne ein kpl. Backup wieder herstellen zu müssen

[Rushmed]

@sborg Puh, danke für die ausfühliche Beschreibung ich beobacht das mal weiter.

[Boronsbruder]

@SBorg
Ich han da mol a Frach:
Bei mir ist vorhin die Internetverbindung zusammengebrochen.
Ab diesem Zeitpunkt wurden keine Daten mehr im Iobroker geschrieben. Die Wetterstation ist aber über LAN erreichbar.
Es scheint so, dass irgendwas im Skript verhindert, dass der nächste Datensatz geschrieben werden kann, weil ein Timeout fehlt.
Kann das sein, dass daran die Verbindung (oder besser nicht-Verbindung) zu AWEKAS schuld ist?
Ich hab nämlich mal die Internetverbindung getrennt und folgendes im Debug-Log gefunden und musste den eigentlich einmaligen Durchlauf dann terminieren:

--2024-09-05 20:50:40--  https://ws.awekas.at/weatherstation/updateweatherstation.php?ID=ITSME&PASSWORD=1234&dateutc=2024-09-05+18:48:28&tempf=70.16&humidity=81&winddir=194&uv=0&windspeedmph=0.67&absbaromin=28.186&baromin=29.811&solarradiation=0.00&windgustmph=2.24&dailyrainin=0.008&indoortempf=81.86&indoorhumidity=56&softwaretype=IOWS
Auflösen des Hostnamens ws.awekas.at (ws.awekas.at)… 195.189.4.166
Verbindungsaufbau zu ws.awekas.at (ws.awekas.at)|195.189.4.166|:443 … fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.
Erneuter Versuch.

--2024-09-05 20:52:52--  (Versuch: 2)  https://ws.awekas.at/weatherstation/updateweatherstation.php?ID=ITSME&PASSWORD=1234&dateutc=2024-09-05+18:48:28&tempf=70.16&humidity=81&winddir=194&uv=0&windspeedmph=0.67&absbaromin=28.186&baromin=29.811&solarradiation=0.00&windgustmph=2.24&dailyrainin=0.008&indoortempf=81.86&indoorhumidity=56&softwaretype=IOWS
Verbindungsaufbau zu ws.awekas.at (ws.awekas.at)|195.189.4.166|:443 … ^C

Zwischen den Versuchen liegen schon mal 2 Minuten...

[SBorg]

@boronsbruder
"wget" hat einen Default-Timeout von 900 Sekunden. Solange wird er also versuchen sein Datenpaket loszuwerden.
Zeile ~#2012 in der sub

local MESSAGE=$(wget -qO- "${AWEKAS_URL}")

ändern in

local MESSAGE=$(wget -qO- --timeout=15 "${AWEKAS_URL}")

sollte das fixen. Wenn er in 15 Sekunden das Datenpaket nicht los wird, stimmt extern irgendwas nicht. Er ist aber wieder ready ein Datenpaket von der Station zu empfangen.

[Boronsbruder]

@sborg
Ich werde das mal testen
Mir ist aber gerade aufgefallen, dass im Wetterstations-Log weit über 15 Minuten keine Daten kamen:

PASSKEY=XXXX&stationtype=GW2000A_V3.1.4&runtime=4281915&heap=147048&dateutc=2024-09-05+17:39:14&tempinf=81.32&humidityin=56&baromrelin=29.784&baromabsin=28.160&tempf=74.12&humidity=77&winddir=234&windspeedmph=0.67&windgustmph=2.24&maxdailygust=8.05&solarradiation=1.72&uv=0&rainratein=0.000&eventrainin=0.051&hourlyrainin=0.000&dailyrainin=0.008&weeklyrainin=0.059&monthlyrainin=0.059&yearlyrainin=22.547&totalrainin=22.547&temp1f=75.38&humidity1=76&soilmoisture1=50&soilad1=258&soilmoisture2=48&soilad2=207&soilmoisture3=52&soilad3=269&soilmoisture4=54&soilad4=273&soilmoisture5=27&soilad5=176&wh65batt=0&wh25batt=0&batt1=0&soilbatt1=1.6&soilbatt2=1.7&soilbatt3=1.4&soilbatt4=1.3&soilbatt5=1.1&freq=868M&model=GW2000A&interval=30

PASSKEY=XXXX&stationtype=GW2000A_V3.1.4&runtime=4284692&heap=150960&dateutc=2024-09-05+18:25:31&tempinf=81.50&humidityin=57&baromrelin=29.805&baromabsin=28.180&tempf=71.42&humidity=82&winddir=173&windspeedmph=2.01&windgustmph=4.47&maxdailygust=8.05&solarradiation=0.00&uv=0&rainratein=0.000&eventrainin=0.051&hourlyrainin=0.000&dailyrainin=0.008&weeklyrainin=0.059&monthlyrainin=0.059&yearlyrainin=22.547&totalrainin=22.547&temp1f=73.04&humidity1=80&soilmoisture1=50&soilad1=257&soilmoisture2=48&soilad2=207&soilmoisture3=52&soilad3=269&soilmoisture4=54&soilad4=273&soilmoisture5=27&soilad5=176&wh65batt=0&wh25batt=0&batt1=0&soilbatt1=1.6&soilbatt2=1.7&soilbatt3=1.4&soilbatt4=1.4&soilbatt5=1.1&freq=868M&model=GW2000A&interval=30

dateutc=2024-09-05+17:39:14 bis dateutc=2024-09-05+18:25:31

Wann wird das Log geschrieben?

Nicht dass das Gateway keine Daten gesendet hat, weil es keine Verbindung zum Internet hatte?

[SBorg]

@boronsbruder
Hmm, Gateway bin ich außen vor, allerdings hatte ich auch schon öfters ein abgestürtzes Internet. Da kamen nach Wiederherstellung ziemlich zügig wieder Daten an.

Zumindest fast 45 Minuten kommt IMO nicht vom Skript, muss ich mir aber noch mal anschauen.
Das Ganze ist eine Endlosschleife:

• warte auf ein Datenpaket
• verarbeite dies in zig Schritten
• mach den Beikram wie Min/Max etc.
• führe bei Bedarf 5,6 oder 15 Minutenjobs aus
• Mitternacht? --> Mitternachtjobs
• sende die Daten an die aktivierten Dienste
• und zum Schluß bevor wir einen neuen Durchlauf starten schreibe die Logzeile

[Boronsbruder]

@sborg
Ahh, dann kann es sein, da er laut dem Log ja einen 2. Versuch bei Awekas unternommen hat.
Bei den Wiederholungsversuchen ist das Default übrigens 20.
Kann mit --tries=number geändert werden.

Da ich Internet über LTE habe und es die Fritte nicht geschafft hat eine Neuverbindung aufzubauen, war das Internet ne gute 3/4 Stunde weg, bis ich sie manuell wiederverbunden habe --- was zu den Log Daten passen würde.

[Boronsbruder]

@sborg
Also...
Mit folgender Änderung

local MESSAGE=$(wget -qO- --tries=1 --timeout=15 "${AWEKAS_URL}")

werden die von der Wetterstation kommenden Daten intern (im LAN) weiter verarbeitet und an den Iobroker gesendet, wenn die Verbindung ins Web abreisst.

Ohne bleibt das Skript in der 20x 900 Sekunden Schleife stehen und wird (vermutlich) erst dann wieder Daten an den Iobroker weiterleiten.

Grüße
Markus

[SBorg]

@boronsbruder
Ich weiß aktuell nicht mehr ob das bei Awekas einen richtigen Grund hat mittels "wget" zu kommunizieren. Die "Anderen" Dienste laufen mittels "curl" und haben einen Timeout von 10 Sekunden

Danke auf jeden Fall fürs testen, die Änderung nehme ich für die nächste Version mit auf.

[Boronsbruder]

Das sind die besten Tage, sonnig bei geschlossener Wolkendecke und Regen

[WernerS]

@SBorg

Hallo

Also bei mir funktioniert das Sript mit HP1000SE super. Nur ist mir aufgefallen das beim Regen die Daten zweimal kurz hintereinander geschrieben werden. Ist schlecht für eine Auswertung.

Gruß
Werner

[SBorg]

@werners
Immer oder auch nur wenn es tatsächlich regnet? Andere Werte sind nicht betroffen?
Auch wenn du es wahrscheinlich nicht lesen magst, sieht aber nach einem lokalen Problemchen (oder der Station) bei dir aus.
Das Skript macht zuerst von alleine nichts, es führt also keine Aktion zwischenzeitlich aus wie bspw. Werte schreiben.
Es benötigt immer einen Trigger/Auslöser. Dies ist dann ein Datenpaket von der Station. Erst dann wird die Routine durchlaufen. Läuft bspw. gegen Mitternacht die Station nicht (=sendet keinerlei Datenpakete), wird auch nichts zurückgestellt (es fehlt dafür der Auslöser "empfangenes Datenpaket") und zB. der Solarwert wird nicht zurückgestellt.
Wenn er also bei dir kurz hintereinander den Regen 2x schreibt, muss auch 2x kurz hintereinander ein Datenpaket eingetrudelt sein (dann schreibt er aber auch fast alle anderen Werte).
Du kannst mal testweise das "Logging" per "conf" (nicht Debug) aktivieren (sudo systemctl restart wetterstation zum aktivieren nicht vergessen). Dann schreibt er jedes empfangene Datenpaket in die Logdatei. Ev. sieht man dann schon am Zeitstempel ob er tatsächlich kurz hintereinander zwei Datenpakete sendet. Dies könnte ich dann notfalls ausfiltern

[WernerS]

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

sudo systemctl restart wetterstation

ok habe ich gemacht. Jetzt muss ich nur noch auf den nächsten Regen warten dann schicke ich dir hier die logs.
Ich gehe davon aus das in den logs keine vertrauliche Daten gespeihert werden.

Gruß
Werner

[WernerS]

@sborg

So es hat gestern geregnet. Hier die logs

Gruß
Werner

20240927_station.log 20240926_station.log