Modul 00_KNXIO.pm support

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

Fix warnings on use statements (Perl 5.040)

l.g. erwin

[waermepumpe]

Hi!

Bei Multicast "M 224.0.23.12:3671 1.1.250" wird leider ans falsche interface gebunden und man kann kein Interface definieren.

Code Auswählen Erweitern

ip maddr show dev normal
11:    normal
    link  xx:xx:xx:xx:xx:xx users 2
    link  xx:xx:xx:xx:xx:xx users 2
    link  xx:xx:xx:xx:xx:xx users 2
    link  xx:xx:xx:xx:xx:xx users 2
    link  xx:xx:xx:xx:xx:xx users 2
    link  xx:xx:xx:xx:xx:xx users 2
    inet  224.0.23.12
    inet  224.0.0.252
    inet  224.0.0.1
    inet6 ff02::1:3
    inet6 ff02::1:fff7:nnnn
    inet6 ff02::1
    inet6 ff01::1

Bei socat kann man interface bindung definieren "socat -u UDP4-RECVFROM:3671,ip-add-membership=224.0.23.12:iot,fork /dev/null"

Ich umgehe das derzeit mit einer host route für den multicast, ist aber nicht schön.

Code Auswählen Erweitern

ip route add 224.0.23.12/32 dev iot
dann wandert der eintrag inet

Code Auswählen Erweitern

inet  224.0.23.12 vom normal interface zum iot interface, nach restart/reconnect des knxio

Kann man bei der KNXIO def. nicht auch eine interface spezifikation/binding einbauen, sowie bei socat möglich, oder übersehe ich was?

Code Auswählen Erweitern

# SO_BINDTODEVICE = 25 auf Linux
setsockopt($sock, SOL_SOCKET, 25, "$iface\0")
    or die "setsockopt SO_BINDTODEVICE failed: $!";

die finale routing table:

Code Auswählen Erweitern

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    400    0        0 normal
192.168.1.0     0.0.0.0         255.255.255.0   U     402    0        0 iot
192.168.2.0     0.0.0.0         255.255.255.0   U     400    0        0 normal
192.168.179.0   0.0.0.0         255.255.255.0   U     401    0        0 guest
224.0.23.12     0.0.0.0         255.255.255.255 UH    0      0        0 iot

Danke!

[erwin]

Hi,
das ist seltsam,
bist du sicher, dass das interface iot MULTICAST unterstützt ?
Die doku zu SOCKS:: ist da nicht eindeutig, siehe:SOCKS

Grundsätzlich passsiert das joingroup in TcpServerUtils.pm mit INETADDR_ANY - aufgerufen durch 00_KNXIO.pm.
Nach meinem Verständnis sollten alle (passenden) if verwendet werden.

Zum Testen könntest du versuchen in TcpServerUtils.pm Zeile 145 INADDR_ANY auf dein if zu patchen....
...falls das funktioniert, könnte man über def/attr-parameter nachdenken...
l.g. erwin

[erwin]

Hi waermepumpe,
sorry, das hat lang gedauert, noch Interesse an der Lösung?
Wie schon beschrieben, jetzt auch getestet:
Ändern der Zeile 145 in TcpServerUtils.pm:

Code Auswählen Erweitern

##von:
my $ip_mreq = Socket::pack_ip_mreq( inet_aton( $addr ), INADDR_ANY );
##nach:
my $ip_mreq = Socket::pack_ip_mreq( inet_aton( $addr ), inet_aton('192.168.xxx.yyy') );
...wobei die ip-adresse deinem gewünschten Interface entsprechen sollte! Vorsicht, das betrifft ALLE multicast connections, ist NUR zum testen!
Falls das bei dir funktioniert, würde ich einen patch Vorschlag für TcpServerUtils.pm dem Maintainer schicken und das Modul KNXIO entsprechend anpassen.
l.g. erwin

[tostmann]

Aus einem Support-Fall heraus — ein Nutzer kämpfte mit dem Umweg TUL → WLAN → knxd → FHEM — haben wir uns KNXIO genauer angeschaut, direkt gegen ip4knx getestet und empfehlen es jetzt: damit spart man sich knxd komplett. Danke an erwin, das Modul ist inzwischen so rund, dass FHEM einen KNXnet/IP-Gateway direkt anbinden kann.

Kurz zum Aufbau: die busware TUL (ESP32-C3 + NCN5130) wird mit der Firmware ip4knx zu einem vollwertigen KNXnet/IP-Gateway (Routing + Tunneling), und FHEM dockt per KNXIO direkt an.

Passend zur aktuellen Multicast-Diskussion: für so einen WLAN-Gateway würde ich ohnehin Modus H (Unicast-Tunneling) statt Modus M (Multicast) nehmen — dann stellt sich das Interface-Binding-Problem gar nicht erst, und über WLAN ist Unicast unkritischer als Multicast. Bei Tunneling schreibt der Gateway die Absender-IA auf die zugewiesene Tunnel-Adresse um, also gibt es auch keinen Adresskonflikt.

Code Auswählen Erweitern

define KNXGW KNXIO H <IP-des-Sticks>:3671 1.1.250
define myLight KNX 1/2/3:dpt1

Hier läuft das mit KNXIO H bidirektional gegen den echten Bus (TX + RX) sauber durch. Firmware per Web-Flasher direkt im Browser, keine Toolchain nötig; dazu eine kurze Schritt-für-Schritt-Anleitung "FHEM ohne knxd":

https://install.busware.de/ip4knx/
https://github.com/tostmann/ip4knx/blob/main/HowToFHEM.md

(Full disclosure: TUL/busware ist von mir; ip4knx baut auf dem OpenKNX-Stack auf.)