Modul 00_KNXIO.pm support

[erwin]

Hi KNX-Community,
ich hab ein neues Modul gebastelt, dass mittelfristig das TUL und KNXTUL Modul ablösen soll und zusätzlich noch weitere Optionen bietet, wie KNX in FHEM integriert werden kann.
Nach einem halben Jahr Beta-Test geht das Modul nun ins SVN. Danke nochmals an alle Beta-Tester für ihren wertvollen Input!

Vorteil: Ein Modul für (fast) alle bisher unterstützten Methoden plus zwei neue Optionen der Connectivity. Verwendung von FHEM-Core Funktionen für IO-Handling (DevIO / TcpServerUtils). Keine zusätzliche Paket-Installation (z.B: multicast für KNXTUL Modul) notwendig.

Folgende connectivity optionen gibts:

• H Host mode - connect to a KNX-router with UDP point-point protocol.
    This is the mode also used by ETS when you specify KNXNET/IP as protocol. You do not need a KNXD installation. The protocol is complex and timing critical!
    If you have delays in FHEM processing close to 1 sec, the protocol may disconnect. It should recover automatically, however KNX-messages could have been lost!
• M Multicast mode - connect to KNXD's or KNX-router's multicast-tree.
    This mode is the successor of the KNXTUL-modul, also used by ETS when you specify KNXNET/IP Routing as protocol.
    If you have a KNX-router that supports multicast, you do not need a KNXD installation. Default address:port is 224.0.23.12:3671
    Pls. ensure that you have only one GW/KNXD in your LAN that feed the multicast tree!
• T TCP mode - uses a TCP-connection to KNXD (default port: 6720).
    This mode is the successor of the TUL-modul, but does not support direct Serial/USB connection to a TPUart-USB Stick.
    If you want to use a TPUart-USB Stick or any other serial KNX-GW, use either the TUL Module (not recommended, no support), or connect the USB-Stick to KNXD and use modes M,S or T to connect to KNXD.
• S Socket mode - communicate via KNXD's UNIX-socket on localhost. default Socket-path: /var/run/knx
    Path might be different, depending on knxd-version or -config specification! This mode is tested ok with KNXD version 0.14.30. It does NOT work with ver. 0.10.0!

Mode H: ist komplex und timing kritisch! (< 1sec). Indikatonen dass fhem zu langsam reagiert / etwas länger als 1 sekunde braucht sind Log-mesages:

Code Auswählen Erweitern

TunnelRequest received: duplicate message received ...
TunnelRequest received: out of sequence ....
KNXIO_TunnelRequestTO hit - ...
Evtl. hilft der cmd: "apptime average all" herauszufinden, welches Modul zu langsam ist....Verdächtig sind bei mir z.b.: OneWire und SVG. Dieser Mode hat jedoch den Vorteil, dass jede empfangene/gesendete Message vom gegenüber acknowledged werden muss! Damit ist (im Gegensatz zu Mode M u. S) sichergestellt, das "verlorene Messages" in FHEM erkannt werden.
Mode S: funktioniert mit knxd version 0.14.30 - mit version 0.10.0 bei mir nicht! Wenn ihr testet, dann bitte um feedback der knxd version.
Mode M: Funktioniert mit einem KNX-Router der Multicast spricht oder mit knxd!

Definition syntax ist in der cmd-ref zu finden.
Im wiki gibts einen Artikel zu KNXIO: https://wiki.fhem.de/wiki/KNXIO mit Hinweisen zur Konfiguration bzw. Migration von TUL/KNXTUL Modul.

Für die user des beta-Moduls: Bitte die GIT Version NICHT MEHR verwenden!
Die GIT version werdet ihr wie folgt los:

Code Auswählen Erweitern

update delete https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXIO.txt

change history:
2022-05-25  initial SVN version
2022-07-07 code cleanup, no functional changes
2022-12-05 change parameter parsing in define
                    add renameFn - correct reading & attr IODev in KNX-devices after rename of KNXIO-device
                    change disabled handling
                    fix src-addr for Mode M,H
                    change internal PhyAddr to reabable format + range checking on define.
2022-12-27 minor changes, cleanup
2023-01-22 no functional changes, cleanup
2023-01-28 simplify openDev, PBP fixes
2023-03-13 PBP changes, replaced cascading elsif -> when
2023-03-27 Log msg's vereinheitlicht, duplicate msg detection verbessert.
2023-04-07 Logging überarbeitet, keepalive Timeouts limit
2023-05-24 new event "<device>:INITIALIZED" after sucessful start
                  change (shorten) timeout parameters on disconnect
                  cmd-ref: correct wiki links, W3C conformance
2023-06-15 Die Funktion KNXscan ist jetzt im KNXIO-Modul!
                  Problem mit KNXscan mit 50+ scanned devices gefixt.
                  neues Attribut: enableKNXscan - autom. starten von KNX_scan nach FHEM init und/oder nach jedem connect event.
                  update cmdref.
2023-07-13 Die Funktion KNX_scan ist jetzt (wieder) im KNX-Modul
2023-08-25 reorg code for mode X
2023-10-04 FIFO & Rate limit for write (set/get-cmd) from KNX-Modul
2023-11-25 performance tuning KNXIO_write
                  replace GP_export function
                  PBP cleanup -1
                  change regex's (unnecessary i)
2023-12-21 modify KNXIO_Ready fn
                  fix problem in _write2 (high load)
                  add recovery on open Timeout - mode H
                  modify dipatch2/ processFIFO
                  new Attr KNXIOdebug - selective debugging on Loglvl 1 - use only on developer advise 
2023-12-25 optimize write queue handling - high load
                  new: write flooding detection
2024-01-20 cmdref: KNXIOdebug attribute
                  new: set cmds: connect, disconnect, restart
                  modify INITIALIZED logic
2024-03-05 modify write queing (mode H)
                  add a few debug msgs

l.g. erwin

[Hauswart]

Umstieg hat problemlos funktioniert. Danke dir!

[PatrickR]

Hi!

Umstieg hat auch bei mir problemlos funktioniert. Keinen Erfolg hatte ich aber bislang mit dem Eliminieren des knxd.

Der ist aktuell so konfiguriert:

Code Auswählen Erweitern


knxd \
--eibaddr=1.0.250 --client-addrs=1.0.251:1 \
--GroupCache \
--listen-tcp \
-B single \
--layer2=ipt:192.168.0.191

und funktioniert mit folgender KNXIO-Konfiguration:

Code Auswählen Erweitern


define knx KNXIO T knxd.prdom:6720 1.0.251


Laut Wiki kann mein MDT SCN-IP100.02 den TCP-Mode, was leider (auch bei gestopptem knxd) mit folgender Konfiguration nicht funktioniert:

Code Auswählen Erweitern


define knx KNXIO T knx.prdom:6720 1.0.251

(knx.prdom ist identisch zu der obigen IP 192.168.0.191, aber nicht zu verwechseln mit knxd.prdom, wo der knxd läuft/lief).

Hast Du eine Idee?

/Update:

Code Auswählen Erweitern


2022.05.30 18:35:14.272 3: Opening knx device 192.168.0.191:6720
2022.05.30 18:35:14.275 1: knx: Can't connect to 192.168.0.191:6720: Operation now in progress
2022.05.30 18:35:14.284 1: knx: Can't connect to 192.168.0.191:6720: 192.168.0.191: Connection refused (111)
2022.05.30 18:35:14.284 2: KNXIO_callback: device open knx failed with: 192.168.0.191: Connection refused (111)


Patrick

[erwin]

Mhh,
Nachdem KNXIO->knxd->GW funktioniert, aber KNXIO->GW nicht:
möglicherweise läuft der knxd noch immer (irgendwie) , und blockiert damit die Addresse des GW's 192.168.0.191....
Test ob zum GW eine Verbindung steht:

Code Auswählen Erweitern

sudo netstat -anp | grep knx ...vom system wo der knxd läuft...
um den knxd zu stoppen:

Code Auswählen Erweitern

sudo systemctl stop knxd.service
sudo systemctl stop knxd.socket
anschließend checken:

Code Auswählen Erweitern

ps -efw | grep KNX
bzw:
sudo systemctl status knxd.service
sudo systemctl status knxd.socket

andere Vermutungen:
1) du hast im GW nur eine Client-Addresse definiert (das vermute ich aus deiner KNXD definition)? - Evtl. das GW neu starten ....
2) evtl versucht du vorerst auch mal mit der IP-addr, statt mit namen....könnte auch am dns liegen...

l.g. erwin

edit: Sorry, sorry, sorry.... Die Tabelle im WIKI ist FALSCH!!!
Mode T geht NUR mit dem knxd !!!! nicht mit einem GW!!!
Deine Optitonen: MIT MODE T -> knxd -> GW
oder: MODE H - ohne knxd - allerdings mit denangesprochenen timing Herausfoprderungen.....

[PatrickR]

Hi!

[Tests für die Theorie, dass die Adresse des GWs noch durch knxd blockiert ist]

Alle negativ, auch mit grep -i.

1) du hast im GW nur eine Client-Addresse definiert (das vermute ich aus deiner KNXD definition)? - Evtl. das GW neu starten ....

Neu gestartet habe ich nicht, aber auch 4 Adressen im GW zur Verfügung. (s. Screenshot 'mit knxd.png'). Selbst wenn der ursprünglich durch knxd benutzte "Slot" frei ist, funktioniert es nicht (s. Screenshot "knxd gestoppt...").

2) evtl versucht du vorerst auch mal mit der IP-addr, statt mit namen....könnte auch am dns liegen...

Auch probiert (obwohl knxio lt. Internals und Log korrekt auflöst). => Keine Besserung.

Habe es nochmal im Host-Mode ohne knxd probiert => funktioniert, möchte ich aber aus sicherlich nachvollziehbaren Gründen nicht nutzen.

Port 6720/tcp auf dem MDT-Router ist übrigens auch closed. Kann es evtl. sein, dass der TCP-Mode vielleicht doch nicht unterstützt wird? Muss ich ggf. im TCP-Mode zwingend die Tunneling-Adressen aus dem MDT-Router-GUI nutzen?

Patrick

[erwin]

Hi Patrik,
da haben sich meine Korrektur vom vorigen post und dein post überschnitten, nochmals sorry für den Fehler im wiki und DANKE für's finden...
Muss nochmal korrigieren - du hast ja einen mdt100.02 - da geht doch auch Mode M (falls im selben LAN!)
l.g. erwin

[PatrickR]

Hi!

Alles klar, dann wissen wir jetzt zumindest, was Sache ist. Danke für die Korrektur.

Hatte heute noch das Problem, dass der Status eines Aktors in FHEM nicht stimmte, obwohl der letzte Schaltvorgang wohl passierte, als sowohl knxd als auch fhem liefen. Das Ganze ist mir nur durch Zufall aufgefallen. Der Aktor war so konfiguriert, dass nur bei Statusänderung gesendet wird, was ich nun geändert habe.

Besteht irgendeine Möglichkeit, zu prüfen, ob alle Nachrichten auf dem Bus auch tatsächlich bei knxio ankommen? Leider habe ich scheinbar kein KNX-Gerät, das einen Counter der Nachrichten auf dem Bus pflegt, den ich mit dem Wert im KNXIO-Modul vergleichen könnte. Im FHEM-Log steht mit Standard-Verbose nichts.

Patrick

[EinEinfach]

Hallo zusammen,

ich werde die nächsten Tage auch den Umstieg machen.

Als Schnittstelle in die KNX-Welt verwende ich MDT SCN-IP000.02. Fhem kommuniziert mit knxd über das TUL Modul.

Verstehe ich das richtig, dass es für mich zwei Möglichkeiten gibt das KNXIO Modul zu nutzen:
1. Mode H ohne knxd
2. Mode T mit knxd

Oder übersehe ich etwas?

Gruß
Alexander

[erwin]

@Alexander: absolut richtig verstanden, Falls du den mode H probieren möchtest, könntest du schon vorher mit apptime... checken, wie dein system perfomed.. Falls da viele average werte größer 500ms sind, würde ich den Mode H nicht empfehlen, bzw vorher versuchen das zu verbessern...

@Patrik:
es gibt sowohl im KNXIO als auch in jedem KNX-device ein internal: <devicename>_MSGCNT - das zählt die empfangenen msgs. Aber du schreibst auch dass du kein Gerät hast, das auf der KNX-seite mitzählt.....
Msgs können im KNX immer verloren gehen, auf dem KNX-Bus wird das durch ein ACK protokoll und erneut senden verhindert, am LAN kann das auch passieren (UDP-Protokoll).
Der KNIO-Mode, der das mit Sicherheit verhindert (oder einen Error ins Log schreibt) ist MODE H !!! Da wird ein transmit und receive counter jeweils vom GW und FHEM mitgeführt und kontrolliert! jede gesendete/emfangene msg muss innerhalb < 1 Sekunde acknowledged werden, das ist der Grund warum das Protokoll so timing sensitiv ist.

Zum verifizieren, ob der FHEM device status mit der "Realität" übereinstimmt, gibst noch den "KNX_scan" cmd.
l.g. erwin

[PatrickR]

Hallo Erwin,

Der KNIO-Mode, der das mit Sicherheit verhindert (oder einen Error ins Log schreibt) ist MODE H !!! Da wird ein transmit und receive counter jeweils vom GW und FHEM mitgeführt und kontrolliert! jede gesendete/emfangene msg muss innerhalb < 1 Sekunde acknowledged werden, das ist der Grund warum das Protokoll so timing sensitiv ist.

Hmm. Dass der Mode Vorteile hat, war mir garnicht in den Sinn gekommen. Da meine FHEM-Installation gut in Schuss ist (zumindest so weit das bei einer großen FHEM-Installation überhaupt möglich ist), werde ich das mal testen.

Zum verifizieren, ob der FHEM device status mit der "Realität" übereinstimmt, gibst noch den "KNX_scan" cmd.

Ah den kannte ich noch nicht und nachdem ich den Code gelesen habe, habe ich auch die Doku in der Commandref gefunden

Patrick

[erwin]

Der Mode H verwendet das gleiche Protokoll wie der knxd mit ipt:xx.xx.xx.xx zum Gateway... (und auch die ETS) ... das wird auch manchmal IP-Tunneling genannt...
Nochmal zum knxd: kompatibel mit Mode: M,S,T - unabhängig davon wie das GW an knxd angebunden ist.
Aufpassen muss man mit Mode M: Falls das GW multicast spricht und der knxd gleichzeitig auch... dann werden im besten Fall alle Messages verdoppelt oder schlimmeres!
Konsequenz: GW multicast & KNXIO mode M => knxd stoppen!!!
l.g. erwin

[PatrickR]

Hi!

Nachdem ich nun Blut geleckt habe, habe ich einen Feature-Request:
Besteht die Möglichkeit, im KNXIO-Device beim Auftreten eines Timing-Fehlers (z. B. in KNXIO_TunnelRequestTO) einen Fehlercounter (am besten als Reading, nicht Internal) hochzuzählen? Dann könnte man nicht nur elegant in FHEM einen Überblick über Probleme bekommen sondern auch darauf triggern.

Patrick

[erwin]

Besteht die Möglichkeit, im KNXIO-Device beim Auftreten eines Timing-Fehlers .....

Im Prinzip JA, allerdings müsste ich das genauer spezifiziert haben, was ein "Fehler" ist:
Es gibt da 4 Situationen:
1) senden FHEM->GW
1a) tunnel request TO (FHEM empfängt das Ack vom GW nicht) - versucht ein resend
2b) das resend bekommt wieder kein Ack -> close & restart communication
2) empfangen GW->FHEM
2a) duplicate msg received (weil FHEM die letzte msg zwar korrekt empfangen/processed hat, aber das Ack zu spät geschickt hat) - keine msg ging verloren!
2b) msg out of sequence (der read-counter stimmt nicht mit den erwartungen vom GW überein ) - msg lost-> close & restart communication with GW

Auf welchen "event" ich den Fehlercounter incrementiere ist noch einfach, aber wie/wann der counter resetten? - Am einfachsten noch im define/defmod....

Im Prinzip könnte man das ganze auch mit einem notify (Attr readLog) lösen.....
l.g. erwin

[EinEinfach]

Umstellung hat geklapt. Habe mich für die zweite Variante Mode T + knxd entschieden.

Jetzt gilt es zu schauen, ob alles wie gewohnt funktioniert.

Danke!

[MarkusN]

Habe auch mal ein feature request:
Ich nutze aktuell knxd mit dem KNX TUL Modul. Ich habe mir über einen ziemlich schmutzigen Umweg einen Message counter gebaut (ausserhalb von FHEM mit busmonitor aus dem knxtool). Letzten Endes monitore ich damit die Telegrame pro Minute auf dem Bus, um festzustellen ob was schief läuft (habe damit auch bereits ungünstige Konfigurationen ausfindig machen und beseitigen können).

Jetzt würde ich gerne knxd komplett loswerden (und damit hätte auch das knxtool keine Verbindung mehr zum Bus) und auf dieses Modul im H-mode wechseln. Wäre es möglich einen counter in das Modul einzubauen? Entweder ein Wert der einfach nur hochzählt, oder direkt die Anzahl von Telegrammen pro Minute ausgibt?

Grüße,
Markus

[erwin]

@EinEinfach:
super das es geklappt hat!

@Markus: den counter gibt es bereits, siehe device internal: <name>_MSGCNT und <name>_TIMESTAMP. Der zählt die empfangenen msg's.
Dasselbe gibts dann nochmal pro KNX-device...
ad knxd loswerden: Du kannst den knxd auch ohne weiteres für deine speziellen Zwecke weiterbetreiben und dennoch mit KNXIO eine direkte Verbindung zum GW aufbauen. Nur nicht FHEM -> GW UND FHEM ->knxd gleichzeitig!!! GW -> knxd und GW -> FHEM gleichzeitig sind kein Problem (bei Mode M aufpassen - siehe mein post v. gestern 14:04).

@Patrik: Falls es nur um die "harten" Fehler geht (=wo msgs verloren gehen), kannst du auch auf den event <name>: disconnected triggern....
l.g. erwin

[MarkusN]

Super, das mit dem internal reicht mir zum monitoren, danke!
Erwin, wie hast du denn dein 1-Wire Netz angebunden? owserver scheint ja aufgrund von delays weniger optimal zu funktionieren. Ich habe aktuell einen USB stick in einem entfernten RaspberryPi stecken welcher über owserver mit FHEM kommuniziert. Hätte am liebsten irgendwas mit MQTT.

[erwin]

Hi Markus,
re OWServer: ich hab da noch keine wirklich zufriedenstellende Lösung.....
Tatsache ist, dass trotz nonblocking die Abfrage von 18B20 knapp eine Sekunde FHEM blockiert..... Ich hab OW via I2C angebunden. - DS2480 wenn ich mich richtig erinnere...
Ich hab mir damit geholfen, die resolution  der 18x20's auf 10 zu stellen (insgesamt 8Stück), damit komm ich auf < 500ms und das passt dann fürs KNXIO mode H.
l.g. erwin
PS: irgendwo hab ich was von OW2MQTT gelesen, aber (noch) nicht weiterverfolgt....

[MarkusN]

Ich habe jetzt mal von KNX/TUL via KNXD auf KNXIO im H-Modus gewechselt.

Die Definition sieht so aus:

Code Auswählen Erweitern

defmod KNX KNXIO H 10.0.2.142:3671 0.0.3
attr KNX icon knx
attr KNX room 25_KNX->99_Interface

Verbindung steht, im eventMonitor sehe ich auch die Events für alle definierten Devices, und das deckt sich auch mit dem was ich im Gruppenmonitor der ETS sehe.
Was nicht so gut funktioniert ist senden. Wenn ich eine gewisse Zeit (Minuten) nichts auf den Bus sende, und dann ein Gerät schalte, sehe ich zwar im eventMonitor dass der Befehl rausgeht, aber im Gruppenmonitor der ETS taucht nichts auf, und das entsprechende Gerät schaltet natürlich auch nicht. Manchmal passiert das auch noch ein bis zwei mal direkt danach, aber irgendwann sehe ich die Telegramme auf dem Bus und ab dann geht auch alles durch. Bis einige Zeit wieder nichts gesendet wird. Es sieht aus als würde FHEM die Verbindung zu meinem Interface (MDT SCN-IP000.03) verlieren, was aber nicht stimmt da ich die ankommenden Telegramme in FHEM ohne Unterbrechung sehen kann, es scheint also nur die sendende Richtung zu betreffen.
Irgendwelche Ideen?

[erwin]

Hi Markus,
3 Ideen dazu:
1) Gibts im Log - auf Level3 irgendwelche Messages ? (Timeout / duplicate packets.... /disconnect/connect...)
2) stimmt das reading IODev im betroffenen KNX-device
3) stimmt 0.0.3 mit dem im GW definierten Tunnel-Adressen überein?

Es gibt ein keepalive zwischen KNXIO und dem GW, wenn das nicht funktioniert, gibts was im Log!
erwin

[MarkusN]

1) Gibts im Log - auf Level3 irgendwelche Messages ? (Timeout / duplicate packets.... /disconnect/connect...)

Ja, ich kann in der Tat Meldungen in den Fällen wo nichts durchgeht sehen, habe dafür das KNX device auf verbose 3 gesetzt, ich denke das ist der richtige Weg, oder?

Code Auswählen Erweitern

2022.06.03 18:56:50 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.06.03 18:56:49 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.06.03 18:52:06 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.06.03 18:52:04 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.06.03 18:49:33 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.06.03 18:49:32 3: KNXIO_TunnelRequestTO hit - attempt resend

2) stimmt das reading IODev im betroffenen KNX-device

Ja die passen alle, der Einfachheit halber hat das KNX Device auch den exakt gleichen Namen behalten.

3) stimmt 0.0.3 mit dem im GW definierten Tunnel-Adressen überein?

Okay, hier muss ich passen. Ich habe nie richtig verstanden wie ich das konfigurieren muss. An welcher Stelle würde ich das konfigurieren, und muss es in der selben Linie wie meine restliche Installation sein? Habe jedenfalls nur ein IP Interface, keinen Router.

[erwin]

Na da haben wir ja das Problem,
irgendwas in deinem FHEM ist zu langsam/blockiert für ???ms ... - nach einem disconnect dauerts ein paar sekunden, bis die Verbindung wieder aufgebaut wird! In dieser Zeit geht nix raus oder rein....
schon mal apptime laufen lassen?
Falls du das nicht unmittelbar lösen kannst, würde ich auf mode T gehen - mit knxd.
ad phy-addr.: schau mal in den internals unter PhyAddr da stehts (in Hex codiert) - poste einfach ein list device!

[MarkusN]

Na da haben wir ja das Problem,
irgendwas in deinem FHEM ist zu langsam/blockiert für ???ms ... - nach einem disconnect dauerts ein paar sekunden, bis die Verbindung wieder aufgebaut wird! In dieser Zeit geht nix raus oder rein....
schon mal apptime laufen lassen?
Falls du das nicht unmittelbar lösen kannst, würde ich auf mode T gehen - mit knxd.
ad phy-addr.: schau mal in den internals unter PhyAddr da stehts (in Hex codiert) - poste einfach ein list device!

Bezüglich der Physikalischen Adresse habe ich mich mal auf meinem IP interface angemeldet und FHEM eine der Tunneling Adressen gegeben die dort angegeben ist (15.15.241). Angehängt habe ich noch ein screenshot vom Webinterface.

Code Auswählen Erweitern



Internals:
   DEF        H 10.0.2.142:3671 15.15.241
   DeviceName 10.0.2.142:3671
   FD         29
   FUUID      629a2275-f33f-b36e-3cb5-b5253492dfe1a509
   KNX_MSGCNT 393
   KNX_TIME   2022-06-03 19:23:17
   NAME       KNX
   NR         345
   PARTIAL   
   PhyAddr    0fff1
   STATE      connected
   TYPE       KNXIO
   eventCount 43
   model      H
   nextOpenDelay 30
   KNXIOhelper:
     CCID       16
     FIFOMSG    C0110aw032050c06
     FIFOTIMER  0
     SEQUENCECNTR 3
     SEQUENCECNTR_W 0
     FIFO:
   READINGS:
     2022-06-03 19:22:51   state           connected
Attributes:
   icon       knx
   room       25_KNX->99_Interface
   verbose    3

Bezüglich dem timeout/block:
Ich bin mir ziemlich sicher dass dem nicht so ist. Bis auf ein paar Ausreisser (einmal alle paar Stunden, z.B. echodevice oder octoprint) habe ich keine delays über 200ms. Um das sicherzustellen nutze ich apptime und freezemon (letzerer ist auf freezes ab 0.5s konfiguriert). Auch sonst sollte performance kein Problem sein (FHEM läuft auf proxmox als LXC container), das Netzwerk schließe ich auch aus (alles direkt verkabelt, kein WiFi, Powerline oder sonstige Bastellösung).

[PatrickR]

Hi!

@Patrik: Falls es nur um die "harten" Fehler geht (=wo msgs verloren gehen), kannst du auch auf den event <name>: disconnected triggern....

Auf dem KNXIO-Device? Da habe ich schon einen Trigger, der bislang ruhig ist. Betrifft das ein- und ausgehende verlorene Nachrichten?

Bekomme aktuell im Log nur duplicate messages, die wenn ich Dich richtig verstehe, harmlos sind, da die Acks nur zu spät kamen.

Code Auswählen Erweitern


2022.06.03 06:12:52.129 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=213) - ack it
2022.06.03 06:30:20.844 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=217) - ack it
2022.06.03 08:57:51.999 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=159) - ack it
2022.06.03 09:46:51.940 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=210) - ack it
2022.06.03 20:36:47.401 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=121) - ack it


Patrick

[erwin]

Hi Patrick,
JA, auf dem KNXIO-device.  disconnect kann bei ein- u. aus-gehenden msgs passieren.
Und ja, in der Häufigkeit ist das harmlos, heisst nur, dass das GW eine msg nochmals geschickt hat, weil es nicht rechtzeitig ein Ack von FHEM bekommen hat. (obwohl FHEM die 1ste msg bekommen und verarbeitet hat.....)
da gibts KEIN disconnect, erst falls das Ack auf die duplicate msg auch nicht ankommt, dann sendet das GW einen disconnect request....

[erwin]

@Markus:

PhyAddr    0fff1

ergibt 15/15/241 - das stimmt also jetzt mit dem GW-Settings überein!
Was mir aufgefallen ist - in deinem screenshot:

individual-address 15/15/255 -  das ist lt. KNX-specs der wert für nicht konfiguriert, und soll nicht für normalen Betrieb verwendet werden.
Ob das was mit deinen Problemen zu tun hat, weiß ich allerdings nicht.

[erwin]

Hi KNX-Community!
Eine neue Version, keine funktionellen Änderungen!
Es gibt ein neues Internal: SVN - zeigt SVN-id und commit datum, falls das wer ausser mir noch brauchen soltte...
Es ist sehr ruhig hier, das kann 2 Ursachen haben:
1) Das Ding verwendet niemand... 
2) Es gibt keine Probleme / Fragen!

schönen Sommer !
erwin

[PatrickR]

2) Es gibt keine Probleme / Fragen!

[MarkusN]

Bei mir läuft es auch ohne Probleme, allerdings nur im TCP mode. Der Host-Mode macht nach wie vor Probleme

[MarkusN]

Habe heute morgen mein FHEM geupdated und danach konnte ich nichts mehr auf den Bus senden. Sowohl TCP mode über knxd als auch der Hostmode direkt ans interface hat nicht mehr funktioniert. Bin wieder zurück auf die Version vom 25.05.

Konkret sah das Log so aus mit der neuen Version (das KNXIO Device sagte jederzeit "connected"):

Code Auswählen Erweitern

2022.07.07 09:17:42 3: KNXIO_write called while not connected! Msg: w0320800079e lost
2022.07.07 09:17:42 3: KNXIO_write called while not connected! Msg: w0340100442a lost
2022.07.07 09:16:25 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:16:25 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:16:24 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:16:23 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:15:56 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:15:56 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:15:56 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:15:55 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:15:55 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:15:54 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:15:52 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:15:51 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:15:31 3: KNXIO_write called while not connected! Msg: w032080007bc lost
2022.07.07 09:15:31 3: KNXIO_write called while not connected! Msg: w03401003fb7 lost
2022.07.07 09:15:13 3: KNXIO_write called while not connected! Msg: w015000002 lost
2022.07.07 09:14:32 3: KNXIO_write called while not connected! Msg: w0111b00 lost
2022.07.07 09:13:52 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:13:51 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:13:51 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:13:51 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:13:50 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:13:50 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:13:50 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:13:49 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:13:49 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:13:48 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:13:47 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:13:46 3: KNXIO_write called while not connected! Msg: w0110001 lost

[erwin]

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....

[MarkusN]

Hallo Erwin,

war 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.

Verwendest du in einem global:INITIALIZED notify  KNX-set commands? z.b.: auf 1/1/0  oder 1/1/27 ...

Nein, sowas nutze ich nicht

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....

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,

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.

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.

[GammaTwin]

Grüße,

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

den Fehlermeldungen sehen ähnlich aus:

Code Auswählen Erweitern

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

[erwin]

Hi,
fix ist im SVN - ab morgen im update!
Sorry erwin

[GammaTwin]

Läuft jetzt problemlos 

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[erwin]

Irgendwer dazu eine Idee?

Ja, der Wechsel vom TYPE=TUL auf TYPE=KNXIO geht lt. wiki so:

Code Auswählen Erweitern

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

[ThoTo]

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

[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

[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.

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

define CUL_KNX KNXIO T 192.168.100.150:6720 1.1.240

Code Auswählen Erweitern

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

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:

Code Auswählen Erweitern

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 

Viele Grüße
Sebastian

[erwin]

Hi Sebastian,

localhost 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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[Nokz]

Hallo erwin,

vielen Dank für deine Rückmeldungen.

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:

Code Auswählen Erweitern

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

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?

Code Auswählen Erweitern


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


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]

Also 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!

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:

Code Auswählen Erweitern

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

[Nokz]

Hallo erwin,

danke für die Erklärungen bzgl. dem Aufbau der Nachrichten. Kann ja nicht schaden sowas mal verstanden zu haben, wenn man mal Fehler sucht Bzgl. des Codings probiere ich das gerne mal aus. Leider musste ich heute morgen feststellen, dass ich mich scheinbar zu früh gefreut hatte. Ich habe jetzt erstmal wieder auf KNXD umgestellt und werde endlich meine lange Baustelle (LAN-Kabel ziehen für den FHEM-Server angehen) abschließen. Ich bin mir nämlich ziemlich sicher, dass die Wlan-AP's hier einen strich durch die Rechnung machen. Es ging nämlich alles bis zum Neustart des Switches/ Ap's und FHEM. Ich bleibe hier aber am Ball, weil ich will das zum Laufen bekommen ^^

Code Auswählen Erweitern

.. 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
Das ist glaube ich auch soweit richtig, nur das bei mir die Hauptlinie 1.x.x IP-Topologie ist und die Linie 1.1.x ist Twistet Pair. Somit stellt mein IP-Router mit der 1.1.0 die Verbindung zwischen der IP-Welt 1.x.x und der TP-Welt 1.1.X her. Da ich hier eh nochmal ran muss, wird es wahrscheinlich sinniger sein, dass man evtl. nochmal ein Dummy in z.B. 1.2.x anlegt, damit der Router auch denkt er muss mit der IP-Welt zwingend kommunizieren. Aber solange ich keine Lan-Verbindung gezogen habe ist die Fehlersuche wahrscheinlich zu schwierig. Am Modul liegt es jedenfalls nicht - das nutze ich ja aktuell für die Kommunikation über KNXD

[erwin]

... ja, ich hab mal wo gelesen, dass multicast und WLAN nicht unbedingt Freunde sind...
In diesem Fall ist das noch verschärft, weil falls die WLAN-Verbindung nur ganz kurz unterbricht - und FHEM davon nichts mitbekommt, (was der NormalFall ist),
dann macht natürlich FHEM auch kein reconnect...
Ich hab mir die Sache mit der src-adressen nochmal angesehen, muss noch weiter testen, wird jedenfalls in der nächsten Version für Multicast und Host-mode gefixt.
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[ahermann86]

Hallo,

ich habe mit

Code Auswählen Erweitern

myKNXGW KNXIO H 192.168.2.150:3671 0.0.51
die Anbindung zu meinem Bus über das Gateway MDT SCN-IP000.02 hergestellt.
Soweit funktioniert das auch.

Wenn ich aber über die FHEM Befehlszeile z.B. mit

Code Auswählen Erweitern

get EG_Fenster_Arbeit g1
den Status Abfrage, erscheint ein leeres Fenster, das ich mit "ok" (Bild1) bestätigen kann.
Der Wert im Device wird dennoch aktualisiert.

Wenn ich aber

Code Auswählen Erweitern

get EG_Fenster.* g1
ausführe, passiert meistens nichts. Manchmal wird ein Device abgefragt.
In diesem Aufruf kommt auch das leere Fenster (Bild2) und manchmal ein request, der oben rechts mit dem schwarzen Fald angezeit wird.

Wenn ich das mit meinem bisherigen System (knxd/TUL) mache, werden alle betroffenen Devices abgefragt und das Fenster ist mit der Liste der requests gefüllt und die werden auch alle durchgeführt.

Ich habe in meinem neuen System bewusst das KNXIO direkt mit dem Gateway verbunden, da so knxd entfällt. Im Wiki zum KNXIO steht was mit Mode H und zeitkritisch.. ist dieser Fall damit betroffen oder habe ich einen anderen Denkfehler?

Gruß
Axel

[erwin]

Hi Axel,

get EG_Fenster.* g1

ist so nicht als cmd vorgesehen, wildcards sind in set/get cmd's nicht erlaubt. - diesen Fehler hab ich bisher nicht abgefangen...- sollte ich fixen!
Nachdem der set/get cmd immer über das KNX-Modul abgewickelt wird - und nur das IO-Modul  unterschiedlich ist, sollten hier keine Unterschiede sein. Das KNXIO-Modul ist allerdings um etliches schneller die cmd's abzuarbeiten, sodass du mgl. weise nicht alle requests sehen kannst...
Für deinen Problem gibts allerdings eine Lösung:

Code Auswählen Erweitern

{KNX_scan('EG_Fenster.*')} Details dazu zu finden unter "help KNX" auf der FHEM cmd-line.

Im Wiki zum KNXIO steht was mit Mode H und zeitkritisch..

Ob du betroffen bist, würdest du im Log sehen, die relevanten Messages sind im KNXIO- wiki beispielhaft dokumentiert.
l.g. erwin

[erwin]

Hi Axel,
Korrektur zu meinem post:
Ein set/ get cmd mit wildcards ist grundsätzlich erlaubt ( das wird durch eine core funktion in fhem.pl erledigt) - damit kann ich das im KNX-Modul gar nicht verhindern. - dort kommen die device namen einzeln / komplett an!
jetzt zum Problem damit:
Es gehen alle msg richtig aus FHEM hinaus (verifiziert mit ETS-Monitor).
Allerdings so schnell hintereinander, dass evtl. das KNX-GW bzw. der KNX-bus diese nicht so schnell verarbeiten kann.  Das ist auch der Grund, warum ich im KNX_scan eine Verzögerung um 200ms (nonblocking) zwischen den einzelnen requests eingebaut habe.
Das könnte auch den Unterschied zw. TUL und KNXIO Modul erklären. Das KNXIO Modul ist im processing etwa um den Faktor 4 schneller!

noch eine Frage: wie startest du das "get EG_Fenster.* ... ? Aus der FHEM-cmdline ? oder beim FHEM-start mittels notify, doif,.... ?
gibts im fhem Log irgendwelche fehler/msgs?

[ahermann86]

Hallo Erwin,

ich habe meine Fenster als Devices in mein neues FHEM per define eingefügt.
Da sie in dem Moment noch nie abgrufen waren, existierte jeweils das Reading getG1 noch nicht...

Ich habe dann versucht, alle Zustände in der FHEM Kommandozeile mit "get EG_Fenster.* g1" abzurufen.
Eine Fehlermeldung bekomme ich nicht sowie auch keine Log Einträge.

Gruß
Axel

[erwin]

Hi Axel!
danke fürs feedback,

Da sie in dem Moment noch nie abgrufen waren, existierte jeweils das Reading getG1 noch nicht...

...die Set/Get Kommandos funktionieren auch wenn es das entspechende reading noch nicht gibt und erzeugen/updaten auch das entsprechende reading, ALLERDINGS: Du must danach einen Browser refresh machen, damit du die neu erzeugten readings siehst! (NUR falls es das entsprechende reading vorher nicht gab! - sonst automatisch...) Das ist eine core-FHEM Funktion.
ich hab weitere Fragen:
1) Funktioniert ein "einzel device Get...." ?
2) hast du das KNX_Scan versucht ?
3) Gibts im Log Hinweise auf KNXIO Timeouts ? (Mode H)

PS: ich bin gerade dabei das KNX- und KNXIO-Modul zu überarbeiten - falls es Vorschläge/Probleme gibt... kann ich das noch berücksichtigen.
l.g. erwin   

[GammaTwin]

Grüße,

ich habe zum Jahreswechsel vom Mode M auf Mode H gewechselt. Hat etwas mit docker zu tun, ist aber hier nicht wichtig.

Ich beobachten die selben Effekte. Ich frage zum Bsp. mehrere Jalousiezustände mit Wildcards ab wenn ich Szenen für ganze Räume schalte. Die Sperre der MDT-Aktoren sendet nämlich keine Aktualisierung wenn diese durch eine zweite Gruppenadresse gesetzt wird.
Im Mode M läuft das problemlos. Im Mode H passiert viel weniger. Es gibt keinen Logeintrag im FHEM.

Bsp einer Jalousie-Sperren-Abfrage, Teil eines DOIFs, es sind 14 Adressen

Code Auswählen Erweitern

get KNX_02060..
Mode M: Löst 14 Abfragen aus. Laut ETS "schlagen" diese innerhalb von 0,007 Sekunden auf dem Bus auf. Die 14 Antworten starten 0,020 Sekunden nach der ersten Abfrage und brauchen 0,516 Sekunden
Mode H: Eine Abfrage erreicht die ETS. Die ETS antwortet nach 0,057 Sekunden

Auch so hatte ich das Gefühl, dass manche Abfrage nicht ankamen, kann das aber sicher sagen.

Habe es wieder auf Mode M umgestellt. Kann aber jederzeit testen.

[ahermann86]

Hallo Erwin,

1) Funktioniert ein "einzel device Get...." ?

Das resultierende Fenster bleibt zwar leer und man kann "ok" klicken aber das Reading des jeweiligen Devices wird abgefragt und aktualisiert.

2) hast du das KNX_Scan versucht ?

Nein, noch nicht - wo geht das?

3) Gibts im Log Hinweise auf KNXIO Timeouts ? (Mode H)

Ich habe "verbose" auf 5 gesetzt und das aus dem Log kopiert:

Code Auswählen Erweitern


2023.01.22 01:25:22 4: KNXIO_keepalive - expect ConnectionStateResponse
2023.01.22 01:25:22 5: DevIo_SimpleWrite myKNXGW: 0610020700102f000801000000000000
2023.01.22 01:25:22 5: KNXIO_Read: buf= 0610020800082f00
2023.01.22 01:25:22 5: KNXIO_Read: buf= 061004200017042f9a002900bce0114012280300800c47
2023.01.22 01:25:22 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 154
2023.01.22 01:25:22 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9a00
2023.01.22 01:25:22 4: KNXIO_decodeCEMI: src=1.1.64 dst=2/2/40 destaddrType=1 prio=3 hop_count=6 leng=3 data=800c47
2023.01.22 01:25:22 5: KNXIO_decodeCEMI: buf=C01140w022280c47
2023.01.22 01:25:22 4: KNXIO_processFIFO (myKNXGW): buf= C01140w022280c47 Nr_msgs= 1
2023.01.22 01:25:22 5: myKNXGW: dispatch C01140w022280c47
2023.01.22 01:25:22 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.64 dest=2/2/40 msg=C01140w022280c47
2023.01.22 01:25:22 5: KNXIO_processFIFO (myKNXGW): finished
2023.01.22 01:25:23 5: KNXIO_Read: buf= 061004200017042f9b002900bce011f007040300800000
2023.01.22 01:25:23 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 155
2023.01.22 01:25:23 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9b00
2023.01.22 01:25:23 4: KNXIO_decodeCEMI: src=1.1.240 dst=0/7/4 destaddrType=1 prio=3 hop_count=6 leng=3 data=800000
2023.01.22 01:25:23 5: KNXIO_decodeCEMI: buf=C011f0w007040000
2023.01.22 01:25:23 4: KNXIO_processFIFO (myKNXGW): buf= C011f0w007040000 Nr_msgs= 1
2023.01.22 01:25:23 5: myKNXGW: dispatch C011f0w007040000
2023.01.22 01:25:23 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.240 dest=0/7/4 msg=C011f0w007040000
2023.01.22 01:25:23 5: KNXIO_processFIFO (myKNXGW): finished
2023.01.22 01:25:31 5: KNXIO_Read: buf= 061004200017042f9c002900bce011f0070503008086b6
2023.01.22 01:25:31 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 156
2023.01.22 01:25:31 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9c00
2023.01.22 01:25:31 4: KNXIO_decodeCEMI: src=1.1.240 dst=0/7/5 destaddrType=1 prio=3 hop_count=6 leng=3 data=8086b6
2023.01.22 01:25:31 5: KNXIO_decodeCEMI: buf=C011f0w0070586b6
2023.01.22 01:25:31 4: KNXIO_processFIFO (myKNXGW): buf= C011f0w0070586b6 Nr_msgs= 1
2023.01.22 01:25:31 5: myKNXGW: dispatch C011f0w0070586b6
2023.01.22 01:25:31 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.240 dest=0/7/5 msg=C011f0w0070586b6
2023.01.22 01:25:31 5: KNXIO_processFIFO (myKNXGW): finished
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02633
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/51
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11633010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11633010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02636
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/54
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11636010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11636010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02637
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/55
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11637010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11637010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r0263a
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/58
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff1163a010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff1163a010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02639
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/57
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11639010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11639010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02632
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/50
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11632010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11632010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02634
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/52
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11634010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11634010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02635
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/53
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11635010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11635010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 061004200015042f9d002e00bce0fff11633010000
2023.01.22 01:25:34 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 157
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9d00
2023.01.22 01:25:34 4: KNXIO_decodeCEMI: src=15.15.241 dst=2/6/51 destaddrType=1 prio=3 hop_count=6 leng=1 data=00
2023.01.22 01:25:34 5: KNXIO_decodeCEMI: buf=C0fff1r0263300
2023.01.22 01:25:34 4: KNXIO_processFIFO (myKNXGW): buf= C0fff1r0263300 Nr_msgs= 1
2023.01.22 01:25:34 5: KNXIO_Read: buf= 061004200015042f9e002900bce011991633010040
2023.01.22 01:25:34 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 158
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9e00
2023.01.22 01:25:34 4: KNXIO_decodeCEMI: src=1.1.153 dst=2/6/51 destaddrType=1 prio=3 hop_count=6 leng=1 data=40
2023.01.22 01:25:34 5: KNXIO_decodeCEMI: buf=C01199p0263300
2023.01.22 01:25:34 5: KNXIO_processFIFO (myKNXGW): dispatch not complete, waiting
2023.01.22 01:25:34 5: myKNXGW: dispatch C0fff1r0263300
2023.01.22 01:25:34 4: KNX_Parse -enter: IO-name=myKNXGW src=15.15.241 dest=2/6/51 msg=C0fff1r0263300
2023.01.22 01:25:34 4: KNXIO_processFIFO (myKNXGW): buf= C01199p0263300 Nr_msgs= 1
2023.01.22 01:25:34 5: myKNXGW: dispatch C01199p0263300
2023.01.22 01:25:34 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.153 dest=2/6/51 msg=C01199p0263300
2023.01.22 01:25:34 5: KNXIO_processFIFO (myKNXGW): finished

Gruß
Axel

[erwin]

Hi Axel & GammaTwin !

Das resultierende Fenster bleibt zwar leer und man kann "ok" klicken....

Gut, aus KNX-sicht ist damit alles ok. Allerdings scheint ein Problem mit dem automatischen refresh der Webseite zu sein. Der OK dialog kommt nur, wenn FHEMWEB ein Prblem hat, siehe Attribute: longpoll...
bei mir sieht die Seite so aus (für ca. 5 sec):

hast du das KNX_Scan versucht ?

siehe mein posting vom 15.1.2023 hier....

KNXIO Timeouts: Timeout Log msgs kommen auf Loglevel 3, und schauen so aus:

Code Auswählen Erweitern

2021.12.13 00:00:08.023 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.12.15 13:12:09.045 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=67) - ack it
2021.12.15 13:12:10.012 3: KNXIO_Read: TunnelRequest received: out of sequence, (seqcntrRx=99, seqcntrTx= 45) - no ack & discard
... keine Notwendigkeit verbose hochzusetzen.

@GammaTwin:
Genau für diesen Fall hab ich das KNX_scan cmd gebaut....
Das Problem: lt. KNX-specs sind nicht mehr als 40 Messages/Sekunde auf dem KNX-Bus (TP1) empfohlen.... - dein Beispiel (14 msg / 0.007sec) hochgerechnet ergibt 20000 msg/sec!
Ich glaube nicht, dass die Messages zwischen FHEM und Router verworfen werden, da würden entsprechende Fehlermeldungen im FHEM Log auftauchen....
Im Mode M wirds funktionieren, weil der KNX-Router die multicast msg aktiv abholen muss, und das multicast protoll offensichtlich puffert....

KNX_scan ist ASYNCRON - soll heissen: wenn das command returned, sind die Antworten vom Bus noch nicht da!!! dass gilt allerdings auch für das Get-cmd, nur beim KNX_scan dauert es noch viel länger!!! (0.2 sec pro get ist die Verzögerung )

OT:

Die Sperre der MDT-Aktoren sendet nämlich keine Aktualisierung ....

...kann man evtl. mit ETS parametrierung ändern, siehe ETS Group Address Flag T
l.g.erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
...auch ein test für SVN-commit nach Server change...
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
ad. Log msg vereinfacht  - die Log-msg sehen jetzt immer so aus:

Code Auswählen Erweitern

<timestamp> <logLevel>: <devicename> [<subroutine zeilennummer>]: <log-text>
    also z.B. so:
2023.03.27 20:19:01.295 4: myKNXIO_R [KNXIO_ReadH 395]: TunnelRequest received - send Ack and decode. seqcntrRx= 232
das ermöglich ein gezieltes suchen/parsen nach messages. Ich hab mir das vom FRITZBOX Modul abgeschaut....
eine regex (zugegeben etwas "sperrig") könnte so aussehen:

Code Auswählen Erweitern

my ($date,$time,$loglvl,$dev,$sub,$subline,$logtxt) = $str =~ /^([^\s]+)\s([^\s]+)\s([0-5]):\s([\w]+)\s\[([\w]+)\s([\d]+)\]:\s(.*)$/gms;Sollte sich das bewähren, werde ich das auch fürs KNX-Modul übernehmen...
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Neuer EVENT:

Code Auswählen Erweitern

<device>:INITALIZED kommt bei fhem-start 30 Sekunden nach global:INITIALZED falls das device connected ist.
damit wirds möglich, mittels notify darauf zu reagieren und im notify z.b. "get <KNX-device> <Gadname>" abzufragen und FHEM mit der "Realität" zu synchronisieren. Beispiele hierzu in der cmd-ref vom KNX-Modul.
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Neu: FIFO und Rate-limit fürs senden FHEM->KNX
"Zu schnell hintereinander" FHEM set/get cmds werden jeweils verzögert, sodass auch langsamere knx-GW's keine Meldungen "verschlucken".
Hilft speziell bei set/get cmds mit DeviceNamen mit wildcards und beim KNX_scan cmd.
Im Log wird jeweils eine Zeile

Code Auswählen Erweitern

<timestamp> 3: <device> [KNXIO_Write2 590]: frequent IO-write cmd - delayedgeschrieben. Das ist kein Fehler, sondern eine Info. Evtl. setzte ich in der nächsten Version den LogLevel auf 4, damit die Meldung im Normalfall nicht kommt...
Meinungen dazu?
 
l.g. erwin

[erwin]

Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[MarkusN]

Hallo Erwin!

Seit einiger Zeit habe ich in meiner Logfile hunderte Meldungen dieser Art pro Tag:

2023.12.13 09:00:37 3: KNX [KNXIO_Write2 612]: frequent IO-write cmd - delayed

So wie ich das verstehe ist das ein neues Feature dieses Moduls. Ich wüsste gerne was die Ursache dafür ist, das meldende Gerät (KNX) ist jedoch mein KNXIO Device selber, also das Interface.
Wenn ich mir meinen Busmonitor anschaue sehe ich keine Auffälligkeiten, die Anzahl der Telegramme pro Minute beläuft sich auf 10-20, 2 bis 3 davon sind von FHEM gesendete Telegramme.

Im täglichen Betrieb merke ich nicht dass irgendwas verzögert ist oder gar nicht umgesetzt wird. Wie finde ich am besten raus was die Ursache für diese Logmeldungen sind?

Der Vollständigkeit halber hier noch die def von meinem KNXIO Device:

Code Auswählen Erweitern

define KNX KNXIO T 127.0.0.1:6720 1.1.243
attr KNX comment T 127.0.0.1:6720 1.1.243\
H 10.0.2.142:3671 1.1.241
attr KNX icon knx
attr KNX room 25_KNX->99_Interface
attr KNX verbose 3
#   DEF        T 127.0.0.1:6720 1.1.243
#   DeviceName 127.0.0.1:6720
#   FD         27
#   FUUID      629a2275-f33f-b36e-3cb5-b5253492dfe1a509
#   NAME       KNX
#   NR         319
#   PARTIAL   
#   PhyAddr    1.1.243
#   STATE      connected
#   SVN        28206 2023-11-25
#   TYPE       KNXIO
#   devioLoglevel 4
#   devioNoSTATE 1
#   eventCount 2
#   model      T
#   msg_count  258410
#   msg_time   2023-12-13 09:10:27
#   nextOpenDelay 10
#   KNXIOhelper:
#     FIFOMSG    C01112w0340401b8
#     FIFOTIMER  0
#     lastWrite  1702455027.96518
#     startdone  1
#     FIFO:
#     FIFOW:
#   READINGS:
#     2023-11-26 12:51:42   state           connected
#
setstate KNX connected
setstate KNX 2023-11-26 12:51:42 state connected


Grüße
Markus

[erwin]

Hi Markus,
ja das ist ein neues Feature. Es begrenzt die Anzahl der unmittelbar hintereinander gesendeten messages von FHEM an den KNX_Bus auf 10/Sekunde!.
Es hat einige Probleme gegeben da manche KNX-Interface's nicht alle Messages in der Geschwindigkeit verarbeiten konnte und damit etliche verloren gegangen sind.

Die Log msg's sind kein Fehler, sollen nur darauf hinweisen, dass etwas verzögert wird.
Ursache ist meist ein set cmd mit wildcard device spezifikaton, oder ein notify/doif das mehrere set-cmd unmittelbar hintereinander auslöst.
Nachdem dieses Feature "neu" ist, hab ich das timing eher konservativ ausgelegt, ich werde das limit in der nächsten version verringern und den Loglevel auf 4 setzten, dann kommen diese Log-msg nicht mehr.
Es gibt eine Design-Empfehlung (vom KNX-Standard) nicht mehr als 40 msg/Sekunde auf dem Bus zu haben. Nach dem ein "set cmd" ja üblicherweise eine Reaktion von Bus auslöst und evtl. auch noch für jede gesendete/empfangene msg aucch noch "ACK" msg geschickt werden... kommt man schnell auf diese 40/Sekunde.

Danke jedenfalls für den post, sehr hilfreich!
l.g. erwin

[StefanG]

Hi Erwin,

ich hatte mit einem MDT SCN-IP000.03 IP-Interface und MDT BE-GT2TW.02 Glastastern eine einfache Laufschrift mit einem Update-Intervall von 2 Sekunden programmiert, die mit der 00_KNXIO.pm vom 04/04/2023 problemlos funktioniert hat. Natürlich wird der KNX-Bus damit belastet, aber ich hatte keine merkbaren Probleme.

Mit der aktuellen 00_KNXIO.pm wird die Ausgabe der Laufschrift merklich verzögert, wenngleich sie vorerst weiter funktioniert. Nach rd. 1-2 Tagen laufen dann aber anscheinend irgendwelche FHEM-internen Puffer über und es werden Nachrichten am Taster ausgegeben, die schon Stunden vorher generiert wurden, d.h. die gesamte FHEM<->KNX-Kommunikation ist massiv verzögert und damit lahmgelegt. Nach einem FHEM-Neustart funktioniert es wieder für 1-2 Tage.

Mit der alten 00_KNXIO.pm funktioniert es auch in einer up-to-date FHEM-Umgebung weiterhin problemlos.

Nachdem ich in meinem Setup keinen Nutzen in dem neuen Feature sehe, daher die Frage, ob es sich vielleicht per Schalter auch wieder deaktivieren lässt?

Danke jedenfalls für Euren tollen Support hier!

LG
Stefan

[erwin]

Hi Stefan,
ich habe einen Verdacht... kanns aber (noch) nicht nachstellen.
kannst du bitte ein list vom KNXIO dev posten, sobald eine "merkliche" Verzögerung auftritt?
Gibts evtl. msgs im Log ?
Um es nachzuvollziehen wäre auch die def mit der du die Laufschrift erzeugst hilfreich.
l.g. erwin

[StefanG]

Hi Erwin,

danke! Habe jetzt wieder auf die neue KNXIO-Version gewechselt und melde mich mit "list KNXIO" in den nächsten Tagen, sobald die Kommunikation wieder "einschläft".

Unmittelbar wird die Anzeige etwas langsamer und es gibt folgende Logeinträge (alle 2 Sekunden wird die Schrift aktualisiert, zur vollen Minute etwas umfangreicher, d.h. das ist plausibel):

Code Auswählen Erweitern

2023.12.19 20:51:57.081 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:51:59.105 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:00.022 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:00.023 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:00.024 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:00.024 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:00.408 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:00.809 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:02.033 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:04.042 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.19 20:52:06.262 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed

Habe auch testweise Freezemon probiert, fallweise mit folgenden Einträgen im Log:

Code Auswählen Erweitern

2023.12.19 20:49:51.220 1: [Freezemon] Freezemon: possible freeze starting at 20:49:49, delay is 2.22 possibly caused by: tmr-KNXIO::KNXIO_dispatch2(KNXD) tmr-BOSEST_checkWebSocketConnection(BoseRec) tmr-KNXIO::KNXIO_processFIFO(KNXD) tmr-harmony_connect(HarmonyBuero) tmr-ENIGMA2_GetStatus(DMTwo) tmr-ENIGMA2_GetStatus(DM7020HD) tmr-at_Exec(at_updateKNXPerSecond) tmr-PRESENCE_StartLocalScan(AlexaKuechePresenceWLAN) tmr-PRESENCE_StartLocalScan(AlexaSZPresenceWLAN)

Sonst keine für mich auffälligen Log-Einträge.

Ich habe für die 6 Zeilen des Tasters 6 Geräte wie folgt definiert (Statustext1 bis Statustext6):

Code Auswählen Erweitern

Internals:
  DEF        9/0/5:dpt16:status
  FUUID      6469ec09-f33f-d238-8fbc-fac81e843050deaa
  IODev      KNXD
  NAME      Statustext1
  NR        201
  STATE      19.12.23 21:05
  TYPE      KNX
  eventCount 18
  model      dpt16
  GADDETAILS:
    status:
      CODE      09005
      MODEL      dpt16
      NO        1
      OPTION   
      RDNAMEGET  status-get
      RDNAMESET  status-set
      SETLIST    :multiple,>CLR<
  GADTABLE:
    09005      status
  READINGS:
    2023-12-19 20:48:20  IODev          KNXD
    2023-12-19 21:05:00  last-sender    fhem
    2023-12-19 21:05:00  state          19.12.23 21:05
    2023-12-19 21:05:00  status-set      19.12.23 21:05
Attributes:
  group      KNX
  room      KNX

... und noch der Auszug aus dem Code für die Laufschrift, der aber m.E. unkritisch sein sollte. Es werden nur regelmäßig die Statustexte neu geschrieben:

Code Auswählen Erweitern

#-----------------------------------------------------------------------------------------------------------------#
sub updateKNXPerMinute() {
 
  (my $sec, my $min, my $hour, my $mday, my $month, my $year) = localtime(); 
  my $total = (($hour * 60) + $min) * 60 + $sec + 5;
  # Zeitangaben ermitteln
 
  updateKNXHeaderText();
  updateWakeupTimers(); # ruft auch updateKNXWakeupText()
  updateTVTimers();
  updateRadioTimers();
  updateKNXPerSecond(); # sicherheitshalber auch das aufrufen, damit synchronisiert wird
  # regelmäßiger Hilfsaufruf für KNX-Anzeige, TV-Zeit und Wecker in FHEMApp 
 
  $total = $total + 60;
  my $text = sprintf("%02d:%02d:00", ($total / 60 / 60) % 24, ($total / 60) % 60);
  setTimer("at_updateKNXPerMinute1", $text, "updateKNXPerMinute()", "Allgemein", "");
  # jeweils zur nächsten vollen Minute at auslösen
  # teilweise erfolgt Aufruf vor voller Minute, daher 5 Zusatzsekunden addieren

  $total = $total + 60;
  $text = sprintf("%02d:%02d:00", ($total / 60 / 60) % 24, ($total / 60) % 60);
  setTimer("at_updateKNXPerMinute2", $text, "updateKNXPerMinute()", "Allgemein", "");
  # sicherheitshalber zweiten Timer setzen (in zwei Minuten)

  $total = $total + 8 * 60;
  $text = sprintf("%02d:%02d:00", ($total / 60 / 60) % 24, ($total / 60) % 60);
  setTimer("at_updateKNXPerMinute3", $text, "updateKNXPerMinute()", "Allgemein", "");
  # sicherheitshalber dritten Timer setzen (in 10 Minuten)
}

#-----------------------------------------------------------------------------------------------------------------#
sub updateKNXHeaderText() {

  (my $sec, my $min, my $hour, my $mday, my $month, my $year) = localtime();
 
  my $total = (($hour * 60) + $min) * 60 + $sec + 5;
  my $text = sprintf('%02d.%02d.%02d %02d:%02d', $mday, $month + 1, $year % 100,
                                                ($total / 60 / 60) % 24, ($total / 60) % 60);
  # teilweise erfolgt Aufruf vor voller Minute, daher 5 Zusatzsekunden addieren
 
  setKNXText(1, $text, 0);
  # Datum/Uhrzeit in KNX-Feld schreiben
 
  $text = sprintf("A: %s/%s/%s km/h", ReadingsNum("Wetter", "temperature", "", 1), ReadingsVal("Wetter", "weather", ""), ReadingsVal("Wetter", "wind", ""));
  $text = (length($text) > 28 ? substr(sprintf("%-42s", $text), 0, 42) : # auf Vielfaches von 14 Stellen formatieren
            (length($text) > 14 ? substr(sprintf("%-28s", $text), 0, 28) : substr(sprintf("%-14s", $text), 0, 14))) .
          sprintf("I1: %4s/%-5s", ReadingsNum("TemperaturKinderzimmer", "state", "", 1), getModusText()) .
          sprintf("I2: %4s/%-5s", ReadingsNum("TemperaturBewegungsmelder", "state", "", 1), getModusText());
  setKNXText(2, $text, 14);
  # Temperatur und Modus in KNX-Feld schreiben (Einzelzimmertemperatur nicht skalierbar)
}

#-----------------------------------------------------------------------------------------------------------------#
# Routinen für Weckersteuerung auf MDT-Taster (Zeile 3 + 4)
sub updateKNXWakeupText() {
  my $wakeup = getCurrentWakeupSwitch();
  setKNXText(3, isWakeupOn($wakeup) ? Value("WakeupTime". $wakeup) : "--:--", 0);
 
  my $timer = ReadingsVal("WakeupTime" . $wakeup, "timer", "default");
  if ($timer ne "-") { $timer = " (" . $timer . ")"; } else { $timer = ""; } 
  setKNXText(4, ReadingsVal("WakeupTime" . $wakeup, "text", "default") . $timer, 7);
 
  if ($timer ne "") {
    fhem("set WakeupLED 3"); # Grüne LED, wenn Wecker ein und nächster Wecker gewählt
  } else {
    fhem("set WakeupLED 2"); # Rote LED, wenn Wecker aus und nächster Wecker gewählt
  }
  # abhängig von Wecker-Status LEDs setzen
}

#-----------------------------------------------------------------------------------------------------------------#
# Spaltenweise Laufschrift auf KNX-Taster implementieren
my @knxText = ("leer", "init", "init", "init", "init", "init");
my @knxPos = (0, 0, 0, 0, 0, 0);
my @knxStep = (0, 0, 0, 0, 0, 0);
my $knxStatusText = "init";
my $knxStatusPos = 0;

sub setKNXText($$$) {
  my ($nr, $text, $step) = @_;
 
  $knxText[$nr] = $text;
  $knxPos[$nr] = 0;
  $knxStep[$nr] = $step;
  # Text merken und vorne beginnen
}

sub updateKNXPerSecond() {

  if ($knxText[1] ne "") { doKNXText(1); }
  if ($knxText[2] ne "") { doKNXText(2); }
  if ($knxText[3] ne "") { doKNXText(3); }
  if ($knxText[4] ne "") { doKNXText(4); }
  if ($knxText[5] ne "") { doKNXText(5); }
  if ($knxStatusText ne "") { doKNXStatusText(); }
  # belegte Zeilen aktualisieren
 
  setTimer("at_updateKNXPerSecond", "+00:00:02", "updateKNXPerSecond", "Allgemein", "");
  # Timer neu setzen
}

sub doKNXText($) {
  my ($nr) = @_;
 
  my $text = $knxText[$nr];
  my $pos = $knxPos[$nr];
  my $step = $knxStep[$nr];

  if ($pos + 14 - $step >= length($text)) {
    $pos = 0;
  }
  # wenn kein Resttext mehr vorhanden, dann wieder vorne beginnen

  if ($pos > 0 && (substr($text, $pos - 1, 2) eq "°" || substr($text, $pos - 1, 2) eq "ß")) { $pos = $pos + 1; }
  # nur "halbes" Unicode-Zeichen °/ß am Anfang, dann gleich ein Zeichen weiter springen
 
  if (substr($text, $pos, 1) eq " ") { $pos = $pos + 1; }
  # Leerzeichen am Anfang, dann gleich ein Zeichen weiter springen

  my $subtext = ($pos <= length($text)) ? substr($text, $pos, 14) : "";
  if (($pos + 13 <= length($text)) &&
      ((substr($text, $pos + 13, 2) eq "°") || (substr($text, $pos + 13, 2) eq "ß"))) {
    $subtext = substr($subtext, 0, 13);
  }
  # nur "halbes" Unicode-Zeichen °/ß am Ende, dann abschneiden 
 
  fhem("set Statustext$nr status " . (($subtext eq "") ? ">CLR<" : $subtext));
  $knxPos[$nr] = $pos + $step;
  # Nächsten Teil der Zeile anzeigen und neue Position merken 

  if ($step == 0 || length($text) <= 14) {
    $knxText[$nr] = "";
  }
  # wenn keine Laufschrift gewünscht oder zu kurz, Text löschen, womit er nicht mehr angezeigt wird
}

#-----------------------------------------------------------------------------------------------------------------#
# Zeilenweise Laufschrift auf KNX-Taster implementieren

sub setKNXStatusText($)
{
  my ($text) = @_;

  $text =~ s/ä/ae/g;
  $text =~ s/ö/oe/g;
  $text =~ s/ü/ue/g;
  $text =~ s/ß/ss/g;
  # Umlaute entfernen
 
  $knxStatusText = $text;
  $knxStatusPos = 0;
  # Text merken und vorne beginnen 
}

sub doKNXStatusText() {

  my $text = $knxStatusText;
  my $pos = $knxStatusPos;

  if (length($text) > 28) {
  } else {
    $knxStatusText = "";
  }
  # sofern mehr als zwei Zeilen benötigt werden, Timer für Laufschrift aktivieren
 
  if ($pos * 28 >= length($text)) {
    $pos = 0;
  }
  # wenn kein Resttext mehr vorhanden, dann wieder vorne beginnen

  $text = substr($text, $pos * 28, 28);
  fhem("set Statustext5 status " . substr($text, 0, 14));
  $text = length($text) > 14 ? substr($text, 14) : "";
  fhem("set Statustext6 status " . (($text eq "") ? ">CLR<" : $text));
  $knxStatusPos = $pos + 1;
  # Zwei Zeilen anzeigen und neue Startzeile merken, auch für PanelGruppe verwenden
}

Soweit mal als Erstinfo, danke nochmals!

LG
Stefan

[StefanG]

Hi Erwin,

die Nacht hat schon gereicht. Der Taster ist "eingeschlafen" und ja, man sieht einen großen Backlog. Es sind ca. 10.000 Zeilen im Puffer.

Ich hoffe, das hilft. Danke nochmals!

LG
Stefan

Code Auswählen Erweitern

Internals:
  DEF        T 127.0.0.1:6720 1.1.200
  DeviceName 127.0.0.1:6720
  FD        52
  FUUID      64836d77-f33f-d238-6ac8-05813af6fc26a2e3
  NAME      KNXD
  NR        215
  PARTIAL   
  PhyAddr    1.1.200
  STATE      connected
  SVN        28206 2023-11-25
  TYPE      KNXIO
  devioLoglevel 4
  devioNoSTATE 1
  eventCount 2
  model      T
  msg_count  33351
  msg_time  2023-12-20 07:26:58
  nextOpenDelay 10
  KNXIOhelper:
    FIFOMSG    C01104w0130641bccccd
    FIFOTIMER  0
    lastWrite  1703053618.77262
    startdone  1
    FIFO:
    FIFOW:
      T
      ␔'H␆�I1: 20.8/Nacht
      T
      ␔'H␄�Heute Mi (+00:
      T
      ␔'H␆�I2: 22.2/Nacht
      T
      ␔'H␄�i (+00:03)
      T
      ␔'H␆�A: 2.7/Regen/3
      T
      ␔'H␄�Heute Mi (+00:
      T
      ␔'H␆�.6 km/h
      T
      ␔'H␄�i (+00:03)
      T
      ␔'H␆�I1: 20.8/Nacht

... (ca. 10.000 Zeilen)

      ␔'H␄�Do (+22:49)
      T
      ␔'H␆�I1: 21.0/Nacht
      T
      ␔'H␄�Morgen Do (+22
  READINGS:
    2023-12-19 20:48:20  state          connected
Attributes:
  devStateIcon connected:control_on_off@green
  group      Allgemein
  room      Allgemein


[erwin]

OK danke und noch eine Bitte:
kannst du im Log suchen, ob in der Zeit von FHEM-start bis zum "einschlafen" irgendwelche disconnect od. connect messages vom KNXIO dev auftauchen?
ich hab versucht, das Problem nachzustellen bisher ohne Erfolg, aber ich vermute wo das Problem ist.
Ich muss noch etwas länger testen...
klar ist mittlerweile, warum dein FHEM irgendwann "stehen bleibt" oder evtl. automatisch restarted wird: mit jeder zusätzlichen msg im buffer, steigt der Speicherbedarf und irgendwann zieht das Linux die Notbremse und killed / restarted FHEM!
l.g. erwin

[StefanG]

Hi Erwin,

nach knapp 48 Stunden sind jetzt ca. 18000 Zeilen im Puffer, d.h. sie steigen weiter an.

Im Log finden sich unzählige delayed-Meldungen und Freezemon-Einträge, aber keine connect/disconnect vom KNXIO.

Code Auswählen Erweitern

2023.12.20 00:32:28.190 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed
2023.12.20 00:32:28.314 3: KNXD [KNXIO_Write2 612]: frequent IO-write cmd - delayed

2023.12.21 00:00:02.963 1: [Freezemon] Freezemon: possible freeze starting at 00:00:00, delay is 2.963 possibly caused by: tmr-CODE(0x555f06fbd478)(KNXIO_Write2) tmr-SYSSTAT_GetUpdate(NGSwitch26) tmr-SYSSTAT_GetUpdate(NGSwitch8) tmr-SYSMON_Update(sysmon) tmr-BOSEST_checkWebSocketConnection(BoseRec) tmr-BOSEST_checkWebSocketConnection(BoseRec) tmr-FRITZBOX_Readout_Start(N/A) tmr-FRITZBOX_Readout_Start(N/A) tmr-PRESENCE_StartLocalScan(GristPresenceWLANGuest) tmr-PRESENCE_StartLocalScan(HarmonyWZPresenceWLAN) tmr-FRITZBOX_Readout_Start(N/A) tmr-harmony_connect(HarmonyWZ) tmr-PRESENCE_StartLocalScan(AlexaKuechePresenceWLAN) tmr-PRESENCE_StartLocalScan(SeimaPresenceWLANMAC) tmr-PRESENCE_StartLocalScan(GristPresenceWLANMAC) tmr-PRESENCE_StartLocalScan(AlexaSZPresenceWLAN)

Beim FHEM-Start habe ich noch das gefunden:

Code Auswählen Erweitern

2023.12.19 20:47:49.135 3: KNXD [KNXIO_closeDev 928]: closed
2023.12.19 20:47:50.796 3: KNXD [KNXIO_Write 502]: called while not connected! Msg: w090060049323a2032332e312f5461670000 lost
2023.12.19 20:47:50.798 3: KNXD [KNXIO_Write 502]: called while not connected! Msg: w09004004d6920282b30393a323829000000 lost
2023.12.19 20:47:50.800 3: KNXD [KNXIO_Write 502]: called while not connected! Msg: w09007004648454d2d53797374656d206765 lost
2023.12.19 20:47:50.801 3: KNXD [KNXIO_Write 502]: called while not connected! Msg: w090080073746f707074202e2e2e00000000 lost

2023.12.19 20:48:20.381 3: KNXD [KNXIO_handleConn 878]: initial-connect

Kann ich noch was helfen? Danke jedenfalls!

LG
Stefan

[erwin]

Hi Stefan,
ok danke fürs Feedback, ja das bestätigt meine Theorie!
ich hab jetzt 48 Stunden mit meinen fix getestet, sollte funtionieren.

wegen Log msg beim Start:
offensichtlich versucht irgendein notify/doif/at... unmittelbar nach global:initialized event, set od. get cmd's zu machen.
Das KNX-system ist aber noch nicht fertig initialisiert! - siehe die nachfolgende "initial-connect" message.
Falls diese set od. get cmd's im initial_nf sind, kannst du sie in ein notify KNXIO:INITIALIZED verschieben... Dieser event wird genau dafür ausgelöst.
l.g. erwin

[erwin]

Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Die "frequent IO-write cmd - delayed" Log-msg's kommen jetzt ab LogLvl 4.

@stefan:
Dein problem sollte gefixt sein.
Es gibt jetzt ein Attribut "KNXIOdebug" wenn du das auf 1 setzt, kannst du im Log verfolgen, wie hoch die Anzahl der msg in der queue sind und wann sie abgearbeitet werden.
Mein Stresstest: 4 set und 1 get cmd unmittelbar hintereinander, mit 2 sekunden Wiederholung, ergibt folgendes Log:

Code Auswählen Erweitern

2023.12.21 21:12:02.280 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0 # vom vorigen zyklus
2023.12.21 21:12:03.718 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0 # 1stes set gesendet
2023.12.21 21:12:03.719 1: myKNXIOTest [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1        # kommt in die queue
2023.12.21 21:12:03.720 1: myKNXIOTest [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 2        # kommt in die queue
2023.12.21 21:12:03.722 1: myKNXIOTest [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 3        # kommt in die queue
2023.12.21 21:12:03.723 1: myKNXIOTest [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 4        # kommt in die queue
2023.12.21 21:12:04.068 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 3 # 2tes set gesendet, noch 3 warten
2023.12.21 21:12:04.139 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 2 # 3tes set gesendet
2023.12.21 21:12:04.209 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 1 # 4tes set gesendet
2023.12.21 21:12:04.280 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0 # get gesendet
2023.12.21 21:12:05.718 1: myKNXIOTest [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0 # nächster zyklusWichtig: es muss innerhalb von einigen Sekunden irgendwann ein remain=0 vorkommen. Falls nicht, überlastet du den KNX-Bus und es gehen msg's am Grünen-Kabel verloren ohne dass du es merkst! Das ist dzt. im Modul noch nicht abgefangen! Ich bin nicht sicher, wie ich das realisieren soll, jedenfalls müsste ich msg's aktiv verwerfen!
Ich hab jetzt in etlichen Foren recherchiert, andere Implementationen blockieren grundsätzlich nach jeder gesendeten msg für 50ms - so wollen wir das nicht, das würde FHEM blockieren.

l.g. erwin

[StefanG]

Hi Erwin,

super, danke! Schaut mal gut aus nach ein paar Minuten. Immer zur vollen Minute gibt es etwas mehr Traffic, aber das ist so gewollt und "remain=0" folgt. Langzeittest folgt noch.

Ist das Limit der Messages noch auf 10/Sekunde? Wenn ja, wäre da noch Reserve bis zu 40/Sekunde, sofern das IP-Interface das kann, oder? Das MDT-Interface dürfte da recht tolerant sein bzgl. der Geschwindigkeit.

Code Auswählen Erweitern

2023.12.21 22:03:56.511 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:03:56.512 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:03:56.652 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:03:58.519 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:03:58.523 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:03:58.660 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:00.006 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:00.017 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:00.017 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 2
2023.12.21 22:04:00.018 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 3
2023.12.21 22:04:00.018 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 4
2023.12.21 22:04:00.357 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 3
2023.12.21 22:04:00.428 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 2
2023.12.21 22:04:00.499 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 1
2023.12.21 22:04:00.570 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:02.023 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:02.025 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:02.164 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:04.742 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:04.745 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:04.883 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:07.844 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:07.846 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:07.985 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:09.853 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:09.857 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:09.993 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:11.863 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:11.866 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:12.003 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:13.873 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:13.875 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:14.013 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:15.882 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:15.886 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:16.023 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:19.011 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:19.013 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:19.152 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:21.019 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:21.022 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:21.159 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:23.028 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:23.030 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:23.168 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:25.036 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:25.039 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:25.177 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:27.045 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:27.047 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:27.186 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:30.182 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:30.184 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:30.322 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:32.191 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:32.194 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:32.331 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:34.201 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:34.203 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:34.342 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:36.208 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:36.211 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:36.349 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:38.217 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:38.220 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:38.358 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:41.344 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:41.347 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:41.485 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:43.354 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:43.358 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:43.494 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:45.363 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:45.366 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:45.504 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:47.374 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:47.377 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:47.514 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:49.384 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:49.387 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:49.525 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:52.514 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:52.516 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:52.655 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:54.523 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:54.527 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:54.664 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:56.533 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:56.536 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:56.674 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:58.540 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:04:58.543 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:04:58.681 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:00.435 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:00.441 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:05:00.442 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 2
2023.12.21 22:05:00.442 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 3
2023.12.21 22:05:00.443 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 4
2023.12.21 22:05:00.787 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 3
2023.12.21 22:05:00.857 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 2
2023.12.21 22:05:00.928 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 1
2023.12.21 22:05:00.998 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:02.451 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:02.454 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:05:03.680 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:04.460 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:04.463 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:05:04.745 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:06.470 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:06.473 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:05:06.610 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:08.479 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:08.482 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:05:08.620 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:11.584 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:11.586 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1
2023.12.21 22:05:11.725 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:13.593 1: KNXD [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0
2023.12.21 22:05:13.597 1: KNXD [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 1

Danke jedenfalls nochmals für den tollen Support!

LG
Stefan

[erwin]

Das Limit ist jetzt 14/sekunde, - oder anders formuliert alle 0,07 Sekunden wird eine msg gesendet.
Allerdings kann es ohne Probleme kurzzeitig (etliche Sekunden) überschritten weden, es sollte nur nicht permanent über 14/sek. sein, dann gibts die erwähnten Probleme..
Viel Reserve ist da nicht, 14 msg bedeuten 14 Antworten vom Bus, plus Handshake, und msg die direkt von einem KNX-Geber/Sensor zu einem KNX-Aktor gehen,...
Da IP-Interface wird nicht das Problem sein, der KNX-Bus kann am "Grünen Kabel" 9600 Bps... und nicht mehr. Speziell bei deinen 14Byte langen msg's, da kommen noch zumindest 12 Bytes Overhead/msg dazu...
Der dpt16 sendet IMMER 14 Byte user daten, auch wenn du nur ein einziges Zeichen senden willst!
Dein Log schaut gut aus! Da sollte es keine Probleme geben.
... wieder was gefixt...
l.g. erwin

[GammaTwin]

Super Feature!

Wildcards, ich komme

Ich habe mal "wild" ins System gefragt und über 400 Anfragen kreiert. Wurden sauber abgearbeitet.
Einzige Auffälligkeit. Zwischen der letzten Anfrage 08:07:50 und dem ersten Remain 08:08:19 liegen 29 Sekunden.

Nochmal, mega Feature.

Code Auswählen Erweitern

2023.12.22 08:07:50.813 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 406
2023.12.22 08:07:50.816 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 407
2023.12.22 08:07:50.819 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 408
2023.12.22 08:07:50.823 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 409
2023.12.22 08:07:50.826 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 410
2023.12.22 08:07:50.829 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 411
2023.12.22 08:07:50.832 1: KNX [KNXIO_Write2 628]: DEBUG1>>frequent IO-write - Nr.msg= 412
2023.12.22 08:08:19.682 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 411
2023.12.22 08:08:19.752 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 410
2023.12.22 08:08:19.823 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 409
2023.12.22 08:08:19.893 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 408
2023.12.22 08:08:19.963 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 407
...
2023.12.22 08:09:29.081 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 2
2023.12.22 08:09:29.151 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 1
2023.12.22 08:09:29.222 1: KNX [KNXIO_Write2 651]: DEBUG1>>IO-write processed- Nr.msg remain= 0

[erwin]

Einzige Auffälligkeit. Zwischen der letzten Anfrage 08:07:50 und dem ersten Remain 08:08:19 liegen 29 Sekunden.

Ja, stimmt: 400x0,07 ~ 28 sekunden...
sehr guter Stress-Test!

PS: jetzt deinen Log nochmal angeschaut: das erste remain nach 29 sek, das ist nicht ok, muss ich nochmal nachbessern!
l.g. erwin

[erwin]

Hi Gammatwin,

kannst du bitte in der 00_KNXIO.pm die Zeile 629

Code Auswählen Erweitern

InternalTimer($nextwrite + $adddelay, \&KNXIO_Write2,$hash);
#ändern in:
InternalTimer($nextwrite + 0.07, \&KNXIO_Write2,$hash);
und deinen Test wiederholen ?
ich weiß nicht mehr, warum ich diesen Unfug eingebaut hab. Vermutlich hab ich etliche Varianten ausprobiert.....
l.g.erwin

[GammaTwin]

Ich habe es mit der alten Variante nochmal nachgestellt und es gab wieder die Pause.

Mit der neuen Zeile, gibt es keine Pause.

[erwin]

ok, danke fürs testen, ich werde noch ein wenig optimieren und testen. Für morgen geht sich eine neue Version nicht mehr aus....
l.g. erwin

[StefanG]

Auch nochmals kurzes Feedback von mir:

* Auch nach drei Tagen ist die Laufschrift am Taster stabil, d.h. ja, der Fix hat funktioniert. Maximale Queue-Size ist üblicherweise 3-4, nach Freezes (z.B. von BOSEST) maximal 16.
* Wenn ich in Zeile 629 und 632 jeweils 0.07 durch 0.01 ersetze, läuft die Schrift nochmals schneller und bei mir ohne erkennbare negative Nebeneffekte.

Ich lasse das jetzt mal so weiterlaufen und beobachte ...

lg
Stefan

[erwin]

Hi Stefan & GammaTwin

danke nochmal fürs Feedback, ich werde das demnächst einchecken.

Wenn ich in Zeile 629 und 632 jeweils 0.07 durch 0.01 ersetze, läuft die Schrift nochmals schneller und ...

Ja, das glaube ich dir, weil vermutlich der KNX-Router auch noch puffert und du das "nur" jede Minute auslöst.
Die Limits sind in der neuen Version so: 14 msg/sekunde (gemittelt), können aber kurzeitig überschritten werden. Falls innerhalb von 30 Sekunden nicht mindestens EINMAL der "remain counter" (=Alle msg wurden gesendet) 0 ist, gibts eine Warning im Log - noch ohne Konsequenz...
Das ist auch etwas abhängig von der Performance des Systems.
Am Benchmark von GammaTwin würde ich schätzen zwischen 400-500 unmittelbar gesendete msgs.
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!

siehe auch mein post v. 13:07
Es gibt eine neue Log-msg falls die write-queue nicht komplett abgearbeitet werden kann, innerhalb von 30 Sekunden!

Code Auswählen Erweitern

... number of write cmds exceed limits of KNX-Bus; Falls diese msg kommt, sollte man überlegen warum soviele set/get request passieren....
Dzt. noch ohne Konsequenz, mit dem Risiko das man damit FHEM lahmlegen kann. Konsequenz wäre, die write-queue zu löschen - msg gehen verloren!
l.g. erwin

[GammaTwin]

Am Benchmark von GammaTwin würde ich schätzen zwischen 400-500 unmittelbar gesendete msgs.

Es waren 438 get-Abfragen

[StefanG]

Hi Erwin,

Du hattest mir in einem früheren Post geschrieben, dass man beim FHEM-Start auf "KNXIO:INITIALIZED" warten soll, bevor man Infos auf den KNX-Bus schickt. Ich habe gesehen, dass vorher auch ein "KNXIO:CONNECTED" geschickt wird. Da kann aber noch nichts geschickt werden. Soweit verstanden.

Ich habe jetzt aber die Konstellation, dass beim FHEM-Start der KNX-IP-Router stellenweise noch nicht bereit ist und KNXD mehrmals neu startet, bis die Verbindung steht. Es wird dann beim FHEM-Start kein KNXIO:INITIALIZED geschickt, weil eben der KNXD noch nicht bereit. Sobald der KNX-IP-Router dann nach dem FHEM-Start zur Verfügung steht, KNXD läuft und die Verbindung steht, wird ein KNXIO:CONNECTED geschickt, aber es kommt kein KNXIO:INITIALIZED mehr.

D.h. KNXIO:INITIALIZED ist m.E. wertlos, weil es nur dann geschickt wird, wenn FHEM noch nicht fertig gestartet hat. Wenn KNXIO erst nach dem FHEM-Start connected, dann wird eben kein INITIALIZED mehr geschickt. Ich muss daher stattdessen auf KNXIO:CONNECTED abfragen, was aber dann beim FHEM-Start zu Fehlern im Log führt. Ich kann zu diesem Zeitpunkt m.E. aber nicht wissen, ob ich noch auf ein KNXIO:INITIALIZED warten muss (weil FHEM noch startet) oder nicht (weil FHEM schon läuft und nur KNXIO neu connected hat).

Evtl. habe ich hier etwas falsch verstanden, evtl. kann das auch ein Bug sein. Bitte gerne um Deine Rückmeldung dazu.

Vielen Dank vorab!

LG
Stefan

[erwin]

ok, zur Klärung:
Bei der ersten Verbindung mit einem KNX_Router wird KEIN KNXIO:connected geschickt, stattdessen nach Verzögerung- (wiel da auch noch Handshakes mit dem GW passieren) ein KNXIO:INITIALIZED.
Diese Logik ist dazu da, die FHEM-internen Strukturen nach FHEM-start und das Handshake mit dem Router fertig zu bekommen, bevor Dinge auf den Bus geschickt werden, aber NICHT um Verbindungsprobleme zu lösen.
Wenn wie in deinem Fall vermutet, unmittelbar nach FHEM start der knxd kurz erreichbar ist, aber dann sofort restarted, wird natürlich kein INITIALIZED ausgelöst, - FHEM versucht dann einen weiteren Verbindungsaufbauten und generiert, falls erfolgreich, ohne Verzögerung ein KNXIO:connected !
Du hast leider kein list (ich nehme an es geht um ein notify) geposted, daher kann ich nur raten...
Vorschlag:

Code Auswählen Erweitern

defmod knxio_nf notify <device>:INITIALIZED|<device>:connected {...} - also in deinem Fall beides berücksichtigen.
Details dazu in der cmd.ref!
Die Frage bleibt, warum der knxd mehrmals starten muss... Evtl. kann man ja auch an der startreihenfolge / Abhängigkeiten drehen...
l.g. erwin

Edit: Ich hab eine Idee, wie ich das lösen könnte....
Dazu brauche ich ein Log vom FHEM start - ab '<KNXIO-dev> opening mode=...' bis ca. 1 Minute nach 'FHEM global:INITIALIZED occured'

[StefanG]

Hi Erwin,

danke für Dein Feedback!

Ich mache mit notify folgendes:

Code Auswählen Erweitern

Internals:
   DEF        KNXD:(CONNECTED|INITIALIZED) { knxStarted($EVENT) }
   FUUID      658c735f-f33f-2679-1718-e5016136e52bb75f
   NAME       notify_knx_started
   NR         431
   NTFY_ORDER 50-notify_knx_started
   REGEXP     KNXD:(CONNECTED|INITIALIZED)
   STATE      2024-01-14 21:50:57
   TRIGGERTIME 1705265457.06469
   TYPE       notify
   READINGS:
     2024-01-14 21:37:08   state           active
     2024-01-14 21:50:57   triggeredByDev  KNXD
     2024-01-14 21:50:57   triggeredByEvent CONNECTED
Attributes:
   room       Allgemein


Code Auswählen Erweitern

sub knxStarted($) {
  my ($event) = @_;
 
  if ($event eq "CONNECTED") {
    sendTelegram("KNXD gestartet ($event/Schritt 2) ...");
  } elsif ($event eq "INITIALIZED") {
    sendTelegram("KNXD gestartet ($event/Schritt 3) ...");

    updateKNXPerSecond();

    fhem("set InBetrieb_Dimmaktor off");
    fhem("set InBetrieb_Glastaster off");
    fhem("set InBetrieb_IPRouter off");
    fhem("set InBetrieb_Jalousieaktor off");
    fhem("set InBetrieb_LEDController off");
    fhem("set InBetrieb_Schaltaktor off");
  }
}

Im Erfolgsfall kommt CONNECTED und INITIALIZED, im Fehlerfall nur CONNECTED wie folgt:

Code Auswählen Erweitern

2024.01.14 16:22:03.244 3: KNXD [KNXIO_Define 244]: opening mode=T
2024.01.14 16:22:03.257 3: INIT: FB4040_debugLog
2024.01.14 16:22:03.272 3: [SamsungAV] SamsungLED defined with host: 192.168.0.21 port: 55000
2024.01.14 16:22:15.515 3: BOSEST: BOSE SoundTouch v2.2.1
2024.01.14 16:22:15.542 3: RokuBuero: ssdp responder started
2024.01.14 16:22:15.542 3: RokuBuero: listener started
2024.01.14 16:22:15.542 3: RokuWZ: ssdp responder started
2024.01.14 16:22:15.542 3: RokuWZ: listener started
2024.01.14 16:22:15.561 3: freezemon defined FreezeMon freezemon
2024.01.14 16:22:15.561 3: [Freezemon] FreezeMon: Wrapping Log3
2024.01.14 16:22:15.564 1: Including ./log/fhem.save
2024.01.14 16:22:15.597 2: Alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx -s
2024.01.14 16:22:15.598 3: Alexa: starting
2024.01.14 16:22:15.603 3: Alexa: using logfile: ./log/alexa-2024-01-14.log
2024.01.14 16:22:15.604 3: Opening GristPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.605 3: GristPresenceBT device opened
2024.01.14 16:22:15.606 3: Opening GristPresenceBTKueche device 10.0.1.13:5111
2024.01.14 16:22:15.609 3: GristPresenceBTKueche device opened
2024.01.14 16:22:15.610 3: Opening GristPresenceBTWZ device 10.0.1.14:5111
2024.01.14 16:22:15.613 3: GristPresenceBTWZ device opened
2024.01.14 16:22:15.614 3: harmony: starting discovery
2024.01.14 16:22:15.614 3: harmony: sending discovery
2024.01.14 16:22:15.615 3: harmony: sending discovery
2024.01.14 16:22:15.615 3: Opening KeeperPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.616 3: KeeperPresenceBT device opened
2024.01.14 16:22:15.707 2: PhilipsHue: autocreate: created 0/0/0 devices (ignored 0/0/4)
2024.01.14 16:22:15.709 3: Opening PolarPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.710 3: PolarPresenceBT device opened
2024.01.14 16:22:15.714 3: RokuBuero: ssdp responder stoped
2024.01.14 16:22:15.714 3: RokuBuero: ssdp responder started
2024.01.14 16:22:15.717 3: RokuBuero: listener stoped
2024.01.14 16:22:15.719 3: RokuBuero: listener started
2024.01.14 16:22:15.719 3: RokuWZ: ssdp responder stoped
2024.01.14 16:22:15.719 3: RokuWZ: ssdp responder started
2024.01.14 16:22:15.722 3: RokuWZ: listener stoped
2024.01.14 16:22:15.724 3: RokuWZ: listener started
2024.01.14 16:22:15.724 3: [SamsungAV] device SamsungLED initialising....
2024.01.14 16:22:15.724 3: Opening SeiliPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.726 3: SeiliPresenceBT device opened
2024.01.14 16:22:15.728 3: Opening SeimaPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.730 3: SeimaPresenceBT device opened
2024.01.14 16:22:15.735 3: sendTelegram: FHEM-System neu gestartet (INITIALIZED/Schritt 1) ...
2024.01.14 16:22:15.748 2: [Freezemon] FreezeMon: ready to watch out for delays greater than 1 second(s)
2024.01.14 16:22:15.748 3: NTFY return:  sysmon:Initialized
2024.01.14 16:22:15.748 0: Featurelevel: 6.2
2024.01.14 16:22:15.748 0: Server started with 349 defined entities (fhem.pl:28227/2023-11-29 perl:5.034000 os:linux user:fhem pid:1571796)
2024.01.14 16:22:15.768 3: telnetForBlockingFn_1705245735.76591: port 39433 opened
2024.01.14 16:22:15.848 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:22:15.963 1: Velux: Can't connect to 192.168.0.12:51200: 192.168.0.12: No route to host (113)
2024.01.14 16:22:15.968 3: KNXD [KNXIO_handleConn 928]: initial-connect
2024.01.14 16:22:16.037 2: AttrTemplates: got 260 entries
2024.01.14 16:22:16.173 3: [FBWLAN450E | 0000 | 128.07.15 | API_Check_Run.2570] - BASIC:API luaQuery call responded with: 403 Forbidden
2024.01.14 16:22:16.364 3: [FBWLAN450E | 0000 | 128.07.15 | API_Check_Run.2593] - BASIC:API luaData call responded with: 403 Forbidden
2024.01.14 16:22:16.542 2: PhilipsHue: autocreate: created 0/0/0 devices (ignored 0/0/4)
2024.01.14 16:22:18.785 3: sendTelegram: SamsungLED: absent
2024.01.14 16:22:22.494 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:22:22.495 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:22:33.133 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:22:33.138 3: KNXD [KNXIO_handleConn 923]: connected
2024.01.14 16:22:42.748 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:22:42.748 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:22:47.621 3: BOSEST: BoseRec, new IP (192.168.0.22)
2024.01.14 16:22:49.912 3: BOSEST: BoseRec, WebSocket connection succeed.
2024.01.14 16:22:53.443 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:22:53.449 3: KNXD [KNXIO_handleConn 923]: connected
2024.01.14 16:23:02.999 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:23:02.999 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:23:13.122 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:23:13.129 3: KNXD [KNXIO_handleConn 923]: connected
2024.01.14 16:23:23.141 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:23:23.141 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:23:34.006 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:23:34.011 3: KNXD [KNXIO_handleConn 923]: connected

Der Root-Cause ist ein DHCP-Lease-Problem, das ich zwischenzeitlich gelöst habe. Der KNX-IP-Router war dann einfach nicht erreichbar und KNXD hat immer wieder neu gestartet. Trotzdem wäre es m.E. gut, wenn der FHEM/KNX-Start toleranter gegen Verbindungsprobleme wäre. Ich hätte jetzt noch daran gedacht, $init_done abzufragen, d.h. wenn $init_done == 0, dann CONNECTED ignorieren, ansonsten eine fixe Zeitspanne warten und dann KNX-Kommunikation starten, sofern kein disconnected zwischenzeitlich auftritt. Ist natürlich nur ein unschöner Workaround, sofern er überhaupt funktioniert.

Freue mich jedenfalls auf Dein Feedback, danke nochmals!

LG
Stefan

Edit: $init_done-Workaround funktioniert nicht, weil das bereits 1 ist, wenn CONNECTED das erste Mal aufgerufen wird. Ich könnte nur generell bei jedem CONNECTED 30 Sek. warten (das macht anscheinend INITIALIZED beim FHEM-Start auch), bevor ich was auf den Bus schreibe (sofern nicht ein DISCONNECT/disconnected zwischenzeitlich auftritt).

[erwin]

Hi Stefan,
der erste Teil des Problems ist gefunden:
versuche im notify und im sub knxstarted NICHT 'CONNECTED' sondern 'connected' zu schreiben!
Das GROSSGESCHRIEBENE kommt aus dem Modul DevIO, kann ich nicht ändern, einfach ignorieren,
das kleingeschriebene kommt aus KNXIO - und wäre richtig! - siehe cmd-ref

Den zweiten Teil des Problems schau ich mir morgen an. (..falls das erste connect nach 30 sekunden nicht erfolgreich ist...)
PS: völlig richtig, init_done hilft hier nicht - das ist zeitgleich mit global:INITIALIZED gesetzt und daher für diesen Zweck zu früh!

d.h. wenn $init_done == 0, dann CONNECTED ignorieren, ansonsten eine fixe Zeitspanne warten und dann KNX-Kommunikation starten, sofern kein disconnected zwischenzeitlich auftritt.

Fast genauso funktioniert die INITIALIZED/connected Logik im KNXIO Modul, einziger Unterschied:
das erste connected wird ignoriert, 30 Sekunden gewartet, nochmal gecheckt ob reading state noch immer connected ist- und dann INITIALIZED ausgelöst!
l.g.erwin

[StefanG]

Hi Erwin,

danke für das Feedback, soweit verstanden! Damit könnte ich notfalls auch selber einen Timer basteln.

Eine Frage noch: Wenn die kleingeschriebenen connected/disconnected die vom KNXIO sind, warum wird dann beim Disconnecten kein disconnected-Event ausgelöst? Den bekomme ich nur beim Runterfahren von FHEM. D.h. beim Connecten zum KNXIO kommt CONNECTED, gefolgt von connected. Beim Disconnecten kommt aber nur DISCONNECTED. Wenn ich das sauber lösen will, muss ich ja bei zwischenzeitlichen Unterbrechungen auch die KNX-Kommunikation stoppen und irgendeinen Alert ausgeben. Dass generell der Root-Cause zu lösen ist, ist klar.

Siehe hier:

Code Auswählen Erweitern

2024-01-20_13:22:41 global DEFINED at_updateKNXPerSecond
2024-01-20_13:22:41 global ATTR at_updateKNXPerSecond room Allgemein
2024-01-20_13:22:42 KNXD CONNECTED
2024-01-20_13:22:42 Telegram msg 2024-01-20 13:22:42: KNXD gestartet (CONNECTED/Schritt 2) ...
2024-01-20_13:22:42 KNXD connected
2024-01-20_13:22:42 Telegram msg 2024-01-20 13:22:42: KNXD gestartet (connected) ...
2024-01-20_13:22:42 Telegram sentMsgResult: SUCCESS
2024-01-20_13:22:42 Telegram sentMsgId: 440969

Aber hier:

Code Auswählen Erweitern

2024-01-20_13:22:52 FBWLAN450E WLAN: on gWLAN: on
2024-01-20_13:22:52 FBWLAN450E retStat_lastReadout: 64 values captured in 0.37 s
2024-01-20_13:22:52 KNXD DISCONNECTED
2024-01-20_13:22:52 Telegram msg 2024-01-20 13:22:52: KNXD gestoppt (DISCONNECTED) ...
2024-01-20_13:22:52 Telegram sentMsgResult: SUCCESS
2024-01-20_13:22:52 Telegram sentMsgId: 440971
2024-01-20_13:22:52 Telegram sentMsgPeerId: 6001913647
2024-01-20_13:22:53 PiZeroPresence present

lg
Stefan

[erwin]

Hi Stefan!

Damit könnte ich notfalls auch selber einen Timer basteln.

Das versteh ich nicht. Wenn du NICHT auf CONNECTED triggerst, sondern nur auf INITIALIZED und connected, brauchst du keinen zusätzlichen timer, um z.B: set-cmds zu schicken!

Es stimmt, ein disconnected event wird erst geschickt, falls die Kommunikation absolt tot ist, nicht solange noch recovery versucht wird... es sollte allerdings ein connected event passieren, sobald die Verbindung wieder steht!
Das zweite Problem (falls der erste conn-Versuch schiefgeht..., KEIN INITALIZED geschickt wird), wird mit dem update heute gefixt.
Sorry, ich hatte verstanden, das der root-cause bei dir gefixt ist, dasshalb hatte ich keine Prio mit dem update....
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!

l.g. erwin

[erwin]

Hi KNX-Community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!

l.g. erwin

[erwin]

Hi KNX-Community!
ich bin gerade am testen von FHEM im Docker (noch nicht die Version 4).
Dazu hab ich zum Thema Docker & Multicast bzw. knxd im Docker das Wiki ergänzt.
l.g. erwin