Hallo zusammen,
Ich bin absoluter Neuling und versuche mich an einem Raspberry Pi 3 mit OpenHab 2.5M2 . Eventuell war mein erster Fehler diese Version zu verwenden?
Ich habe das KNX Binding installiert, bin dann über die Inbox auf das hinzufügen und habe dort IP Adresse des MDT KNX IP Gateway hinterlegt.
Als die weiß hinterlege ich doch in meinem aktuellen Fall den Schaltactor mit der KNX Adresse 1.1.1
Und als Channel füge ich dann den Buchstaben des Kanals d und KNX Adresse 1.3.1 hinzu. Ist das korrekt?
Somit wird unter control mein KG Schaltaktor mit dem Item Licht angezeigt.
Schalten funktioniert aber nicht. Habe ich hier noch irgendwo einen Denkfehler oder etwas vergessen? Muss in irgendwelchen Konfigurationsdateien noch etwas hinterlegt werden in der Version 2.5?
Absoluter Neuling, KNX Binding
-
- Beiträge: 11
- Registriert: 6. Aug 2018 08:30
Re: Absoluter Neuling, KNX Binding
Ich muss mir hier selber antworten! Ist mir gerade peinlich. Bei den Beschriftungen steht x.y.z daher habe ich die Adressen auch mit 1.1.1 eingegeben und nicht mit einem /
- udo1toni
- Beiträge: 15247
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Absoluter Neuling, KNX Binding
Nenene...
Es gibt physikalische Adressen, die werden x.y.z geschrieben (wobei gilt: x,y 0-15; z 0-255) und es gibt GruppenAdressen, die werden in der Form x/y/z geschrieben (andere Gruppierung lass ich mal außen vor). Dabei gilt (Standard) x 0-31, y 0-7, z 0-255.
Die GA-Notation ist zugegebenermaßen in Paper UI nicht explizit angegeben, aber mit Punkten wirst Du die Notation nur für die physikalischen Adressen finden (in der Bridge und im Thing)

Es gibt physikalische Adressen, die werden x.y.z geschrieben (wobei gilt: x,y 0-15; z 0-255) und es gibt GruppenAdressen, die werden in der Form x/y/z geschrieben (andere Gruppierung lass ich mal außen vor). Dabei gilt (Standard) x 0-31, y 0-7, z 0-255.
Die GA-Notation ist zugegebenermaßen in Paper UI nicht explizit angegeben, aber mit Punkten wirst Du die Notation nur für die physikalischen Adressen finden (in der Bridge und im Thing)

openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 11
- Registriert: 6. Aug 2018 08:30
Re: Absoluter Neuling, KNX Binding
Hallo Udo,
danke für deine Rückmeldung. Wenn ich das wiederholen darf, dann sollte in der Paper UI unter Configuration - Things - mit + (Hinzufügen) - KNX Binding - KNX Device - bei Adress mit Punkt gearbeitet werden und nachdem anlegen dieses Devices klicke ich auf das Device, und füge dort mit x/y/z dann die Channels hinzu?
Derzeit habe ich die Device und IP Gateway mit x/y/z hinzugefügt und es funktioniert.
danke für deine Rückmeldung. Wenn ich das wiederholen darf, dann sollte in der Paper UI unter Configuration - Things - mit + (Hinzufügen) - KNX Binding - KNX Device - bei Adress mit Punkt gearbeitet werden und nachdem anlegen dieses Devices klicke ich auf das Device, und füge dort mit x/y/z dann die Channels hinzu?
Derzeit habe ich die Device und IP Gateway mit x/y/z hinzugefügt und es funktioniert.
- udo1toni
- Beiträge: 15247
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Absoluter Neuling, KNX Binding
Mal langsam, bevor Du noch mehr durcheinander wirfst.
Das Gateway (in openHAB die Bridge):
1. ipAddress -> eine IPv4 Adresse (wahlweise FQDN, falls Dein Netzwerk Namensauflösung unterstützt). Die IP hat die Notation a.b.c.d, jeweils von 0 - 255. Die IP ist vom System vorgegeben.
2. localIp -> die IPv4 Adresse des Interfaces, über welches die Kommunikation laufen soll. Im Normalfall ist diese IP identisch mit der IP, über die auch openHAB erreichbar ist. Hier darf keinesfalls der FQDN verwendet werden, da er auf localhost aufgelöst wird (127.0.0.1). localIp muss normalerweise nicht gesetzt werden.
3. localSourceAddr ist die physikalische Adresse des Gateway in der Notation a.b.c. Mit dieser Adresse kommuniziert openHAB mit dem knx Bus. Wird hier keine oder eine ungültige Adresse eingetragen, verwendet openHAB den Default Wert 0.0.0. Man kann das nur sehen, wenn man einen Gruppenmonitor laufen lässt (z.B. in ETS) oder das knx2 Addon logging auf DEBUG stellt.
Das/die Thing(s):
address: die physikalische Adresse des Devices, welches durch das Thing repräsentiert wird. Notation mit Punkten, also a.b.c. Die physikalische Adresse hat keine Auswirkung auf die Kommunikation, wenn hier etwas falsches eingetragen ist, wird openHAB das einfach ignorieren.
Nur Gruppenadressen werden in der Notation a/b/c geschrieben. Ich garantiere Dir, dass fehlerhafte Konfigurationen immer zur Nicht-Funktion führen
- bis auf die physikalische Adresse, da sie keine wichtige Rolle spielt.
Das Gateway (in openHAB die Bridge):
1. ipAddress -> eine IPv4 Adresse (wahlweise FQDN, falls Dein Netzwerk Namensauflösung unterstützt). Die IP hat die Notation a.b.c.d, jeweils von 0 - 255. Die IP ist vom System vorgegeben.
2. localIp -> die IPv4 Adresse des Interfaces, über welches die Kommunikation laufen soll. Im Normalfall ist diese IP identisch mit der IP, über die auch openHAB erreichbar ist. Hier darf keinesfalls der FQDN verwendet werden, da er auf localhost aufgelöst wird (127.0.0.1). localIp muss normalerweise nicht gesetzt werden.
3. localSourceAddr ist die physikalische Adresse des Gateway in der Notation a.b.c. Mit dieser Adresse kommuniziert openHAB mit dem knx Bus. Wird hier keine oder eine ungültige Adresse eingetragen, verwendet openHAB den Default Wert 0.0.0. Man kann das nur sehen, wenn man einen Gruppenmonitor laufen lässt (z.B. in ETS) oder das knx2 Addon logging auf DEBUG stellt.
Das/die Thing(s):
address: die physikalische Adresse des Devices, welches durch das Thing repräsentiert wird. Notation mit Punkten, also a.b.c. Die physikalische Adresse hat keine Auswirkung auf die Kommunikation, wenn hier etwas falsches eingetragen ist, wird openHAB das einfach ignorieren.
Nur Gruppenadressen werden in der Notation a/b/c geschrieben. Ich garantiere Dir, dass fehlerhafte Konfigurationen immer zur Nicht-Funktion führen

openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 11
- Registriert: 6. Aug 2018 08:30
Re: Absoluter Neuling, KNX Binding
Hi Udo,
ich komme aus dem IT Bereich und das Thema mit Gateway IP Adressen usw. ist mir alles klar, da hab ich auch nichts verwechselt.
Ich habe das nun getestet. Schau dir bitte die beigefügten Screenshots an. Es spielt in der Funktion keine Rolle ob ich für das Decive die Adresse 1.1.104 oder 1/1/104 (auch wenn ich verstanden habe dass da hier falsch ist) oder ob ich nichts eintrage. wird komplett ignoriert.
Für den Channel, da ist es wichtig 2/2/24 zu verwenden sonst geht nichts. Wieso das davor keine Rolle spielt, keine Ahnung....
Aber ich denke hier ist auch mein Verständnis Problem begraben. Ich gehe die ganze Zeit davon aus dass ich bei dem KNX Binding mit Device meinen Aktor z.B. einen Dimmaktor einen Schaltaktor einen Jalousie Aktor hinzufüge... und dann je Aktor (Device) einen Channel.
Aber so wie ich das sehe nehme ich die Übersetzungen zu genau und denke das ein Channel ein Aktor Kanal ist. Korrekt dass das falsch ist :-
Was ein Satz ...
Denn wie ich nun gemerkt habe. Kann ich ein Device Hinzufügen, ohne Adresse, ist ja eh egal, also definieren oder Bezeichne ich "Device" eher mal als Kategorie. Bspw. Erdgeschoss oder Lichter
Und in dem Device Erdgeschoss habe ich dann Channels. Das kann im Erdgeschoss dann eine Dimmbare Lampe, eine Rolladen aber auch eine schaltbare Steckdose sein. Oder wenn man es aus Kategorie Sicht Lichter sieht. sind es dann die einzelnen schalt/oder dimmbaren Lichter im ganzen Haus.
Sehe ich das nun so richtig?
Kann aber absolut nicht kapieren wieso dann unter device nach x.y.z Adresse gefragt wird...
Wenn ich nun wieder falsch liege, dann bitte ich dich mich mal privat zu kontaktieren. Ginge das? Sende dir gerne meine Nummer
ich komme aus dem IT Bereich und das Thema mit Gateway IP Adressen usw. ist mir alles klar, da hab ich auch nichts verwechselt.
Ich habe das nun getestet. Schau dir bitte die beigefügten Screenshots an. Es spielt in der Funktion keine Rolle ob ich für das Decive die Adresse 1.1.104 oder 1/1/104 (auch wenn ich verstanden habe dass da hier falsch ist) oder ob ich nichts eintrage. wird komplett ignoriert.
Für den Channel, da ist es wichtig 2/2/24 zu verwenden sonst geht nichts. Wieso das davor keine Rolle spielt, keine Ahnung....
Aber ich denke hier ist auch mein Verständnis Problem begraben. Ich gehe die ganze Zeit davon aus dass ich bei dem KNX Binding mit Device meinen Aktor z.B. einen Dimmaktor einen Schaltaktor einen Jalousie Aktor hinzufüge... und dann je Aktor (Device) einen Channel.
Aber so wie ich das sehe nehme ich die Übersetzungen zu genau und denke das ein Channel ein Aktor Kanal ist. Korrekt dass das falsch ist :-
Was ein Satz ...
Denn wie ich nun gemerkt habe. Kann ich ein Device Hinzufügen, ohne Adresse, ist ja eh egal, also definieren oder Bezeichne ich "Device" eher mal als Kategorie. Bspw. Erdgeschoss oder Lichter
Und in dem Device Erdgeschoss habe ich dann Channels. Das kann im Erdgeschoss dann eine Dimmbare Lampe, eine Rolladen aber auch eine schaltbare Steckdose sein. Oder wenn man es aus Kategorie Sicht Lichter sieht. sind es dann die einzelnen schalt/oder dimmbaren Lichter im ganzen Haus.
Sehe ich das nun so richtig?
Kann aber absolut nicht kapieren wieso dann unter device nach x.y.z Adresse gefragt wird...
Wenn ich nun wieder falsch liege, dann bitte ich dich mich mal privat zu kontaktieren. Ginge das? Sende dir gerne meine Nummer
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
- udo1toni
- Beiträge: 15247
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Absoluter Neuling, KNX Binding
Hallo Andreas,
ich wollte nicht Dein Wissen infrage stellen, aber ich weiß ja nicht, wo ich Dich abholen muss
Also noch mal, was die Device Adressen betrifft: die sind für die Funktion in openHAB irrelevant.
Das Thing Modell in openHAB soll die Hardware abbilden. Es ist einfach eine Abstraktionsebene, die vor allem aus Programmierersicht erforderlich ist.
In knx besteht die Hardware streng genommen aus einzelnen Devices, wobei jedes Device eine physikalische Adresse hat. (Die spielt aber bei der Kommunikation erst mal nur eine untergeordnete Rolle - bei openHAB spielt sie keine Rolle). Man kann den knx Bus aber auch als geschlossenes System betrachten, weshalb man dann auch nur ein einziges Device anlegen kann (abgesehen von der Bridge natürlich).
Es ist nicht so, dass die physikalisch Adresse keinerlei Auswirkung hat. Wenn Du die Devices mit physikalischer Adresse anlegst, wird openHAB im Abstand von pingInterval Sekunden prüfen, ob ein Device am knx Bus auf die physikalische Adresse antwortet. Ist das der Fall, wird das Device ONLINE angezeigt, sonst OFFLINE. Aber wie erwähnt hat das keine Auswirkung auf die Kommunikation an sich.
weiterhin gibt es knx Devices, die bereitwillig Details über sich verraten, wenn fetch=true gesetzt ist, versucht openHAB, diese Details auszulesen. Meist erfährt man die Maskennummer, evtl. den Hersteller oder auch den Firmwarestand. Spielt für die Funktion keine Rolle und kann auch zu Problemen führen.
Wenn man in der Bridge eine localSourceAddr einträgt, verwendet openHAB diese, um mit dem Bus zu kommunizieren. Wenn die Adresse bereits vergeben ist, kommt es zur Kollision und die Kommunikation wird gestört sein. Wenn die Adresse noch frei ist, kann man im Busmonitor Filter definieren, um ausschließlich Nachrichten von openHAB zu Gesicht zu bekommen.
Du kannst knx Things grundsätzlich so anlegen, wie Du lustig bist. Ich habe meinen Bus komplett abgebildet - dabei habe ich die Channel (ja, ein Channel entspricht normalerweise einem Aktorkanal) jeweils im zuständigen Device angelegt. Das bedeutet, dass die Lochtschalter keine Channel haben, nur in den RTR sind welche für die RTR-Funktionen vorhanden (ist/solltemperatur usw.)


Also noch mal, was die Device Adressen betrifft: die sind für die Funktion in openHAB irrelevant.
Das Thing Modell in openHAB soll die Hardware abbilden. Es ist einfach eine Abstraktionsebene, die vor allem aus Programmierersicht erforderlich ist.
In knx besteht die Hardware streng genommen aus einzelnen Devices, wobei jedes Device eine physikalische Adresse hat. (Die spielt aber bei der Kommunikation erst mal nur eine untergeordnete Rolle - bei openHAB spielt sie keine Rolle). Man kann den knx Bus aber auch als geschlossenes System betrachten, weshalb man dann auch nur ein einziges Device anlegen kann (abgesehen von der Bridge natürlich).
Es ist nicht so, dass die physikalisch Adresse keinerlei Auswirkung hat. Wenn Du die Devices mit physikalischer Adresse anlegst, wird openHAB im Abstand von pingInterval Sekunden prüfen, ob ein Device am knx Bus auf die physikalische Adresse antwortet. Ist das der Fall, wird das Device ONLINE angezeigt, sonst OFFLINE. Aber wie erwähnt hat das keine Auswirkung auf die Kommunikation an sich.
weiterhin gibt es knx Devices, die bereitwillig Details über sich verraten, wenn fetch=true gesetzt ist, versucht openHAB, diese Details auszulesen. Meist erfährt man die Maskennummer, evtl. den Hersteller oder auch den Firmwarestand. Spielt für die Funktion keine Rolle und kann auch zu Problemen führen.
Wenn man in der Bridge eine localSourceAddr einträgt, verwendet openHAB diese, um mit dem Bus zu kommunizieren. Wenn die Adresse bereits vergeben ist, kommt es zur Kollision und die Kommunikation wird gestört sein. Wenn die Adresse noch frei ist, kann man im Busmonitor Filter definieren, um ausschließlich Nachrichten von openHAB zu Gesicht zu bekommen.
Du kannst knx Things grundsätzlich so anlegen, wie Du lustig bist. Ich habe meinen Bus komplett abgebildet - dabei habe ich die Channel (ja, ein Channel entspricht normalerweise einem Aktorkanal) jeweils im zuständigen Device angelegt. Das bedeutet, dass die Lochtschalter keine Channel haben, nur in den RTR sind welche für die RTR-Funktionen vorhanden (ist/solltemperatur usw.)
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet