Anfängerfrage KNX Binding

[sourex]

Hi.
Nachdem ich meine Programierung der ETS so langsam beendet habe wollte ich nun mit OH starten.

Leider bekomme ich mein erstes Item noch nicht hin, da scheint noch ein Verständnisproblem zu sein.
Es ist versuchsweise einfach eine Lampenschaltung
Hier meine bisherigen Zeilen:
KNX.Things

ipAddress="224.0.23.12",
portNumber=3671,
type="ROUTER",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr="1.1.0"
] {
Thing device test [
address="1.1.13",
fetch=false,
pingInterval=300,
readInterval=3600
] {
Type switch : buerolicht "Licht" [ ga="1/0/23" ]

Hier ist das Problem das ich nicht eindeutig herausgefunden habe welche adresse ich beim Thing device eingeben muss.
Ich habe gelesen das diese Funktion der Aktoren eigentlich noch garnicht aktiv ist, und im Beispiel bei der Openhab Confi steht dort nur die Adresse 1.2.3 sodass man schlecht nachvollziehen kann worauf sich das bezieht. Ich habe an dieser Stelle bereits die Adressen des Schaltaktor als auch die des Taster getestet über den ich normalerweise die Lampe schalte.

KNX.items

Switch buerolicht "Licht [%s]" <light> { channel="knx:device:bridge:test:buerolicht" }

Muss ich als Gruppenadresse die GA nehmen worüber ich das Licht mittels Taster schalte oder muss ich extra eine anlegen wo nur das KO des Schaltaktors steht ?

KNX.sitemap

sitemap knx label="Hauptmenue" {
Frame label="Haus" {
Switch item=buerolicht

Item ist sichtbar und lässt sich bedienen, das Licht schaltet jedoch nicht.

Vielen Dank schonmal.

[udo1toni]

Hallo,

erstmal ist Deine knx.things mindestens unvollständig wiedergegeben.
Zum Verständnis der verschiedenen Parameter:

• localSourceAddr: Die physikalische Adresse, die openHAB benutzt, um mit dem Bus zu kommunizieren. Diese Adresse muss frei sein.
  Man kann in ETS ein Dummy Gerät anlegen, damit der Busmonitor keine Fehler anzeigt, es darf aber kein reales Gerät dazu existieren.
• address: Die physikalische Adresse des realen Device, welches als Thing angelegt wurde. Falls man kein reales Device anlegen möchte, sondern z.B. alle Channel in einem einzigen generic Device zusammenfasst, darf man keine physikalische Adresse angeben.
• fetch: openHAB soll versuchen, zusätzliche Informationen über das Gerät zu holen (z.B. Seriennummer, Hersteller, was das Gerät so über sich verrät) Diese Funktion wird nicht von allen Geräten unterstützt und kann zu Problemen führen, wenn sie aktiviert ist.
• pingInterval: openHAB versucht in diesem Abstand, das Gerät zu erreichen.Mit 0 (das ist default) ist die Funktion inaktiv, das Thing wird immer ONLINE angezeigt.
• readInterval: Interval, in dem openHAB regelmäßig Read Requests an die lesbaren GA schickt, um den Status abzugleichen. Diese Funktion ist mit Vorsicht zu genießen, denn
  1. betrifft sie alle GA mit vorangestelltem < des Things, und
  2. sollte sie eigentlich komplett unnötig sein. Es gibt nur wenige Sensoren, die sich weigern, von sich aus bei Wertänderung oder zyklisch ihren Status zu senden, bei denen kann diese Funktion sinnvoll sein, sonst nicht.

Alle Parameter sind optional (mit Ausnahme des Modus und davon abhängig evtl. der ipAddress).
Entsprechend sollte Dein Test zunächst eher so aussehen:

Bridge knx:ip:bridge "IP knx Router" @ "knx" [
    type="ROUTER"
 ] {
    Thing device test "Test Device" @ "knx" []
     {
        Type switch : buerolicht "Licht" [ ga="1/0/23" ]
     }
 }

Da Du keine Rückmelde-GA eingetragen hast, bekommt openHAB leider nicht mit, ob der Schaltbefehl ausgeführt wurde. Rückmeldungen sind in knx eine nicht unwichtige Funktion, auch um z.B. sicherzustellen, dass das Toggle mehrerer Wandtaster einwandfrei funktioniert, vor allem im Zusammenhang mit knx-Zentralbefehlen, Zwangssteuerung oder Szenen.

Gruppenadressen haben keine physische Zuordnung zu einem Gerät, allerdings gehören sie logisch zu einem Gerät. Bei Licht gehören alle GA zum Aktor, da dieser den echten Status kennt (Schaltzustand des Relais) und auch den Schaltbefehl ausführt. GA gehören nur dann zu einem Taster, wenn es kein eindeutiges knx-Device für diese GA gibt (z.B. steuere ich die Lautstärke eines Mediaplayers über Wandtaster, in diesem Fall ist openHAB also der Aktor - dafür nutzt man dann auch switch-control als Type). Zentralbefehle gehen an mehrere Channel, entsprechend ist auch hier eher kein Aktor zuständig. Wenn man die GA auf mehreren Wandtastern hat, nutzt man aber nur einen davon für die Konfiguration in openHAB.
Sensorwerte bzw. die zugehörigen GA gehören natürlich dem Sensor. Entsprechend wäre ide physikalische Adresse zu wählen, wenn man sie denn angeben möchte.

Bitte vermeide Namensgleichheiten im kompletten openHAB-System, mit einer Ausnahme: in verschiedenen Things dürfen die Channel jeweils gleich heißen. wenn Du also 2 Things für reale Devices hast, die jeweils für einen 6-Kanal-Schaltaktor stehen, kannst Du die Channel zum Beispiel jeweils channel1, channel2, channel3, channel4, channel5 und channel6 nennen.
Das Item identisch mit dem Channel zu beschriften, ist zwar möglich, kann aber zumindest zu Verwirrung führen.

Wenn die Kommunikation grundsätzlich funktioniert, kannst Du in einen 2. Schritt eine localSourceAddr eintragen, die nirgends sonst verwendet wird. Solange keine Filtertabellen aktiv sind, sollte die Adresse selbst keine Rolle spielen (also in welche Linie sie gehört usw.)

[sourex]

Hi,
schonmal Danke für deine Antwort.
Das mit den Rückmeldungen ist mir bekannt. Die trage ich dann ein wenn ich mal irgendwas steuern kann.
Ich habe es jetzt so gemacht wie du vorgeschlagen hast.
Leider verhält es sich genau so wie vorher.
Item ist angelegt, lässt sich schalten aber es passiert im KNX nichts.

Bridge knx:ip:bridge "192.168.8.241" @ "knx" [type="ROUTER"] {
Thing device test "Test Device" @ "knx" [] {
Type switch : bueroLicht "Licht" [ ga="1/0/23" ]
}
}

Das Problem ist das keine Fehlermeldung kommt.

Weiterhin frage ich mich ob ich die interne oder die externe IP vom KNX Router eintragen muss.
In der PaperUI funktionieren beide, bzw steht bei beiden online.
Am Bus kommt allerdings nichts an.

[Fred Feuerstein]

Hallo
Ich bin auch gerade mit oh angefangen.
udo1toni Vielen Dank für die ausführliche Beschreibung der Parameter!

Hatte zunächst auch die Probleme im Router Modus. Gateway online, aber nichts tat sich. Es lag an der Filterung bzw. Blockierung der GA im IP Gateway. Speziell im Router Modus wird die Multicast IP wie im ersten Beitrag benutzt und die Filtereinstellungen im IP Gateway müssen gesetzt werden. Anschließend wurden auch die Items richtig angezeigt.

[sourex]

ich schaue mal in der Anleitung ob ich dazu was finde.
Du kannst mir aber auch gerne verraten wie das geht, falls du auch den mdt router benutzt.

[Fred Feuerstein]

Ja, steht auch in der Anleitung, habe auch den mdt Router, der Zugriff geht über den Webbrowser. Wenn Du nicht weiter kommst kann ich nochmal in meiner Konfiguration nach sehen.

[Fred Feuerstein]

ist doch schon wieder ein paar Tage her, Einstellungen erfolgen in der ETS, siehe Bilder...

[sourex]

super !!
Das war es, hatte die Einstellung auf der Weboberfläche gesucht.
jetzt geht schonmal das Licht endlich an
Vielleicht kannst du mir nochmal weiterhelfen

[ ga="1/0/23+<1/4/7" ] bei der zweiten GA habe ich das KO vom Schaltaktor Status schalten verknüpft. Trotzdem erkennt OH nicht ob das Licht an oder aus ist.
Gibts da etwas was ich übersehe ?

[Fred Feuerstein]

Die erste GA ist der Schaltbefehl an den Aktor die zweite GA der aktuelle Status.
Der Status wird aber nur bei Änderung aktualisiert, also frühestens nach dem ersten schalten. Eventuell gibt es Funktionen die den Status zyklisch oder bei Neustart aktiv am KNX Bus abfragen können, die kenne ich aber noch nicht. Hierzu muss allerdings auch das entsprechende KNX Flag an der GA gesetzt sein.

[udo1toni]

Für eine korrekte Status-Meldung gibt es ein paar Voraussetzungen.

1. Die Rückmelde GA ist als 1. GA im Rückmelde KO des Aktors eingetragen.
   Das bedeutet, wenn von diesem KO gesendet wird, passiert das ausschließlich auf dieser GA
2. im Aktor ist für dieses KO das L-Flag gesetzt (zusätzlich zu K und Ü)
   Das bedeutet, das KO reagiert auf Leseanfragen
3. Es gibt kein anderes KO, bei dem diese GA als 1. GA eingetragen ist, bei dem auch K und Ü oder gar zusätzlich L Flag gesetzt sind
   Soll heißen: ausschließlich der Aktor darf auf dieser GA senden, und das auch ausschließlich mit der Rückmeldung.

Das < vor der GA bedeutet, dass openHAB beim Systemstart einen Read Request auf diese GA schickt. Der Aktor sollte dann umgehend mit einem Response antworten und openHAB kennt den aktuellen Status.
Es gibt knx-Hardware, die nicht in der Lage ist, zyklisch zu senden oder auch bei Wertänderung zu senden. Diese (und bitte nur diese) kann man dann von openHAB aus zyklisch abfragen. Dazu definiert man im Thing das readInterval, was dann bewirkt, dass jede GA unterhalb dieses Things, bei der ein < vorangestellt ist zyklisch abgefragt wird.
Zyklische Abfragen sollten bei einem korrekt aufgesetzten knx System unnötig sein (wie erwähnt mit der einen Ausnahme).
Zyklische Abfragen erhöhen die Buslast, was bei kleinen Installationen vielleicht nicht ins Gewicht fällt, aber schon bei einer einzigen mittelgut bestückten Linie (z.B. insgesamt 45 Geräte) zu merklichen Schaltverzögerungen führen kann.

Bei Dimmern sollte die Rückmeldung ausschließlich über position (=Helligkeit) erfolgen, nicht über die switch-Eigenschaft (das führt sonst zu Sprüngen in der Anzeige, da ON als 100 gewertet wird, auch wenn der Dimmer vielleicht bei einem ON-Befehl nur auf 80% dimmt). Zusätzlich sollte man, wann immer möglich, im Item noch autoUpdate="false" setzen, damit der Status wirklich der von knx gemeldete Status ist, und nicht ein von openHAB angenommener Status.

[sourex]

Wow, super ausführliche Antwort. perfekt !
Und leider doch nicht ganz verständlich für mich als Anfänger Sorry.

Die Rückmelde GA ist als 1. GA im Rückmelde KO des Aktors eingetragen.
Das bedeutet, wenn von diesem KO gesendet wird, passiert das ausschließlich auf dieser GA

bedeutet in meinem Beispiel das ich nur die 1/0/7 als Rückmeldung eintragen müsste ? das wäre schlecht das ist nämlich die GA fürs schalten und wenn die ich die Positionierungen alle umlegen müsste...
5.PNG

besten Dank für deine Bemühungen !

btw ist ihr Wissen einfach angesammelt oder lesen sie das irgendwo nach ??
Falls ja würde ich mich über einen Link freuen, dann müsste ich sie nicht immer fragen.

[Fred Feuerstein]

Hallo sourex,
Du musst unterscheiden zwischen Schalten und Rückmelden über Status.
Die mdt Aktoren liefern den Status über ein zusätzliches KO, dieses sollte für die Rückmeldung Anzeige in Visu und für Toggle Funktionen mit mehreren Tastern genutzt werden.
Setze die Flags an deinem Schalt-KO lieber erstmal wieder auf die Standard-Werte.

An das "Schalt-KO" können zur besseren Übersicht, - wer schaltet, durchaus mehrere "Befehls GA" (von Taster, von Visu, von Zeitschaltuhr,, Gruppenbefehle usw.)
An das "Status-KO" soll immer nur eine GA. Diese kann dann von den verschiedenen Anzeigen und Schaltquellen z.B. für das Umschalten genutzt werden.

Es gibt auch (ältere) KNX-Geräte die bieten den Status nicht gesondert an, nur dann übernimmt man dann den aktuellen Zustand vom Schalt-KO.

[sourex]

Hallo Fred, grundsätzlich ist mir das mit dem Status klar, ich nutze den auch in der ETS um mir bspw auf den GT2 Tastern das richtige Bild von den Rolladen anzeigen zu lassen (zu schwarz weiß auf).
Mir ist das nur mit der Visu nicht ganz klar, bzw warum OH die nicht erkennt.
Ich habe jetzt bspw extra eine GA angelegt und in OH eingetragen. OH erkennt den Status jedoch nicht. Ich finde dort nicht den Fehler.

https://knx-user-forum.de/core/image...EAAAICRAEAOw==

Wenn ich udo1toni richtig verstanden habe muss es ja die erste GA sein. Kann ich dann bei OH einfach die GA eintragen die ich auch für den GT2 nutzte um den Rolladenstatus abzufragen ?

Danke

[udo1toni]

Das Bild in Freds Posting zeigt es eigentlich ganz exakt, so wie es sein sollte. Ein passender switch channel sähe dann mit diesen GA so aus:

Type switch : chS "Kanal S" [ ga="1/1/216+<1/4/26" ]

GA 1/4/26 ist lesbar (Flags K,L,Ü gesetzt) und mit dem Status des Aktors verbunden.
GA 1/1/216 ist schreibbar (Flags K,S gesetzt) und mit dem Schaltbefehl des Aktors verbunden.
Die GA, mit der man den Aktor steuert, sollte natürlich eine GA sein, die exklusiv mit diesem Aktor verbunden ist (natürlich dürfen auch z.B. Wandschalter mit der GA verbunden sein, aber eben keine anderen Aktoren).

Wenn man tatsächlich keinen Status zur Verfügung hat, muss man sämtliche GA mit eintragen, welche einen Befehl an den Aktor senden.
Die Regel mit der 1.GA ist eine knx-Regel, das ist vollkommen unabhängig von openHAB. Du musst nur die Reihenfolge der GA im Aktor ändern, falls Du möchtest, dass der Aktor auf einer anderen GA sendet (Das Stichwort ist Haupt-GA oder sendende GA, wenn ich mich recht erinnere).
Wenn ich Deine Zeile aus Posting #11 nehme, ist 1/0/7 die sendende GA. Wenn Du einen Read Request auf 1/0/23 schickst, wird der Aktor auf 1/0/7 antworten, da es für den Aktor keine Rolle spielt, auf welcher GA der Read Request auf der KO herein kommt. Das kann zu "lustigen" Effekten führen, wenn man die Reihenfolge der GA nicht eingehalten hat, führt dann der Start einer Software, die die Status abfragt, eventuell zu einer kleinen Lightshow, besonders, wenn vielleicht ein Lichtschalter antwortet (jepp, hab ich alles selbst 'ausprobiert'...)

Der Status ist übrigens auch noch aus einem anderen Grund wichtig. der Aktor kann auf verschiedene Weisen gesteuert werden:

• direkter Befehl
• direkter Befehl über andere GA (Zentralsteuerung...)
• Zwangssteuerung
• Zeitsteuerung im Aktor (Treppenlicht...)
• Szenen

Nur im ersten und zweiten Fall bekäme openHAB den Schaltvorgang mit, und auch nur dann sicher, wenn alle eingetragenen GA auch in openHAB eingetragen sind. Spätestens bei der Szene gibt es keinen zwingenden Zusammenhang zwischen GA-Wert und Zustand des Aktors mehr, er lässt sich also nicht mal über eine Rule zuverlässig bestimmen (Szenen können oftmals per Wandtaster umkonfiguriert werden).

Aus dem gleichen Grund (obige Liste) sollte man den Status auch in allen Wandtastern mit hinterlegen, damit Toggle über mehrere Schalter und im Zusammenspiel mit Zentralfunktionen oder Szenen zuverlässig funktioniert.

[sourex]

Hi,
ich habe das jetzt soweit umgesetzt, danke für die Tipps von euch! Der Bus bekommt auch die enstprechende Meldung, OH jedoch leider nicht.

5.PNG

4.PNG

6.PNG
Ich denke ich habe jetzt alles 1zu1 umgesetzt, habe auch mal den Parameter Status senden bei Änderung auf Status senden bei jedem Telegramm senden geändert.
Leider blieb auch das ohne Erfolg. Da der Bus immer fleißig an und aus sendet denke ich es liegt an OH. Aber ich habe die Zeile jetzt 10mal verglichen, das ist so wie ihr es empfohlen habt und ich es auch immer in den Beispielen sehe. Es tut mir leid das ich erneut fragen muss, aber wo ist jetzt wieder der Fehler ?