Modul 00_KNXIO.pm support

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

Vorheriges Thema - Nächstes Thema

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:
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:
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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Hauswart

Umstieg hat problemlos funktioniert. Danke dir!
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

PatrickR

#2
Hi!

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

Der ist aktuell so konfiguriert:

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:

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:

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:

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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

erwin

#3
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:

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

anschließend checken:
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.....
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

PatrickR

#4
Hi!

Zitat von: erwin am 30 Mai 2022, 20:52:36
[Tests für die Theorie, dass die Adresse des GWs noch durch knxd blockiert ist]
Alle negativ, auch mit grep -i.

Zitat von: erwin am 30 Mai 2022, 20:52:36
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...").

Zitat von: erwin am 30 Mai 2022, 20:52:36
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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

erwin

#5
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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

PatrickR

Hallo Erwin,

Zitat von: erwin am 02 Juni 2022, 09:48:29
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.

Zitat von: erwin am 02 Juni 2022, 09:48:29
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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

erwin

ZitatBesteht 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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

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!
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

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