KNX IP Gateway mit Weinzierl funktioniert nicht

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
Norick
Beiträge: 234
Registriert: 31. Jan 2022 06:35

KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von Norick »

Hallo
ich habe für meine KNX Anlage ein Weinzierl 732 welches ich mit OH 3.3.0.M3 eingebunden und online ist. Dieser Teil funktioniert schon mal. Was ich aber noch nicht ganz kapiert habe wie ich nun zum Beispiel einen einfachen Lichtschalter anlegen kann.

Hier ist die Frage: Wie mache ich nun den Link des Schalters (Adresse x.y.z) zum IP-Gateway? Ich kann zwar ein Equipment anlegen mit einem Switch aber irgendwie weiss ich nicht wie resp. wo ich die Switchadresse anlegen muss damit ich den Schalter dann verwenden kann.

Danke
von udo1toni » 11. Mai 2022 10:16
Ja, wunderbar, das ist ein Switch Channel.

Also das knx Device erstellst Du über das knx Binding, ja. Dieses knx Thing ist eine Hülle. Wenn Du es ordentlich machen willst, erstellst Du pro Busankoppler ein Thing (jedes Gerät am knx Bus hat einen Busankoppler).

Pro knx Thing gibt es acht Parameter:
  • die Unique ID, welche man beim Erstellen setzen muss (es wird ein Wert vorgegeben, aber man sollte hier etwas sinnvolles hinschreiben, z.B. bei mir schalt_1_1_15. Wichtig ist vor allem, dass man selbst an der Unique ID erkennen kann, um welches Gerät es sich handelt.
  • Das Label, z.B. "Hager 6-Kanal Schaltaktor 1"
  • Die Location (optional, nur sinnvoll bei Geräten, die tatsächlich an einem fixen Ort sind, also z.B. ein fest verbauter Temperaturfühler)
  • Die Bridge. Hier gibt es eine Auswahlliste, denn man könnte ja auch mehrere knx Busse in einem openHAB System anbinden wollen. Gewöhnlich gibt es nur einen möglichen Eintrag. Muss ausgewählt werden (passiert nie automatisch)
  • Address (optional) ist die physikalische Adresse in der Form x.y.z, wobei gilt [0-15].[0-15].[0-255]. Alle Geräte an einer knx Bus-Linie unterscheiden sich nur durch das letzte Oktett, also x.y. sind für alle Geräte an einer Linie identisch, lediglich z ist pro Gerät verschieden.
  • Fetch (default ist false, optional) ist Schnickschnack, den man nicht braucht. Man kann (vor allem bei neueren Geräten) zusätzliche Informationen auslesen, z.B. den Namen des Herstellers und welche ROM-Maske verwendet wird. Ist Fetch=true gesetzt, so geschieht dies, ansonsten nicht. Kann zu Problemen auf dem Bus führen, wie gesagt, Schnickschnack.
  • pingInterval(optional, default 600), Zeit in Sekunden zwischen zwei Pollversuchen. Anhand der Antwort wird das Gerät als Online oder Offline gekennzeichnet. (Hat keine Auswirkungen auf die Funktion der Channel!!!)
  • readInterval(optional, default 0), Zeit in Sekunden zwischen zwei Leseversuchen. Dieser Parameter sollte immer auf 0 stehen, es sei denn, es gibt einen triftigen Grund dagegen (es gibt nur einen, der betrifft meist ältere Hardware)
Bis auf Unique ID, Label und Bridge sind alle Parameter also optional. Fetch und pingInterval funktionieren nur, wenn Address korrekt gesetzt ist. readInterval funktioniert nur bei nicht-control-Channels, die eine lesbare Adresse gekennzeichnet haben und sollte grundsätzlich auf 0 stehen bleiben.

Unterhalb des Thing legst Du dann die zugehörigen Channel an, um bei obigem Beispiel zu bleiben, wären das erst mal sechs Stück vom Typ Switch.
Die Channel brauchen einen Namen und ein Label, z.B. ch1 und "Licht Bar" (womit der Channel sowohl auf Hardwareebene als auch auf Bedienebene eindeutig identifiziert werden kann). Weiterhin braucht es dann noch einen Parameter, in dem die zugehörigen GA notiert werden müssen, hier ist das 1/0/13+<1/1/13. Die erste GA ist die sendende, damit wird also ein Befehl an knx geschickt. die zweite GA sollte lesbar sein, weshalb openHAB beim Start versuchen sollte, von dieser GA den aktuellen Status zu bekommen. Das wird durch das < gekennzeichnet. Es gibt pro Channel genau eine GA, die das < als Kennzeichen trägt. Maximal kann man es weg lassen, wenn keine der GA lesbar ist, aber bitte niemals mehrere GA als lesbar kennzeichnen.

Als Code sieht das dann ungefähr so aus:

Code: Alles auswählen

UID: knx:device:55aa39e1e3
label: KNX Device
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
channels:
  - id: ch1
    channelTypeUID: knx:switch
    label: Licht Bar
    description: ""
    configuration:
      ga: 1/0/13+<1/1/13
wobei ich hier aus Faulheit keine bridge angelegt habe - ist ja nicht mein Gerät - und im Thing auch keine anderen Werte eingetragen habe (alles default Werte) Das gilt aber nicht für den Channel, den habe ich sinnvoll befüllt.
Gehe zur vollständigen Antwort

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von udo1toni »

Punkt 1: Die Bridge ist nur die Verbindung zum Bus. Nach der Verbindung zum Bus musst Du Geräte anlegen. Da knx ein Bus ist, hast Du die Wahl, nur ein Gerät anzulegen, oder eben für jedes Gerät, was am Bus angeschlossen ist ein eigenes Gerät (das hat den Vorteil, sich an der Hardware zu orientieren).

Punkt 2: openHAB braucht keine Verbindung zum Schalter! openHAB braucht eine Verbindung zum Aktor. Pro Aktorkanal musst Du einen passenden Channel anlegen, dieser enthält dann die Information, wie der Channel gesteuert wird und wo der aktuelle Status her kommt.
Es gibt natürlich doch einen Fall, wo Du Schalter in openHAB brauchst (bzw. in 99% der Fälle Taster), das ist dann der Fall, wenn der Aktor nicht zu knx gehört, also z.B. wenn Du über einen knx Taster an der Wand das Webradio lauter und leiser steuern willst.

Punkt 3: Die Adressen x.y.z sind die physikalischen Adressen der Geräte. Diese spielen bei der Kommunikation auf dem knx Bus grundsätzlich keine Rolle! Du brauchst die GruppenAdressen (GA), welche mit den KommunikationsObjekten (KO) der Geräte verbunden sind. Z.B. kann die GA 3/6/12 dazu dienen, den Kanal 1 des Aktors mit der pA 12.3.15 zu steuern, was gewöhnlich über das KO 0 geschieht. Wenn es sich dabei um einen Schaltaktor handelt, wird der Datentyp (DPT) 1.001 sein (der DPT spielt in zukünftigen Versionen des knx Bindings eine bedeutende Rolle, momentan ist nur die Stelle vor dem Punkt interessant, der DPT muss aber vollständig angegeben werden). Auf der GA 7/3/219 kommt dann vielleicht die Rückmeldung für den Aktorkanal, von KO 3, dort teilt der Aktor also mit, ob er An oder Aus ist.

Anhand der Zahlen kannst Du eines erkennen: Es gibt keinerlei feststehende Zuordnungen in knx. Das heißt, Du musst zwingend eine Dokumentation zum knx Bus haben, eine Liste aller GA mit Informationen, was die GA steuern. Man kann mit diversen Hilfsmitteln weitreichende Analysen durchführen und so den Bus per Reverse Engineering aufdecken, aber zum einen kann es sein, dass man dabei nur Teilinformationen erhält, zum anderen ist das relativ zeitraubend. Eine vorhandene Doku ist also Pflicht.
Da eine Visu für knx grundsätzlich andere Anforderungen an den knx Bus hat als eine konventionelle Steuerung über Wandtaster, ist es auch fast nicht zu vermeiden, am Bus mittels ETS (EngineeringToolSoftware) Änderungen vorzunehmen.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Norick
Beiträge: 234
Registriert: 31. Jan 2022 06:35

Re: KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von Norick »

Vielen Dank für die ausführliche Erklärung zum KNX-Bus. Nun eine solche Doku zu den Aktoren ist bei mir vorhanden sodass ich das Ganze nicht mehr suchen muss. Was mir eben noch nicht klar ist wie ich eine Verbindung von OH zu dem Aktor mache bzw. einen Channel anlege.

Gibt es dazu ein kurzes Tutorial wie das auf dem UserInterface von OH gemacht werden kann? Das wäre super wenn es sowas gibt. Ich meinte gelesen zu haben dass man Text-Files anlegen muss aber mir scheint es müsse doch einfacher direkt über das UI zu machen - oder nicht?

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von udo1toni »

Wie gesagt, Du legst einfach ein generic knx Thing an. Dieses wird der Bridge zugeordnet, welche Du ja schon online hast.
Dann legst Du in diesem neuen Thing Channel an.

Die Konfiguration für den Zugriff auf externe Ressourcen funktioniert in openHAB immer nach dem gleichen Prinzip. Einzelgeräte sind Things, Busse nutzen eine Bridge, welche (Nomen es Omen) eine Brücke zwischen den Things und dem Bus schlägt.
Channel beinhalten eine einzelne Eigenschaft eines Geräts, also z.B. bei einem Schaltaktor die Entsprechung des Relais. Der Channel kann dann den Befehl ON oder OFF erhalten, woraufhin das Relais entsprechend ein- oder ausgeschaltet wird. Außerdem repräsentiert der Channel auch den Zustand des Relais, er leitet also die Information "Relais ist ein- bzw. ausgeschaltet" als ON und OFF weiter. Der Channel wird mit einem Item verknüpft, welches zur Art des Channels passen muss, für den Schaltaktor ist das der Typ Switch. Das Item kann Befehle senden und den Status halten. Solange es noch keinen gültigen Status gibt, nimmt das Item den Status NULL an. Der Status kann auch gezielt auf UNDEF gesetzt werden.

Der knx Bus ist dafür optimiert, mit geringen Datenmengen möglichst effizient zu arbeiten, deshalb gibt es nur die reine Steuerinformation, welche vom Elektriker bei der Inbetriebnahme programmiert wurde.

Wie gesagt, Du kannst den Bus abhorchen, aber es gehört schon ein wenig Erfahrung dazu, die korrekten Schlüsse zu ziehen. Du kannst z.B. das knx Binding Log in den DEBUG Modus schalten und siehst anschließend im Log den gesamten Datenverkehr auf dem knx Bus. Dann kannst Du den Taster an der Wand betätigen, also ein paar Mal das Licht an- und ausschalten und im Log anschließend nachschauen, welche GA denn da gesendet wurde. Aber mit hoher Wahrscheinlichkeit werden zwischendurch auch andere GA auf dem Bus auftauchen, je nachdem, wie umfangreich die knx Installation ist.
Und mit dieser Methode bekommst Du maximal einen Teil der GA heraus.

Die Doku gehört übrigens zur Installation dazu, das ist wie die Montageanleitung der Heizungsanlage, der Handwerker muss diese bei der Übergabe bereitstellen, das ist gesetzlich geregelt. Das hilft Dir natürlich nicht, wenn Du gar nicht Auftraggeber für die Anlage warst, sondern das Haus oder die Wohnung nur gekauft hast. Und wenn der Betrieb nicht mehr existiert, hast Du auch keine Chance mehr, eine Kopie der Unterlagen zu bekommen.

Mit der ETS professional ist es möglich, den Bus auszulesen und eine Liste der Geräte zu erhalten. Mit der Liste ist es dann möglich, jedes Gerät einzeln auszulesen und so zu erfahren, welche KO mit welchen GA gekoppelt sind. Daraus kann man im Idealfall die Konfiguration zu 90% wiederherstellen. Es fehlen dann nur die Anteile, welche gar nicht in den Geräten vorliegen, also z.B. Beschreibungen der einzelnen GA, aber die kann man dann selbst nachpflegen.
Was auf diese Weise nicht ausgelesen werden kann, sind fortgeschrittene Konfigurationen, z.B. wenn man einen Smarten Taster hat, der auch noch als Raumtemperaturregler arbeitet. Für solche Geräte gibt es dann extra Plugins für ETS, mit denen die Geräte über den Bus konfiguriert werden können. Diese Geräte müssen dann einzeln behandelt werden, und da kommt es auch sehr darauf an, was der Hersteller implementiert hat, ob das Plugin das Auslesen der Konfiguration ermöglicht. Im Zweifel kann man aber das alte Verhalten auch händisch wiederherstellen.

ETS5 pro (bzw. inzwischen wohl ETS6 pro) kostet allerdings 1000 € plus MwSt. Aber vielleicht kennst Du ja jemanden, der eine ETS hat und Dir Deinen Bus rekonstruieren kann. Ansonsten bleibt Dir nur der Weg über die Loggings.

Ach so... Es gibt auch noch eine kostenlose Variante der ETS (die bekommt man, wenn man erfolgreich an einem "Seminar" teilgenommen hat... ist aber eher ein Quiz, welches man beantworten kann, wenn man sich vorher ein klein wenig eingelesen hat).
Diese kostenlose Variante ist allerdings stark eingeschränkt, und zwar durch die Anzahl der Geräte in einem Projekt. Man kann die Probleme damit umgehen, indem man viele kleine Projekte erstellt, statt ein großes, aber für das Reverse Engineering geht das so nicht, allenfalls, um einzelnen Devices zusätzliche GA zu verpassen.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Norick
Beiträge: 234
Registriert: 31. Jan 2022 06:35

Re: KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von Norick »

udo1toni hat geschrieben: 9. Mai 2022 09:12 Wie gesagt, Du legst einfach ein generic knx Thing an. Dieses wird der Bridge zugeordnet, welche Du ja schon online hast.
Dann legst Du in diesem neuen Thing Channel an.

Dazu diese zwei Fragen:
- das heisst ich lege das Thing an mit: KNX Binding -> KNX Device? Wenn ja, welche Adresse bei "New KNX Device" wird hier eingegeben?



-Ich habe für meine KNX Geräte eine Liste welche zum Beispiel so aussieht:

1/1/13 Actors Relais Licht Bar [Return]
1/0/13 Actors Relais Licht Bar [Set]


Ich frage mich gerade welche von beiden die Gruppenadresse ist. Ist dies die "Set-Adresse"


Danke

Benutzeravatar
udo1toni
Beiträge: 13867
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von udo1toni »

Ja, wunderbar, das ist ein Switch Channel.

Also das knx Device erstellst Du über das knx Binding, ja. Dieses knx Thing ist eine Hülle. Wenn Du es ordentlich machen willst, erstellst Du pro Busankoppler ein Thing (jedes Gerät am knx Bus hat einen Busankoppler).

Pro knx Thing gibt es acht Parameter:
  • die Unique ID, welche man beim Erstellen setzen muss (es wird ein Wert vorgegeben, aber man sollte hier etwas sinnvolles hinschreiben, z.B. bei mir schalt_1_1_15. Wichtig ist vor allem, dass man selbst an der Unique ID erkennen kann, um welches Gerät es sich handelt.
  • Das Label, z.B. "Hager 6-Kanal Schaltaktor 1"
  • Die Location (optional, nur sinnvoll bei Geräten, die tatsächlich an einem fixen Ort sind, also z.B. ein fest verbauter Temperaturfühler)
  • Die Bridge. Hier gibt es eine Auswahlliste, denn man könnte ja auch mehrere knx Busse in einem openHAB System anbinden wollen. Gewöhnlich gibt es nur einen möglichen Eintrag. Muss ausgewählt werden (passiert nie automatisch)
  • Address (optional) ist die physikalische Adresse in der Form x.y.z, wobei gilt [0-15].[0-15].[0-255]. Alle Geräte an einer knx Bus-Linie unterscheiden sich nur durch das letzte Oktett, also x.y. sind für alle Geräte an einer Linie identisch, lediglich z ist pro Gerät verschieden.
  • Fetch (default ist false, optional) ist Schnickschnack, den man nicht braucht. Man kann (vor allem bei neueren Geräten) zusätzliche Informationen auslesen, z.B. den Namen des Herstellers und welche ROM-Maske verwendet wird. Ist Fetch=true gesetzt, so geschieht dies, ansonsten nicht. Kann zu Problemen auf dem Bus führen, wie gesagt, Schnickschnack.
  • pingInterval(optional, default 600), Zeit in Sekunden zwischen zwei Pollversuchen. Anhand der Antwort wird das Gerät als Online oder Offline gekennzeichnet. (Hat keine Auswirkungen auf die Funktion der Channel!!!)
  • readInterval(optional, default 0), Zeit in Sekunden zwischen zwei Leseversuchen. Dieser Parameter sollte immer auf 0 stehen, es sei denn, es gibt einen triftigen Grund dagegen (es gibt nur einen, der betrifft meist ältere Hardware)
Bis auf Unique ID, Label und Bridge sind alle Parameter also optional. Fetch und pingInterval funktionieren nur, wenn Address korrekt gesetzt ist. readInterval funktioniert nur bei nicht-control-Channels, die eine lesbare Adresse gekennzeichnet haben und sollte grundsätzlich auf 0 stehen bleiben.

Unterhalb des Thing legst Du dann die zugehörigen Channel an, um bei obigem Beispiel zu bleiben, wären das erst mal sechs Stück vom Typ Switch.
Die Channel brauchen einen Namen und ein Label, z.B. ch1 und "Licht Bar" (womit der Channel sowohl auf Hardwareebene als auch auf Bedienebene eindeutig identifiziert werden kann). Weiterhin braucht es dann noch einen Parameter, in dem die zugehörigen GA notiert werden müssen, hier ist das 1/0/13+<1/1/13. Die erste GA ist die sendende, damit wird also ein Befehl an knx geschickt. die zweite GA sollte lesbar sein, weshalb openHAB beim Start versuchen sollte, von dieser GA den aktuellen Status zu bekommen. Das wird durch das < gekennzeichnet. Es gibt pro Channel genau eine GA, die das < als Kennzeichen trägt. Maximal kann man es weg lassen, wenn keine der GA lesbar ist, aber bitte niemals mehrere GA als lesbar kennzeichnen.

Als Code sieht das dann ungefähr so aus:

Code: Alles auswählen

UID: knx:device:55aa39e1e3
label: KNX Device
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
channels:
  - id: ch1
    channelTypeUID: knx:switch
    label: Licht Bar
    description: ""
    configuration:
      ga: 1/0/13+<1/1/13
wobei ich hier aus Faulheit keine bridge angelegt habe - ist ja nicht mein Gerät - und im Thing auch keine anderen Werte eingetragen habe (alles default Werte) Das gilt aber nicht für den Channel, den habe ich sinnvoll befüllt.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Norick
Beiträge: 234
Registriert: 31. Jan 2022 06:35

Re: KNX IP Gateway mit Weinzierl funktioniert nicht

Beitrag von Norick »

Super Beschreibung..!!!!

Vielen Dank hat genau so funktioniert wie du geschrieben hast..! :D Jetzt muss ich nur noch alle restlichen Kanäle fühlen und so nimmt dann das Ganze langsam aber sicher gestalt an.


Danke nochmals :!:

Antworten