Neues YouTube-Video: Visualisierung im Devices-Adapter

[Urs]

Hallo,

Seit längerem setze ich Openknx ein. Das funktionierte auch sehr stabil in den 0.x.x Versionen. Vor kurzem hab ich das Update auf V 1.0.5 (glaub ich zumindest) und inzwischen auf V1.1.10 durchgeführt.
Seitdem steht der Adapter immer wieder auf rot (Verbunden mit Host und Verbunden mit Gerät oder Dienst sind Rot, Lebenszeichen ist grün). Nach einem Neustart des Adapters läuft wieder alles eine Zeit lang.

Inzwischen hab ich ein hier im Forum gefundenen Script so angepasst dass es den Adapter automatisch neu startet wenn er keine Verbindung hat. Dazu setzt es entsprechende Meldungen an Gotify ab. Was ich dabei festgestellt habe: Er verliert immer 2-6 minuten nach der vollen Stunde die Verbindung, momentan grad alle 4 h.

Minimale Sendeverzögerung hab ich von 25ms auf 80, dann auf 150ms erhöht, leider ohne Erfolg (gefühlt sind die Ausfälle seitdem eher öfter, aber das sind keine Fakten, nur ein erstes Gefühl).

Der KNX-IP-Router ist von MDT und über Wireguard mit meinem Heimnetz und sich darin befindlichem IOB verbunden, aber daran ist in letzter Zeit nichts geändert worden, daher und da es vorher ja problemlos lief würde ich das als Fehlerursache ausschliessen.

Die Buslast dümpelt um die 10-15% rum, mit Spitzen von 25%. Um 20 Uhr, ungefähr als der Fehler wieder kam ging es für kurze Zeit auf 40% aber sehr schnell auch wieder runter. Nach 4 Sekunden war die Buslast wieder bei 25 und wenige Sekunden später wieder unter weit unter 20%.

Hier noch das Log mit den Openknx-Meldungen mit dem Fehler inkl Restart:

openknx.0
	2026-05-08 20:03:32.981	info	Found 362 valid KNX objects of 366 objects in this adapter.
openknx.0
	2026-05-08 20:03:32.949	info	Autoread on startup: 350 read requests, 362 DPT configs resolved, estimated ~1m 10s (200ms interval). Write commands may be delayed during this period.
openknx.0
	2026-05-08 20:03:32.932	info	Resolving DPT configs...
openknx.0
	2026-05-08 20:03:32.932	info	Connected! channelID=16 physAddr=1.1.0
openknx.0
	2026-05-08 20:03:30.756	info	Connecting to knx gateway: 10.10.100.10:3671 device name: KNX IP Router with physical adr: 1.1.0 minimum send delay: 150 ms debug level: info
openknx.0
	2026-05-08 20:03:30.729	info	starting. Version 1.1.10 in /opt/iobroker/node_modules/iobroker.openknx, node: v20.20.2, js-controller: 7.1.1
openknx.0
	2026-05-08 20:02:29.631	info	terminating
openknx.0
	2026-05-08 20:02:29.631	info	terminating
openknx.0
	2026-05-08 20:02:29.132	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
openknx.0
	2026-05-08 20:02:29.131	info	terminating
openknx.0
	2026-05-08 20:02:29.131	warn	Error during KNX disconnect: Error: No client socket defined
openknx.0
	2026-05-08 20:02:29.130	info	Got terminate signal TERMINATE_YOURSELF
openknx.0
	2026-05-08 20:02:29.120	info	Reconnect attempt 1/7 in 10s...
openknx.0
	2026-05-08 20:02:29.119	error	Connection lost: 10.10.100.10:3671 Received KNX packet: DISCONNECT_REQUEST, ChannelID:16 Host:10.10.100.10:3671

Was läuft da schief? Mittels script den Adapter immer wieder neu Starten funktioniert zwar, ist aber unter dem Strich halt dennoch nur eine Krücke!

Danke

[Thomas Braun]

@Urs sagte:

node: v20.20.2

Auf nodejs22 bringen. Per

iob nodejs-update

aber daran ist in letzter Zeit nichts geändert worden

Den 'Rest vom Fest' auch auf Stand bringen.

[Urs]

Danke.
Der ganze Rest inkl OS worauf Iob läuft (Proxmox-Container) war bereits bis auf 3 Adapter welche nodejs 22 verlangten, aber gar nicht benutzt wurden geupdated.

Dass ich nodejs nicht hoch gezogen hab, hat den einfachen Grund dass ich unterwegs bin und nur ein Handy und ein Tablett dabei habe. Wer schonmal damit versucht hat in der besch... Linux-Konsole unter Proxmox zu arbeiten ,und vor allem darin sichere, lange Passwörter einzufügen weiss warum...
Naja ich hab es nun trotzdem gemacht. Dabei auch openknx auf die neu verfügbare Version (Laut Changelog verbesserung an der UDP- Verbindung...???) hoch gezogen. In einer viertel Stunde werden wir mehr wissen ob das was gebracht hat oder nicht.

(Btw: Danke an den Verantwortlichen der entschidden hat dass das Update von nodejs nicht mehr per root sondern nur noch per "normalem" iobroker-user möglich ist. Mit Root loggt man sich einmal unter Proxmox ein macht seine Sachen loggt sich aus und gut ist. Mit dem Iob Passwort durfte ich mich da x mal einloggen. Da ich ein sicheres Passwort mit xx Stellen, Gross/Kleinschreibung und Zahlen für all meine Passwörter habe und das Kopieren ohne Physische Tastatur nicht möglich war bzw nicht funktionierte, war das natürlich ganz toll das Passwort x mal Zeichen für Zeichen einzutippen. Naja, wird nicht wieder passieren, das Passwort wird in ein ganz einfaches geändert welches auch ganz einfach für zukünftige geschichten wie diese auf Mobile Geräte einzutippen ist. Danke für die Bevormundung, ganz toller Beitrag zu mehr Sicherheit! Vielleicht wäre es ein besserer Ansatz statt solche Bevormundungen ein simpler Update mit einer simplen Schamtfläche in der Benutzeroberfläche gestartet werden könnte... aber das ist ja nur meine bescheidene Meinung. Sorry ffürs auskotzen, musste jetzt sein...)

Danke und Gruss

[Urs]

Problem immer noch da, siehe 16:05:06:

026-05-10 16:00:00.786 - info: swiss-weather-api.0 (1241) update current hour...
2026-05-10 16:00:40.850 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:00:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:00:40.881 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:00:38 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:00:41.154 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:01:41.303 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:01:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:01:41.331 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:01:39 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:01:41.609 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:02:36.607 - warn: openknx.0 (1294) Could not decode GA 0/0/2 (DPT19.001), raw=[0a051a]. Check DPT configuration in ETS (buffer length mismatch?).
2026-05-10 16:02:36.608 - info: openknx.0 (1294) State value to set for "openknx.0.System.Datum_Uhrzeit.Datum_und_Zeit_senden" has to be type "number" but received type "string"
2026-05-10 16:02:37.915 - warn: fb-checkpresence.0 (1135) checkPresence: getDeviceList: AxiosError timeout of 10000ms exceeded
2026-05-10 16:02:40.793 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:02:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:02:40.822 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:02:39 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:02:41.090 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:03:18.583 - error: netatmo.0 (529) Error: getHomeData error: Operation is forbidden
2026-05-10 16:03:41.339 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:03:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:03:41.371 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:03:39 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:03:41.695 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:04:22.867 - warn: fb-checkpresence.0 (1135) checkDevices: getMeshList: AxiosError timeout of 14000ms exceeded
2026-05-10 16:04:40.921 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:04:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:04:40.949 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:04:39 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:04:41.214 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:05:06.468 - error: openknx.0 (1294) Connection lost: 10.10.100.10:3671 Received KNX packet: DISCONNECT_REQUEST, ChannelID:16 Host:10.10.100.10:3671
2026-05-10 16:05:06.468 - info: openknx.0 (1294) Reconnect attempt 1/7 in 10s...
2026-05-10 16:05:06.470 - info: javascript.0 (411) script.js.Anwenderscripte.Garage.Restart_openknx: openknx Verbindung verloren – Adapter wird für 60s deaktiviert.
2026-05-10 16:05:06.470 - info: javascript.0 (411) script.js.Anwenderscripte.Garage.Restart_openknx: Using setObject on system object system.adapter.openknx.0 can be dangerous (protected instance attributes may be lost)
2026-05-10 16:05:06.473 - info: host.Iobroker-Live "system.adapter.openknx.0" disabled
2026-05-10 16:05:06.475 - info: openknx.0 (1294) Got terminate signal TERMINATE_YOURSELF
2026-05-10 16:05:06.474 - info: host.Iobroker-Live stopInstance system.adapter.openknx.0 (force=false, process=true)
2026-05-10 16:05:06.476 - info: host.Iobroker-Live stopInstance system.adapter.openknx.0 send kill signal
2026-05-10 16:05:06.476 - warn: openknx.0 (1294) Error during KNX disconnect: Error: No client socket defined
2026-05-10 16:05:06.477 - info: openknx.0 (1294) terminating
2026-05-10 16:05:06.477 - info: openknx.0 (1294) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2026-05-10 16:05:06.976 - info: openknx.0 (1294) terminating
2026-05-10 16:05:06.976 - info: openknx.0 (1294) terminating
2026-05-10 16:05:07.045 - info: host.Iobroker-Live instance system.adapter.openknx.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2026-05-10 16:05:19.578 - warn: fb-checkpresence.0 (1135) checkDevices: getDeviceList: AxiosError timeout of 10000ms exceeded
2026-05-10 16:05:41.330 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:05:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:05:41.359 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:05:39 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:05:41.621 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:06:00.563 - info: admin.1 (349) ==> Connected system.user.ursicin from ::ffff:192.168.1.253
2026-05-10 16:06:06.470 - info: javascript.0 (411) script.js.Anwenderscripte.Garage.Restart_openknx: openknx wird jetzt neu gestartet...
2026-05-10 16:06:06.470 - info: javascript.0 (411) script.js.Anwenderscripte.Garage.Restart_openknx: Using setObject on system object system.adapter.openknx.0 can be dangerous (protected instance attributes may be lost)
2026-05-10 16:06:06.502 - info: host.Iobroker-Live "system.adapter.openknx.0" enabled
2026-05-10 16:06:07.010 - info: host.Iobroker-Live instance system.adapter.openknx.0 in version "1.1.11" started with pid 9944
2026-05-10 16:06:08.054 - info: openknx.0 (9944) Plugin sentry Sentry Plugin disabled for this process because sending of statistic data is disabled for the system
2026-05-10 16:06:08.054 - error: openknx.0 (9944) Plugin sentry Failed to initialize plugin: Sentry Plugin disabled for this process because sending of statistic data is disabled for the system
2026-05-10 16:06:08.178 - info: openknx.0 (9944) starting. Version 1.1.11 in /opt/iobroker/node_modules/iobroker.openknx, node: v22.22.2, js-controller: 7.1.1
2026-05-10 16:06:08.206 - info: openknx.0 (9944) Connecting to knx gateway: 10.10.100.10:3671 device name: KNX IP Router with physical adr: 1.1.0 minimum send delay: 150 ms debug level: info
2026-05-10 16:06:10.359 - info: openknx.0 (9944) Connected! channelID=16 physAddr=1.1.0
2026-05-10 16:06:10.360 - info: openknx.0 (9944) Resolving DPT configs...
2026-05-10 16:06:10.373 - info: openknx.0 (9944) Autoread on startup: 350 read requests, 362 DPT configs resolved, estimated ~1m 10s (200ms interval). Write commands may be delayed during this period.
2026-05-10 16:06:10.405 - info: openknx.0 (9944) Found 362 valid KNX objects of 366 objects in this adapter.
2026-05-10 16:06:40.955 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:06:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:06:40.994 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:06:38 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:06:41.272 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:07:20.640 - info: openknx.0 (9944) Autoread on startup finished: 350 of 350 requests sent
2026-05-10 16:07:41.254 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:07:38 PM" for ebus.0.15.messages.At.lastup because no number
2026-05-10 16:07:41.284 - info: influxdb.0 (433) Do not store value "5/10/2026, 4:07:39 PM" for ebus.0.15.messages.Parameter_level.lastup because no number
2026-05-10 16:07:41.555 - info: ebus.0 (1257) found ebusd update version OK, broadcast.csv: newer version
2026-05-10 16:08:07.916 - warn: fb-checkpresence.0 (1135) checkDevices: getMeshList: AxiosError timeout of 14000ms exceeded

[tombox]

Kannst du die GitHub version testen und ein debug log an tombox2020@gmail.com schicken

[Urs]

Danke für die Antwort.
Hab die Github version installiert, und die speziellen MDT-Einstellungen angepasst, leider keine Besserung. Gestern dann noch die neuste Version 1.1.13 aus dem latest installiert. hat leider auch nichts gebracht. Was ich aber noch nicht ganz verstehe ist das hier:

image.jpeg)
Ich hab jetzt lange in der ETS gesucht, aber das einzige was dem am nächsten kommt ist ein Parameter für die Latenzzeit der Verbindung. Den von WAN (2s) auf Telefon (4s) gestellt. (das ganze läuft 200km weit weg und ist mittels LTE-Router ans Internet angebunden und über Wireguard mit meinem heimischen IOB verbunden). Dazu die Verbindung von TCP auf UDP umgestellt und die FW vom KNX-Router (MDT SCN IP 100) aktualisiert. Leider auch alles ohne Erfolg. ETS gestern auch noch auf die Version 6.4.1 hoch gezogen aber dennoch keine der im Adapter erwähnten Einstellungen vorhanden. Sind die erwähnten Einstellungen da nicht mehr vorhanden oder doch irgendwo sehr gut versteckt wo ich sie noch nicht gefunden habe?

Meine Einstellungen im IOB:

Log per mail folgt. Der Fehler erfolgt inzwischen auch immer noch alle 4h, hat aber geändert von 2-3 Minuten nach Mitternacht auf 2-3 Minuten nach 2 Uhr und dann alle 4h...wieso das ändert hab ich noch nicht herausgefunden, denn Heute scheint es wieder bei 0 Uhr zu sein...also gerade eben...

Irgend welche weiteren Ideen?

PS: _Nur so am Rande erwähnt: Die Farben gewisser Auswahl-Menues usw. sind mit weisser Schrift auf fast weissem Hintergrund etwas unglücklich im Darkmode, aber das ist auch bei anderen Adaptern so...

Danke und Gruss

[tombox]

@Urs Ja da hilft nur debug log via mail

Aber„Disconnect alle 4 h" = klassisches LTE-NAT-Timeout
ioBroker zu Hause → WireGuard → LTE-Router → MDT. Auf dem Pfad sitzen mindestens zwei NAT-Geräte (LTE-Router + Provider-CGNAT). Provider-CGNAT bei UDP läuft typischerweise auf 3–4 h Aging

UDP überlebt NAT-Aging schlechter als TCP. Wenn dein MDT KNX Secure unterstützt, schalte zurück auf TCP

Setze in der WireGuard-Peer-Config (auf der Seite, die hinter LTE-NAT sitzt) folgendes:
PersistentKeepalive = 25
Das hält den WireGuard-UDP-Tunnel alle 25 s aktiv und damit auch die NAT-Mappings auf dem ganzen Pfad warm. Default ist 0 = aus. Das ist die typische Standard-Empfehlung für „WG hinter NAT".

Ohne PersistentKeepalive friert der WG-Tunnel ein, sobald nichts mehr durchkommt — KNX-Heartbeat (30 s) reicht zwar theoretisch, aber wenn auf irgendeinem NAT-Hop ein Paket verworfen wird, kommt die Antwort nicht zurück und du läufst in den Heartbeat-Timeout.

[Urs]

@tombox Vielen Dank für die Hilfe.

Mail ist unterwegs, hoffe es kommt durch. Das Emailprogramm motzte dass es allenfalls zu gross sei, hat es aber verschickt. Melde dich wenn es hängen geblieben ist, dann schicke ich es in kleineren Teilen...

@tombox sagte:

UDP überlebt NAT-Aging schlechter als TCP. Wenn dein MDT KNX Secure unterstützt, schalte zurück auf TCP

Eigentlich müsste es KNX Secure können, hab ich mich aber noch nicht wirklich damit befasst. Komisch ist das es nach dem FW-Upgrade angeblich automatisch mit TCP verbunden hat, obwohl das so wie ich verstehe gar nicht möglich sein dürfte da ich KNX secure gar nicht aktiviert habe...Aber wie geschrieben, das Thema ist für mich komplettes Neuland. Schaue ich wenn ich dazu komme morgen mal an...

@tombox sagte:

Setze in der WireGuard-Peer-Config (auf der Seite, die hinter LTE-NAT sitzt) folgendes:
PersistentKeepalive = 25

Muss ich Morgen noch mal kontrollieren, wenn ich mich aber nicht täusche steht der schon auf 25s (wie all meine WG-Verbindungen).
Aber ist es denn nicht so dass die Anzahl der Meldungen schon genug sein sollte um die Verbindung aufrecht zu erhalten? Etliche Meldungen vom KNX werden da im Sekunden-Takt verschickt. Aber vielleicht verstehe ich da auch was falsch.

Was für mich auffällig ist, ist dass es mit den 0.x-Versionen die Abbrüche nicht gab. Seitdem hab ich am WG-Tunnel, KNX-Projekt und Menge der übermittelten Daten nichts bewusst verändert...was jetzt nicht heisst dass es da kein Verbesserungspotential seitens meines Systems gibt, im Gegenteil. Und ist auch kein Vorwurf an dich...soll nur als Info dienen um das Problem allenfalls weiter eingrenzen zu können...

Vielen Dank und Gruss