openhabforum.de

Die Channel-Angaben, die du in deinen Beispielen benutzt, sind die Versionen aus MQTT1.

Probiers mal so:

Wie Peter-Pan schon erwähnt hat, bringst Du da was durcheinander.

Man kann durchaus ohne Paper UI auskommen, aber wenn man ein OH2-Addon verwenden will, muss man auch Things anlegen. Du brauchst also unterhalb des Verzeichnisses ./things/ eine Datei (z.B. mqtt.things), in der Du die mqtt Bridge und die zugehörigen Things definierst.
Im Falle von mqtt stehen die Beispiele für diese Art der Konfiguration nicht in der normalen Dokumentation, da David Graeff diesen Teil der Anleitung ausgegliedert hat, die Dokumentationsautomatik aber nur eine Quelldatei pro Binding verarbeiten kann. Du musst also nach github wechseln:
https://github.com/openhab/openhab2-add ... xamples.md erläutert die Definition von Bridge, Things und Channels. Für einige Spezialitäten, die Bridge betreffend, kannst Du außerdem noch https://github.com/openhab/openhab2-add ... xamples.md zurate ziehen.
Grundsätzlich sieht das dann so aus: Lohn der Arbeit ist dann, dass Du Things kopieren und vervielfältigen kannst, bei geschicktem Aufbau der einzelnen Konfigurationsabschnitte mit nur geringen Nacharbeiten.
Wenn Du VSCode als Editor verwendest (mit Plugin für openHAB) kannst Du aus angelegten Things und Channels bequem passende Items erzeugen lassen, die Du dann wiederum leicht bearbeiten kannst, um sie den eigenen Bedürfnissen anzupassen.

Es gibt noch eine zweite Form der Definition, wobei dann Bridge und zugeordnete Things unabhängig voneinander stehen, zum Preis, dass die Bridge dann bei jedem Thing mit angegeben werden muss. Das ist ein bisschen Geschmacksache

Hi,

danke für die Antworten.
Ich benutze im Moment Beides, PaperUi und .items Dateien. Daher habe ich auch im PaperUi alle items mit 2 Schaltern.
Im Moment bin ich am überlegen meine .items Datei soweit zu reduzieren, das ich alles was im paperUI konfiguriert und zu sehen ist aus dieser Datei nehme damit ich keine doppelten Einträge mehr habe.

Soweit ich jetzt verstanden habe ist der Weg mqtt Infos anzuzeigen über PaperUI, dort Things und Channel anlegen und dann die Thing Bezeichnung aus PaperUI (channel="mqtt:topic:0d3028e6:Temp") als item in Regeln benutzen die einfachste. Hier entnehme ich dem Mqtt String, mit entsprechenden Einträgen in "incoming value transformation", dann automatisch in den Wert um den ich anzeigen möchte.Ich brauche also in keiner .items Datei noch etwas wie dieses:
'Number Temp1_T_TH16 "TH16 Temperatur [%.1f°C]" <temperature> (sonoff) { channel="mqtt:topic:0d3028e6:Temp" }' anlegen.
da ich dann in den Regeln mit der Textbezeichnung von PaperUI Hier TH16 und dem entsprechenden in paperUI angelegten Channel arbeiten kann.
Ich arbeite somit also nur noch mit den von PaperUI generierten Definitionen "mqtt:topic:0d3028e6:Temp" und nicht mehr mit der "nativen" mqtt Ausgabe.

Um ohne PaperUI auszukommen muss ich eine .things Datei mit Bridge und den mqtt Things definieren. Diese Things müssen dann noch in einer .items Datei mit den entsprechenden mqtt Pfaden definiert werden, oder ? das was ich sonst im PaperUI mache wenn ich den Things Channel zuweise.
Oder ist der Channels: Eintrag in deinem Beispiel ausreichend um die Daten zu erhalten?
Um ohne PaperUI auszukommen wäre dies in meinem Falle:

Sonoff_TH16/tele/SENSOR mit Ausgabe: {"Time":"2019-10-13T12:39:31","DS18B20":{"Temperature":21.3},"TempUnit":"C"}
Wenn ich jetzt also "Sonoff_TH16" in die sitemap oder eine Regel einbaue erhalte ich dort diese Ausgabe:
{"Time":"2019-10-13T12:39:31","DS18B20":{"Temperature":21.3},"TempUnit":"C"}
Und muss später den Wert mit JSONPATH entnehmen.

Oder kann ich den JSONPATH Anhang hier mit einbringen? Und erhalte dann mit "Sonoff_TH16" in Sitemap oder Regel den entnommenen Zahlenwert 21.3?

Ich verwende VSCode als Editor mit Plugin. Und genau das Copy/Paste verfielfältigen der der things, items etc. macht das ganze so positiv.
Daher auch das Ganze rumgefrage damit ich das endlich mal verstehe.

Ich benutze im Moment Beides, PaperUi und .items Dateien. Daher habe ich auch im PaperUi alle items mit 2 Schaltern.
Im Moment bin ich am überlegen meine .items Datei soweit zu reduzieren, das ich alles was automatisch erkannt wird und im paperUI zu sehen ist aus dieser Datei nehme damit ich keine doppelten Einträge mehr habe.
Für alles was nicht automatisch erkannt wird erstelle ich dann .items Datein.

Oder ich nutze für alles paperUI und muss dort dann jedes Einzelne mqtt Gerät über die grafische Oberfläche erstellen und habe keine Möglichkeit ein Copy/Paste zu machen.

Danke für eure Geduld hier.

Gruß

AirMR hat geschrieben: ↑13. Okt 2019 14:12 Ich benutze im Moment Beides, PaperUi und .items Dateien.

Das ist mindestens missverständlich. Du nutzt .items Dateien, um Items zu konfigurieren - in diesen Dateien kannst Du auch ausschließlich Items definieren, nichts anderes.
Paper UI stellt viele Konfigurationsmöglichkeiten zur Verfügung, auch (aber eben nicht nur) Itemkonfiguration.
Willst Du andere Dinge konfigurieren, musst Du auch andere Dateien anlegen (Things, Sitemaps, Rules,...)

Daher habe ich auch im PaperUi alle items mit 2 Schaltern.

Definitiv nein, das hat so gar nichts mit items Dateien zu tun. Eventuell hast Du den Simple Mode eingeschaltet? Dann erzeugt openHAB automatisch für jeden Channel ein passendes Item, in der Folge hast Du dann zwei Items, wenn Du selbst noch ein Item anlegst. Schalte bitte den Simple Mode aus, dann erhältst Du im Konfigurationsmenü einen Punkt Items, wo Du alle Items konfigurieren kannst. Leider kannst Du die ID der schon angelegten Items nicht ändern, so dass Du als ersten Schritt alle Verlinkungen entfernen, und anschließend alle überzähligen Items löschen musst.

Im Moment bin ich am überlegen meine .items Datei soweit zu reduzieren, das ich alles was im paperUI konfiguriert und zu sehen ist aus dieser Datei nehme damit ich keine doppelten Einträge mehr habe.

Versuche nicht, die beiden Konfigurationen parallel zu betreiben. Entweder, Du legst alle Items über *.items Dateien an, oder gar keine. Falls Du Amazon Echo oder Google Assistant verwenden willst, musst Du Items taggen, das geht ausschließlich über *.items Dateien (ok, Du kannst es auch über die REST API...)

Soweit ich jetzt verstanden habe ist der Weg mqtt Infos anzuzeigen über PaperUI, dort Things und Channel anlegen und dann die Thing Bezeichnung aus PaperUI (channel="mqtt:topic:0d3028e6:Temp") als item in Regeln benutzen die einfachste.

Du musst pro Channel ein Item verlinken, ob Du das über Paper UI machst oder in einer oder mehreren *.items Dateien, bleibt Dir überlassen. Aber entscheide Dich für eine der beiden Optionen.

da ich dann in den Regeln mit der Textbezeichnung von PaperUI
5TopicSonoff3.PNG
Hier TH16 und dem entsprechenden in paperUI angelegten Channel arbeiten kann.

Nein, in Rules kannst Du nur auf Items zurückgreifen. Items sind Items, es spielt keine Rolle, wie sie definiert wurden, ob über Text oder über Paper UI oder über REST API oder über Karaf (geht alles).

Ich arbeite somit also nur noch mit den von Paper UI generierten Definitionen "mqtt:topic:0d3028e6:Temp" und nicht mehr mit der "nativen" mqtt Ausgabe.

Es gibt keine native mqtt Ausgabe. mqtt arbeitet mit Broker, Topic und Payload. Mit mqtt2 definierst Du eine Bridge, die die Verbindung zum Broker darstellt, einem oder mehreren Thing(s), und unterhalb mit Channels, in denen die einzelnen Topics angelegt werden. Damit openHAB mit dem Payload arbeiten kann, muss der Channel mit einem Item verlinkt sein...

Um ohne PaperUI auszukommen muss ich eine .things Datei mit Bridge und den mqtt Things definieren. Diese Things müssen dann noch in einer .items Datei mit den entsprechenden mqtt Pfaden definiert werden, oder?

Korrekt, ohne Paper UI legt man Bridge, Thing(s) und Channel in einer *.things Datei an. Anschließend verlinkt man diese Channel mit passenden Items. Wenn Du Visual Studio Code (bitte nicht mit Visual Studio verwechseln, das ist etwas komplett anderes!) nutzt, gibt es ein openHAB Plugin, welches vollautomatisch aus Things und deren Channeln Items erzeugen kann.Ebenso können vorhandene Items automatisch in Sitemaps oder Rules eingefügt werden. Das ist übrigens sehr viel komfortabler, als die Arbeit mit Paper UI.

Oder ist der Channels: Eintrag in deinem Beispiel ausreichend um die Daten zu erhalten?
Um ohne PaperUI auszukommen wäre dies in meinem Falle:

Sonoff_TH16/tele/SENSOR mit Ausgabe: {"Time":"2019-10-13T12:39:31","DS18B20":{"Temperature":21.3},"TempUnit":"C"}

Code: Alles auswählen

Bridge mqtt:broker:myUnsecureBroker [ host="meine IP", secure=false ]
{
    Thing topic mything {
    Channels:
	Type string : Sonoff_TH16     "TH16 Temp"       [ stateTopic="Sonoff_TH16/tele/SENSOR"]
    }
}

Wenn ich jetzt also "Sonoff_TH16" in die sitemap oder eine Regel einbaue erhalte ich dort diese Ausgabe:
{"Time":"2019-10-13T12:39:31","DS18B20":{"Temperature":21.3},"TempUnit":"C"}
Und muss später den Wert mit JSONPATH entnehmen.

Oder kann ich den JSONPATH Anhang hier mit einbringen?

Code: Alles auswählen

Bridge mqtt:broker:myUnsecureBroker [ host="meine IP", secure=false ]
{
    Thing topic mything {
    Channels:
	Type number : Sonoff_TH16     "TH16 Temp"       [ stateTopic="Sonoff_TH16/tele/SENSOR:JSONPATH:$.DS18B20.Temperature"]
    }
}

Und erhalte dann mit "Sonoff_TH16" in Sitemap oder Regel den entnommenen Zahlenwert 21.3?

Genau so, allerdings wird das JSONPATH als Transformation angegeben, das ist ein eigener Parameter (wie im übrigen in Paper UI auch) Sieht dann für den Channel so aus: