Modul 00_KNXIO.pm support

Begonnen von erwin, 25 Mai 2022, 14:00:35

Vorheriges Thema - Nächstes Thema

erwin

#30
Hi Markus,

war das unmittelbar nach FHEM start?
Die einzige Änderung in dem Bereich war: statt Internal 'STATE' wird in der neuen Version das reading 'state' auf connected getestet!!! - um festzustellen ob das KNX-GW connected ist.

Unimttelbar nach dem start könnte das KNX-GW noch nicht mit dem initialen Handshake mit FHEM fertig sein -
Verwendest du in einem global:INITIALIZED notify  KNX-set commands? z.b.: auf 1/1/0  oder 1/1/27 ...
l.g. erwin
PS: noch eine Möglichkeit: Hast du mehr als ein KNXIO device definiert? - Falls ja, dann check doch mal das reading IODEV im KNX-Device 1/1/0....
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,...

MarkusN

Hallo Erwin,

Zitatwar das unmittelbar nach FHEM start?
Wie du dem Log entnehmen kannst war das ein Zeitraum von etwa 5 Minuten. In der Tat sehe ich diese Art von Meldungen auch mit dem alten Modul in den ersten paar Sekunden nach dem FHEM neustart, danach aber nicht mehr.

ZitatVerwendest du in einem global:INITIALIZED notify  KNX-set commands? z.b.: auf 1/1/0  oder 1/1/27 ...
Nein, sowas nutze ich nicht

ZitatPS: noch eine Möglichkeit: Hast du mehr als ein KNXIO device definiert? - Falls ja, dann check doch mal das reading IODEV im KNX-Device 1/1/0....
Ebenfalls nein, ich habe nur das eine KNXIO device welches ich zum testen zwischen H und T Mode entsprechend umkonfiguriere. Dementsprechend haben die KNX-Devices auch alle das korrekte IODEV.

erwin

Hi,
ZitatIn der Tat sehe ich diese Art von Meldungen auch mit dem alten Modul in den ersten paar Sekunden nach dem FHEM neustart, danach aber nicht mehr.
Das zeigt aber, dass irgendwas ein Set - cmd, noch vor dem fertigwerden der initialisation, auslöst und zwar mehrfach/sekunde...speziell auf die GA 's 1/1/0 und 1/1/1 (aber nicht nur)
..das kann auch ein AT, Doif,... sein
Siehe auch mein Kommentar in der Commandref zu: KNX_scan, letzter Absatz...
Zum debuggen würde ich:
1) attr global mseclog 1
2) das KNX-device mit GA 1/1/1 auf verbose 5
3) das KNXIO-device auf verbose 4
setzen und dann ein fhem save/restart machen und den log hier posten.
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,...

GammaTwin

Grüße,

ich kann seit dem Update ebenfalls nicht auf den Bus senden.

den Fehlermeldungen sehen ähnlich aus:
2022.07.08 14:39:15.258 3: KNXIO_write called while not connected! Msg: w0000c01 lost
2022.07.08 14:39:23.680 3: KNXIO_write called while not connected! Msg: w0000a01 lost
2022.07.08 14:39:28.519 3: KNXIO_write called while not connected! Msg: w0000a00 lost
2022.07.08 14:39:33.450 3: KNXIO_write called while not connected! Msg: w0000a01 lost
2022.07.08 14:39:36.993 3: KNXIO_write called while not connected! Msg: w0000c00 lost
2022.07.08 14:39:40.039 3: KNXIO_write called while not connected! Msg: w0000c01 lost
2022.07.08 14:39:55.081 3: KNXIO_write called while not connected! Msg: w0000a01 lost
2022.07.08 14:39:58.811 3: KNXIO_write called while not connected! Msg: w0000c01 lost
2022.07.08 14:40:00.062 3: KNXIO_write called while not connected! Msg: w0221000ff lost
2022.07.08 14:40:02.064 3: KNXIO_write called while not connected! Msg: w0221100ff lost
2022.07.08 14:41:13.400 3: KNXIO_write called while not connected! Msg: w0000a01 lost
2022.07.08 14:41:16.539 3: KNXIO_write called while not connected! Msg: w0000c01 lost
2022.07.08 14:41:40.036 3: KNXIO_write called while not connected! Msg: w0000a01 lost
2022.07.08 14:41:49.284 3: KNXIO_write called while not connected! Msg: w0000c01 lost
2022.07.08 14:42:00.089 3: KNXIO_write called while not connected! Msg: w0221000ff lost

erwin

Sorry Gentlemen,
ich hab den Fehler gefunden, aber (noch) nicht verstanden, warum das bei mir nur auf EINEM von 3 systemen auftritt...
Ich werde heute Nachmittag weiter analysieren - mit dem update morgen gibts jedenfalls einen fix!
l.g. erwin
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,...

erwin

Hi,
fix ist im SVN - ab morgen im update!
Sorry erwin
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,...

GammaTwin

Läuft jetzt problemlos  8)

Danke Dir

ThoTo

Hallo alle :-)

Ich wollte von KNX/TUL auf KNXIO wechseln, Vorgehensweise laut Wiki eingehalten.
Nach dem Wechsel konnte ich weder auf den Bus senden noch empfangen, im Log folgende Einträge:
2022.07.13 17:48:11 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.07.13 17:48:12 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.07.13 17:48:50 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.07.13 17:48:52 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.07.13 17:49:50 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.07.13 17:49:52 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.07.13 17:50:22 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.07.13 17:50:24 3: KNXIO_TunnelRequestTO hit - sending disconnect request


KNX/TUL List:
Internals:
   AckLineDef
   Clients    :KNX:EIB:
   DEF        eibd:192.168.1.160 1.0.241
   DevType    EIBD
   DeviceAddress 010fb
   DeviceName eibd:192.168.1.160
   FD         6
   FUUID      5f9adaac-f33f-7974-7a2f-1aa7eebe74af8874
   KNX_MSGCNT 49
   KNX_TIME   2022-07-13 18:14:17
   NAME       KNX
   NR         8
   PARTIAL   
   RAWMSG     C01165w0630c363e
   REFUSED   
   STATE      Initialized
   TYPE       TUL
   MatchList:
     2:KNX      ^C.*
     3:EIB      ^B.*
Attributes:


KNXIO Definition:
H 192.168.1.160:3671 1.0.241

Ich habe nun wieder auf die alte Variante zurückgebaut -> funktioniert sofort.

Irgendwer dazu eine Idee?

LG Thomas
KNX | MQTT | Docker | Sonos | FHEMapp

"Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher." (Albert Einstein)

erwin

ZitatIrgendwer dazu eine Idee?
Ja, der Wechsel vom TYPE=TUL auf TYPE=KNXIO geht lt. wiki so:
Aus:
define myTUL TUL eibd:192.168.5.246:6720 5.1.251
..wird:
define myKNXGW KNXIO T 192.168.5.246:6720 5.1.251

du hast mit mode H versucht....
Mode H muss:
1.) vom KNX-GW unterstützt werden.
2.) der knxd sollte nicht laufen!
3.) die IP-adresse muss die vom KNX-GW sein, das kann nicht die gleiche sein wie vom knxd! (du hast in beide defs 192.168.1.160....)
3.) ist timing kritisch.

Vorschlag: mal mit T probieren, wenns damit funktioniert, können  wird weiter forschen!
l.g. erwin
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,...

ThoTo

Zitat von: erwin am 13 Juli 2022, 21:31:40
Vorschlag: mal mit T probieren, wenns damit funktioniert, können  wird weiter forschen!
l.g. erwin

Wer lesen kann, ist klar im Vorteil  :) :) Danke dir für den Hinweis, aus irgendeinem Grund habe ich H statt T genommen, vmtl. weil mal so getestet.
Jetzt läufts - top!

LG Thomas
KNX | MQTT | Docker | Sonos | FHEMapp

"Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher." (Albert Einstein)

erwin

Hi KNX community!

nach langer Zeit,... eine neue Version ist am SVN
change-history:
Package-name change FHEM::KNXIO -> KNXIO
simplify duplicate msg detection, perf improvements
modify fifo logic
unify log msgs
cmd-ref improvements

Sollte keine funktionellen Auswirkungen haben!
l.g. erwin
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,...

Nokz

Hallo erwin,

super das es hier weitergeht :)

Ich versuche seit gestern es bei mir stabil zu laufen bekommen, allerdings habe ich ein komisches Verhalten.
Meine alte Installation war MDT SCN-IP100.02 -> KNXD -> TUL.
define CUL_KNX TUL eibd:localhost 1.1.240

Dies habe ich auch erfolgreich auf das KNXIO Modul mit folgender Definition umstellen können (localhost hat er nicht gemocht, deswegen hier die IP-Auflösung):
define CUL_KNX KNXIO T 192.168.100.150:6720 1.1.240

Internals:
   DEF        T 192.168.100.150:6720 1.1.240
   DeviceName 192.168.100.150:6720
   FD         34
   FUUID      637869b9-f33f-e343-09ee-65372c788ddfa8d9
   NAME       CUL_KNX
   NR         1244
   PARTIAL   
   PhyAddr    011f0
   STATE      connected
   SVN        26687 2022-11-12 21:43:22
   TYPE       KNXIO
   eventCount 2
   model      T
   msg_count  3417
   msg_time   2022-11-19 07:49:47
   nextOpenDelay 10
   Helper:
     DBLOG:
       state:
         DBLOG:
           TIME       1668838349.45418
           VALUE      connected
   KNXIOhelper:
     FIFOMSG    C01103w07000445c4000
     FIFOTIMER  0
     FIFO:
   READINGS:
     2022-11-19 07:12:29   state           connected
Attributes:


KNXD läuft in diesem Fall weiter und es funktioniert hiermit bisher alles super :D

Allerdings hatte ich in der Vergangenheit ab und zu Probleme, dass es einen Reconnect oder Absturz beim KNXD Service gab, deswegen möchte ich hiervon gerne weg. Mein KNX Router kann Multicast und ich kann dies auch erfolgreich mit FHEM durch folgende Definition verbinden:
define CUL_KNX KNXIO M 224.0.23.12:3671 1.1.240

Für die M-Definition habe ich knxd.service und knxd.socket gestoppt und ich kann alle Telegramme empfangen und senden, aber nur in den ersten 3-4min, dann bricht plötzlich der Datenfluss ab. Ab diesem Zeitpunkt kann ich zwar weiterhin zum Bus senden, bekomme aber keine Nachrichten mehr zurück.
Sobald ich vom Device CUL_KNX die bestehende Definition wieder 1:1 "ändere" sind direkt wieder alle Busnachrichten wieder für die nächsten 3-4 min verfügbar. Meine Vermutung ist, dass der Router eine Art Ping oder so vom Empfänger erwartet, damit er die Nachrichten weiterhin raussendet und sofern dieser nicht erfolgt stellt er die Kommunikation ein.
Im KNX habe ich nur eine Linie und der Router hat die Adresse 1.1.0 -> Evtl. muss ich hier noch eine andere Linie erstellen, damit er dauerhaft auch über Multicast kommuniziert? Allerdings war meine ersten Versuche hier bisher erfolglos und evtl. liegt hier das Problem ;)
Eine Idee was ich probieren könnte? Es scheint ja zu funktionieren nur das es für eine kurze Zeitspanne über Multicast geht finde ich komisch und schreit nach einem Art Timeout Problem oder einer Definitionsfrage im KNX.
Im Logging ist mit verbode 5 leider gar nichts zu sehen. Man sieht hier nur, dass das letzte Packet erfolgreich verarbeitet wurde und dann war stille und fhem hatte dann nach 20 sekunden eine Nachricht versendet, aber es kommen keine mehr rein. Ich habe einmal zwei Screenshots davon angehangen. CUL_KNX ist auch weiterhin "connected".  Starte ich in der ETS5 den Busmonitor für den Multicast, dann habe ich auch direkt wieder alle Nachrichten im fhem, aber nur solange der Busmonitor auch läuft. Also für mich sieht es so aus, dass mein KNX-Router einfach die Weiterleitung eingestellt hat, weil er keine Empfänger vermutet und sich somit die Arbeit sparen will  ;D

Viele Grüße
Sebastian

erwin

#42
Hi Sebastian,

Zitatlocalhost hat er nicht gemocht, deswegen hier die IP-Auflösung
kann ich jetzt nicht unmittelbar testen, weil meine knxd's auf unterschiedlichen Host's laufen,
allerdings die DNS_Ausflösung funktioniert, siehe:
KNXIO_define (KNXIOdummy): DNS query result= 127.0.0.1
ich aber dzt. mode T mit hostnamen erfolgreich am laufen.

Das Problem bei Multicast ist, dass es kein "keepalive" od. ähnliches gibt, das anzeigt ob das gegenüber noch aktiv ist...
Da das senden bei dir funktioniert, bin ich der Meinung, das alles soweit ok ist.
Um sicherzugehen, das wirklich kein KNXD mehr läuft, kannst mal rebooten und danach schauen mit:
ps -efw | grep knx ob dein knx wirkich nicht mehr läuft?

Vermutung 2: deine phy-adresse 1.1.240 - ist die im KNX-Router so definiert?
...und... Wie lauten die phy-adressen auf deinem KNX-BUS? das sollte jedenfalls NICHT auch 1.x.x sein ...
Falls zutreffend, würde ich die phy-adr. vom KNX-Router auf 0.1.24X (mittels ETS) ändern.... (siehe Client phy-addr. in KNX-Router ..ETS...)

Du schreibst, es gab immer wieder restarts vom knxd - welche version, und wie lauten die knxd optrions?
Evtl. kann man auch aus den logs vom knxd ein konfig-problem erkennen...
einige infos findest du auch im KNXIO wiki....
l.g.erwin
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,...

Nokz

Hallo erwin,

vielen Dank für deine Rückmeldungen.

Zitat von: erwin am 19 November 2022, 11:13:12

Das Problem bei Multicast ist, dass es kein "keepalive" od. ähnliches gibt, das anzeigt ob das gegenüber noch aktiv ist...
Da das senden bei dir funktioniert, bin ich der Meinung, das alles soweit ok ist.
Um sicherzugehen, das wirklich kein KNXD mehr läuft, kannst mal rebooten und danach schauen mit:
ps -efw | grep knx ob dein knx wirkich nicht mehr läuft?
Also KNXD hatte ich sogar disabled inkl. Neustart und es hat 100% nicht mehr gelaufen. Ich hatte mittlerweile in einem anderen Forum Hinweise gefunden, dass es einen Multicastquerier gibt und dieser scheinbar beendet werden kann aufgrund z.B. von z.B. Netzwerkhardware und hier lag wohl auch mein Problem. Die Verbindung wurde scheinbar von meiner Hardware nach 3-4 min immer gekillt. Ich konnte es nämlich mittlerweile scheinbar lösen (läuft nun seit 40 min ohne Unterbrechungen im Multicastmodus). Ich nutze Unifi-AP's und Switches und habe in den Einstellungen die Punkte "Multicast Enhancement" und "Multicast and Broadcast Control" entfernt. Bei "Multicast and Broadcast Control" waren eigentlich alle Clients aufgelistet bis auf die Wlan-AP's und Switches. Vllt. hätten die hier auch noch reingemusst und es hätte auch funktioniert. Ist mir aber nun egal da es klappt und kann von mir aus auch aus bleiben :)

Zitat
Vermutung 2: deine phy-adresse 1.1.240 - ist die im KNX-Router so definiert?
...und... Wie lauten die phy-adressen auf deinem KNX-BUS? das sollte jedenfalls NICHT auch 1.x.x sein ...
Falls zutreffend, würde ich die phy-adr. vom KNX-Router auf 0.1.24X (mittels ETS) ändern.... (siehe Client phy-addr. in KNX-Router ..ETS...)
Also mein KNX-Router ist 1.1.0 und das bleibt dieser auch ;) Weil alle meine Geräte sind ja auch im 1.1.X Bereich die darunter liegen und der Router auch als Linienkoppler die X.X.0 haben muss. Die 1.1.240 ist ein Dummy-Gerät in der Linie, welche den FHEM-Server darstellen soll. Ich habe nämlich die Adresse welche man bei der Definition angibt als die Sender-Adresse betrachtet, mit der die Übertragung erfolgt oder nicht? Da dachte ich es macht weiterhin Sinn bei 1.1.240 zu bleiben (funktioniert damit ja aktuell auch), weil hierfür ja auch ein Dummy in der Linie vorhanden ist.
Was mir allerdings im Gruppenmonitor und auch Busmonitor aufgefallen ist, dass keine Quelladresse entschlüsselt wurden sobald die Nachrichten von fhem ankommen sondern immer nur 0.0.0 angezeigt wird. Mit KNXD wurde hier immer die 1.1.240 angezeigt und mit KNXTUL 0.0.5 (das hatten andere User auch als Bug gemeldet).
Mich stört es jetzt nicht so sehr, weil ich kann meine Geräte ja trotzdem schalten, aber hier mal paar Sendenachricht. Wie kann ich hier erkennen, was geschickt wird? Müsste hier nicht irgendwo die 1.1.240 (codiert versteht sich ;) ) ersichtlich sein?

2022.11.19 16:04:05 5: KNXIO_write: started
2022.11.19 16:04:05 5: KNXIO_write: sending w0510000302e302047312e32205431372e32
2022.11.19 16:04:05 5: KNXIO_Write: data=80302e302047312e32205431372e32 size=0f acpi=80 src=009f0 dst=05100
2022.11.19 16:04:05 4: KNXIO_Write: Mode= M buf=06100530001f2900bce0000029000f0080302e302047312e32205431372e32 rc= 31
2022.11.19 16:04:05 5: KNXIO_write: started
2022.11.19 16:04:05 5: KNXIO_write: sending w0510100302e302047312e32205431372e32
2022.11.19 16:04:05 5: KNXIO_Write: data=80302e302047312e32205431372e32 size=0f acpi=80 src=009f0 dst=05101
2022.11.19 16:04:05 4: KNXIO_Write: Mode= M buf=06100530001f2900bce0000029010f0080302e302047312e32205431372e32 rc= 31
2022.11.19 16:04:05 5: KNXIO_write: started
2022.11.19 16:04:05 5: KNXIO_write: sending w05150003133392f31313539570000000000
2022.11.19 16:04:05 5: KNXIO_Write: data=803133392f31313539570000000000 size=0f acpi=80 src=009f0 dst=05150
2022.11.19 16:04:05 4: KNXIO_Write: Mode= M buf=06100530001f2900bce0000029500f00803133392f31313539570000000000 rc= 31
2022.11.19 16:04:05 4: KNXIO_processFIFO (CUL_KNX): buf= C01133w07250431351ec Nr_msgs= 1


Zitat
Du schreibst, es gab immer wieder restarts vom knxd - welche version, und wie lauten die knxd optrions?
Evtl. kann man auch aus den logs vom knxd ein konfig-problem erkennen...
einige infos findest du auch im KNXIO wiki....
l.g.erwin
Die Fälle waren sehr selten - sprich 1-2 mal im Quartal und meistens morgens. Ist auch nicht weiter schlimm gewesen sondern nur nervig, wenn die HUE-Lampe nicht angeht, weil der KNX Präsenzmelder die nicht einschalten kann ^^ Da es nun mit Multicast ja scheinbar geht würde ich hier keine Zeit mehr investieren.

Viele Grüße
Sebastian

erwin

ZitatAlso mein KNX-Router ist 1.1.0 und das bleibt dieser auch ;)
.. das war ja nur eine Vermutung... allerdings das ist ein Router, und der hätte gerne auf jedem seiner Interfaces einen anderen Adress-Bereich,
sprich: auf Twistet Pair 1.x.x auf dem LAN z.b.: 0.x.y. So stehts jedenfalls in den KNX-specs. Wenn es so auch funktioniert, solls mir recht sein! ;D

Gut ist, das du das Problem lösen konntest!

wg. Source Adressen: ... geb ich dir recht, es wird immer mit 0.0.0 gesendet...
Ich hab lange in der History graben müssen, warum ich das damals gemacht habe.....
Das Problem: wenn ein User in der FHEM-definiton die phy-addr angibt, die dem -e Parameter im KNXD entspricht, (statt einem aus dem Bereich von -E) dann hat das ab einer gewissen knxd-version nicht funktioniert!
Problem2: in den "uralten" knxd versionen (und im eibd) gab es keinen -E Parameter, da hat das nur mit der -e adresse funkktioniert....
...und 0.0.0 wird im knxd (oder KNX-Router?) dann auf die aktuelle phy-adresse vom knxd übersetzt... also am twisted pair sollte alles wieder ok sein.
Ich hab deine debug msg etwas zerlegt, zur Erklärung:
022.11.19 16:04:05 5:  KNXIO_write: sending w05150003133392f31313539570000000000
                                             --1--
2022.11.19 16:04:05 5: KNXIO_Write: data=803133392f31313539570000000000 size=0f acpi=80 src=009f0 dst=05150
2022.11.19 16:04:05 4: KNXIO_Write: Mode= M buf=06100530001f2900bce0 0000 2950 0f 00 803133392f31313539570000000000 rc= 31
                                                                     --3- --2- -5      ---4------------------------
2022.11.19 16:04:05 4: KNXIO_processFIFO (CUL_KNX): buf= C01133 w 07250431351ec Nr_msgs= 1
                                                          -6---   --7-


-1- Dest GA = 5/1/50
-2- dest GA codiert
-3- src adr 0.0.0
-4-- payload
-5   datasize
-6-  src addresse 1.1.33 # das ist ein receive vom Bus
-7-  GA-Adr.. 7/2/50     # das ist ein receive vom Bus

Ich hab das jetzt mal zum Testen geändert, funkt. soweit,  bei Interesse kann ich dir gerne schicken, was/wo du in der aktuellen KNXIO ändern musst.
... ist ein "EinZeiler."...
l.g. erwin
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,...