KNX - Probleme beim Schalten gemäß Timer

Begonnen von Bronze, 07 Dezember 2025, 16:58:00

Vorheriges Thema - Nächstes Thema

Bronze

Hallo,
wie aus einem anderen Thread bekannt habe ich Schwierigkeiten mit dem KNX-Gateway beim Schalten gemäß Timer.
Das gilt nun auch für Licht.

Diese Logik
([[OUT_Sonnenstand:ss]-[OUT_Sonnenstand:sr]])
(set Licht_TH_Stufen on; msg push @rr_ Stufenbeleuchtung an.)
DOELSE (set Licht_TH_Stufen off; msg push @rr_ Stufenbeleuchtung aus.)

hätte um 16:15:24 Uhr die Stufenbeleuchtung einschalten sollen

und führt zu folgendem Log:
2025.12.07 16:15:24 5: myKNXGW [KNXIO_Write 587]: started
2025.12.07 16:15:24 5: myKNXGW [KNXIO_Write 594]: sending w0230001
2025.12.07 16:15:24 5: myKNXGW [KNXIO_Write 615]: data=81 size=1 acpi=80 src=15.15.242 dst=2/3/0
2025.12.07 16:15:24 5: DevIo_SimpleWrite myKNXGW: 061004200015046e00001100bce0fff21300010081
2025.12.07 16:15:24 5: myKNXGW [KNXIO_Write2 702]: Mode=H buf=061004200015046e00001100bce0fff21300010081 rc=0
2025.12.07 16:15:24 3: msg rr_:  STATUS=OK PRIORITY=0 TITLE='' MSG='Stufenbeleuchtung an.'
2025.12.07 16:15:25 3: myKNXGW [KNXIO_TunnelRequestTO 1360]: timeout - attempt resend
2025.12.07 16:15:25 5: DevIo_SimpleWrite myKNXGW: 061004200015046e00001100bce0fff21300010081
2025.12.07 16:15:27 3: myKNXGW [KNXIO_TunnelRequestTO 1368]: timeout - sending disconnect request
2025.12.07 16:15:27 5: DevIo_SimpleWrite myKNXGW: 0610020900106e000801000000000000
2025.12.07 16:15:27 5: myKNXGW [KNXIO_Read 307]: buf=0610020a00086e21
2025.12.07 16:15:27 4: myKNXGW [KNXIO_ReadH 499]: DisconnectResponse received - sending connrequest
2025.12.07 16:15:27 5: DevIo_SimpleWrite myKNXGW: 06100205001a0801000000000000080100000000000004040200

Die Message wird gesendet, dass Stufenbeleuchtung eingeschaltet sei, aber sie wurde es nicht.

Hier das Listing des Devices:
Internals:
   DEF        2/3/0:dpt1:EinAus 2/3/1:dpt1:Status:listenonly
   FUUID      6773b92e-f33f-1fbc-4c1b-21287d53577fd1a6
   FVERSION   10_KNX.pm:v5.1.0-s30443/2025-10-24
   IODev      myKNXGW
   LASTInputDev myKNXGW
   MSGCNT     2
   NAME       Licht_TH_Stufen
   NR         325
   STATE      off
   TYPE       KNX
   eventCount 6
   model      dpt1
   myKNXGW_MSGCNT 2
   myKNXGW_TIME 2025-12-07 10:40:13
   GADDETAILS:
     EinAus:
       CODE       02300
       MODEL      dpt1
       NO         1
       OPTION     
       RDNAMEGET  EinAus-get
       RDNAMESET  EinAus-set
       SETLIST    :on,off,toggle
     Status:
       CODE       02301
       MODEL      dpt1
       NO         2
       OPTION     listenonly
       RDNAMEGET  Status-get
       RDNAMESET  Status-set
       SETLIST    :on,off,toggle
   GADTABLE:
     02300      EinAus
     02301      Status
   Helper:
   READINGS:
     2025-12-07 10:40:13   EinAus-get      off
     2025-12-07 16:15:24   EinAus-set      on
     2025-12-05 20:09:30   IODev           myKNXGW
     2025-12-07 10:40:13   Status-get      off
     2025-12-07 16:15:24   last-sender     fhem
     2025-12-07 16:15:24   state           on
Attributes:
   devStateIcon off:li_wht_off:on on:li_wht_on:off
   room       KNX->Licht
   stateFormat Status-get
   webCmd     :


Generell fällt mir auf, dass die Statusanzeige der über KNX steuerbaren Leuchten nicht funktioniert, wenn das Licht manuell geschaltet wurde.
Schaltet man also manuell über einen Schalter ein, zeigt das FHEM nicht an, nur wenn man manuell über FHEM schaltet.
Das war früher, bevor meine ganzen Schwierigkeiten mit KNX in FHEM begannen, anders und zuverlässig.

Was könnte bitte die Ursache sein?

VG

erwin

#1
Das Problem liegt in der Kommunikation zwischen FHEM und dem KNX-GW.
...und zwar sowohl in Sende- als auch in Empfangsrichtung, das zeigt das Log:
2025.12.07 16:15:24 5: DevIo_SimpleWrite myKNXGW: 061004200015046e00001100bce0fff21300010081
2025.12.07 16:15:24 5: myKNXGW [KNXIO_Write2 702]: Mode=H buf=061004200015046e00001100bce0fff21300010081 rc=0
2025.12.07 16:15:24 3: msg rr_:  STATUS=OK PRIORITY=0 TITLE='' MSG='Stufenbeleuchtung an.'
2025.12.07 16:15:25 3: myKNXGW [KNXIO_TunnelRequestTO 1360]: timeout - attempt resend #Timeout beim Senden
2025.12.07 16:15:25 5: DevIo_SimpleWrite myKNXGW: 061004200015046e00001100bce0fff21300010081
2025.12.07 16:15:27 3: myKNXGW [KNXIO_TunnelRequestTO 1368]: timeout - sending disconnect request
2025.12.07 16:15:27 5: DevIo_SimpleWrite myKNXGW: 0610020900106e000801000000000000
2025.12.07 16:15:27 5: myKNXGW [KNXIO_Read 307]: buf=0610020a00086e21
2025.12.07 16:15:27 4: myKNXGW [KNXIO_ReadH 499]: DisconnectResponse received - sending connrequest

Die letzte empfangene msg von Gateway war:
2025-12-07 10:40:13   Status-get      off !!! Timestamp

ZitatDas war früher, bevor meine ganzen Schwierigkeiten mit KNX in FHEM begannen, anders und zuverlässig.
Was könnte bitte die Ursache sein?
Was war früher anders ? - evtl. die KNXIO definition passt nicht zum Gateway, oder ein anderes Modul blockiert FHEM für > 1sec?
Was ist das für ein Gateway, und bitte auch ein list vom KNXIO - device

Und versuche bei nächsten Test die set-cmds NICHT via Doif,at,notify,... sondern direkt aus dem KNX-device

Unabhängig von dem Problem würde ich die MSG push nicht in time-logik unterbringen sondern als notify auf das KNX-device:
define xxx_nf notify Licht_TH_Stufen:Status-get:.* msg push ... $EVENT
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Bronze

#2
Das Gateway ist ein MDT IP-Interface SCN-IP 000.02.
Hier das Listing:
Internals:
   DEF        H 192.168.178.50:3671 15.15.242
   DeviceName 192.168.178.50:3671
   FD         16
   FUUID      676c32c4-f33f-1fbc-f735-65b7a637e711e79d
   FVERSION   00_KNXIO.pm:0.304420/2025-10-24
   MSGCNT     664
   MSGTIME    2025-12-08 17:24:36
   NAME       myKNXGW
   NR         42
   PhyAddr    15.15.242
   STATE      connected
   TYPE       KNXIO
   devioLoglevel 4
   devioNoSTATE 1
   eventCount 16
   model      H
   KNXIOhelper:
     CCID       24
     CNTRTO     0
     SEQUENCECNTR 0
     SEQUENCECNTR_W 0
     nextWrite  1765206905.07501
     startdone  1
     FIFO:
     FIFOW:
   READINGS:
     2025-12-08 17:07:19   state           connected
Attributes:
   event-on-change-reading .*
   room       KNX
   verbose    5

Gegenüber früher hat sich geändert, dass FHEM früher auf einem Notebook mit Linux lief, direkt mit Netzwerkkabel verbunden, und heute über eine Linux-VM auf einem Synology NAS.

Bronze

Auf der Suche nach einem Lösungsansatz zu den Tiemouts von KNXGW fand ich:

ZitatBekannte Probleme
Timing Problem Mode H
Wie bereits erwähnt, dieser Mode stellt hohe Ansprüche an das Antwortzeitverhalten von FHEM. Jede empfangene und gesendete Message muss in weniger als 1 Sekunde bestätigt werden. Der Vorteil: Es kann keine msg verloren gehen, ohne einen Eintrag im Logfile! Falls allerdings FHEM länger mit anderen Modulen beschäftigt ist, gibt das Probleme. Typische Module, die Probleme machen können, sind (u.A.): SVG, Onewire, HTTPMOD, usw...

Typische Meldungen im Log:

2021.12.13 00:00:06.506 3: <device> [KNXIO_TunnelRequestTO 1216]: timeout - attempt resend
2021.12.13 00:00:08.023 3: <device> [KNXIO_TunnelRequestTO 1224]: timeout - sending disconnect request
2021.12.15 13:12:09.045 3: <device> [KNXIO_ReadH 414]: TunnelRequest received: duplicate message received (seqcntr= xxx) - ack it
2021.12.15 13:12:10.012 3: <device> [KNXIO_ReadH 426]: TunnelRequest message out of sequence received: seqcntrRx received/expected= xxx/yyy - no ack & discard
Eine mögliche Lösung: Mittels Apptime cmd: "apptime average" bzw. "apptime max" jene Funktionen/Module herausfinden, die viel Zeit in FHEM beanspruchen... Werte größer 500ms können die Kommunikation zwischen FHEM und dem KNX-GW massiv stören. Werte die mit "tmr_" beginnen, sind nicht ganz so kritisch, sollten aber jedenfalls unter 900ms sein.

Evtl hilft auch, die Anzahl Events zu reduzieren (Stichwort: event-on-change-reading).

Falls das nicht zur Lösung führt, ist die Empfehlung, die Kommunikation über knxd zu lösen. Also: KNX-GW <-> knxd <-> FHEM (mode S, M od. T). Der knxd als eigenständiger Deamon ist nicht von Verzögerungen durch FHEM betroffen und hat bessere Fehler-Toleranz.

Also Lösungsversuch hierüber, knxd "zwischen zu schalten".
Da Debian-Linux vorhanden, war knxd leicht zu installieren
sudo apt-get install knxd knxd-tools.

So wie ich das verstehe, muss man, um knxd "zwischen zu schalten", 2 Einstellungen verändern:
Über
nano /etc/knxd.conf:
Dort habe ich eingetragen: "KNXD_OPTS="-E 15.15.242:4 -c -DTRS -b ipt:192.168.178.50"

Nach
/etc/init.d/knxd status war der Status "grün".

Und in FHEM muss man die Definition des KNXGW ändern:
Bisher:
ZitatH 192.168.178.50:3671 15.15.243
Wenn man neu:
ZitatT 192.168.178.50:3671 15.15.243
("T" statt "H") einträgt,
bleibt KNXGW disconnected.

Und nun komme ich nicht weiter, bitte um Rat.






Bronze

Geht man auf "H" zurück wie vorher, gibt es immer noch Timeouts:
2025.12.13 21:07:58 5: myKNXGW [KNXIO_Read 307]: buf=061004200015041d01002900bcd011031a00010081
2025.12.13 21:07:58 4: myKNXGW [KNXIO_ReadH 508]: TunnelRequest received - send Ack and decode seqcntrRx=1
2025.12.13 21:07:58 5: DevIo_SimpleWrite myKNXGW: 06100421000a041d0100
2025.12.13 21:07:58 4: myKNXGW [KNXIO_decodeCEMI 1267]: src=1.1.3 dst=3/2/0 destaddrType=1 prio=3 hop_count=5 length=1 data=81
2025.12.13 21:07:58 5: myKNXGW [KNXIO_decodeCEMI 1287]: outbuf=C01103w0320001
2025.12.13 21:07:58 4: myKNXGW [KNXIO_processFIFO 1099]: dispatching buf=C01103w0320001 Nr_msgs=1
2025.12.13 21:07:58 5: myKNXGW: dispatch C01103w0320001
2025.12.13 21:07:58 4: myKNXGW [KNX_Parse 1303]: src=1.1.3 dest=3/2/0 msg=C01103w0320001
2025.12.13 21:08:03 5: myKNXGW [KNXIO_Read 307]: buf=061004200017041d02002900bce0121e180303008007c9
2025.12.13 21:08:03 4: myKNXGW [KNXIO_ReadH 508]: TunnelRequest received - send Ack and decode seqcntrRx=2
2025.12.13 21:08:03 5: DevIo_SimpleWrite myKNXGW: 06100421000a041d0200
2025.12.13 21:08:03 4: myKNXGW [KNXIO_decodeCEMI 1267]: src=1.2.30 dst=3/0/3 destaddrType=1 prio=3 hop_count=6 length=3 data=8007c9
2025.12.13 21:08:03 5: myKNXGW [KNXIO_decodeCEMI 1287]: outbuf=C0121ew0300307c9
2025.12.13 21:08:03 4: myKNXGW [KNXIO_processFIFO 1099]: dispatching buf=C0121ew0300307c9 Nr_msgs=1
2025.12.13 21:08:03 5: myKNXGW: dispatch C0121ew0300307c9
2025.12.13 21:08:03 4: myKNXGW [KNX_Parse 1303]: src=1.2.30 dest=3/0/3 msg=C0121ew0300307c9
2025.12.13 21:08:23 5: myKNXGW [KNXIO_keepAlive 1328]: send conn state request - expect connection state response
2025.12.13 21:08:23 5: DevIo_SimpleWrite myKNXGW: 0610020700101d000801000000000000
2025.12.13 21:08:23 5: myKNXGW [KNXIO_Read 307]: buf=0610020800081d00
2025.12.13 21:08:37 5: myKNXGW [KNXIO_Read 307]: buf=061004200015041d03002900bcd0110b1a0a010080
2025.12.13 21:08:37 4: myKNXGW [KNXIO_ReadH 508]: TunnelRequest received - send Ack and decode seqcntrRx=3
2025.12.13 21:08:37 5: DevIo_SimpleWrite myKNXGW: 06100421000a041d0300
2025.12.13 21:08:37 4: myKNXGW [KNXIO_decodeCEMI 1267]: src=1.1.11 dst=3/2/10 destaddrType=1 prio=3 hop_count=5 length=1 data=80
2025.12.13 21:08:37 5: myKNXGW [KNXIO_decodeCEMI 1287]: outbuf=C0110bw0320a00
2025.12.13 21:08:37 4: myKNXGW [KNXIO_processFIFO 1099]: dispatching buf=C0110bw0320a00 Nr_msgs=1
2025.12.13 21:08:37 5: myKNXGW: dispatch C0110bw0320a00
2025.12.13 21:08:37 4: myKNXGW [KNX_Parse 1303]: src=1.1.11 dest=3/2/10 msg=C0110bw0320a00
2025.12.13 21:09:04 5: myKNXGW [KNXIO_Read 307]: buf=061004200017041d04002900bce0122019030300800c51
2025.12.13 21:09:04 4: myKNXGW [KNXIO_ReadH 508]: TunnelRequest received - send Ack and decode seqcntrRx=4
2025.12.13 21:09:04 5: DevIo_SimpleWrite myKNXGW: 06100421000a041d0400
2025.12.13 21:09:04 4: myKNXGW [KNXIO_decodeCEMI 1267]: src=1.2.32 dst=3/1/3 destaddrType=1 prio=3 hop_count=6 length=3 data=800c51
2025.12.13 21:09:04 5: myKNXGW [KNXIO_decodeCEMI 1287]: outbuf=C01220w031030c51
2025.12.13 21:09:04 4: myKNXGW [KNXIO_processFIFO 1099]: dispatching buf=C01220w031030c51 Nr_msgs=1
2025.12.13 21:09:04 5: myKNXGW: dispatch C01220w031030c51
2025.12.13 21:09:04 4: myKNXGW [KNX_Parse 1303]: src=1.2.32 dest=3/1/3 msg=C01220w031030c51
2025.12.13 21:09:04 5: myKNXGW [KNXIO_Read 307]: buf=061004200017041d04002900bce0122019030300800c51
2025.12.13 21:09:04 3: myKNXGW [KNXIO_ReadH 513]: TunnelRequest duplicate message received CCID=29 seqcntrRx=4 - ack and verify connection
2025.12.13 21:09:04 5: DevIo_SimpleWrite myKNXGW: 06100421000a041d0400
2025.12.13 21:09:04 5: myKNXGW [KNXIO_keepAlive 1328]: send conn state request - expect connection state response
2025.12.13 21:09:04 5: DevIo_SimpleWrite myKNXGW: 0610020700101d000801000000000000
2025.12.13 21:09:06 3: myKNXGW [KNXIO_keepAliveTO 1347]: timeout - retry 1
2025.12.13 21:09:06 5: myKNXGW [KNXIO_keepAlive 1328]: send conn state request - expect connection state response
2025.12.13 21:09:06 5: DevIo_SimpleWrite myKNXGW: 0610020700101d000801000000000000
2025.12.13 21:09:06 5: myKNXGW [KNXIO_Read 307]: buf=0610020800081d00
2025.12.13 21:10:06 5: myKNXGW [KNXIO_keepAlive 1328]: send conn state request - expect connection state response
2025.12.13 21:10:06 5: DevIo_SimpleWrite myKNXGW: 0610020700101d000801000000000000
2025.12.13 21:10:06 5: myKNXGW [KNXIO_Read 307]: buf=0610020800081d00
2025.12.13 21:11:04 5: myKNXGW [KNXIO_Read 307]: buf=0610020900101d000801c0a8b2320e57
2025.12.13 21:11:04 4: myKNXGW [KNXIO_ReadH 491]: DisconnectRequest received, restarting connection
2025.12.13 21:11:04 5: DevIo_SimpleWrite myKNXGW: 0610020a00081d00
2025.12.13 21:11:04 5: DevIo_SimpleWrite myKNXGW: 06100205001a0801000000000000080100000000000004040200
2025.12.13 21:11:04 5: myKNXGW [KNXIO_Read 307]: buf=0610020600141e0008010000000000000404fff2
2025.12.13 21:11:04 3: myKNXGW [KNXIO_handleConn 991]: connected
2025.12.13 21:11:39 5: myKNXGW [KNXIO_Read 307]: buf=061004200017041e00002900bce0122519160300800c5b
2025.12.13 21:11:39 4: myKNXGW [KNXIO_ReadH 508]: TunnelRequest received - send Ack and decode seqcntrRx=0
2025.12.13 21:11:39 5: DevIo_SimpleWrite myKNXGW: 06100421000a041e0000
2025.12.13 21:11:39 4: myKNXGW [KNXIO_decodeCEMI 1267]: src=1.2.37 dst=3/1/22 destaddrType=1 prio=3 hop_count=6 length=3 data=800c5b
2025.12.13 21:11:39 5: myKNXGW [KNXIO_decodeCEMI 1287]: outbuf=C01225w031160c5b
2025.12.13 21:11:39 4: myKNXGW [KNXIO_processFIFO 1099]: dispatching buf=C01225w031160c5b Nr_msgs=1
2025.12.13 21:11:39 5: myKNXGW: dispatch C01225w031160c5b
2025.12.13 21:11:39 4: myKNXGW [KNX_Parse 1303]: src=1.2.37 dest=3/1/22 msg=C01225w031160c5b
2025.12.13 21:12:04 5: myKNXGW [KNXIO_keepAlive 1328]: send conn state request - expect connection state response
2025.12.13 21:12:04 5: DevIo_SimpleWrite myKNXGW: 0610020700101e000801000000000000
2025.12.13 21:12:04 5: myKNXGW [KNXIO_Read 307]: buf=0610020800081e00

erwin

Und nun komme ich nicht weiter, bitte um Rat.
Überlege noch einmal deine Konfiguration:
Welche IP-Adresse hat das KNX-GW? - die gehört in die Definition vom knxd. Das schein ok zu sein!
Welche IP-Adresse hat der knxd ? - sicher nicht die vom KNX-GW !!! - die richtige gehört jetzt in def def vom KNXIO T .....

Wie du richtig aus dem wiki zitierst, gehts darum den knxd "zwischen zu schalten"...
PS: im zitierten wiki gibts auch Empfehlungen für die Parameter des knxd...

Und falls dein Problem nicht durch delays in FHEM hervorgerufen wird, sondern wg. Netzwerkproblemen, wird das auch keine Lösung sein.
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...