Grundaufbau Openhab

[Julian1712]

Hallo,

Gibt es irgendwo eine vernünftige Anleitung für Anfänge zum Grundaufbau in Openhab? Ich verstehe den Aufbau nicht ganz. Soll ich für jeden Aktor ein eigenes Thing anlegen?
Was sind Channels?

Bitte um tipps...

[udo1toni]

Die Reihenfolge ist eigentlich ganz einfach. Zuerst installierst Du openHAB, ganz nach Geschmack. Der Normalfall wäre, das openHABian Image auf einen Raspberry Pi 4 mit 4 GByte einzurichten, aber es gibt auch viele andere Möglichkeiten.

Wenn openHAB läuft und Du Dich erstmalig in der UI angemeldet hast, richtest Du die benötigten Addons ein, um mit Deiner Hardware kommunizieren zu können, also z.B. das knx Binding, um mit dem knx System Kontakt aufzunehmen.

Anschließend benötigst Du Zugriff auf das physische Interface von openHAB aus. Dazu richtest Du dann ein spezielles Thing ein, das ist die Bridge. In der Bridge werden die notwendigen Zugangsdaten hinterlegt, also z.B. beim Zugriff auf ein knx/IP Gateway die IP-Adresse des Gateway, die Betriebsart TUNNEL und die lokale IP-Adresse des openHAB Systems (letztere Angabe ist wichtig, damit openHAB weiß, über welche Schnittstelle es kommunizieren soll... der Rechner könnte ja mehrere Schnittstellen haben).

Nun benötigst Du ein Thing. Das Thing entspricht einem physischen Gerät, also z.B. ein knx REG im Schaltschrank. Man kann auch den gesamten Bus als ein Thing betrachten, verliert dabei aber verschiedene Funktionen. Also vertrete ich den Standpunkt, dass man für jedes am Bus angeschlossene Gerät ein eigenes Thing definiert.

Gerade bei knx Devices ist es gewöhnlich so, dass man mehr als einen Wert steuern kann oder auch abrufen kann, z.B. bei einem 6-Kanal Schaltaktor mal mindestens sechs Kanäle, die schaltbar sind. Vielleicht hat der Aktor auch noch Strommessung implementiert, das wäre dann pro Kanal noch eine weitere, vom Schaltzustand unabhängige Größe. Jede Messgröße bzw. jeder Zustand bzw. jeder Befehl entspricht einem Channel. Wobei ein Channel für den Befehl und die passende Rückmeldung ausreicht. Um beim 6-Kanal-Aktor ohne Strommessung zu bleiben, haben wir sechs Kanäle, ein einzelner Kanal wird genutzt, um dem passenden Kanal in der Hardware zu befehlen, das Relais einzuschalten oder auszuschalten. Der Zustand des Relais wird im selben Channel zurückgemeldet.

Bis dahin handelt es sich um die Modellierung der Hardware. Letztlich hast Du nun in der openHAB Oberfläche ein Abbild Deines Aktors.

Damit openHAB diese Hardware auch nutzen kann, braucht es innerhalb openHAB ebenfalls etwas, das sind Items. openHAB hat einen internen Bus, das ist der openHAB Bus (eigentlich müsste ich das eine B weg lassen...) Auf dem openHAB Bus werden die Zustände der einzelnen Schaltkanäle in Items repräsentiert. Weiterhin kann man Befehle an Items senden, die diesen Befehl dann an die Hardware weiterleiten.

Die Reihenfolge ist also -> Binding installieren -> Bridge einrichten -> Thing erstellen -> Channel einrichten -> Channel mit Item verlinken.

openHAB kann bei Hardware, die das unterstützt, automatisch Things und zugehörige Channel erzeugen (nicht bei knx!).

openHAB kann für existierende Channel automatisch Items erzeugen und diese verlinken (uneingeschränkt).

Wenn man diese Automatik nutzt, ist es aber enorm wichtig, die Namen der erzeugten Dinge (Things, Channel, Items) den eigenen Wünschen anzupassen. Die Namen spielen bei der Programmierung, also z.B. Steuerung der Rollläden usw. eine herausragende Rolle. Man möchte nicht mit Items hantieren, die irgendein_Name_Mit_Irgendwelchen_Zahlen heißen, man möchte lieber Rollladen1_Schlafzimmer schreiben (nur als Beispiel)
Leider kann man über die UI die Namen der Items, Channel und Things nicht nachträglich ändern, man muss diese Entscheidung also unmittelbar treffen oder die Arbeit wiederholen.

Ich habe mir angewöhnt, die Namen der Things und Channel streng an der Hardware auszurichten, also z.B. so:

Bridge knx:ip:bridge "Weinzierl 730 IP" [
    ipAddress="192.168.178.55",
    localIp="192.168.178.66",
    type="TUNNEL",
    portNumber=3671,
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=60,
    localSourceAddr="0.0.0"
 ]

 {
    Thing device hagerDim2_2_5 "DimmerGruppe 1" @ "KNX" [
        address="2.2.5",
        fetch=false,
        pingInterval=600,
        readInterval=0
     ] {
        Type dimmer                 : ch1 "Strahler Buffet"     [ switch="3/5/20",position="5.001:3/5/22+<3/5/27" ]
        Type dimmer                 : ch2 "Strahler Couch"      [ switch="3/5/0",position="5.001:3/5/2+<3/5/7" ]
        Type dimmer                 : ch3 "Strahler Essen"      [ switch="3/5/10",position="5.001:3/5/12+<3/5/17" ]
    }
}

Ich habe nur eine knx Bridge, weil ich nur ein knx Universum betreibe weshalb bridge als Identifier hinreichend ist (knx steht später auch noch dabei). Im Label steht hingegen genau, welches Gerät das denn ist.
Beim Thing handelt es sich um einen 3-Kanal Dimmer von Hager, ich habe davon mehrere und habe mir deshalb angewöhnt, im Namen des Thing die physikalische Adresse mit anzugeben. Das ist aber nicht notwendig, nur meine Methode, Ordnung zu halten. Entsprechend heißt das Thing also hagerDim2_2_5 und ich kann direkt erkennen, um welchen Typ Hardware es sich handelt.
Das Gerät hat drei Channel, welche funktional identisch sind. deshalb reicht mir die Unterscheidung, um welchen Channel es sich handelt, ch1, ch2 oder ch3.
Im Label steht hier aber schon, welche Lampen denn da gedimmt werden. Bei den GA kannst Du sehen, dass ich auch bei der Definition der GA darauf geachtet habe, für ähnliche Funktionen ähnliche GA zu verwenden. Hier richten sie sich nach der Nummer des KO am Device, KO 0 ist der Schaltkanal,KO 2 ist der absolute Dimmbefehl, KO 7 ist die Rückmeldung als Absolutwert. Die ersten beiden Abschnitte definieren den Raum und die Funktion, 3 ist also das Wohnzimmer, 5 ist Beleuchtung.
Die drei GA sind hinreichend, um den Dimmer vollständig von openHAB aus zu kontrollieren.

Die zugehörigen Items:

Dimmer GFLivingLight_Ch1 "Strahler Buffet" (GLights,GLights_GF_Living,GDimmer) {channel="knx:device:bridge:hagerDim2_2_5:ch1",autoupdate="false"}
Dimmer GFLivingLight_Ch2 "Strahler Couch" (GLights,GLights_GF_Living,GDimmer) {channel="knx:device:bridge:hagerDim2_2_5:ch2",autoupdate="false"}
Dimmer GFLivingLight_Ch3 "Strahler Essen" (GLights,GLights_GF_Living,GDimmer) {channel="knx:device:bridge:hagerDim2_2_5:ch3",autoupdate="false"}

Man kann hinten im Link direkt erkennen, dass alle drei Items zum gleichen Aktor gehören und auf welchem Channel die Lampen angeschlossen sind. Wenn man die Items automatisiert erzeugen lässt, werden die Label automatisch aus dem Channel Label abgeleitet. Ähnliches funktioniert auch für die Namen der Items, aber nicht bei mir, da ich Hardware und openHAB Bus getrennt und unterschiedlich betrachte.

Die Schreibweise in den beiden Codeschnipseln stammt im Übrigen aus der Textdefinition, in der UI sieht das komplett anders aus. Die Definition über Textdateien hat den großen Vorteil, dass man alle Aspekte jederzeit ändern kann, auch wenn das eventuell erst nach einem Neustart von openHAB volle Wirkung entfaltet Und ja, mit dem passenden Editor (VSCode) kann man sich auch im Text Items automatisch generieren lassen - sogar wesentlich bequemer als über die UI (wobei das natürlich Ansichtssache ist...)

[Julian1712]

WOW!!!
Vielen vielen Dank! - Das ist eine tolle Erklärung.

Mein 1. Thing schaut nun so aus, Frage: Was mache ich nun mit der Gruppen Status Adresse?

Lg

UID: knx:device:9cdb0739e7:MDT_12fach_Schaltaktor_1
label: 12-Fach Schaltaktor 1
thingTypeUID: knx:device
configuration:
pingInterval: 600
address: 1.1.1
readInterval: 0
fetch: false
bridgeUID: knx:ip:9cdb0739e7
location: Technikraum
channels:
- id: ch1
channelTypeUID: knx:switch
label: Küche Spots
description: ""
configuration:
ga: 0/0/1

[udo1toni]

Die Status GA wird einfach als zweite GA im passenden Parameter eingetragen, z.B. oben im Beispiel des Dimmers.
Die GA 3/5/22 ist der Befehl, die GA 3/5/27 ist der passende Status. das < definiert die nachfolgende GA als lesbar, openHAB wird beim Systemstart versuchen, von dieser GA den aktuellen Status zu erfragen.
openHAB versucht <readRetrysLimit> mal ,den Status zu erfragen, danach gibt openHAB auf.
Die Angabe des DPT ist optional und erfolgt zu Beginn, also vor der ersten GA im Parameter.
Mehrere GA werden mit + verkettet. Die erste GA ist die sendende GA, alle weiteren GA werden nur ankommend verwendet (so wie bei knx üblich).

[wuestenfuchs]

Tolle Zusammenfassung!

Einfach zum Verständnis: will man einen Statuswert vom KNX-Bus abfragen, also z.B. die Temperatur eines KNX-Temperatursensors in OpenHAB darstellen, dann verwendet man die "<"-Notation in der Gruppenadresse, richtig? Also so:

Type number : kg_kellertreppe_temp                 "KG Kellertreppe Temperatur"        [ ga="9.001:<1/4/0" ]

[udo1toni]

Genau. Das < bedeutet, dass das knx Addon die GA beim Start einmalig abfragt.

knx Sensoren senden im Allgemeinen entweder zyklisch oder bei Wertänderung (oder sogar beides), es geht hierbei also nur darum, die Daten direkt von Beginn an aktuell zu haben.
Das KO (KommunikationsObjekt) im Device muss lesbar gekennzeichnet sein (L-Flag gesetzt). Das KO muss herstellerseitig lesbar sein. Es darf nur maximal ein KO pro GA lesbar sein, niemals (!!!) mehr als ein KO.

[wuestenfuchs]

Es darf nur maximal ein KO pro GA lesbar sein, niemals (!!!) mehr als ein KO.

Ok, das entspricht ja auch der allgemeinen Regel in KNX. Verstanden.

Wie ist es mit Dingen, die in OpenHAB ihren Status haben, und dieser Status soll dann auf KNX gesendet werden. Das sind doch die in der Doku erwähnten control-*-Channels, oder?
Also Beispiel: Man frägt die Heizung oder den Photovoltaik-Wechselrichter in OpenHAB mittels HTTP, MQTT, Modbus oder sonstwas ab. Dieser Wert soll dann auch von OpenHAB an KNX gesendet werden, um z.B. die aktuelle Temperatur auf einem Taster oder in einer Visu angezeigt zu bekommen. Dann würde man dafür einen control-Channel anlegen, richtig?

Wobei man in diesem Fall vermutlich eine Art Brücke bauen müsste, um die Werte von HTTP nach KNX zu schieben. Stelle mir das so vor:

knx.thing (KNX-Binding):

Type number-control : HEATING_Temp_ambient_KNX "Außentemperatur" [ ga="6/1/0" ]

heizung.thing (HTTP-/MQTT/Sonstwas-Binding):

Type number : HEATING_Temp_ambient "Außentemperatur" [ mode = "READONLY", stateTransformation = "JSONPATH:$.path.to.my.value" ]

Dann auch zwei Items:

Number HEATING_Temp_ambient "Außentemperatur [%.1f °C]" { channel="http:url:heizung:HEATING_Temp_ambient" }
Number HEATING_Temp_ambient_KNX "Außentemperatur [%.1f °C]" { channel="knx:device:bridge:generic:HEATING_Temp_ambient_KNX" }

Und eine Rule, die das Ganze von HTTP nach KNX schickt:

rule "HEATING_Temp_ambient"
when
    Item HEATING_Temp_ambient changed
then
    if(HEATING_Temp_ambient.state instanceof Number) {
        var Number HEATING_Temp_ambient_value = (HEATING_Temp_ambient.state as Number).intValue
        HEATING_Temp_ambient_KNX.sendCommand(HEATING_Temp_ ambient_value)
}
end

So in etwa richtig gedacht?

[FloBi]

Hi,

wie macht Ihr dass denn grundsätzlich mit den IST-Temperaturen?
Bei mir wird die IST-Temp. durch Gira TS3 erfasst.
Würdet ihr jetzt für jeden TS3 ein Device anlagen, oder ein "Dummy-Device", welches alles IST-Werte zusammenfasst?

[udo1toni]

Ja und nein.
Wenn Du einen *-control Channel definierst, übernimmt openHAB gegenüber dem knx System für die angegebenen GA die Rolle des Aktors.
ACHTUNG! Die knx-Notation gilt weiterhin, das heißt, die erste angegebene GA ist die Status-GA, weil openHAB diese GA verwendet, um in Richtung knx zu senden.

Weiterhin ist das Verhalten von openHAB bezüglich der *-control Channel exakt gegenteilig zu den normalen Channels.

Ein empfangenes Datentelegramm in einem *-control Channel wird als received command gewertet.
Ein empfangenes Datentelegramm in einem normalen Channel wird als received update gewertet. Sollte es dabei zu einer Änderung des aktuellen Status kommen, wird außerdem zusätzlich noch ein changed Ereignis ausgelöst.

Wird der Status eines Items aktualisiert, welches an einen normalen Channel gekoppelt ist, so passiert weiter nichts (außer die erwähnten Ereignisse received update + evtl. changed).
Wird der Status eines Items aktualisiert, welches an einen *-control Channel gekoppelt ist, so wird der Status sofort an knx übermittelt.

	normal	*-control
Empfang aus knx	received update	received command
dito, mit Wertänderung	changed	received command
sendCommand()	Übertragen an knx	es passiert nichts
postUpdate()	Status Update des Items	Übertragen an knx

Da der empfangene Wert in http/mqtt/sonstwas in openHAB als received update und/oder changed auftritt, reicht es also, ein Item zu nutzen, welches mit beiden Channels verlinkt ist:

Number HEATING_Temp_ambient "Außentemperatur [%.1f °C]" { channel="http:url:heizung:HEATING_Temp_ambient", channel="knx:device:bridge:generic:HEATING_Temp_am bient_KNX" }

Solange man den Wert nicht manipulieren muss (z.B. weil der Wert noch die Einheit mit liefert; knx kann mit UoM nichts anfangen), sollte diese Definition ausreichen. Bei jedem Update wird der Wert unmittelbar von http nach knx gesendet.

[udo1toni]

Hi,

wie macht Ihr dass denn grundsätzlich mit den IST-Temperaturen?
Bei mir wird die IST-Temp. durch Gira TS3 erfasst.
Würdet ihr jetzt für jeden TS3 ein Device anlagen, oder ein "Dummy-Device", welches alles IST-Werte zusammenfasst?

Ich habe bei mir sogar Things für Devices angelegt, die überhaupt keine Channel besitzen... also definitiv ja. Jedes Device, welches einen Status hält, sollte meiner Meinung nach auch als Thing in openHAB angelegt werden, damit ist in openHAB die Hardware bestmöglich abgebildet.
Aber bitte keinesfalls andere Channel anlegen, die gar nicht zum Taster gehören, wie z.B. die Befehle zum Schalten eines Aktors, das ist Bestandteil des Aktors.

[FloBi]

Vielen Dank für die Rückmeldung.

Ich werde mich mal an dem Anlegen der knx.things im Editor versuchen.

[Julian1712]

Hallo,

Ich habe jetzt folgendes gesetzt, aber bekomme scheinbar keine Statusrückmeldung. Meine openHab App zeigt als Status beim Schalter immer den letztstand an, was ich in der Openhab App betätigt habe

Wenn ich z.B über einen Taster das Licht ausschalte müsste das doch sichtbar sein?

channels:
- id: ch1
channelTypeUID: knx:switch
label: Küche Spots
description: ""
configuration:
ga: 0/0/1+<0/2/0

[udo1toni]

Unter der Voraussetzung, dass die GA stimmen, ja, dann sollte der Status immer dem des Aktors folgen. Ist 0/2/0 die Status GA des Aktorkanals? Ist diese GA im Aktor sendend hinterlegt? Ist der Aktor das einzige Device, welches auf dieser GA sendet? Ist das L-Flag im zugehörigen KO gesetzt?

Wie ist die knx Bridge definiert?

Ein weiterer wichtiger Punkt, der leider in der openHAB Doku etwas untergeht:

Standardverhalten von openHAB ist, dass ein für ein Item empfangener Befehl zum einen an alle verlinkten Channel gesendet wird und zum anderen der wahrschenliche neue Status des Items berechnet und unmittelbar gesetzt wird. Damit erreicht openHAB eine bessere Reaktionsfreudigkeit um den Preis, dass für eine ungewisse Zeit potenziell ein falscher Stataus angezeigt wird.
Im Fall von Channels, die immer den korrekten Status melden, kann man dieses gezielt abschalten. Das geht über die Metadaten, der Parameter heißt autoUpdate und muss auf false gesetzt werden. Über die UI wäre das Add Metadata -> Auto-update -> Force auto-update OFF (also Haken aus dem Feld entfernen)

[nsm2knx]

Hallo Zusammen,

ich habe mich jetzt ein paar Tage lang mit OpenHAB beschäftigt und auch die o.g. Anleitung ein paar mal gelesen aber ich verzeifle daran. Ich bin zwar Fachinformatiker aber nur Linux Admin und kein Anwendungsentwickler. In der Zwischenzeit habe ich es geschaft das OpenHAB an mein KNX-Netz anzubinden und auch ein paar Aktoren. Aber in der Übersicht sind die Aktoren angeblich offline. Licht kann ich nicht schalten, das Rollo aber rauf und runter fahren allerdings reagiert OpenHAB mit etwas Verzögerung.

OpenHAB.png

Ich habe mir den Einstieg in OpenHAB einfacher vorgestellt und bin echt am Ende.

Daher möchte ich auf diese Weise jemanden suchen der sich sehr gut mit OpenHAB auskennt und mir ggf. über eine Teams Session mein System soweit auf vordermann bringt das ich den Rest alleine machen kann.

Wer sich etwas Taschengeld verdienen möchte möge sich gerne per PM bei mir melden.

Schöne Grüße

Paulo

[DiMa]

Dein GW heisst KNXGW1, deine Aktoren sind an KNXGW gebunden... Das kann nicht funktionieren.