Keine stabile FRITZBOX Verbindung

Begonnen von @tango, 23 Januar 2026, 14:51:55

Vorheriges Thema - Nächstes Thema

@tango

Ja, auch ne Möglichkeit.
Aber nein, IPs sind unterschiedlich.

Mittlerweile habe ich mal alles, was an Fritzbox erinnert aus HA rausgelöscht.
HM restartet.
Dann mal wieder SmartHome Integration geladen.
FHEM meldete sich wieder im Log. Machte Pause und wollte sich nach 5 Sek wiedermelden.
Das Tat es auch!!
Wieder mit den genannten Einträgen im Log. Aber friert nicht ein.
Dann auch in HA die Fritz Tool Integration geladen. Und es ging weiter in FHEM.

Mittlerweile ist 1Std vergangen und beide Systeme rühren sich noch und können bedient werden.
Ich hoffe, das bleibt so.

Soweit noch mal Dank an alle.
RASPI 4B, PI USV+, ext. SSD, ohne MicroSD
IO: CUL433,2xHMUART
HM, IT, Rev, AVM

@tango

Satz mit X: war wohl nix.
1 Std. war OK. 1 Nacht nicht.
Am nächsten Morgen stand alles und benötigte Restart: FHEM, HA, Fritzbox.
Ich hab's aufgegeben, aus einer Instanz müssen die Fritzbox Verbindungen rausfliegen.
Ich bilde mir ein, beim vielen Forschen irgendwo bei der tr64 Beschreibung gelesen zu haben, dass, wenn mehrere
Instanzen (etwa FHEM, HA) über tr64 auf die Fritzbox zugreifen, sich alle über Transaktionen
absichern müssen. Verstehe ich das richtig? Passiert das?

Grüße Tango
RASPI 4B, PI USV+, ext. SSD, ohne MicroSD
IO: CUL433,2xHMUART
HM, IT, Rev, AVM

JoWiemann

Hallo,

ich glaube Du versteifst Dich da zu sehr auf Fhem und suchst nicht tiefer liegend. Der Log Eintrag: SIGNIFICANT:500 Can't connect to 192.168.168.1:80 zeigt, dass auf der Transport Ebene des Netzwerks die FritzBox nicht erreichbar ist. Hier liegt kein Problem bei Fhem und auch kein Problem bei TR064 vor, sondern es ist einfach kein Routing zur IP der FritzBox möglich.

Wenn Du in diesem Fall noch über Putty oder ein entsprechendes Tool auf den RPi kommst, dann würde ich erst einmal prüfen, ob ein Routing zu FritzBox noch stattfindet. Kannst Du den RPi gar nicht mehr erreichen, aber alle anderen Geräte im Netz sind noch erreichbar, dann würde ich den RPi einmal komplett neu aufsetzen.

Ich hatte eine ähnliche Situation. Regelmäßig verlor der RPi, so ca nach 12 Stunden, die Netzwerkverbindung. Das mittlerweile angeschlossene LCD4Linux Display zeigte zwar an, dass der RPi noch lebt, allerdings lag die CPU Auslastung bei 100%. Und das auch bei einfachem vor sich hin dümpeln und deaktiviertem Fhem.

Erster Gedanke RPi hat einen defekten Kommunikations-Prozessor. Also in einen neuen RPi die SD-Karte rein. Zunächst ok und dann gingen die Probleme wieder los. Also gesichertes Image auf eine neue SD-Karte. Kein Verbesserung. Erst ein komplett neues Aufsetzen des RPi führte zu einem nachhaltigem stabilen Betrieb. Warum, keine Ahnung.

Hierbei sind viele Stunden verbraucht worden und auch die KI hat hier wenig beitragen können.

Grüße Jörg

PS: Du kannst ja mal TR064 in der FB deaktivieren. Das FRITZBOX Modul funktioniert trotzdem. Es fehlen halt ein paar Funktionen und Infoermationen.
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

RalfRog

#18
Hi
Ich bin da bei Jo.

Aber eine Idee - wenn du den Doppelzugriff auf die FritzBox komplett ausschließen möchtest - ist, dass du das Attribut "disable" im FritzBox-Device nutzt. Damit kannst du mal schnell den Zugriff von FHEM auf die Box ausschließen/abschalten.

Gruß Ralf
FHEM VM Debian13 (trixie) auf Proxmox VE9  (Futro S740) - nanoCUL, HM-MOD-RPI-PCB und MAX!Cube über LAN
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder sowie Shelly 3EM, 1PM, PlugS und IT Schaltsteckdosen

VB90

ich habe aktuell ähnliche Probleme.
Mein fhem läuft auf einem LXC in Proxmox auf einem HP EliteDesk. Also keinerlei RPi-Bezug.
Unregelmäßig aber nachvollziehbar geht die Auslastung des RAM steil nach oben. fhem laggt dann bis zur Unbedienbarkeit.
Ein Neustart bringt Abhilfe, jedoch nicht auf Dauer.

Zeitgleich sind im fhem-log Einträge mit FRITZBOX Bezug. Allerdings ebenfalls nur "500"-er Einträge.
Allerdings führt das Ganze wohl auch dazu, das die Netzwerk-Verbindung komplett in die Brüche geht.
Andere Abfragen ins LAN, Nachrichten vom Mosquitto etc. funktionieren auch nicht.

Stellt sich die Frage, was is Henne, was ist Ei ;)

Aktuell nutze ich die aktuelle Labor-Firmware der FB 7690.
Ich habe jetzt alle FRITZBOX-Geräte mal im fhem deaktiviert und will beobachten wie sich fhem verhält.
Bleibt es stabil, werde ich zuerst die Repeater aktivieren.

vb
Man muss das Rad nicht neu erfinden, nur wissen wie es gedreht wird.

JoWiemann

Hallo VB,

wie schon mal geschrieben, das FRITZBOX Modul zeigt nur Symptome. Zunächst würde ich mal prüfen warum das RAM voll läuft. Ich selber habe Fhem mit vielen Devices und Schnittstellen laufen. Auch werden 8 Fritz Geräte durch Fhem abgefragt. Eine vollständige Auslastung des RAM habe ich in Zusammenhang mit Fhem bisher nicht beobachten können.

Die Frage ist also, welche Module nutzt Du? Dann würde ich über das sysmon Modul mal monitoren, welche Module in Betracht kommen können.

Bitte auch einmal in der FritzBox unter System/Ereignisse nachsehen, ob von der FritzBox etwas festgehalten worden ist.

Und dann die Frage, was läuft noch in Proxmox bzw auf dem HP EliteDesk.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

VB90

Moin Jörg,

Danke für deine Antwort und endlich mal: Danke für das Modul und deine Arbeit drumherum.

Nur das wir uns richtig verstehen, ich sage ganz bewusst nicht: fhem oder gar das Modul FRITZBOX ist schuld.
Das liegt mir fern. ;)

In erster Linie ging es mir darum, aufzuzeigen das es nicht (nur) am RPi als Gerät liegen kann/muss. Eine Fehlerquelle kann es natürlich auch sein, aber nicht allein.

zu meiner Konstellation:
Der RAM läuft nur auf dem fhem-Container voll, ansonsten ist das System unauffällig. Ebenso die anderen Container.
Zu laufen habe ich da nur so den typischen Kram, mosquitto, zigbee2mqtt etc. Nichts wildes also und auch alles unauffällig.


Aktuell vermute ich ein "Ungleichgewicht" im Zusammenspiel fhem <-> FritzBox aufgrund von eventuellen Problemen in der Labor-Firmware.
Da gab es heute Nacht auch wieder ne neue Version.
Leider führt das bekanntlich dazu, das die Logs in der Box gelöscht sind, eine Fehlersuche dort also unmöglich ist.

Wenn das Problem in der Firmware zu suchen wäre, sollte ja eventuell bei den Kollegen von HA und dergleichen ebenfalls Probleme zu finden sein!?
Ich bin da aber kein Stück im Bilde, vielleicht kann das jemand anderes besser beurteilen.

Offenbar ist es ja auch kein flächendeckendes Problem, sonst wären hier wohl mehr Wortmeldungen.

vb
Man muss das Rad nicht neu erfinden, nur wissen wie es gedreht wird.

JoWiemann

Hallo VB,

irgendwo in den Tiefen des Forums habe ich das mal gefunden:
###############################################################################
sub listInternalTimer(;$) {
    my ($p) = @_;
$p ||= "";
    my %cop;

    foreach my $e (@intAtA)
    {
        my $name = "";
        if (ref($e->{ARG}) eq "HASH")
        {
            if (exists($e->{ARG}{NAME}))
            {
                $name = $e->{ARG}{NAME};
            }
            elsif (exists($e->{ARG}{arg}))
            {
                $name = $e->{ARG}{arg};
            }           
        }
        elsif ((ref($e->{ARG}) eq "REF") && exists(${$e->{ARG}}->{hash}))
        {
            $name = ${$e->{ARG}}->{hash}{NAME};
        }
        elsif (ref($e->{ARG}) ne "REF")
        {
            $name = $e->{ARG};
        }
        my $time = strftime('%d.%m.%Y %H:%M:%S', localtime($e->{TRIGGERTIME}));
        my $function = sprintf("%-25s %-25s", $name, $e->{FN});
        my $line = "<td>".$e->{atNr}."</td><td>".$time."</td><td>".$function."</td>";

        if ('f' eq $p)
        {
            $cop{$function} = $line;
}
        elsif ('t' eq $p)
        {
            $cop{$time} = $line;
}
        else
        {
            $cop{$name." ".$e->{atNr}} = $line;
}
    }

    my $ret = '<html><table width=50%>';
    $ret .= "<td><b>InternalTimer List</b></td>";
    $ret .= '</tr></tr>';
    $ret .= "<td><b>Number</b></td>";
    $ret .= "<td><b>Date/Time</b></td>";
    $ret .= "<td><b>Function</b></td>";
    $ret .= '</tr>';
   
    foreach my $k (sort keys %cop) {
        $ret .= "$cop{$k}";
        $ret .= '</tr>';
    }

    $ret .= '</table></html>';
    return $ret;
}

Die Sub in die 99_myUtils packen.

Dann einen cmdAlias definieren.
defmod InternalTimer cmdalias InternalTimer .* AS {{listInternalTimer()}}
attr InternalTimer alias InternalTimer
attr InternalTimer room System

setstate InternalTimer defined

Damit kannst Du dann prüfen, ob sich Timer Aufrufe vermehren. Hierdurch würde mit jedem Aufruf RAM allokiert, was am Ende zu einem Speicherüberlauf führt.

Sollten sich Timer des FRITZBOX Moduls "vermehren", dann brauche ich ein Log mit verbose 5.

Bei verbose 5 im FRITZBOX Device wird ein eigenes Log File erstellt, für das dann auch ein FakeLog Device erzeugt wird. Den Inhalt kann man dann über einen Klick auf das neu erstellte INTERNAL Reading anzeigen. Das Log File selber kann man dann hier als Dateianhang gut posten und muss es nicht aufwändig aus dem gesamten Log extrahieren.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM