Upgrade auf OH3

[andiger]

Hallo Leute,

Umstellung von OH 2.4.0 auf 3.3.0: so weit sind die sachen am laufen.

zB folgende zeile gibts in einem items file:

Code: Alles auswählen

Number garageInnenTemp "Luft [%.1f °C]" <temperature> {onewire="deviceId=28.C2245C060000;propertyName=temperature;refreshinterval=10"}

Hier als beispiel für OneWire binding. Dieses item hat so in der Form mit OH2 wunderbar funktioniert.

Nun wird das Item zwar von OH3 erkannt und in der UI angezeigt, aber die daten kommen dort nicht an. Erst wenn ich mühsam ein Channel anlege und mit dem item verknüpfe funktioniert es, wie es soll.
Das gleiche gilt für alle anderen items, die onewire binding nutzen bzw. auch andere bindings wie knx etc...

Wenn ich mir vorstelle, dass ich jetzt für jedes Item noch ein Channel erzeugen muss, dann werde ich weich...

Ich hoffe, das Problem ist klar. Gibt es eine Möglichkeit auf channels zu verzichten, bzw. sie irgend wie automatisch zu erzeugen.
Laut OH doku kann man bei items sowohl channels als auch direkt bindings angeben.

Code: Alles auswählen

Switch Kitchen_Light "Kitchen Light" {channel="mqtt:topic:..." }
String Bedroom_Sonos_CurrentTitle "Title [%s]" (gBedRoom) {channel="sonos:..."}
Number Bathroom_WashingMachine_Power "Power [%.0f W]" <energy> (gPower) {channel="homematic:..."}

Number Livingroom_Temperature "Temperature [%.1f °C]" <temperature> (gTemperature, gLivingroom) ["TargetTemperature"] {knx="1/0/15+0/0/15"}

Danke für Eure Hilfe im Voraus
André

[udo1toni]

Nein, in openHAB3 gibt es ausschließlich Bindings, welche über Things definiert werden. Achte darauf, dass die Doku auch auf die Version 3.3 bezogen ist.

Du kannst die Things aber ebenso über Textdateien erzeugen wie bei den Items, was die Definition dann ein Stück einfacher macht.

[andiger]

Moin,
vielen Dank für die schnelle Antwort.
Die Konfiguration für das binding (in dem fall für einen owserver) einmalig als Thing bzw Bridge ist ja an sich gar kein Problem.
Was mich stört, ist dass die einzelnen Items nun mühsam eigene extra Channels/Things brauchen.
Also noch mal als Beispiel.
Vorher mit OH2 war es einfach ein Item mit dem onewire sensor zB so zu konfigurieren (eine Zeile!):

Code: Alles auswählen

Number kgBueroTemp "Luft [%.1f °C]" <temperature_ref> {onewire="deviceId=28.CC630A060000;propertyName=temperature;refreshinterval=10"}

Jetzt mit OH3 muss ich das Item so konfigurieren

Code: Alles auswählen

Number kgBueroTemp "Luft [%.1f °C]" <temperature_ref> {channel="onewire:basic:onewire:kgBueroTemp:temperature"}

und der dazugejörige Channel (Thing) innerhalb der onewire Bridge:

Code: Alles auswählen

 Thing basic kgBueroTemp "kgBueroTemp" [id="28.CC630A060000", refresh=10] {}

Das ist eine lockere Verdoppelung der Config, da würde ich dann einpaar Tage dran sitzen, bis ich alle meine Items umgestellt habe.
Ist es denn notwendig? Geht es nicht irgend wie eleganter sprich kürzer, am besten mit einer Zeile ?
mit onewire sensoren ist es ja noch überschauber, wenn ich aber an die ganzen KNX geschichten denke mit all den adressen, horror...

[udo1toni]

Nein, das ist keine Verdoppelung, sondern eine Verschiebung.
Tatsächlich hast Du bei den alten Bindings die Konfiguration in zwei Bereichen gehabt (die meisten Bindings hatten eine eigene Konfiguration unterhalb /etc/openhab2/services/ bzw. unter openHAB1 in der openhab.cfg, wo alles in einer großen Datei zusammengefasst war.
Jetzt ist es so, dass dieser Teil der Konfiguration als Thing angelegt wird.
Der Teil, welcher ein spezifisches Detail des Geräts mit einem Item verbindet, lag hingegen in der *.items-Datei. der steht jetzt halt im Channel als Teil des Things. Somit ist alles, was bindingspezifisch ist an einem Ort.

Korrekt ist, dass Du dadurch das Item mit dem Channel verlinken musst, insofern ist tatsächlich ein bisschen mehr Text fällig.

Dafür ist aber die logische Trennung nun wesentlich besser und Du kannst auch durch weniger Aufwand profitieren. Beispiel:
Wenn Du Gerät hast, welches ein JSON Objekt liefert, von dem Du mehrere Werte auslesen möchtest, musstest Du bisher mehrere Kommunikationskanäle öffnen, um das immer wieder gleiche JSON Objekt zu laden. Im http1 Binding wurde deshalb der http Cache geschaffen, um die Kommunikation etwas zu reduzieren. Im neuen Modell lädst Du das JSON Objekt in einen String Channel und extrahierst das betreffende Datum über ein JSONPath Profile, die Items werden alle identisch konfiguriert, bis auf das JSONPath Statement.

Ganz grundsätzlich werden nun alle Items zu 100% gleichartig konfiguriert, Unterschiede bei der Konfiguration durch die verschiedenen Bindings liegen nun alle in den Things. Autodiscovery wird erst durch diese Trennung möglich.