openhabforum.de

Hallo zusammen,

ich habe nach langem herumspielen endlich die Daten meiner Wetterstation mit MQTT einlesen, und die Sensordaten mittels JSONPATH auslesen können. Da ich selber keinerlei Programmier-Kenntnis habe, bin ich auf viele Beispiele angewiesen, die ich dann nachbaue. Mein Problem ist nun, dass die Daten, die ich ausgelesen bekomme, um eine Zehner-Potenz zu hoch angezeigt werden. Die Daten aus dem Empfangsbaustein der Wetterstation habe ich als Screenshot angehängt.
Bild

mittels dieser Rule lese ich die empfangenen Rohdaten:

Code: Alles auswählen

rule "Regel zum Auslesen der Wetterdaten aus den strings"
when
    Item Outdoor_Weatherstation_Outdoor_Weather_Station received update
then
    WindrichtungOWS.postUpdate(transform("JSONPATH", "$.wind_direction", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
    TemperaturOWS.postUpdate(transform("JSONPATH", "$.temperature", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
    LuftfeuchtigkeitOWS.postUpdate(transform("JSONPATH", "$.humidity", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
    WindgeschwindigkeitOWS.postUpdate(transform("JSONPATH", "$.wind_speed", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
    BoeenOWS.postUpdate(transform("JSONPATH", "$.gust_speed", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
    RegenOWS.postUpdate(transform("JSONPATH", "$.rain", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
    BatterieLowOWS.postUpdate(transform("JSONPATH", "$.battery_low", Outdoor_Weatherstation_Outdoor_Weather_Station.state.toString))
end

ich habe gelesen, das OH die Werte trotz Typ string intern dennoch als number behandelt - die ausgelesenen Werte ensprechen jedoch nicht dem eigentlichen Werten:

{"identifier": 129, "temperature": 297, "humidity": 38, "wind_speed": 0, "gust_speed": 3, "rain": 3, "wind_direction": "e", "battery_low": false}

kann mir jemand helfen, die Daten richtig zu formatieren?

dankbar für jeden Tip
Andreas

Ach ja, ich betreibe OH in der aktuellen stable Release in einer Suse-VM

Du geht einen zu komplizierten Weg

Es reicht, ein passendes Generic mqtt Thing mit passenden Channels anzulegen (sowie natürlich die passenden Items):

Code: Alles auswählen

Bridge mqtt:broker:broker "Mosquitto" [
    host="192.168.178.55",
 ] {
    Thing topic weather "Wetterstation" {
      Channels:
          Type number : temp   "Temperatur"   [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.temperature", unit="d°C" ]
          Type number : hum    "Luftfeuchte"  [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.humidity",    unit="%" ]
          Type number : wspeed "Tempo Wind"   [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.wind_speed",  unit="m/s" ]
          Type number : gspeed "Tempo Böen"   [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.gust_speed",  unit="m/s" ]
          Type number : rain   "Regen"        [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.rain",        unit="mm/h" ]
          Type string : dir    "Windrichtung" [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.wind_direction" ]
          Type switch : bat    "Batterie"     [ stateTopic= "pfad zum topic", transformationPattern="JSONPATH:$.battery_low", onValue="true", offValue="false" ]
    }
}

Items:

Code: Alles auswählen

Number:Temperature   OWS_Temperatur   "Temperatur"             {channel="mqtt:topic:broker:weather:temp",   unit="°C",   stateDescription=""[pattern="%.1f °C"]}
Number:Dimensionless OWS_Luftfeuchte  "Luftfeuchte"            {channel="mqtt:topic:broker:weather:hum",    unit="%",    stateDescription=""[pattern="%.1f %"]}
Number:Speed         OWS_TempoWind    "Windgeschwindigkeit"    {channel="mqtt:topic:broker:weather:wspeed", unit="m/s",  stateDescription=""[pattern="%.1f km/h"]}
Number:Speed         OWS_TempoBoeen   "Windböen"               {channel="mqtt:topic:broker:weather:gspeed", unit="m/s",  stateDescription=""[pattern="%.1f km/h"]}
Number:Speed         OWS_Regen        "Regenmenge"             {channel="mqtt:topic:broker:weather:rain",   unit="mm/h", stateDescription=""[pattern="%.1f mm/h"]}
String               OWS_Richtung     "Windrichtung"           {channel="mqtt:topic:broker:weather:dir"}
Switch               OWS_BatterieLeer "Batteriestand kritisch" {channel="mqtt:topic:broker:weather:bat"}

Ich habe hier die Textform genutzt, Du kannst die Parameter aber genauso gut auch über die UI setzen (die entsprechenden Felder kann man ganz gut aus der Textdefinition ableiten).
Hinweis: Die unit als Parameter steht nur im Number Channel zur Verfügung (advanced Options).
Ein Channel mit gesetzter Unit sollte unbedingt immer mit einem Number:QuantityType Item verlinkt werden. Alle UoM Items (Units of Measurement; eben die QuantityType Items) haben ab OH4.0.0 ebenfalls einen unit Parameter, der zwingend gesetzt werden muss. Der Parameter bestimmt, in welcher Einheit der Wert im Item gehalten wird - und damit auch, wie der Wert persistiert wird.
Die stateDescription ist Teil der Metadaten. Dort wird festgelegt, wie der Wert dargestellt wird. %.1f bedeutet: Der Wert wird als Float Wert mit einer Nachkommastelle dargestellt. Die angegebene Einheit muss zu der Einheit des Items passen, also bei Temperature z.B. °C, °F oder K. Man kann aber (siehe Channel) auch die gebräuchlichen Vorsilben setzen, hier z.B. d°C -> deziGrad Celsius. Im Item zeigen wir °C an und das Komma wird automatisch um eine Stelle nach links verschoben.
Wenn Du willst, kannst Du auch noch das Semantic Model ergänzen (das habe ich mir hier gespart, damit wird die Textdefinition etwas länglich...)
Für die Windrichtung gibt es eine Besonderheit, denn dort wird ja ein Text geliefert.
Um nun sinnvolle Ausgaben zu erhalten, bietet sich die MAP-Transformation an.
Du musst dazu lediglich in der State Description unten Wertepaare eingeben, also z.B.

Code: Alles auswählen

s=Süd
e=Ost
w=West
n=Nord
sw=Südwest
se=Südost
...

Allerdings musst Du dazu natürlich erst mal alle möglichen Werte kennen. Hast Du mehrere Items, die das selbe Mapping brauchen, kannst Du das Mapping auch in eine Textdatei auslagern und darauf verlinken.
Links vom Gleichheitszeichen müssen Leerzeichen mit einem vorangestellten \ escaped werden. Die Texte sind exakt anzugeben (Groß-/Kleinschreibung pro Buchstabe beachten)

Der Batteriestatus kann bequem über ein Switch Item signalisiert werden, dazu muss man lediglich aus true/false ein ON/OFF machen, was schon im Channel über die gesetzten Parameter passiert. In der UI kann ein Switch ohne Probleme auch nur angezeigt werden (also ohne Schalter, nur der Status).
legt man noch passende Icons ab (battery-on und battery-off) und verlinkt auf battery als Icon, so bekommt man sogar eine volle bzw. leere Batterie als Icon angezeigt, je nach Zustand des Switch Items.

PS: bestimmt sind da jede Menge Tippfehler...

Hallo Udo,

vielen Dank für die ausführliche Erklärung. Ich werde es am Wochenede direkt umsetzen und gebe Rückmeldung.

Hallo Udo,

ich habe das so in der UI hinbekommen und wieder ein paar Zusammenhänge verstanden. Vielen Dank noch einmal für die großartige Unterstützung.

Hallo nochmal,

nachdem alles so super geklaptt hatt, versuche ich nun auch drei Raumsensoren des selben Systems nach dem gleichen Prinzip auszulesen. Einzige Schwierigkeit ist, das die Sensoren über das selbe State-Topic mit verschiedenen IDs ihre Daten melden:

{"identifier": 45, "temperature": 257, "humidity": 57}
{"identifier": 1, "temperature": 203, "humidity": 81}
{"identifier": 199, "temperature": 205, "humidity": 79}

Wie müsste die JSONPATH-Abfrage aussehen, um in Abhängigkeit von der ID die Werte einem Channel zuzuweisen?

Da mutmaßlich in der Payload immer nur die Messwerte eines Sensors im JSON eingepackt sind, werden die jeweils gerade nicht übertragenen Channel Fehler der unangenehmen Sorte (die auf die Items durchschlagen) hervorrufen. Die einfachste Möglichkeit, damit umzugehen:

Code: Alles auswählen

Type number : temp   "Temperatur"   [ stateTopic= "pfad zum topic", transformationPattern="REGEX:(.*identifier.: 45.*)∩JSONPATH:$.temperature", unit="d°C" ]

Regex lässt nur Strings durch, die die Zeichenfolge identifier": 45 enthalten - wobei ich der Einfachheit halber statt des Anführungszeichens nach einem beliebigen Zeichen (der Punkt) an dieser Stelle suchen lasse. Das Symbol für Schnittmenge (∩, in der Zeichentabelle unter Windows fälschlich als Durchschnitt benannt) steht im Hilfstext zur Incomming Value Transformation, dort kann man es am unkompliziertesten kopieren. Die Transformation wird von links nach rechts ausgeführt, also zuerst REGEX, dann JSONPATH, aber da REGEX nur die passenden JSON Objekte durchlässt, gibt JSONPATH immer die passenden Werte aus.

Hallo Udo,

danke für die Antwort. Aber anscheinend passt etwas mit der Syntax nicht, denn der Channel nimmt trotz der REGEX-Anweisung immer den Wert des zuletzt gesendeten Payloads an.

Hast Du REGEX auch installiert?

Ähm... und nach REGEX gehört natürlich ein Doppelpunkt...
Ich hab das oben abgeändert...

Ähm,räusper- jetzt, nachdem ich es installiert habe, läuft es wunderbar.

Vielen Dank für Deime Geduld und Hilfe!

Gerne

openhabforum.de

Sensordaten konvertieren

Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren

Re: Sensordaten konvertieren