Empfang von KNXD ins OH3 klappt, aber keinerlei Senden von Datagrammen an den KNXD

[jvell]

002226.jpg
Hallo zusammen,
ich versuche mein altes Powernet-System aus 1997 (!) mit moderner Technik aufzurüsten. Daher OH3.2 auf Raspi 4 geladen und an die USB-Verbindung zum Bus gekoppelt. KNXD läuft prächtig! Senden und Empfangen via KNXTool klappt perfekt.
Konfigurierte Events kommen auch im Openhab an, wenn ich im Powernet z.B. Tasten betätige, die ich entsprechend konfiguriert habe.
Aber auch nach Tagen des Foren-Lesens und Forschens bekomme ich keinen Event in die Gegenrichtung an KNX gesendet. Ich habe es mit Things/Items/Channels und Gruppenadressen sowie Hardware-Adressen auf dem KNX versucht. Das KNX-Tool kann es, aber Openhab schickt nichts raus.
Gibt es da irgendwo einen "Read-Only"-Schalter oder so etwas?
Konfig wie folgt:
Thing:
UID: knx:device:7d04132219:e0a76d93da
label: Dimm-Aktor Chefbüro
thingTypeUID: knx:device
configuration:
pingInterval: 600
address: 0.0.26
readInterval: 0
fetch: false
bridgeUID: knx:ip:7d04132219
location: Keller
channels:
- id: Chefbuero
channelTypeUID: knx:switch-control
label: Chefbüro Licht schalten
description: ""
configuration:
ga: 1/2/9

Gateway:
UID: knx:ip:7d04132219
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
useNAT: false
readRetriesLimit: 3
ipAddress: 224.0.23.12
autoReconnectPeriod: 60
localIp: 10.4.36.108
localSourceAddr: 0.0.230
readingPause: 50
type: ROUTER
portNumber: 6720
responseTimeout: 10

und das Log aus OpenHAB, wo man die ankommenden Events sieht, aber auch, dass scheinbar nichts rausgeschickt wird als Bild anbei.
Hoffe ihr habt eine gute Idee - mir gehen sie langsam aus.

Vielen Dank!

[udo1toni]

Wäre besser, Du hättest das yaml als Code markiert und beim Einfügen in den Editor auf Quellecode umgeschaltet. Die Indentations sind essenzieller Bestandteil der Definition...

Du hast als channelType switch-control gewählt. Das bedeutet, openHAB übernimmt virtuell die Rolle eines knx Aktors. Ich denke, Du willst eher einen knx-Aktor von openHAB aus steuern (das wäre der Normalfall). Du musst also als ChannelType switch auswählen.

Gibt es einen besonderen Grund, warum Du den Port auf 6720 gesetzt hast? Nicht, dass es stören würde, es ist nur ungewöhnlich...

[jvell]

Events vom KNXD empfangen: Hier die neue Konfig hoffentlich mit richtiger Formatierung. Leider hat die Änderung nicht geholfen. Effekt immer noch identisch.

Anbei nochmal zwei Reaktionen von OH3.2 beim Betätigen des Analyse-Buttons auf dem Item und das zweite beim einem Event vom KNXD. Offensichtlich klappt der Empfang der KNX-Events und auch das Item erzeugt etwas, aber leider reden die beiden nicht miteinander.
Analyse_Button_on_Item.jpg Aus_ein_Aus-Schaltsequenz.jpg
Vom "Analyse-Kommando" aus OH3 kommt leider beim KNXD nichts an.

UID: knx:device:7d04132219:e0a76d93da
label: Dimm-Aktor Chefbüro
thingTypeUID: knx:device
configuration:
pingInterval: 600
address: 0.0.26
readInterval: 0
fetch: false
bridgeUID: knx:ip:7d04132219
location: Keller
channels:
- id: Chefbuero_Licht_Schalten
channelTypeUID: knx:switch
label: Chefbüro Licht schalten
description: ""
configuration:
ga: 1/2/9

Den Port hab ich im Forum gefunden. Der Standard-Port funktionierte nicht und mit diesem hier bekam ich die Kommunikation sofort hin. Könnten die unterschiedlichen Ports mit der Funktionalität Gateway/Tunnel zusammenhängen?
Im Tunnel-Mode bekomme ich keine Verbindung zum Bus.
Vielen Dank!
Schönes Wochenende!

[udo1toni]

Nein, es ist so, dass knxd nur passend konfiguriert werden muss. Kann sein, dass knxd default auf Port 6720 läuft, aber man kann das definitiv anders konfigurieren. Ebenso kann man einstellen, ob knxd im Router-Modus läuft und/oder im Tunnel-Modus, das geht alles an der gleichen Stelle, an der man konfiguriert, über welche Schnittstelle knxd mit dem Bus kommuniziert.

Was meinst Du mit dem "Analyse-Kommando"? So etwas gibt es gar nicht.

[jvell]

Hallo Udo1toni,
ich hab den Port jetzt mal explizit im Startkommando im /etc/default/knxd eingetragen.

KNXD_OPTIONS="--eibaddr=0.0.230 --client-addrs=0.0.231:8 -d -D -T -R -S --Server=224.0.23.12:3671 -i --listen-local=/tmp/knx -b usb:"

Ich konnte danach jetzt auch OH3 zum Tunnel-Mode überreden, aber der Effekt bleibt der gleiche: die Events vom KNX kommen im OH3 an aber ich kann von OH3 nichts rausschicken.
Analyze_Button.jpg
Mit Analyze meine ich diesen Testswitch an verschiedenen Stellen im System. Damit löse ich auch wie oben beschrieben events im OH passend aus, nur werden die nicht an knx übertragen. Da scheint mir noch der letzte Schritt der Verbindung zwischen den Systemen zu fehlen.
Vielen Dank für deine geduldigen Nachrichten! :-) Ich fürchte, mir fehlt irgendwo noch eine Trivialität zum Glück.

[jvell]

Erfolgsmeldung! Und jetzt hier auch noch die Beschreibung, was ich falsch gemacht habe, auf dass das auch noch anderen helfen möge:
Dieser Effekt rührt daher, dass ich als USB-Schnittstelle ein Powernet-Element 6920 (simpler Buskoppler) mit der internen Adresse 0.0.13 verwendet habe.
Wie oben angegeben habe ich aber --eibaddr=0.0.230 im KNXD- Aufruf angegeben, da ich meinte es wäre die erste freie Adresse gemeint. Nein! Es ist die des USB-Adapter-Kopplers im Eib-System. Wenn die nicht stimmt, dann sendet OH3 einfach kommentarlos nichts, bekommt aber alle ansonsten konfigurierten Events brav mit.
Die Falle ist: Nehme ich knxtools zum Senden, so wird sauber rausgesendet mit der Absende-Adresse 0.0.13(!!) Und man denkt sich nichts böses...
Vorsicht Falle!

Vielen Dank Udo1toni für deine Hilfe! Wichtig war noch die Geschichte mit dem switch-Control. Also Doppelfehler - wie immer :-)

[udo1toni]

Prima, dass Du es selbst rausgefunden hast.
Was das "Analyze" betrifft: Das ist keine Beschriftung des Schalters sondern ein Link, mit dem Du in der Auswertung für dieses Item landest.
Du kannst Dir damit den Statusverlauf über die Zeit anschauen,

[DMN]

Hallo Zusammen,
ich beschäftige mich mit dem gleichen Thema wie jvell.
Ich verwende openHAB 3.4.
Zur Anbindung an Powernet verwende ich die Busch Jäger Komponenten 6920U+6133 USB.

Bei der Konfiguration von KNXD stellen sich mir jedoch noch ein paar Fragen.
KNXD_OPTIONS="--eibaddr=0.0.230 --client-addrs=0.0.231:8 -d -D -T -R -S --Server=224.0.23.12:3671 -i --listen-local=/tmp/knx -b usb:"

0.0.230 – sollte dann im Beispiel wohl die Adresse des USB Netzankopplers sein
0.0.231:8 – welche Adresse ist das?
224.0.23.12:3671 welche Adresse ist das?

Vielen Dank

[jvell]

Hallo DMN,

KNXD_OPTS="-e 0.0.19 -E 0.0.231:8 -DTR -S 224.0.23.12:3671 -b usb:"

Mit der Einstellung läufts bei mir seitdem ohne Probleme. Und ja 0.0.19 ist die Adresse des 6920U.
Die anderen sind wohl "hartverdrahtet" in der Software.
Gruss
Jvell

[udo1toni]

KNXD_OPTIONS="--eibaddr=0.0.230 --client-addrs=0.0.231:8 -d -D -T -R -S --Server=224.0.23.12:[B]3671[/B] -i --listen-local=/tmp/knx -b usb:"​

Siehe offizielles Wiki: https://github.com/knxd/knxd/wiki, https://github.com/knxd/knxd/wiki/Co...ine-parameters

-e oder --eibaddr ist die Adresse, unter der knxd gegenüber dem knx Bus auftritt.
-E oder --client-addrs ist der Adressblock für die Clients, hier also die Adressen 0.0.231 bis 0.0.238

Alle aufgeführten Adressen müssen frei sein, sie dürfen z.B. auch nicht von einem USB Interface oder knx/IP Gateway verwendet werden (auch nicht als sekundäre Adressen). Wenn es dennoch funktioniert, so ist das eigentlich ein Fehler denn knxd tritt dem Bus gegenüber korrekter Weise als separates Gerät auf. Dass es dennoch funktioniert, hängt vermutlich daran, dass das Interface selbst überhaupt keinen Datenverkehr hat, weder ankommend noch abgehend. Es wäre aber interessant zu sehen, was passiert, wenn man versucht, das USB Interface über eine knxd-Verbindung mit einer neuen Programmierung zu versehen denn dann kommt es zu einer Adresskollision.

-D oder --Discovery -> Discovery aktivieren (mutmaßlich Avahi oder Zeroconf - knxd kann im Netz automatisch gefunden werden)
-T oder --Tunneling -> Tunneling über Unicast aktivieren (z.B. ETS nutzt den Tunnel Mode)
-R oder --Routing -> Routing über Multicast aktivieren
-S oder --Server -> Multicast Server aktivieren (Default 224.0.23.12:3671)
-i oder --listen-tcp -> Port für Client-Verbindungen öffnen (tcp/udp) (Default 6720)
-u oder --listen-local -> Unix-Socket öffnen (Default /run/knx)
-b oder --layer2 -> das physische Interface zum knx bus.
-d oder --daemon -> knxd nach dem Start zum Daemon machen (gewöhnlich wird das ohnehin passieren, weil knxd über systemd gestartet wird)

Bei ausgeschriebener Option kann für einen Parameter ein Gleichheitszeichen folgen, alternativ auch ein Leerzeichen.
Bei -b usb: sucht sich knxd unter allen zur Verfügung stehenden usb Devices eines heraus, welches als knx-Device auftritt. Man könnte hier auch genau spezifizieren, welches Device verwendet werden soll.

POSIX Parameter ohne Argument können zusammengezogen werden; -D -T -R -S ist das gleiche wie -DTRS