openHAB 3 + KNX Binding

[RB1306]

Hallo zusammen,

ich versuche seit mehreren Abenden eine Verbindung zu den Gruppenadressen herzustellen und einen einfach Schalter zu steuern. Leider ohne Erfolg.

Vielleicht hat jemand die Möglichkeit mir etwas Schützenhilfe zu leisten. Mit der Dokumentation komme ich leider auch nicht wirklich weiter.
Anbei 2 Screenshots der Einstellungen des Bindungs. Sobald die Verbindung als "Online" angezeigt wird müsste doch alles richtigt konfiguriert sein, oder?

Wie wären jetzt die logischen nächsten Schritte?

Vielen Dank für Eure Hilfe!
Gruß, Ronny

[udo1toni]

Sind die Screenshots wirklich Dein Ernst? Also, bei aller Liebe, wenn Du schon unnötigerweise Screenshots postest (es gibt die Code Anzeige, da hast Du die jeweilige Konfiguration vollständig als Text, wesentlich besser lesbar - vorausgesetzt, Du fügst den Text dann hier als Code markiert ein), solltest Du sie zumindest auf die nötige Größe zurechtschneiden, das geht mit dem Snipping Tool ganz einfach.

Du hast eine Router Verbindung definiert. Um welchen knx/IP Router handelt es sich denn? Und auf welcher Basis läuft openHAB bei Dir?

Was die ONLINE Meldung betrifft, so kann openHAB nicht feststellen, ob das Interface erreichbar ist, das liegt in der Natur der Multicast Anbindung.
Die lokale IP-Adresse erscheint mir auch zumindest fragwürdig, bei 192.168.178.1 fällt mir sofort FRITZ!Box ein.
Default nutzt die FRITZ!Box aber selbst die 192.168.178.1 als IP-Adresse, somit könnte die openHAB Maschine diese IP-Adresse nicht nutzen. Stattdessen wäre die 192.168.178.1 das Default Gateway.

[RB1306]

Danke für deine Anmerkungen. Hier der Code:

UID: knx:ip:3638923874
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
useNAT: false
readRetriesLimit: 3
autoReconnectPeriod: 30
localIp: 192.168.178.1
localSourceAddr: 0.0.0
readingPause: 50
type: ROUTER
portNumber: 3671
responseTimeout: 10

Ich nutze das KNX IP INTERFACE 730 von Weinzierl und habe das ganze auf bisher nur auf Windows installiert.
Und das Ganze hängt, wie richtig vermutet, an einer Fritz!Box

Und zum Ausprobieren habe ich einen "test"-Schalter eingebunden mit der GA 1/2/16

UID: knx:device:b06e5c589b
label: KNX Gerät
thingTypeUID: knx:device
configuration:
pingInterval: 10
readInterval: 0
fetch: true
bridgeUID: knx:ip:3638923874
channels:
- id: test
channelTypeUID: knx:switch
label: test
description: ""
configuration:
ga: 1/2/16

[udo1toni]

Grummel... Ich weiß, das wirkt jetzt sehr nörglerisch, aber ein Zitat ist etwas anderes als Code.

​UID: knx:ip:bridge
label: Weinzierl 730 IP
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.178.55
  localIp: 192.168.178.66
  autoReconnectPeriod: 60
  type: TUNNEL
  readingPause: 50
  localSourceAddr: 0.0.0
  portNumber: 3671
  responseTimeout: 10

So sieht das korrekt aus. Man beachte dabei auch die Leerzeichen zu Beginn bestimmter Zeilen. Diese sind nicht optional. Damit das auf Anhieb hier im Forum funktioniert, musst Du vor dem Einfügen auf Quellansicht umschalten - das ist das Symbol ganz links, ein "Blatt Papier" mit <> drauf. Nach dem Einfügen kannst Du wieder auf die Standardansicht umschalten und die Leerzeichen am Zeilenbeginn bleiben erhalten (das gilt aber nur für Code).

Ich habe auch ein Weinzierl 730, deshalb kann ich Dir versichern, dass Du dieses Interface nicht als Router betreiben kannst, es handelt sich um ein einfaches, aber sehr zuverlässiges reines Tunnel Interface.

Der Parameter ipAddress ist die IP-Adresse des Weinzierl 730
Der Parameter localIp ist die IP-Adresse des Interface, über das openHAB kommuniziert. Falls Dein Windows PC nicht mehrere aktive Schnittstellen hat, ist das also die IP-Adresse Deines Windows PC.

Betreffs des Testschalters: Eine Grundregel ist: openHAB tritt als Steuerung auf. Entsprechend spielt es die Rolle eines Schalters. Wir konfigurieren also normalerweise immer Aktoren, nicht Schalter. In bestimmten Sonderfällen kann man davon natürlich abweichen, aber Du solltest mit dem Regelfall beginnen.
Ein Aktor hat immer mindestens zwei KommunikationsObjekte, die für openHAB wichtig sind, das ist zum Einen das Befehls-KO, zum Anderen aber auch das Rückmelde-KO. Das Rückmelde-KO sendet exklusiv aus der zugeordneten GA, kein anderes Gerät darf auf dieser GA senden. Die GA, über die das Device gesteuert wird, wird von beliebig vielen Devices verwendet, um den Aktor zu steuern. Entsprechend sieht das Device eher so aus:

UID: knx:device:bridge:hagerBin_11
label: Schaltaktor 1
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  address: 1.1.11
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:bridge
location: KNX
channels:
  - id: ch1
    channelTypeUID: knx:switch
    label: Schaltkontakt 1
    description: null
    configuration:
      ga: 1/1/1+<1/1/4

1/1/1 ist hier die GA, welche mit dem Befehls-KO verknüpft ist, 1/1/4 ist die GA, welche mit dem Rückmelde-KO verknüpft ist. das < bedeutet, dass openHAB beim Start des Systems einen Read Request an die nachstehende GA sendet. Rückmelde-KO reagieren gewöhnlich auf ein Read Request und geben Auskunft über den aktuellen Zustand, so dass es ab Systemstart kein Rätselraten über den aktuellen Status notwendig ist.
Die Parameter pingInterval, readInterval und fetch sind nur wirksam, wenn eine korrekte address gesetzt ist (die physikalische Adresse des Device) Für die Funktion ist das unerheblich, allerdings sollte man readInterval nur ungleich 0 setzen, wenn dies nicht vermeidbar ist und fetch sollte am besten auch auf false bleiben. Im besten Fall bekommt man ein paar zusätzliche, aber unnötige Informationen über das Device, im schlechtesten Fall reagiert das Device nicht mehr und man muss es neu starten (die Busspannung unterbrechen). Wie gesagt, nur aktiv wenn auch eine physikalische Adresse angegeben ist.

[RB1306]

Perfekt!
Vielen Dank für die tolle ausführliche Hilfe!

[udo1toni]

Immer gerne und Guten Rutsch!

[jakatal]

Grummel... Ich weiß, das wirkt jetzt sehr nörglerisch, aber ein Zitat ist etwas anderes als Code.

​UID: knx:ip:bridge
label: Weinzierl 730 IP
thingTypeUID: knx:ip
configuration:
useNAT: false
readRetriesLimit: 3
ipAddress: 192.168.178.55
localIp: 192.168.178.66
autoReconnectPeriod: 60
type: TUNNEL
readingPause: 50
localSourceAddr: 0.0.0
portNumber: 3671
responseTimeout: 10

So sieht das korrekt aus. Man beachte dabei auch die Leerzeichen zu Beginn bestimmter Zeilen. Diese sind nicht optional. Damit das auf Anhieb hier im Forum funktioniert, musst Du vor dem Einfügen auf Quellansicht umschalten - das ist das Symbol ganz links, ein "Blatt Papier" mit <> drauf. Nach dem Einfügen kannst Du wieder auf die Standardansicht umschalten und die Leerzeichen am Zeilenbeginn bleiben erhalten (das gilt aber nur für Code).

Ich habe auch ein Weinzierl 730, deshalb kann ich Dir versichern, dass Du dieses Interface nicht als Router betreiben kannst, es handelt sich um ein einfaches, aber sehr zuverlässiges reines Tunnel Interface.

Der Parameter ipAddress ist die IP-Adresse des Weinzierl 730
Der Parameter localIp ist die IP-Adresse des Interface, über das openHAB kommuniziert. Falls Dein Windows PC nicht mehrere aktive Schnittstellen hat, ist das also die IP-Adresse Deines Windows PC.

Betreffs des Testschalters: Eine Grundregel ist: openHAB tritt als Steuerung auf. Entsprechend spielt es die Rolle eines Schalters. Wir konfigurieren also normalerweise immer Aktoren, nicht Schalter. In bestimmten Sonderfällen kann man davon natürlich abweichen, aber Du solltest mit dem Regelfall beginnen.
Ein Aktor hat immer mindestens zwei KommunikationsObjekte, die für openHAB wichtig sind, das ist zum Einen das Befehls-KO, zum Anderen aber auch das Rückmelde-KO. Das Rückmelde-KO sendet exklusiv aus der zugeordneten GA, kein anderes Gerät darf auf dieser GA senden. Die GA, über die das Device gesteuert wird, wird von beliebig vielen Devices verwendet, um den Aktor zu steuern. Entsprechend sieht das Device eher so aus:

UID: knx:device:bridge:hagerBin_11
label: Schaltaktor 1
thingTypeUID: knx:device
configuration:
pingInterval: 600
address: 1.1.11
readInterval: 0
fetch: false
bridgeUID: knx:ip:bridge
location: KNX
channels:
- id: ch1
channelTypeUID: knx:switch
label: Schaltkontakt 1
description: null
configuration:
ga: 1/1/1+<1/1/4

1/1/1 ist hier die GA, welche mit dem Befehls-KO verknüpft ist, 1/1/4 ist die GA, welche mit dem Rückmelde-KO verknüpft ist. das < bedeutet, dass openHAB beim Start des Systems einen Read Request an die nachstehende GA sendet. Rückmelde-KO reagieren gewöhnlich auf ein Read Request und geben Auskunft über den aktuellen Zustand, so dass es ab Systemstart kein Rätselraten über den aktuellen Status notwendig ist.
Die Parameter pingInterval, readInterval und fetch sind nur wirksam, wenn eine korrekte address gesetzt ist (die physikalische Adresse des Device) Für die Funktion ist das unerheblich, allerdings sollte man readInterval nur ungleich 0 setzen, wenn dies nicht vermeidbar ist und fetch sollte am besten auch auf false bleiben. Im besten Fall bekommt man ein paar zusätzliche, aber unnötige Informationen über das Device, im schlechtesten Fall reagiert das Device nicht mehr und man muss es neu starten (die Busspannung unterbrechen). Wie gesagt, nur aktiv wenn auch eine physikalische Adresse angegeben ist.

Hallo,

ich habe OpenHAB am Docker in der Version 3.4. Die Dokumentation die ich dazu online finde scheint für OpenHAB 2.x zu sein, zumindest ist die Notation wohl mittlerweile unterschiedlich.

In der WebOberfläche konnte ich das KNX-Binding per Router-Konfiguration soweit einbinden, dass es "Online" anzeigt. Ich gehe mal davon aus, dass eine Kommunikaiton nun damit gehen könnte.

Allerdings bei der Definition der Things. Mir ist einfach nicht klar wo ich diese Code notieren soll? Klicke ich bei Browser auf das KNX-Binding und dann auf "Code" erhalte ich das hier:

UID: knx:ip:4844fae78d
  label: KNX/IP Gateway
  thingTypeUID: knx:ip
  configuration:
  useNAT: true
  readRetriesLimit: 3
  ipAddress: 224.0.23.12
  localIp: 10.0.0.110
  autoReconnectPeriod: 60
  type: ROUTER
  localSourceAddr: 0.0.0
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10
​​

Wenn ich nur nun weiterhin die Things ergänze (wie oben etwa den hagerBin_11) dann bekomme ich nur Fehler angezeigt...

Vermutlich bin ich in einer falschen Maske...

Gibt es online ein How-To das für das OpenHAB3 funktioniert, wie gesagt, die ich gefunden hatte scheinen alle auf der 2.x zu basieren.

SG und Danke

[udo1toni]

openHAB hat beim knx ROUTER Mode keine Möglichkeit, zu erkennen, ob die Kommunikation tatsächlich funktioniert (im Gegensatz zum Tunnel). Entsprechend wird ein konfigurierter Router leider immer ONLINE angezeigt, ob er nun erreichbar ist oder nicht.
Im Zusammenhang mit Docker ist es essenziell, dass der Container im host-Mode läuft (also ohne eigene IP-Range), weil Multicast Datenpakete grundsätzlich nicht geroutet werden - im bridge Mode müsste das aber geschehen, weil der Container sich dann in einem eigenen Subnetz befindet.

Es gibt seit openHAB3 eine neue UI (Main UI), über die nun fast alles konfiguriert werden kann. Unter openHAB1 musste zwingend alles über Textdateien konfiguriert werden, das waren herrliche Zeiten, weil alles so schön einfach ging (ja, ehrlich!) Unter openHAB2 gab es Paper UI, über die man schon vieles konfigurieren konnte. Hatte aber einen entscheidenden Nachteil gegenüber der Textvariante, man konnte die Konfiguration nun nur noch mittels Screenshots (oder mit Abschreiben) teilen - gerade beim Debugging über Internet nicht gerade praktisch.
In openHAB3 mit Main UI wurde deshalb die Codeansicht eingeführt, welche per yaml die Konfiguration editierbar anbietet.
Deshalb sieht das nun anders aus als in veralteten Anleitungen

Wenn ich (oder jemand anderes) hier Code einstellt, ist das gewöhnlich nicht, um exakt dieses Codeschnipsel zu kopieren und stumpf einzufügen (jedenfalls ist das nicht meine Intention). Oftmals geht das auch gar nicht direkt, weil die Codeansicht nur dann zur Verfügung steht, wenn ein entsprechender Rahmen angelegt wurde, z.B. ein generic knx Thing.
Du musst also genau wie bei der knx Bridge das Thing ganz normal über die Main UI erzeugen. Innerhalb des knx Things musst Du auswählen, welche Bridge das Thing verwenden soll. Du könntest in openHAB nämlich durchaus mehrere knx Universen unabhängig voneinander parallel betreiben - incl. Datenaustausch über openHAB.
Im generic knx Thing kannst Du dann Channel hinzufügen. Allgemein sollte man pro Device (jedes Device hat eine eigene physikalische Adresse) ein Thing definieren. Im Thing kann man auch die physikalische Adresse eingeben, das ist aber kein Muss. Ist die korrekte physikalische Adresse angegeben, prüft openHAB alle pingInterval Sekunden, ob das Device antwortet. Ist das nicht der Fall, wird das Thing OFFLINE angezeigt. Das hat aber KEINE Auswirkungen auf die Funktion des Things. Sollte aus irgendeinem Grund keine Antwort auf das Ping erfolgen, können dennoch alle Channel des Device ganz normal arbeiten.

Es gibt eine ganze Videoreihe zu openHAB3, allerdings erscheint die leider nicht mehr auf der openhab-Seite. Ich bin mir auch nicht mehr ganz sicher, aber z.B. hier https://youtube.com/playlist?list=PL...rlAhVypml2T9Jl findest Du achtzehn Videos von BangerTECH zu openHAB3 (sogar Docker wird in mindestens einem der Videos thematisiert). Ein paar der Videos habe ich auch schon mal gesehen ist aber schon eine Weile her.

[jakatal]

Danke für den Hinweis, ich ziehe mir das rein. Das mit dem Host-Mode ist so ne Sache, OpenHAB ist ja nicht der einzige Container und ich hab noch einen der sich partout nicht ohne Host-Mode nutzten lässt. Zwei im Host-Mode geht ja nicht.

ch hab aber jedem Container eine eigene IP-Adresse zugewiesen (also das Linux-System hat insgesamt 10 IP-Adressen, die Port-Freigaben sind IMMER an eine IP-Adresse gebunden), so dass ich prinzipiell in der Lage bin alle Ports einem Container zur Verfügung zu stellen... Nebenbei hat es den Vorteil, das ich die WebUI-Ports (meist 8080 oder 8443) nicht immer umbiegen muss... vorausgesetzt ich weiß welche ich freigeben sollte. Gibt es dazu eine Übersicht, welche Ports freigeschaltet werden müssten?

Danke für den Hinweis mit dem Router. Das heißt ich sollte lieber als Tunnel konfiguieren? Und ja, ich hab tatsächlich mehrere KNX-Linien via LAN-Router....

[udo1toni]

Das mit dem Host-Mode ist so ne Sache, OpenHAB ist ja nicht der einzige Container und ich hab noch einen der sich partout nicht ohne Host-Mode nutzten lässt. Zwei im Host-Mode geht ja nicht.

Das wäre mir neu. Host Mode bedeutet lediglich, dass der Container den Netzwerkverkehr nicht über eine eigene Bridge bekommt, mehr nicht. Was immer sein kann, dass der gleiche Port verwendet wird, dann muss man das halt anders konfigurieren, damit unterschiedliche Ports verwendet werden. openHAB selbst benötigt z.B. Port 5007 für LSP, Port 8080 für http und Port 8443 für https. Alle drei Ports lassen sich aber frei konfigurieren, das muss man dann lediglich beim Aufruf berücksichtigen.

Ich hab aber jedem Container eine eigene IP-Adresse zugewiesen

So geht's natürlich auch. Aber auch da muss der Container im Host Mode laufen.

Danke für den Hinweis mit dem Router. Das heißt ich sollte lieber als Tunnel konfigurieren? Und ja, ich hab tatsächlich mehrere KNX-Linien via LAN-Router....

Nicht dass wir uns da falsch verstehen... Du hast mit sehr großer Sicherheit ein knx Universum (halt mit mehreren Linien). Dafür benötigst Du genau eine knx Bridge über genau ein knx/IP Interface. Mehrere knx Universen wäre z.B., wenn ich mein knx System mit Deinem knx System verbinden wollte, dabei aber keine Rücksicht auf physikalische Adressen oder gar Gruppenadressen nehmen will. Dann baue ich ein VPN zu Deinem Netzwerk und baue eine Verbindung zu Deinem knx/IP Router auf, diese Verbindung wird als zweite knx Bridge angelegt. Eine Verknüpfung der Channel kann dann über Links in openHAB erfolgen. Als Ergebnis kannst Du dann z.B. mit einem Wandtaster meine Rollläden bedienen, oder ich drücke Deinen Türsummer, oder was auch immer in knx verfügbar ist.

Die Verbindung zu knx mit dem Router Mode zu erschlagen ist vor allem dann sinnvoll, wenn die einzelnen Linien ohnehin über den IP Backbone miteinander verbunden sind (also die Linien über knx/IP Router miteinander verbunden sind) - wie gesagt, Multicast ist dafür verpflichtend. Ein einfaches Tunnel Interface sollte auch über eine Unicast Verbindung laufen, aber auch diese Verbindung wird gewöhnlich nicht geroutet, im Zweifel muss man da etwas Hirnschmalz investieren (ich habe bisher noch nicht rausgefunden, wie man Docker dazu bringen kann, Multicast in Container hinein zu routen).

[jakatal]

Danke für die Antworten! Ja, ich bastle da schon ne weile an den Dockern mit OpenHAB, geht KNX geht wieder was anderes nicht. Aber vermutlich ist das einfach so mit "hochintegrierten" Systemen welche eigentlich hardware Zugriff brauchen. Mal sehen, vermutlich ist es sinnvoller auf einen Rasperry auszuweichen oder ne andere Visualierusng in Betracht zu ziehen.

[jakatal]

Das wäre mir neu. Host Mode bedeutet lediglich, dass der Container den Netzwerkverkehr nicht über eine eigene Bridge bekommt, mehr nicht. Was immer sein kann, dass der gleiche Port verwendet wird, dann muss man das halt anders konfigurieren, damit unterschiedliche Ports verwendet werden. openHAB selbst benötigt z.B. Port 5007 für LSP, Port 8080 für http und Port 8443 für https. Alle drei Ports lassen sich aber frei konfigurieren, das muss man dann lediglich beim Aufruf berücksichtigen.

So geht's natürlich auch. Aber auch da muss der Container im Host Mode laufen.

Naja mit dem Host-Mode kann ich dann die Ports nicht mehr umbiegen und nachdem fast jeder irgendetwas mit Port 80 macht ist man sehr schnell bei dem Thema, nur einer im Host-Mode, aber ich geb Dir Recht, diese Darstellung ist technisch falsch.

Nicht dass wir uns da falsch verstehen... Du hast mit sehr großer Sicherheit ein knx Universum (halt mit mehreren Linien). Dafür benötigst Du genau eine knx Bridge über genau ein knx/IP Interface. Mehrere knx Universen wäre z.B., wenn ich mein knx System mit Deinem knx System verbinden wollte, dabei aber keine Rücksicht auf physikalische Adressen oder gar Gruppenadressen nehmen will. Dann baue ich ein VPN zu Deinem Netzwerk und baue eine Verbindung zu Deinem knx/IP Router auf, diese Verbindung wird als zweite knx Bridge angelegt. Eine Verknüpfung der Channel kann dann über Links in openHAB erfolgen. Als Ergebnis kannst Du dann z.B. mit einem Wandtaster meine Rollläden bedienen, oder ich drücke Deinen Türsummer, oder was auch immer in knx verfügbar ist.

Die Verbindung zu knx mit dem Router Mode zu erschlagen ist vor allem dann sinnvoll, wenn die einzelnen Linien ohnehin über den IP Backbone miteinander verbunden sind (also die Linien über knx/IP Router miteinander verbunden sind) - wie gesagt, Multicast ist dafür verpflichtend. Ein einfaches Tunnel Interface sollte auch über eine Unicast Verbindung laufen, aber auch diese Verbindung wird gewöhnlich nicht geroutet, im Zweifel muss man da etwas Hirnschmalz investieren (ich habe bisher noch nicht rausgefunden, wie man Docker dazu bringen kann, Multicast in Container hinein zu routen).

Bin nun auf knxd ausgewichen, dort kann ich ja mehrere IP-Schnittstellen auch zusammenfassen. Glücklicherweise überschneiden sich die GAs in den eizelne Linien nicht. Mein Universum umfasst zwei Gebäude, die mittlerweile per Glasfaser zusammenhänge. Jedoch wurden diese komplett getrennt voneinander mit KNX hochgezogen - und haben nun beide ein IP-Interface und ein gemeinsames Netzwerk ;-)

Als Oberfläche präferiere ich der Einfachheit halber CometVisu im Moment. Die Automatisierung von OpenHAB brauche ich im Moment nicht.

[udo1toni]

Wenn Du tatsächlich mehrere knx Universen betreibst, kannst Du einfach für jedes Universum eine eigene Bridge anlegen. Wenn Du hier allerdings den Router Mode verwenden willst, müssen die knx/IP-Router der unterschiedlichen Universen auch getrennte Multicast Adressen verwenden, sonst kannst Du sie ja nicht individuell ansprechen.
Wenn sich die GA (und die Linien!) nicht überschneiden, kannst Du natürlich auch alle Router gemeinsam als ein knx System betreiben.
Unter der Voraussetzung, dass alle Router sich gegenseitig per Multicast erreichen können - und openHAB ebenso (d.h. gewöhnlich, alle beteiligten Geräte müssen das gleiche Subnetz nutzen - oder die Multicast Adressen müssen extra in der Firewall eingetragen werden - Multicast wird default nicht geroutet) - kannst Du dann alles über eine Bridge abfrühstücken - ganz ohne knxd (welches Du aber natürlich auch verwenden kannst...)