Generic MQTT Thing umbenennen

[kaloschke]

Hallo,
wenn ich über eine Things-Datei ein MQTT-Thing anlege, z.B. so:

Code: Alles auswählen

    Thing topic temp_inside {
        Channels:
            Type number : temp_kitchen "MQTT Temp Inside"  [stateTopic = "zigbee2mqtt/temp_inside/temperature"]
    }

dann wird mit dieses in der Verwaltungsoberfläche immer groß als "Generic MQTT Thing" angezeigt. Da das Thing über eine Datei erzeugt wurde, ist es in der Oberfläche gesperrt und das Label kann nicht geändert werden.

Das muss doch irgendwie gehen oder?

Gruß Kaloschke

[warhook76]

Wie wär's mit:

Code: Alles auswählen

 
Thing topic internal_temperature "Temperatur intern" @ "Temperaturen "

Das ist mit Name und Gruppe.

Gruß

Gesendet von meinem A063 mit Tapatalk

[kaloschke]

Ach da oben muss die Bezeichnung hin.
Super. Vielen Dank!

[warhook76]

Ach da oben muss die Bezeichnung hin.
Super. Vielen Dank!

Gerne geschehen

Gesendet von meinem A063 mit Tapatalk

[udo1toni]

Noch ein Tipp: Das Thing-Modell soll die reale Hardware abbilden. Bei Bussystemen wie z.B. mqtt (der Broker ist das Gateway zum virtuellen "Bus") kann der User allerdings relativ frei entscheiden, wie er die Channel zusammenfasst, also z.B. alle Temperaturen innerhalb eines Thing abbilden.
Das ist möglich, aber die Struktur hält sich damit nicht an die openHAB Konventionen. Daraus folgen dann unnötig komplizierte UIDs. Beispiel oben:

Code: Alles auswählen

Thing topic temp_inside {
        Channels:
            Type number : temp_kitchen "MQTT Temp Inside"  [stateTopic = "zigbee2mqtt/temp_inside/temperature"]
    }

ergibt (bei einem broker mit der UID broker) ein Item

Code: Alles auswählen

Number Kueche_Temperatur "Temperatur Küche [%.1f °C]" {channel="mqtt:topic:broker:temp_inside:temp_kitchen"}

Besser so:

Code: Alles auswählen

Bridge mqtt:broker:broker "Mosquitto" [
    // hier Broker Konfiguration
 ] {
    Thing topic kitchen "Sensorgruppe Küche" {
    Channels:
        Type number : temp "Temperatur"  [stateTopic = "zigbee2mqtt/temp_inside/temperature", unit="°C"]
        Type number : hum  "Luftfeuchte" [stateTopic = "zigbee2mqtt/temp_inside/humidity",    unit="%"]
    }
}

ergibt als Item:

Code: Alles auswählen

Number:Temperature   Kueche_Temperatur "Temperatur Küche"  {channel="mqtt:topic:broker:kitchen:temp", unit="°C", stateDescription=""[pattern="%.1f °C"]}
Number:Dimensionless Kueche_Feuchte    "Luftfeuchte Küche" {channel="mqtt:topic:broker:kitchen:hum",  unit="%",  stateDescription=""[pattern="%.1f %%"]}

Falls man nicht gerade eine Außenküche hat, sollte klar sein, dass es sich um eine Innentemperatur handelt und weitere Messwerte, die von der selben Sensorgruppe geliefert werden können direkt mit abgebildet werden. Aus der UID ist klar erkennbar, dass sich die Sensorgruppe in der Küche befindet (und andere Nicht-mqtt-Things können ebenfalls die ID kitchen verwenden, da es sich um einen anderen Zweig im UID-Baum handelt)
Insgesamt ist die UID klarer strukturiert und man benötigt weniger Doppelungen in der UID.
Die Abbildung als UoM Item ist bisher optional, in zukünftigen Versionen von openHAB wird sich das aber vermutlich ändern, es ist also eine gute Idee, Items bereits jetzt umzustellen. Wenn man noch die passenden Tags und Gruppenzugehörigkeit setzt, landen die Werte auch noch automatisch im Semantic Model

[kaloschke]

Danke, aber so mache ich es auch. Die Bridge-Konfiguration hatte ich weggelassen, weil es für mein Problem nicht wichtig war.
Wenn sie fehlen würde, müsste ich sie doch auch in der Konfiguration des Things (Thing:mqtt:topic:...) angeben oder?

[udo1toni]

Ich habe die Bridge nur der Vollständigkeit halber hinzugefügt, ja, wenn Du das Thing vollständig unabhängig von der Bridge anlegen willst, musst Du eine andere Schreibweise verwenden (und außerdem bei jedem Thing zusätzlich noch die Bridge mit angeben, obwohl sie bereits über die UID identifiziert werden kann.
Mein eigentlicher Punkt war der Name des Things kitchen <-> temp_inside und des Channels temp <-> temp_kitchen, was dann halt kumuliert, kitchen:temp <-> temp_inside:temp_kitchen. Und Letzteres enthält unnötige sowie redundante Informationen, was man grundsätzlich vermeiden sollte. In der Kürze liegt die Würze.

[peter-pan]

..meine zwei Pfennige
Ich habe aus meiner Erfahrung das Ganze aufgespaltet und (auch wenn es nach mehr Arbeit aussieht; aber eigentlich, dank Copy/Paste - nicht ist) die Bridge und den "Rest" gsplittetet.
Es gibt eine Bridge:

Code: Alles auswählen

//https://openhabforum.de/viewtopic.php?f=15&t=970&start=20   // from Udo
//Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" @ "MQTT2" 
//       ^    ^      ^                    ^                      ^ Zeige diese Bridge auf der Unterseite "MQTT2" in Paper UI Control
//       ^    ^      ^                    ^ Label der Bridge
//       ^    ^      ^ Name der Bridge
//       ^    ^ Art der Bridge
//       ^ Binding
Bridge mqtt:broker:claudi "Mosquitto" [ host="localhost", port=1883, secure=false, clientID="OH3_claudi" ]  

und dann gibt es Things nach Gerätetypen, z.B. Gosund-Stecker, oder Sonoff-Stecker oder auch nach diversen Prozessoren, wie ESP-Ptozesoren oder ganz banal nach allen möglichen anderen "Geräten"

Code: Alles auswählen

   Thing mqtt:topic:claudi:liftoff   "Engines startet"      (mqtt:broker:claudi )     @ "MQTT2" {
    Channels:
        Type string : start           "Count Down Ticker"     [ stateTopic="count/down/countDown/status"]

Dabei handelt es sich um ein Script, das irgend etwas an den Broker schickt. Alles ist möglich.
Es geht natürlich auch noch etwas ausführlicher. Hier noch ein Beispiel aus einem andern .things-File:

Code: Alles auswählen

    Thing mqtt:topic:claudi:esp3201 "ESP32 01"  (mqtt:broker:claudi )     @ "MQTT2" {
    Channels:
        Type switch : relay1     "Relay 1"               [ stateTopic="stat/esp32_01/POWER1", commandTopic="cmnd/esp32_01/POWER1" ]
        Type switch : relay2     "Relay 2"               [ stateTopic="stat/esp32_01/POWER2", commandTopic="cmnd/esp32_01/POWER2" ]
        Type switch : relay3     "Relay 3"               [ stateTopic="stat/esp32_01/POWER3", commandTopic="cmnd/esp32_01/POWER3" ]
        Type switch : relay4     "Relay 4"               [ stateTopic="stat/esp32_01/POWER4", commandTopic="cmnd/esp32_01/POWER4" ]
        Type switch : relay5     "Relay 5"               [ stateTopic="stat/esp32_01/POWER5", commandTopic="cmnd/esp32_01/POWER5" ]
        Type number : rssi      "WiFi Signal Strength"   [ stateTopic="tele/esp32_01/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI"]
        Type string : version   "Firmware Version    "   [ stateTopic="stat/esp32_01/STATUS2", transformationPattern="JSONPATH:$.StatusFWR.Version"]
        Type string:  reachable "Reachable"              [ stateTopic="tele/esp32_01/LWT" ]
        Type string : hardware  "Chip Set            "   [ stateTopic="stat/esp32_01/STATUS2", transformationPattern="JSONPATH:$.StatusFWR.Hardware"]
        Type string : ipaddress "IP Address          "   [ stateTopic="stat/esp32_01/STATUS5", transformationPattern="JSONPATH:$.StatusNET.IPAddress"]
        Type string : ssid      "WiFi"                   [ stateTopic="tele/esp32_01/STATE", transformationPattern="JSONPATH:$.Wifi.SSId"]
        Type number : temp      "Temp. DHT11 ESP32 01"   [ stateTopic="tele/esp32_01/SENSOR",  transformationPattern="JSONPATH:$.DHT11.Temperature"]
        Type number : hum       "Hum.  DHT11 ESP32 01"   [ stateTopic="tele/esp32_01/SENSOR",  transformationPattern="JSONPATH:$.DHT11.Humidity"]
        Type number : dew       "Tau.  DHT11 ESP32 01"   [ stateTopic="tele/esp32_01/SENSOR",  transformationPattern="JSONPATH:$.DHT11.DewPoint"]
        Type string : grouptop  "Group Topic         "   [ stateTopic="stat/esp32_01/STATUS1", transformationPattern="JSONPATH:$.StatusPRM.GroupTopic"]
        Type number : smoke1    "Gas Sensor  ESP32 01"   [ stateTopic="tele/esp32_01/SENSOR",  transformationPattern="JSONPATH:$.ANALOG.A1"]
    }

Das hilft auch bei der Problem-Suche (meine ich). Ich bin halt noch ein absoluter Fan von der textbasierenden Darstellung von solchen "Sachen". Manchmal ist halt weniger (oder besser gesagt übersichtlicher) doch mehr. (nur meine Meinung)

[udo1toni]

Ach, wenn man mit VSCode unterwegs ist, kann man einfach alle gerade nicht benötigten Things zuklappen, das erhöht die Übersichtlichkeit ungemein, ohne dass man bei jedem Thing dazu schreiben muss, dass es sich um mqtt handelt.

Übrigens ist es auch kein Problem, beide Verfahren miteinander zu kombinieren, sprich, man legt einen Großteil der Things als "Kinder" der Bridge an, aber ein paar standalone mit der Verknüpfung zur Bridge.

[kaloschke]

Da habe ich aber RICHTIG viele Infos bekommen
Vielen Dank