KNX Gateway geht immer wieder offline und online

[Jbreuer]

Guten Tag,

ich habe im Sommer dieses Jahres basierend auf einem Raspberry 4 Openhab 3.1 komplett neu installiert. Die ersten Monate gab es scheinbar auch keine Probleme, bis ich im Frontail Log View immer wieder ein Problem mit den KNX Gateway gesehen habe. Es geht immer wieder offline und online. Die geschieht inzwischen bis zu 200 mal innerhalb von 24 Std. Ein Upgrade auf die 3.2.0 M3 hat leider auch keine Änderung gebracht.

Es handelt sich um ein Weinzierl KNX IP Interface 730.

Code: Alles auswählen

UID: knx:ip:84322947f0
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 5
  ipAddress: 192.168.0.64
  autoReconnectPeriod: 60
  localIp: 192.168.0.61
  localSourceAddr: 0.0.0
  readingPause: 50
  type: TUNNEL
  portNumber: 3671
  responseTimeout: 20

]

Code: Alles auswählen

==> /var/log/openhab/openhab.log <==
2021-11-10 10:03:47.335 [ERROR] [calimero.link.192.168.0.64:3671     ] - send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: send attempt on closed connection
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:215) ~[?:?]
	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(AbstractLink.java:332) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:243) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:627) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.disconnectIndicate(TransportLayerImpl.java:608) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.disconnect(TransportLayerImpl.java:342) ~[?:?]
	at tuwien.auto.calimero.mgmt.Destination.destroy(Destination.java:371) ~[?:?]
	at tuwien.auto.calimero.mgmt.Destination.close(Destination.java:383) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.$closeResource(ManagementProceduresImpl.java:238) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:311) ~[?:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:342) ~[?:?]
	at org.openhab.binding.knx.internal.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:148) ~[?:?]
	at org.openhab.binding.knx.internal.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:188) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.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) [?:?]
2021-11-10 10:03:47.390 [ERROR] [NXnet/IP Tunneling 192.168.0.64:3671] - establishing connection failed, null
2021-11-10 10:03:47.444 [INFO ] [ab.core.model.script.KNX-Verbindung ] - Anzahl: 237
==> /var/log/openhab/events.log <==
2021-11-10 10:03:47.369 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:ip:84322947f0' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request
2021-11-10 10:03:47.378 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:device:84322947f0:Stellantrieb_3' changed from OFFLINE to OFFLINE (BRIDGE_OFFLINE)
2021-11-10 10:03:47.388 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:device:84322947f0:Stellantrieb_1' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2021-11-10 10:03:47.389 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:device:84322947f0:Stellantrieb_2_KB' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)

Welche Möglichkeiten bestehen, das Problem einzugrenzen bzw. zu beheben.

Beste Grüße
Jürgen

[udo1toni]

Wie ist der Raspberry am Netz angeschlossen?

[Jbreuer]

Der Raspberry ist direkt per LAN-Kabel an die Fritzbox angeschlossen

[udo1toni]

Hm...

Du könntest spaßeshalber mal die Ports tauschen, an denen Pi und Weinzierl Interface angeschlossen sind.
Hast Du die FRITZ!Box mal neu gestartet?

[Jbreuer]

Ich werde dies mal heute Abend versuchen. Danke

[Jbreuer]

]hat leider nichts gebracht ..

hier noch ein Auszug aus dem Log

==> /var/log/openhab/openhab.log <==
2021-11-13 10:52:27.459 [ERROR] [calimero.link.192.168.0.64:3671 ] - send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: waiting for service ack
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:246) ~[?:?]
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(AbstractLink.java:332) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:243) ~[?:?]
at tuwien.auto.calimero.mgmt.TransportLayerImpl.connect(TransportLayerImpl.java:327) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementClientImpl.send(ManagementClientImpl.java:796) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementClientImpl.sendWait2(ManagementClientImpl.java:824) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementClientImpl.readDeviceDesc(ManagementClientImpl.java:447) ~[?:?]
at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:310) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:342) ~[?:?]
at org.openhab.binding.knx.internal.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:148) ~[?:?]
at org.openhab.binding.knx.internal.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:188) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.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) [?:?]
==> /var/log/openhab/events.log <==
2021-11-13 10:52:27.461 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:ip:84322947f0' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request
2021-11-13 10:52:27.463 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:device:84322947f0:Stellantrieb_1' changed from UNKNOWN to OFFLINE (BRIDGE_OFFLINE)
2021-11-13 10:52:27.464 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:device:84322947f0:Stellantrieb_3' changed from UNKNOWN to OFFLINE (BRIDGE_OFFLINE)

[Jbreuer]

Inzwischen bin ich etwas weiter gekommen:
Folgendes wurde angepasst:
bei den meisten Things / Aktoren "readInterval: 0 " gesetzt - hat leider nicht Anzahl der Gateway offline/online Situationen reduziert. Nach spätestens 3-4 Tagen war die Verbindung endgültig weg.

Die Fensterkontakte hatten für die Abfrage über ALEXA das Metadatum "ContactSensor.detectionState und die
Heizungsthermostate die Metadaten "EndPointThermostat" , "Temperature.Sensor-Temperature" etc. Diese Metadaten wurden entfernt.

Nun gibt es nur noch 2-3 mal die offline/online Situation pro Tag. Nicht schlecht, solange es so bleibt.

Gruß
Jürgen

[udo1toni]

Also, mal ganz grundsätzlich... readInterval wird IMMER auf 0 gesetzt! fetch wird IMMER auf false gesetzt. pingInterval wird auf einen sinnvollen Wert gesetzt, z.B. 600 Sekunden. Die Pings belasten den knx Bus, also wird man sich bemühen, dies nur selten zu tun.

Zur Erklärung:
readInterval löst alle x Sekunden einen ReadRequest pro lesbar gesetzter GA (<) des Things aus. Diese Funktion ist ausschließlich sinnvoll, wenn man ein Gerät verwendet, welches weder zyklisch noch bei Wertänderung senden kann, sondern auf die Abfrage von außen angewiesen ist. Es gibt inzwischen nur noch wenige Geräte m Markt, auf die dies zutrifft. Gewöhnlich fragt openHAB beim Systemstart alle Status vom Bus ab und speichert diese. Bei Wertänderungen senden die Geräte des knx Bus ihren Status und openHAB notiert sich den neuen Status. Es gibt also keinen Grund, den Status ständig neu zu übertragen.

fetch ist bisher nur ein Gimmick. Man kann - passende Geräte vorausgesetzt - mehr über das Gerät erfahren, z.B. Hersteller, ROM-Maske usw. Diese Informationen sind interessant, aber für den Betrieb von openHAB vollkommen irrelevant. Also testweise an, ja, klar, aber im regulären Betrieb, unbedingt aus!

pingInterval ist für ONLINE/OFFLINE-Status verantwortlich. Es funktioniert logischerweise nur, wenn eine korrekte physikalische Adresse gesetzt ist, denn diese wird angefragt. Auch das verursacht Buslast, ist aber hinnehmbar, solange es nicht zu häufig passiert. Ein Thing, dessen pingInterval auf 0 steht (oder bei dem keine physikalische Adresse hinterlegt ist) wird immer ONLINE angezeigt (es sei denn, das Gateway selbst ist OFFLINE).