Ankündigung

**udo1toni** · 15.07.2021, 19:15

Code:

KNXD_OPTS="-e 1.1.249 -E 1.1.250:8 -u /tmp/eib -c -DTRS -b usb:"

Ist 1.1.249 frei?
Mit -E 1.1.250:8 werden 8(!) Adressen ab 1.1.250 reserviert. Das geht aber nicht, denn die höchste Adresse wäre dann 1.1.257
Der Doppelpunkt hinter usb ist meines Wissens falsch.

Warum nutzt Du nicht den ROUTER Modus?

**TomW80** · 15.07.2021, 19:47

Zitat von udo1toni Beitrag anzeigen

Ist 1.1.249 frei?

Ja

Zitat von udo1toni Beitrag anzeigen

Mit -E 1.1.250:8 werden 8(!) Adressen ab 1.1.250 reserviert. Das geht aber nicht, denn die höchste Adresse wäre dann 1.1.257
Der Doppelpunkt hinter usb ist meines Wissens falsch.

Ok, habe die 8 in 2 geändert. Den Doppelpunkt nach usb hab ich auch entfernt, obwohl ich der Meinung bin dass dieser dort hingehört.

# If you have KNX hardware on a serial port or USB, add the appropriate
# "-b TYPE:…" option. In this case, you probably want to set up a multicast
# server, not a client (i.e. use "-D -T -R -S", not "-b ip:").
# DO NOT use both.

Zitat von udo1toni Beitrag anzeigen

Warum nutzt Du nicht den ROUTER Modus?

Dann erhalte ich folgenden Fehler, und das KNX-Gateway geht nicht Online.

2021-07-15 20:39:36.505 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
tuwien.auto.calimero.KNXIllegalArgumentException: non-valid routing multicast /192.168.xxx.xx
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.<ini t>(KNXnetIPRouting.java:162) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.<ini t>(KNXnetIPRouting.java:145) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.g etConnection(IPClient.java:122) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.c reateKNXNetworkLinkIP(IPClient.java:93) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.e stablishConnection(IPClient.java:80) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKN XClient.connect(AbstractKNXClient.java:178) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.jav a:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.run(ScheduledThreadPoolExecutor .java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

Leider hat das alles nichts geholfen, das Problem besteht nach wie vor.

**udo1toni** · 15.07.2021, 20:02

Also, der ROUTER Mode kannst Du natürlich erst dann aktivieren, wenn das Problem mit knxd gelöst ist.

Der Doppelpunkt wird bei -b ip: gebraucht, weil hinter dem Doppelpunkt dann die IP der Schnittstelle steht.

**TomW80** · 15.07.2021, 20:03

Zitat von udo1toni Beitrag anzeigen

Also, der ROUTER Mode kannst Du natürlich erst dann aktivieren, wenn das Problem mit knxd gelöst ist.

Deine Anmerkungen zu knxd habe ich ja umgesetzt und dann den Router Mode versucht zu aktivieren.

**udo1toni** · 15.07.2021, 21:06

Wie sieht es denn in journalctl aus? wird dort immer noch der Timeout angezeigt?

Es wäre auch möglich, dass die BJ 6186 USB nicht mit usb eingebunden werden kann (ich kenne die Schnittstelle nicht), jedenfalls ist sie in der udev Rule nicht gelistet, womit die Schnittstelle eventuell gar nicht angesprochen wird. Eventuell könnte der Zugriff auch mit tpuarts funktionieren.

Was den ROUTER Modus betrifft, so darfst Du die Interface IP nicht setzen, denn im Router Modus wird die Multicast Adresse verwendet (224.0.23.12, wenn nicht gezielt bei allen Teilnehmern anders konfiguriert - was man tunlichst unterlassen sollte, wenn dies nicht unbedingt notwendig ist)

**Tru** · 16.07.2021, 07:21

Zitat von udo1toni Beitrag anzeigen

Der Doppelpunkt hinter usb ist meines Wissens falsch.

Diese Aussage ist meines Wissens falsch, hinter dem Doppelpunkt kommt dann optional die Adresse der USB Schnittstelle.

Vielleicht besteht hier eines der üblichen Probleme mit USB Schnittstellen, welche technisch bedingt mit knxd nicht richtig zum Laufen gebracht werden können. Die SuFu wird unzähliche Beiträge dazu liefern. Vor allem Makki hat eine sehr pointierte Meinung dazu.

**udo1toni** · 17.07.2021, 00:55

Zitat von Tru Beitrag anzeigen

hinter dem Doppelpunkt kommt dann optional die Adresse der USB Schnittstelle.

Das ist halt leider nicht wirklich dokumentiert. Ich habe Konfigurationszeilen mit und ohne Doppelpunkt gesehen. Jedoch, wenn man keinen Parameter angibt, erscheint es logisch, auch kein Trennzeichen anzugeben

**Tru** · 17.07.2021, 10:57

Zitat von udo1toni Beitrag anzeigen

Das ist halt leider nicht wirklich dokumentiert.

Mir reicht was "knxd --help" oder "knxd --usage" zurückgeben:

Code:

-b, --layer2=driver:[arg] a Layer-2 driver to use (knxd supports more than
one)

respektive

Code:

 [-b driver:[arg]]

**TomW80** · 18.07.2021, 09:38

Die Verbindung läuft nun stabil.

Ich musste einfach einen anderen USB-Port am Raspi auswählen. Statt USB3 einen USB2-Port.

Warum das so ist weiß ich nicht.

**TomW80** · 27.07.2021, 14:53

Leider läuft die Verbindung nicht stabil.

Jetzt habe ich das Problem, dass nach einer gewissen Zeit die Verbindung beendet wird mit folgender Fehlermeldung:

2021-07-25 19:23:53.881 [ERROR] [net/IP Tunneling 192.168.178.65:3671] - close connection - maximum send attempts
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received
at tuwien.auto.calimero.knxnetip.ConnectionBase.send( ConnectionBase.java:250) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send( KNXnetIPTunnel.java:177) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend( KNXNetworkLinkIP.java:264) ~[?:?]
at tuwien.auto.calimero.link.AbstractLink.send(Abstra ctLink.java:332) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendReq uestWait(KNXNetworkLinkIP.java:243) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendD ata(TransportLayerImpl.java:372) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementClientImpl.sen d(ManagementClientImpl.java:797) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementClientImpl.sen dWait2(ManagementClientImpl.java:824) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementClientImpl.rea dDeviceDesc(ManagementClientImpl.java:447) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementProceduresImpl .isAddressOccupied(ManagementProceduresImpl.java:3 10) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKN XClient.isReachable(AbstractKNXClient.java:342) ~[?:?]
at org.openhab.binding.knx.internal.handler.AbstractK NXThingHandler.pollDeviceStatus(AbstractKNXThingHa ndler.java:148) ~[?:?]
at org.openhab.binding.knx.internal.handler.AbstractK NXThingHandler.lambda$1(AbstractKNXThingHandler.ja va:188) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.cal l(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(Future Task.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.run(ScheduledThreadPoolExecutor .java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

knxd hat folgendes protokolliert:

Jul 25 19:23:39 openhabian knxd[1623]: F00000108: [23:C.usb] Send while buffer not empty
Jul 25 19:23:39 openhabian knxd[1623]: F00000105: [20:C.usb] Link down, terminating
Jul 25 19:23:39 openhabian knxd[1623]: E00000035: [23:C.usb] SendError 10bd720 status 3
Jul 25 19:23:39 openhabian systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Jul 25 19:23:39 openhabian systemd[1]: knxd.service: Failed with result 'exit-code'.
Jul 25 19:23:49 openhabian systemd[1]: knxd.service: Service RestartSec=10s expired, scheduling restart.
Jul 25 19:23:49 openhabian systemd[1]: knxd.service: Scheduled restart job, restart counter is at 3.
Jul 25 19:23:49 openhabian systemd[1]: Stopped KNX Daemon.
Jul 25 19:23:49 openhabian systemd[1]: Starting KNX Daemon...
Jul 25 19:23:49 openhabian systemd[1]: Started KNX Daemon.

Wo liegt hier das Problem? bei openhab oder knxd?

Daraufhin wollte ich das KNX-Gateway auf den Router Mode umstellen, da habe ich aber das Problem dass die KNX-Devices immer als Offline angezeigt werden. Wenn ich die KNX-Adresse entferne werden mir diese zwar als Online angezeigt, aber ich kann dann nichts mehr schalten.

So sieht mein KNX-Gateway und ein KNX-Device aus:

Code:

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

Code:

UID: knx:device:dff364ac3d
label: OG_EZ_RTR
thingTypeUID: knx:device
configuration:
pingInterval: 300
address: 1.1.1
readInterval: 0
fetch: false
bridgeUID: knx:ip:f8a910f094
location: Raumtemperaturregler Esszimmer
channels:
- id: RTR_X_Temp
channelTypeUID: knx:number
label: EZ Temperatur
description: ""
configuration:
ga: 3/1/5
- id: RTR_W_Temp
channelTypeUID: knx:number
label: EZ Solltemperatur
description: ""
configuration:
ga: 3/2/5
- id: RTR_U_Temp
channelTypeUID: knx:number
label: EZ Ventilstellung
description: ""
configuration:
ga: 3/3/5

Warum gehen die KNX-Devices nicht mehr Online?

**udo1toni** · 27.07.2021, 20:06

Wie oben erwähnt, kann der ROUTER Modus (genau wie der TUNNEL Modus) dir nicht helfen, wenn das Interface offline ist - ob nun weil das Interface nicht funktioniert, oder weil knxd nicht funktioniert.
knxd meldet im log ein Link down mit anschließendem Restart des Daemon.
Du musst das Problem mit der Schnittstelle lösen, bevor Du Dich mit der Anbindung von openHAB beschäftigst.

Ankündigung

Probleme mit KNX-Verbindung über knxd

Probleme mit KNX-Verbindung über knxd

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar