Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

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

[da_Woody]

@sborg alter falter...
langsam hauts mir echt den vogel raus.
ich schau nach, blendstat ist installiert, zurück aufs dash,

es lebt...

[Boronsbruder]

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

deswegen wäre hier dann der Reset per conf empfehlenswert.

Was meinste damit?

[SBorg]

@boronsbruder In der kommenden 11er: https://github.com/SBorg2014/WLAN-Wetterstation/wiki/FAQ---Troubleshooting/#was-ist-der-datenpunkt-_kommunikationsfehler-

Mit obiger Änderung wird dann jedes Fehlerpaket von dir zu keinem validen Datenpaket. Dann wäre bei dir "Kommunikationsfehler" true Dauerzustand.
Ich habe mal bei mir geschaut, da waren es im Dezember bisher einmalig 4 Pakete direkt hintereinander.
Anscheinend funkt bei dir einer/etwas auf den 868MHz was so (eigentlich) nicht sein darf.

[Boronsbruder]

@sborg
jetzt im Moment ist wieder alles i.O.
Keine Aussetzer...
Ich versteh es nicht...
Wahrscheinlich gab's bei den Nachbarn China-Spielzeug zu Weihnachten

Das wäre aber zu verkraften, dann kann ich wenigstens was dagegen machen, bevor die Logs überlaufen

[Andre105]

Hallo Leute,
ich sehe ihr versteht die Sache schon ganz gut.
Bin erst Neuling in Sachen ioBroker.
Habe ja jetzt auch die Wetterstation am laufen.(eurochron EFWS 2900)
Würde die Daten auch gerne in den ioBroker bekommen.Später visualisieren.
Wie fange ich da an?
Habe schon einiges hier gelesen,aber für mich als Anfänger doch schon etwas schwierig.
Soll ich ein neues Thema aufmachen? oder stört es euch hier nicht?

[Latzi]

@andre105
Das Wiki dazu ist sehr hilfreich https://github.com/SBorg2014/WLAN-Wetterstation/wiki, damit würde ich starten. Fragen passen hier schon rein

[Andre105]

@latzi Ok , ich lese mir das mal durch

[da_Woody]

@andre105 aber konzentriert und step by step machen. du hast schneller einen knopf drinnen, als du glaubst...
grafana visus gibts ja schöne...

[meloneA]

Ich habe die Feiertage genutzt um von 1.5 auf die aktuellste Version umzusteigen. Ich habe per Updater (später auch manuell) die neue Version gezogen, die Datenpunkte per js Script aktualisiert und auch die config aktualisiert.

Laut Debug kommen auch Daten von der Station an, aber der Datenstring für ioBroker wird nicht erzeugt. Ich habe es auch zwecks Test kurz mit "Ecowitt" versucht, hier kommt es zum selben Fehler. Irgendetwas übersehe ich scheinbar, hat jemand einen Tipp wo ich noch ansetzen könnte?

WLAN-Wetterstation V2.10.1 - (c)2019-2021 by SBorg
 Config-Version: V2.10.0
 Sub-Version   : V2.10.1

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

 'nc' in der Openbsd-Variante installiert:  [✓]
 'netcat' in Openbsd-Variante aktiv, alles korrekt [✓]


Connection to 192.168.254.50 8087 port [tcp/*] succeeded!


Messwerteblock: 


Nicht alle Werte werden unterstützt (abhängig vom Modell der Wetterstation und dem verwendeten Protokoll)!

Temperatur Innen        :  °C
Temperatur Aussen       :  °C
Taupunkt                :  °C
Gefühlte Temperatur     :  °C
Luftfeuchte Innen       :  %
Luftfeuchte Aussen      :  %
Windgeschwindkeit       :  km/h
Windböengeschwindkeit   :  km/h
max. Windböe            :  km/h
Windrichtung            :  °
Windrichtung            : 
Luftdruck absolut       :  hPa
Luftdruck relativ       :  hPa
Regenrate               :  mm/h
Regenstatus             : 
Regen seit Regenbeginn  :  mm
Regen Stunde            :  mm
Regen Tag               :  mm
Regen Woche             :  mm
Regen Monat             :  mm
Regen Jahr              :  mm
Regen Gesamt            :  mm
Sonnenstrahlung         :  W/m²
UV-Index                : 
Zeitstempel             : 
Firmware                : 
Batteriestand:          : 
Gateway-Modell          : 

Zusatzsensoren: keine 


Datenstring für ioBroker:



DATA von Wetterstation:
GET /weatherstation/updateweatherstation.php?ID=xxxxxx&PASSWORD=xxxxxx&indoortempf=74.5&tempf=48.9&dewptf=46.0&windchillf=48.9&indoorhumidity=49&humidity=90&windspeedmph=2.9&windgustmph=5.8&winddir=186&absbaromin=29.197&baromin=30.440&rainin=0.000&dailyrainin=0.122&weeklyrainin=0.323&monthlyrainin=2.882&yearlyrainin=0&solarradiation=35.11&UV=0&dateutc=2021-12-30%2008:19:22&softwaretype=EasyWeatherV1.6.1&action=updateraw&realtime=1&rtfreq=5 HTTP/1.1


Debug VAR:
Installationsverzeichnis: /home/iobroker
IPP: 192.168.254.50:8087        WS_PORT: 1080           WS_POLL: 30             PRE_DP: javascript.0.Wetterstation
WEB: HTTP               WS_PROT: Wunderground   DP40/50/60/70/100/200/250/300: 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 
WH31: 0 
Script-Version: V2.10.1 Config-Version: V2.10.0 Sub-Version: V2.10.1
Kommunikationsfehler!

[SBorg]

@melonea Hi, hast du es als Service oder per cron laufen?

Ich vermute als Service, denn mich macht stutzig:
@melonea sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Kommunikationsfehler!

Es sieht so aus als würde der Service noch laufen, dann schlägt der ./wetterstation.sh --debug fehl, da sich dann zwei Programme um einen Port "prügeln", dass geht schief

Service beenden: systemctl stop wetterstation (oder falls cron sudo pkill -9 wetterstation.sh

[meloneA]

@sborg

ja, via service => dieser läuft aber nicht wenn ich die Tests mache:

root@debian-iobroker:/home/iobroker/test-update# ps -aux | grep wetter
root      237771  0.0  0.0   3088   680 pts/1    S+   11:17   0:00 grep wetter

Ich habe jetzt die Version 1.5 und 2.11 jeweils in einem eigenen Ordner. Bei 1.5 läuft der debug fehlerfrei, bei 2.11 kommt der o.g. Fehler.

[Thomas Braun]

@melonea

Startest du das skript auch als root? Solltest du nicht tun.

[meloneA]

Ok, nach einer kurzen DIFF Session der Konfigs war der Fehler dann doch recht einfach zu finden - die WS_ID war nicht korrekt.

In älteren Versionen gab es dazu einen Hinweis im Debug:

Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?

In der aktuellen 2.10 kommt nur noch die Meldung "Kommunikationsfehler".

[SBorg]

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

In älteren Versionen gab es dazu einen Hinweis im Debug:

Das ist mittlerweile obsolet, da beim Ecowitt-Protokoll keine WS_ID benutzt wird und dies aktuell das Default-Protokoll ist. Es bietet halt auch den Batteriestatus und unterstützt neben den Zusatzsensoren auch Gateways.
Ich kann halt nur feststellen, dass die Kommunikation nicht funktioniert, leider nicht das warum (WU ev. wie bei dir die WS_ID, Ecowitt...?).

...aber, ich habe eben mal schnell nachgeschaut. Ich kann auch problemlos die Meldung wieder hinzufügen wenn man eben WU nutzt

btw: wenn du ./ws_updater.sh --patch nutzt, wird die "conf" problemlos auf die gewünschte Version gepatcht (mit jedem Aufruf +1 Version von der aktuell installierten), ohne dass man noch irgendwas selbst editieren muss, lediglich ggf. halt neu hinzugekommene Parameter.

[Rene55]

@SBorg Ich habe erst jetzt festgestellt, dass ich im Datenpunkt "DP_DRUCK_TENDENZ" neben den erwarteten Werten auch öfters den Wert -999 drin habe. Dann funktioniert natürlich das Grafana-Dashboard nicht. Hast du eine Ahnung, wo der Wert herkommen könnte oder wie man den falschen Wert rausfiltern kann? In Influx ist das schon sehr mühselig.

[SBorg]

@rene55 Ist die Frage wo das herkommt. Das Skript speichert in einer RRD (Datenbank im RAM; da wird der aktuelle Wert hineingeschrieben und der älteste fliegt dafür raus) den Luftdruck der ca. letzten 5 Minuten (10 Werte in der RRD möglich; Datenintervall ca. alle 30 Sekunden der Station).
Nun wird vom ältesten Wert (also ca. vor 5 Minuten) der aktuelle Luftdruck abgezogen = Tendenz (kein Mittelwert oder Gleitwert; der Luftdruck ändert sich binnen 5 Minuten nicht so signifikant +/-3 ist da schon Maximum).

Loggst du den Luftdruck per Influx? Dann könnte man mal sehen ob die Ausreißer von der Station kommen, oder ob dein Rechner irgendwie ein Problem hat (zB. zerschießt die RRD; dann ist klar wenn ich von 0 was abziehe, dass das negativ wird )

Ich könnte es auch pauschal begrenzen und nur +/-9 zulassen, aber dann wäre es auch nicht sehr aussagefähig wenn der korrekte Wert bspw. "+2" wäre, und ich die fälschlichen "-999" dann auf "-9" setze...

[Rene55]

@SBorg Merci für die schnelle und erklärende Antwort. Die Logs von 'Druck_relativ' undf 'Druck_absolut' sehen sauber aus - regelmäßige Daten und keine 0-Werte. Als erste Rettung dachte ich daran, Werte kleiner als -9 einfach zu ignorieren. Hier mal ein Auszug aus 'Luftdruckdendenz':

timestamp;value;acknowledged;from;
2021-12-30T12:00:28.404Z;0;false;simple-api.0
2021-12-30T12:15:23.485Z;0;false;simple-api.0
2021-12-30T12:30:03.636Z;0;false;simple-api.0
2021-12-30T12:45:32.269Z;0;false;simple-api.0
2021-12-30T13:00:27.579Z;0;false;simple-api.0
2021-12-30T13:15:23.569Z;0;false;simple-api.0
2021-12-30T13:30:04.114Z;0;false;simple-api.0
2021-12-30T13:45:32.276Z;1;false;simple-api.0
2021-12-30T14:00:27.500Z;1;false;simple-api.0
2021-12-30T14:15:08.457Z;1;false;simple-api.0
2021-12-30T14:30:03.450Z;1;false;simple-api.0
2021-12-30T14:30:43.245Z;-999;false;simple-api.0
2021-12-30T14:45:00.806Z;1;false;simple-api.0
2021-12-30T14:45:06.867Z;-999;false;simple-api.0
2021-12-30T15:00:27.444Z;1;false;simple-api.0
2021-12-30T15:00:37.088Z;-999;false;simple-api.0
2021-12-30T15:15:01.176Z;-999;false;simple-api.0
2021-12-30T15:15:23.455Z;1;false;simple-api.0
2021-12-30T15:30:03.288Z;1;false;simple-api.0
2021-12-30T15:30:30.302Z;-999;false;simple-api.0
2021-12-30T15:45:32.543Z;2;false;simple-api.0
2021-12-30T15:45:58.824Z;-999;false;simple-api.0
2021-12-30T16:00:23.080Z;-999;false;simple-api.0
2021-12-30T16:00:27.498Z;2;false;simple-api.0

Ich hab ja wohl keine Chance, die RRD näher zu betrachten.

[SBorg]

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

Ich hab ja wohl keine Chance, die RRD näher zu betrachten.

Da könnte ich notfalls eine Ausgabe hinzufügen, aber mich macht eher das stutzig:

2021-12-30T14:45:00.806Z;1;false;simple-api.0
2021-12-30T14:45:06.867Z;-999;false;simple-api.0

Sieht bei den anderen ähnlich aus. 1. Wert noch Ok (kommt alle 15 Minuten + x Sekunden wann das nächste Paket eintrudelt).
2. Wert dann willkürlich später und mit -999?!
Ich schreib da eigentlich nichts mehr und soweit ich mich erinnere auch nix mit -999 (muss ich aber mal eruieren). Kann das von irgendwas anderem (JS-Skript, Alias...) kommen? Denn alle 00, 15, 30 und 45 Minuten kommt auch immer ein korrekter Wert. Wenn man alle -999 eliminiert, hat man einen sauberen Verlauf.