Ein Topic sollte nach Möglichkeit keine Sonderzeichen enthalten.
zigbee2mqtt/Feuchtigkeits-/Temperatursensor Waschküche enthält ein -, ein / (der ist reserviert), ein Leerzeichen und noch ein ü.
Ja, grundsätzlich geht das alles, aber es ist nun mal schlechter Stil und es führt unweigerlich zu Problemen.
Weiter...
Es gibt zwei unterschiedliche Methoden, in openHAB zu konfigurieren. Zum einen über Textdateien, zum anderen über die UI. Was Du in den Textdateien konfigurierst, kannst Du in der UI sehen, aber nicht editieren. Was Du in der UI konfigurierst, erscheint nicht in den Textdateien (dann wäre es ja über die UI nicht mehr änderbar...)
Die Textkonfiguration ist historisch gewachsen, und leider hat man bei der Entwicklung von openHAB2 den Fehler gemacht, die Textvariante nicht zu 100% zu integrieren - man dachte, sie loswerden zu können - und seitdem (ca. 2017) muss jedem User erklärt werden, was dick und fett in der Doku steht, nämlich, dass beide Verfahren 100 % voneinander unabhängig sind. Es gibt keine Übernahme von a nach b oder umgekehrt.
In der UI tauchen die Textelemente lediglich deshalb auf, weil sie nun mal Bestandteil der Konfiguration sind, und die UI liest die Konfiguration über die API aus.
Genauso kannst Du in der Textkonfiguration ohne Einschränkungen die Elemente der UI Konfiguration nutzen (z.B. ein Item auf einen Channel verlinken), Du kannst sie aber nicht bearbeiten - weil sie gar nicht erst auftauchen.
Solltest Du nun auf die Idee kommen, identische Things (oder Items) in den Textdateien zu kreieren, dann zerschießt Du damit die Konfiguration von openHAB.
Du kannst beide Methoden parallel nutzen, Du musst aber wissen, was Du wo konfiguriert hast, denn nur dort kannst Du es auch bearbeiten.
Wenn Du eine Bridge über die UI angelegt hast, kannst Du diese auch über die Textkonfiguration nutzen, Du musst aber für jedes Thing einen Bezug zu der Bridge angeben, es reicht nicht, diesen über die UID des Things herzustellen. Besser wäre es in diesem Fall, die Bridge ebenfalls über die Textdatei anzulegen und die Generic mqtt Things als Kinder der Bridge anzulegen - das spart Tipparbeit.
Die Links zu den Channels sind auch nicht irgendwelche, die müssen schon stimmen (am besten überlässt man es VS Code, diese einzutragen)
Ein Link zu einem mqtt Channel lautet immer "mqtt:topic:<brokerid>:<thingid>:<channelid>", Deine Links lauten "mqtt:broker:..."
Welchen Weg Du wählst, ist egal, meist fühlen sich Einsteiger mit der UI wohler - vor allem, weil dort die Form erzwungen wird, es gibt Felder, in die "nur" das Richtige eingetragen werden muss.
Dein eigentliches Problem, warum Du keine Daten in Deine Channel bekommst, ist ein großes Missverständnis Deinerseits zur Funktionsweise von MQTT.
Es gibt in MQTT Topics und Payloads. Ein Topic besteht gewöhnlich aus einer hierarchischen Struktur <gerätegrupppe>/<gerät>/<topicart>/<endpunkt> wobei <gerätegruppe> gerne weg gelassen wird.
<topicart> könnte verwendet werden, um die Datenrichtung zu bestimmen, muss auch nicht unbedingt vorhanden sein, letztlich ist es jedem selbst überlassen, wie die Topics ausgestaltet sind. Wichtig zu verstehen ist aber, das Topic kannst Du Dir wie einen Dateinamen vorstellen, mitsamt Verzeichnisbaum. Und der Inhalt der Datei ist die Payload. Die Payload kann verschiedene Formate aufweisen, weit verbreitet sind Text und JSON, aber man könnte auch genauso Binärdateien oder XML als Payload verwenden.
Das Beispiel oben etwas anders formatiert:
Code: Alles auswählen
{
"battery": 100,
"humidity": 50.41,
"linkquality": 144,
"power_outage_count": 8,
"pressure": 1007.9,
"temperature": 22.83,
"voltage": 3035
}
Es handelt sich um JSON.
Der Inhalt, der im Channel ankommt, ist der gesamte Text. Die in Anführungszeichen gesetzten Strings sind NICHT Teil des Topics. Stattdessen musst Du im Channel einen Transformation Service nutzen, um den eigentlichen Wert zu extrahieren. Da es sich um JSON handelt, bietet sich JSONPATH an, das steht als Addon zur Verfügung und muss gesondert installiert werden.
Anschließend kannst Du dann im Channel als Incomming Value Transformation mittels JSONPATH:$.pressure z.B. auf den Wert 1007.9 zugreifen.
Wie gesagt geht das ganz bequem über die UI, genauso gut natürlich auch per Textdatei
mqtt.things:
Code: Alles auswählen
Bridge mqtt:broker:bridge "Mosquitto" [
host="localhost"
] {
Thing topic sensor_wk "Sensor Waschküche" {
Channels:
Type number : temp "Temperatur" [ stateTopic = "zigbee2mqtt/allround_sensor_waschkueche", transformationPattern="JSONPATH:$.temperature", unit="°C" ]
Type number : hum "Feuchte" [ stateTopic = "zigbee2mqtt/allround_sensor_waschkueche", transformationPattern="JSONPATH:$.humidity", unit="%" ]
Type number : press "Druck" [ stateTopic = "zigbee2mqtt/allround_sensor_waschkueche", transformationPattern="JSONPATH:$.pressure", unit="hPa" ]
Type number : volt "Spannung" [ stateTopic = "zigbee2mqtt/allround_sensor_waschkueche", transformationPattern="JSONPATH:$.voltage", unit="V" ]
Type number : bat "Batteriestatus" [ stateTopic = "zigbee2mqtt/allround_sensor_waschkueche", transformationPattern="JSONPATH:$.battery", unit="%" ]
Type number : quality "Link" [ stateTopic = "zigbee2mqtt/allround_sensor_waschkueche", transformationPattern="JSONPATH:$.linkquality" ]
}
}
Die Bridge ist hier als Elter definiert, was es erspart, bei jedem Thing mit angeben zu müssen, welche Bridge es denn nun ist.
Und die zugehörige mqtt.items:
Code: Alles auswählen
Number:Temperature WK_temperature "Temperatur" <temperature> {channel="mqtt:topic:bridge:sensor_wk:temp"}
Number:Dimensionless WK_humidity "Feuchtigkeit" {channel="mqtt:topic:bridge:sensor_wk:hum"}
Number:Pressure WK_pressure "Luftdruck" {channel="mqtt:topic:bridge:sensor_wk:press"}
Number:Dimensionless WK_battery "Batteriezustand" <battery> {channel="mqtt:topic:bridge:sensor_wk:bat"}
Number WK_quality "Verbindungsstatus[%d]" {channel="mqtt:topic:bridge:sensor_wk:quality"}
Und die sehen nun völlig anders aus als bei Dir, zum einen durch die anderen Links zu den Channels, zum anderen handelt es sich zum großen Teil um UoM Items, das heißt, sie nutzen automatisch die passende Einheit - die wiederum schon im Channel definiert ist.
Die große Ausnahme bildet die Linkquality, weil dort nicht klar ist, ob es dazu überhaupt eine Einheit gibt. % ist es schon mal nicht, da im Beispiel der Wert 144 beträgt. Deshalb also einfach so die Anzeige - ohne Einheit.
Ich möchte empfehlen, die Gerätenamen insbesondere im mqtt Topic Baum möglichst kurz zu halten - statt allround_sensor_waschkueche wäre z.B. sensor_wk vollkommen ausreichend. Ich bin mir nicht sicher, ob dies tatsächlich das korrekte Topic ist, zur Not musst Du das halt anpassen.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
