Hallo...
hatte vor einiger Zeit schon einmal mit Erwin über das Thema gesprochen
seinerzeit war der Raspy über WLAN angebunden (um hier Timing Problemen
aus den Füßen zu gehen habe ich diesen nun per Lan angebunden).
Das KNX Gateway wechselt nach dem harten Reset / Neustart nicht
von der Initialisierung in den connected Modus - im Logfile steht
2026.02.21 13:20:13 3: myKNXGW: port 3671 opened
2026.02.21 13:20:13 2: myKNXGW [KNXIO_openDev 828]: MC add failed: myKNXGW: could not set IP_ADD_MEMBERSHIP socket option: No such device
Definiert ist es als: define myKNXGW KNXIO M 224.0.23.12:3671 1.1.40
mache ich danach einen shutdown restart ist das Gateway direkt connected
Habe nach Recherche bei KNXD
hier Punkt:
sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
"1" durch "0" ersetzen
da sich die virtuelle Datei nicht direkt ändern lässt hat KI-Goggle
für eine dauerhafte Änderung vorgeschlagen:
sudo nano /etc/sysctl.d/99-custom.conf
mit dem Eintrag
net.ipv4.icmp_echo_ignore_broadcasts = 1
Das funktionierte und ich konnte mit
sudo sysctl --system
den jeweiligen Status 0 oder 1 abfragen.
Hat aber nicht weitergeholfen.
Hatte aus damaliger Antwort noch im Hinterkopf einen Sleep einzubauen:
define KNXReconnect DOIF myKNXGW:INITIALIZED ;; sleep 10 ;; Set myKNXGW connect
das hilft aber auch nicht weiter.
Benutze einen Siemens N146-02 mit den entsprechend benannten Tunnel Adressen 1.1.41 für den virtuellen FHEM
und zum Beispiel 1.1.39 für den Homeserver und 1.1.40 für den FHEM auf Raspy.
Wenn ich die beiden anderen Tunnel nicht mit benutze sprich Homeserver und virtuellen FHEM ausschalte
und nur den Raspy starte bleibt das Problem auch vorhanden
wie gesagt nach einem set myKNXGW connect oder einem shutdown restart funktioniert alles einwandfrei...
Hätte noch einer eine weitere Idee....bzw. kann mir meinen Fehler aufzeigen
ansonsten müsste ich es einmal mit einem anderen Router versuchen.
Der Router hängt direkt an Fritzbox.
Hi,
ich habe keine Ahnung von KNX aber eine Idee: der fhem.service startet ev. vor dem Netzwerk?
Zitat von: petervereecke am 21 Februar 2026, 14:04:09wie gesagt nach einem set myKNXGW connect oder einem shutdown restart funktioniert alles einwandfrei...
Du kannst versuchen, die hier beschriebene Abhängigkeit zu ändern (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Start_von_anderen_Services_abh%C3%A4ngig_machen).
Damit wäre sichergestellt, dass das Netzwerk wirklich aktiv ist wenn FHEM startet.
Gruß Otto
Hi,
ZitatDas KNX Gateway wechselt nach dem harten Reset / Neustart nicht
von der Initialisierung in den connected Modus
meinst du mit "nach harten Reset" das KNX-GW (N146-02) ?
Falls ja, vermute ich, das der KNXD nicht mehr (richtig) läuft, weil sein Kommunikationspartner weggebrochen ist.
Auf der FHEM Seite gibts aus diesem Fehler keine automatisierte recovery, weil der multicast-tree nicht (mehr) vorhanden ist.
zum Testen würde ich wie folgt vorgehen:
set <KNXGW> restart auf der FHEM seite. - das sollte nicht funktionieren!
danach restart KNXD mittels systemctl - evtl in die knxd-logs schauen.
Falls das ok, nochmals "set <KNXGW> restart".
Viel Erfolg!
l.g. erwin
PS: Otto hat natürlich recht, auch die Reihenfolge spielt eine wesentliche Rolle, KNXD muss vor FHEM aktiv sein.
Hallo Erwin,
danke für eure schnellen Hinweise -->
aber ich meinte nicht den KNX IP-Router der
geht nicht offline da eine USV KNX Linie.
Ich meinte das myKNXGW im FHEM wenn ich den Raspy komplett neu unter Spannung setze
(sorry wenn ich mich hiert fehlerhaft artikuliert habe).
Hatte schon so eine Vermutung dass hier das Timing beim Start von FHEM eine Rolle
spielt. Werde mir nun nach dem Sport und - vielleicht mit frischem Elan - den Hinweis
von Otto einmal durchlesen - (auch herzlichen Dank) und testen.
Danke Peter
PS. USV ist ja nicht wirklich die Lösung - weil irgendwann ist jede USV down.
Danke - habe unter Zittern :-) - den
sudo systemctl edit --full fhem
bearbeitet und bei der Umsetzung der Beispiele
siehe Link von Otto die Geschichte teilweise nicht
mehr zum starten gebracht - hier fummelt man ja schon am eingemachten...
Finale Lösung war die Auskommentierung ExecStartPre=/bin/sleep 10
zurückgenommen - Funktioniert nun...
Vielen Dank für den schnellen support.
Aber an alle Hifis wie ich - take care.
LG Peter