2026.05.29 20:39:17 4: fheminfo send (nonblocking): {...}
2026.05.29 20:39:17 4: IP: fhem.de -> [2a01:4f8:221:1b5a::b2]
2026.05.29 20:39:21 1: fheminfo send: Server ERROR: connect to https://fhem.de:443 timed out
Das Problem tritt nur bei einer meiner drei FHEM-Instanzen auf.
Eine der beiden anderen Instanzen läuft hier im gleichen Netzwerk und funktioniert, ein generelles Netzwerkproblem schließe ich deshalb aus.
Hat jemand einen Tipp, wie ich das Problem weiter eingrenzen kann? Bauchgefühl sagt mir, ich könnte mal wieder ein IPv6 Problem haben. Denn die andere Instanz, die hier im Netzwerk funktioniert, verwendet eine IPv4 Adresse von fhem.de
2026.05.29 16:18:30.998 4: fheminfo send (nonblocking): {...}
2026.05.29 16:18:30.999 4: IP: fhem.de -> 188.40.131.57
2026.05.29 16:18:31.510 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.29 16:18:31.510 4: fheminfo send: Server RESPONSE: ==> ok
Wie ist denn Instanz 1 und wie Instanz 2 an dein Netzwerk angebunden?
Haben die Instanzen ggf. mehrere Netzwerkadapter?
Grüße Sidey
- Beide Instanzen laufen als Proxmox Container.
- Die nicht funktionierende Instanz hat das globale Attribut useInet6 gesetzt, die andere Instanz nicht.
- Die "nicht funktionierende" Instanz ist meine Produktivinstanz, auf der ansonsten netzwerktechnisch alle Verbindungen funktionieren, nur das fheminfo send klappt nicht.
Funktionierende Instanz:
udo@fhem-sip:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:ba:0b:06 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.123.219/24 brd 192.168.123.255 scope global dynamic eth0
valid_lft 79650sec preferred_lft 79650sec
inet6 fddc:7b04:1a06:0:be24:11ff:feba:b06/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 7200sec preferred_lft 3600sec
inet6 2002:5510:9940:0:be24:11ff:feba:b06/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 7199sec preferred_lft 3599sec
inet6 fe80::be24:11ff:feba:b06/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Nicht funktionierende Instanz:
udo@fhem:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:46:b6:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.123.111/24 brd 192.168.123.255 scope global dynamic eth0
valid_lft 75883sec preferred_lft 75883sec
inet6 fddc:7b04:1a06:0:be24:11ff:fe46:b6a4/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 6643sec preferred_lft 3043sec
inet6 2002:5510:9940:0:be24:11ff:fe46:b6a4/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 6642sec preferred_lft 3042sec
inet6 fe80::be24:11ff:fe46:b6a4/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Zitat von: betateilchen am 29 Mai 2026, 21:07:44- Die nicht funktionierende Instanz hat das globale Attribut useInet6 gesetzt, die andere Instanz nicht.
Wenn ich das Attribut entferne, funktioniert das Senden auch auf der Produktivinstanz:
2026.05.29 21:09:31 4: fheminfo send (nonblocking): {...}
2026.05.29 21:09:31 4: IP: fhem.de -> 188.40.131.57
2026.05.29 21:09:32 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.29 21:09:32 4: fheminfo send: Server RESPONSE: ==> ok
Dann funktionieren allerdings viele andere Dinge nicht mehr...
Du hast sehr wahrscheinlich ein IP V6 Problem.
Könnte das Problem außerhalb des Containers liegen? Vielleicht eine Firewall?
Grüße Sidey