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

Folgenden 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, or connect the USB-Stick to KNXD and in turn 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 Moed hat jedoch den Vorteil, dass jede empfanmgene/gesendete Message vom gegenüber acknoledged werden muss!
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!
definitions syntax ist in der cmd-ref.
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

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