[Linux Shell-Skript] WLAN-Wetterstation

[Thomas Braun]

@qqolli

Wenn es denn erforderlich wäre...
Ich würde das dann mit scp oder pscp oder ähnlichem machen.
Zum Beispiel so:

pscp -pw password c:\User\Test\testdatei.txt user@192.168.33.10:/etc/var/test/test.txt

pscp kommt aus der puTTY-Ecke. Keine Ahnung, ob das mit einer Grundinstallation von puTTY mitinstalliert wird.

[qqolli]

@thomas-braun

Da ich puTTY habe, ist es (wie bereits von Dir vermutet) dabei:

pscp /?
PuTTY Secure Copy client
Release 0.73
Usage: pscp [options] [user@]host:source target
       pscp [options] source [source...] [user@]host:target
       pscp [options] -ls [user@]host:filespec
Options:
  -V        print version information and exit
  -pgpfp    print PGP key fingerprints and exit
  -p        preserve file attributes
  -q        quiet, don't show statistics
  -r        copy directories recursively
  -v        show verbose messages
  -load sessname  Load settings from saved session
  -P port   connect to specified port
  -l user   connect with specified username
  -pw passw login with specified password
  -1 -2     force use of particular SSH protocol version
  -4 -6     force use of IPv4 or IPv6
  -C        enable compression
  -i key    private key file for user authentication
  -noagent  disable use of Pageant
  -agent    enable use of Pageant
  -hostkey aa:bb:cc:...
            manually specify a host key (may be repeated)
  -batch    disable all interactive prompts
  -no-sanitise-stderr  don't strip control chars from standard error
  -proxycmd command
            use 'command' as local proxy
  -unsafe   allow server-side wildcards (DANGEROUS)
  -sftp     force use of SFTP protocol
  -scp      force use of SCP protocol
  -sshlog file
  -sshrawlog file
            log protocol details to a file

[Thomas Braun]

@qqolli

Mit der Windows PowerShell geht es ähnlich:

PS C:\Users\212396433\Documents\Vodafone_speedtests> scp '.\2021-05-11 20_28_53-Echarts [ioBroker].jpg' echad@chet.fritz.box:/home/echad/testdatei.jpg

[Rene55]

@SBorg Ich muss hier auch noch mal nachfragen: Dein Script läuft bei mir im Docker-Container. Ich habs heute mal geschafft, das Script im debug laufen zu lassen. Hier viel mir folgendes auf:
WLAN-Wetterstation V2.11.0 - (c)2019-2021 by SBorg
Config-Version: V2.11.0
Sub-Version : V2.11.0

'bc' installiert: [✓]
'jq' installiert: [✓]

/opt/weather/wetterstation.sub: line 752: sudo: command not found
/opt/weather/wetterstation.sub: line 756: sudo: command not found
┌────────────────────────────────────────────────────────────┐
│ │
│ "netcat" ist nicht in der benötigten Version installiert! │
│ │
│ Soll er nun installiert werden? [J/N]: j │
│ │
└────────────────────────────────────────────────────────────┘

/opt/weather/wetterstation.sub: line 772: sudo: command not found.
In meinem Dockerfile ist aber explizit die 'netcat-openbsd' installiert.
Weiterhin fiel mir auf, dass der Datenstring seltsam aufhört:
Datenstring für ioBroker: 0_userdata.0.Wetterstation.Innentemperatur=19.11&0_userdata.0.Wetterstation.Aussen...<gekürzt>.....Wetterstation.Windrichtung_Text=SSW&0_userdata.0.Wetterstation.Info.Hitzeindex=
Hast du dazu eine Meinung - oder zwei?

[SBorg]

@rene55 Fangen wir mit dem einfachen an:

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

Datenstring für ioBroker: 0_userdata.0.Wetterstation.Innentemperatur=19.11&0_userdata.0.Wetterstation.Aussen...<gekürzt>.....Wetterstation.Windrichtung_Text=SSW&0_userdata.0.Wetterstation.Info.Hitzeindex=

Ist normal und Ok. Aktuell gibt es keinen Wert für den Hitzeindex, deswegen endet der direkt mit einem "=". So wird ein ggf. vorher existierender Index gelöscht/resettet und gleichzeitig kein Wert geschrieben (hilfreich zB. beim Influx-Logging).
Kleiner Exkurs / Rechnung: 86400 sek. (pro Tag) / 30 sek. (Standardintervall der Datenübertragung) = 2.880 Daten-/Messwerte
Rechnen wir mal grob (IMHO noch viel mehr als die gleich angenommen 250 Tage) die Nächte, Winter, teils Herbst und Frühjahr und teilweise den Sommer ab, wären das 250 Tage x 2.880 = 720.000 Messwerte in denen nur drin steht "es liegt kein Hitzeindex vor".
Ähnliches gilt für den Regen. Es ergibt ja keinen Sinn dauernd zu melden "kein Regen".
Da ist es doch einfacher (weil es auch nicht andauernd regnet) keine Meldung = kein Regen und nur was melden wenn es dann auch tatsächlich regnet

---

Docker bin ich leider außen vor, aber um zB. die netcat-Alternative korrekt einzustellen werden "sudo" - Rechte benötigt. Das meckert er auch an:

/opt/weather/wetterstation.sub: line 752: sudo: command not found
/opt/weather/wetterstation.sub: line 756: sudo: command not found

Er findet "sudo" nicht, wahrscheinlich für/im Container nicht aktiviert/verfügbar. Das ist aber nur die Überprüfung ob netcat korrekt ist. Wenn es das sowieso schon war bzw. installiert ist, macht es auch nichts wenn die Prüfung fehlschlägt, solange es die "openbsd"-Variante ist.

[Rene55]

@SBorg Danke für die ausführlichen Erklärungen - das hilft mir weiter. Tatsächlich gibt es in dem Container kein sudo. Ich könnte ja mal spaßeshalber einen Container mit Sudo bauen und nochmal testen.
Beim Hitzeindex war ich mir nicht so sicher, da ich immer noch Probleme habe, den Simple-API mit User/Kennwort zu betreiben. Ich dachte, der Datenstring wäre unvollständig und deswegen kämen User und Passwort nicht mit rüber. Auch das werde ich dieser Tage nochmals testen. Auf jeden Fall, nochmals Danke für Script und Erklärung.

[SBorg]

@rene55 immer gerne

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

...da ich immer noch Probleme habe, den Simple-API mit User/Kennwort zu betreiben

Habe ich auch offen gestanden nie probiert und der Aufruf ist nur lt. Doku umgesetzt. Muss ich mal Zeit dafür finden (ggf. ein Issue auf GitHub, dann vergesse ich es auch nicht )

[SBorg]

Neue Version des JavaScriptes Wetterstation-Statistik auf GitHub V1.0.1

• ~Bugfixing "error: TypeError: Cannot read property '0' of null"
• ~Wechsel zu axios

Wie immer zu finden im GitHub

---

Der Wechsel zu axios ist lediglich ein "unter der Haube". Der Support der benötigten "request"-Routine wird bzw. ist seitens NPM eingestellt.

[Boronsbruder]

Ich habe in letzter Zeit immer mal wieder das Problem, dass ich folgenden Eintragungen im Log des Wetterstation.service bekomme:

Dec 25 11:57:45 ZEROSERVER wetterstation.sh[26522]: Connection to 192.168.116.249 8087 port [tcp/*] succeeded!
Dec 26 00:41:49 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 26 00:42:08 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 26 00:42:27 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 26 00:42:46 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error

Dec 18 13:05:06 ZEROSERVER wetterstation.sh[14524]: Connection to 192.168.116.249 8087 port [tcp/*] succeeded!
Dec 18 14:14:53 ZEROSERVER wetterstation.sh[14524]: (standard_in) 1: syntax error
Dec 18 14:15:11 ZEROSERVER wetterstation.sh[14524]: (standard_in) 1: syntax error
Dec 19 03:03:46 ZEROSERVER wetterstation.sh[14524]: (standard_in) 1: syntax error

Zu verschiedenen Zeitpunkten

Irgendwann aber nicht gleichzeit treten dann im Iobroker-Log

2021-12-27 08:38:05.097 - info: simple-api.0 (15129) State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Tag" has to be type "number" but received type "string"
2021-12-27 08:38:05.099 - info: simple-api.0 (15129) State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string"
2021-12-27 08:38:05.141 - info: simple-api.0 (15129) State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Monat" has to be type "number" but received type "string"
2021-12-27 08:38:05.141 - info: simple-api.0 (15129) State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Jahr" has to be type "number" but received type "string" 

auf

Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error
Dec 27 08:38:05 ZEROSERVER wetterstation.sh[26522]: (standard_in) 1: syntax error

die syntax error setzen sich dann fort bis zum Service-Restart...

Wo kann ich da suchen bzw. wie?

[Boronsbruder]

Ich glaube ich habe eine Spur...
Mir ist aufgefallen, dass gerade auf der WSView-App keine Daten mehr vom Sensor kamen.
Das Fehlen der Daten scheint die syntax-Error auszulösen...

Hab jetzt mal das in der .conf das logging aktiviert.

Dabei trat bei mir mal wieder ein Fehler auf...

/home/wetter/wetterstation.sub: Zeile 1141: 20211227_station.log: Keine Berechtigung

Erst als ich die Zeile 1141 in der .sub mit "/home/wetter" erweitert habe, durfte er schreiben. Wo wollte er zuvor hin schreiben?

[SBorg]

@boronsbruder Anscheinend bekommt er da keine Daten vom "Sonnensensor", deswegen die Meldungen im Log. Darauf deutet dann auch

"0_userdata.0.Wetterstation.Info.Solarenergie_Tag" has to be type "number" but received type "string"
usw.

Der Wert ist eigentlich eine Zahl, er bekommt aber wg. der vermutlich fehlgeschlagenen Rechnung (weil er keine Daten zum rechnen hatte) nun einen String ("rechne mit nix" = NULL [also kein Wert; dies wird dann als String interpretiert]) zurück.

Trotzdem merkwürdig, denn eigentlich sollte der ganze Solarenergie-Part (der wird ja nur kpl. berechnet und basiert auf keinem Wert den die Station so liefert) nur ausgeführt werden wenn auch ein Wert vorliegt:

 if [ "$SONNEN_STRAHLUNG" -gt "0" ]...

Ev. liefert das Log was schlüssigeres. Aktuell fehlt mir da leider der Ansatzpunkt...

---

Das Log wird (oder sollte) im aktuellen Verzeichnis angelegt (werden). Wenn er aber als Service gestartet wird (IMO waren meine Tests nur per Shell-Aufruf?) will er sie wohl im "systemd"-Verzeichnis anlegen, was ohne root-Rechte nicht erlaubt ist. Fix kommt dann in die V2.11.0 mit rein:

logging() {
      local DATUM=$(date '+%Y%m%d')
      echo -e "\n${DATA}" >> "${DIR}/${DATUM}_station.log"
}

Damit landet es auch wirklich im Installationsverzeichnis

[da_Woody]

@sborg mannmann, wieder typisch... nachdem vor einigen tagen der strom für 5 std abgedreht war, hatte ich probleme mit der station beim wieder einbinden. hat schon gut angefangen, weil sich das kabelmodem nicht mehr mit dem provider verbunden hat. nach einer stunde dann anruf beim provider, der das modem neu gestartet, auf einmal gings...
so bin ich jetzt nach und nach am fehler suchen und zu reparieren.
dann in ws_view nachgeschaut, bei wunderground keine werte! ich schau auf der webpage, meine station ist offline.
das ganze mit aktuellem stand komplett neu gemacht, alles eingetragen, keine änderung.
gestern sogar versucht eine neue station bei WU zu machen, genauso offline.
jetzt seh ich den beitrag, will nachfragen, schau nochmal in ws-view, daten! wunderground.com, die station ist online!
manchmal ist es echt zum aus der haut fahren...
so, genug gekotzt, danke fürs lesen...

[Andre105]

Hallo zusammen,

Ich hänge mich hier mal rein.
Habe auch eine Eurochron EFWS2900 mir gekauft.
Habe sie eingerichtet und die Daten werden schon bei Ecowitt.net angezeigt.
Leider Kommen die Daten bei Weather Underground nicht an.
Dort ist die Station immer offline.
Was muss ich da noch einstellen?

[Boronsbruder]

@sborg
Also, das Problem entsteht z.B. wenn aus unerklärlichen Gründen (sprich ohne Änderungen an der Funkstrecke) der Sensor keine Daten mehr sendet...

dann kommen vom Gateway nur noch

PASSKEY=*****&stationtype=GW1000A_V1.6.8&dateutc=2021-12-28+06:09:35&tempinf=80.2&humidityin=29&baromrelin=29.574&baromabsin=27.929&freq=868M&model=GW1000_Pro

Das löst den Syntaxerror aus (denke ich)

[SBorg]

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

Was muss ich da noch einstellen?

Nur die korrekte Station-ID und -Key. Diese sollte keine Sonderzeichen, Umlaute und Leerzeichen enthalten (sollte so schon seitens WU so sein).
Aber @da_Woody hatte ein Post über deinem temporär das gleiche Problem. Ev. hat WU auch aktuell Probleme.

[SBorg]

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

Das löst den Syntaxerror aus (denke ich)

Jupp, kein Wert der Sonnenstrahlung. Damit kann man arbeiten. Wir erweitern einfach die Definition (es muss auch eine Außentemperatur geben) wann ein Datenpaket valide ist. Damit führt er dann keine Berechnung aus (setzt aber den Komfehlerzähler hoch, deswegen wäre hier dann der Reset per conf empfehlenswert. "Dauerfehler" lösen ihn dann trotzdem permanent aus).

In der sub so um Zeile #265 von

if [ "$STRLEN" -gt "150" ] && [[ "$DATA" =~ "PASSKEY=" ]]; then return 0; else return 1; fi

in

if [ "$STRLEN" -gt "150" ] && [[ "$DATA" =~ "PASSKEY=" ]] && [[ "$DATA" =~ "tempf=" ]]; then return 0; else return 1; fi

[da_Woody]

@sborg wieso meine station auf einmal wieder online ist? k.A.
in deinem script hatte ich anscheinend wiedermal sauhaufen drinnen, bei irgendeinem update was falsch gemacht.
beim neu machen noch ein kleine blindheitsproblem:

 #InfluxDB-Konfiguration / ohne InfluxDB alles leer lassen
  #IP und Port der API [192.168.0.252:8086]
   INFLUX_API=192.168.0.252:8086

die adresse nicht bei INFLUX_API eingetragen, sondern oberhalb.

[SBorg]

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

die adresse nicht bei INFLUX_API eingetragen, sondern oberhalb.

Entschuldige
...der ist aber mal richtig gut...

Aber mit WU habe ich nix am Hut. Das macht die Station von alleine wenn man per WS View dort seine Daten einträgt. Ich mache "nur" OpenSenseMap, Windy und wetter.com

[da_Woody]

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

...der ist aber mal richtig gut...

i know, i know...
grafana tut eigentlich auch wieder was soll. allerdings:
0_userdata.0.WoodyWetter.Druck_Tendenz das steht im objekt -1 und in grafana

raw sieht so aus:

{
  "common": {
    "name": "Luftdrucktendenz",
    "type": "number",
    "role": "state",
    "custom": {
      "influxdb.0": {
        "enabled": true,
        "storageType": "String",
        "aliasId": "",
        "changesOnly": true,
        "debounce": "1000",
        "changesRelogInterval": 3600,
        "changesMinDelta": "0"
      }
    }
  },
  "native": {
    "name": "Luftdrucktendenz",
    "type": "number",
    "role": "state"
  },
  "type": "state",
  "_id": "0_userdata.0.WoodyWetter.Druck_Tendenz",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.influxdb.0",
  "user": "system.user.admin",
  "ts": 1640440814575
}

stimmt da was nicht?

[SBorg]

@da_woody Nö, das ist Ok. Die Tendenz kann +/- 9 sein (idR. allerdings nur -3 bis +3)
Du brauchst aber in Grafana das "farski-blendstat-panel" dafür und ein passendes "value range mapping":

Hier mal das JSON mit obigem Doppelpfeil:

Grafana

{
"id": 42,
"gridPos": {
"h": 1,
"w": 5,
"x": 4,
"y": 10
},
"type": "farski-blendstat-panel",
"datasource": {
"type": "influxdb",
"uid": "000000001"
},
"pluginVersion": "8.0.1",
"maxDataPoints": 100,
"links": [],
"blendName": "total",
"colors": [
"#299c46",
"rgba(237, 129, 40, 0.89)",
"#d44a3a"
],
"format": "none",
"gauge": {
"maxValue": 100,
"minValue": 0,
"show": false,
"thresholdLabels": false,
"thresholdMarkers": true
},
"mappingType": 2,
"mappingTypes": [
{
"$$hashKey": "object:730",
"name": "value to text",
"value": 1
},
{
"$$hashKey": "object:731",
"name": "range to text",
"value": 2
}
],
"nullPointMode": "connected",
"postfixFontSize": "50%",
"prefix": "Luftdrucktendenz: ",
"prefixFontSize": "50%",
"rangeMaps": [
{
"$$hashKey": "object:738",
"from": "null",
"text": "N/A",
"to": "null"
},
{
"$$hashKey": "object:740",
"from": "0",
"text": "⇐",
"to": "0"
},
{
"$$hashKey": "object:742",
"from": "0.1",
"text": "⇖",
"to": "1"
},
{
"$$hashKey": "object:744",
"from": "1.1",
"text": "⇑",
"to": "9"
},
{
"$$hashKey": "object:774",
"from": "-1",
"text": "⇙",
"to": "-0.1"
},
{
"$$hashKey": "object:776",
"from": "-9",
"text": "⇓",
"to": "-1.1"
}
],
"sparkline": {
"fillColor": "rgba(31, 118, 189, 0.18)",
"full": false,
"lineColor": "rgb(31, 120, 193)",
"show": false
},
"targets": [
{
"alias": "Luftdrucktendenz",
"groupBy": [
{
"params": [
"$__interval"
],
"type": "time"
},
{
"params": [
"null"
],
"type": "fill"
}
],
"measurement": "javascript.0.Wetterstation.Druck_Tendenz",
"orderByTime": "ASC",
"policy": "default",
"refId": "A",
"resultFormat": "time_series",
"select": [
[
{
"params": [
"value"
],
"type": "field"
},
{
"params": [],
"type": "last"
}
]
],
"tags": []
}
],
"transparent": true,
"valueFontSize": "70%",
"valueMaps": [
{
"$$hashKey": "object:733",
"op": "=",
"text": "N/A",
"value": "null"
},
{
"$$hashKey": "object:735",
"op": "=",
"text": "=",
"value": "0"
}
],
"valueName": "current",
"colorBackground": false,
"colorValue": false,
"postfix": "",
"tableColumn": "",
"thresholds": "",
"interval": null,
"cacheTimeout": null,
"nullText": null
}