FHEM - Hausautomations-Systeme > KNX/EIB

Modul 00_KNXIO.pm support

(1/12) > >>

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: ---TunnelRequest received: duplicate message received ...
TunnelRequest received: out of sequence ....
KNXIO_TunnelRequestTO hit - ...

--- Ende Code ---
evtl. hilft der cmd: "apptime average all" herauszufinden, welches modul zu langsam ist....Verdächtig sind bei mir z.b.: OneWire und SVG.
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: ---update delete https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXIO.txt

--- Ende Code ---

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

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: --- knxd \
--eibaddr=1.0.250 --client-addrs=1.0.251:1 \
--GroupCache \
--listen-tcp \
-B single \
--layer2=ipt:192.168.0.191

--- Ende Code ---
und funktioniert mit folgender KNXIO-Konfiguration:

--- Code: ---define knx KNXIO T knxd.prdom:6720 1.0.251

--- Ende Code ---

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

--- Code: ---define knx KNXIO T knx.prdom:6720 1.0.251

--- Ende Code ---
(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: ---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)

--- Ende Code ---

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: ---sudo netstat -anp | grep knx
--- Ende Code ---
...vom system wo der knxd läuft...
um den knxd zu stoppen:

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

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

--- Ende Code ---
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!


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

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

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

--- Ende Zitat ---
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

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln