Hauptmenü

Neueste Beiträge

Seiten 1 ... 3 4 5 6 7 ... 10
#41
Unterstützende Dienste / Aw: JeeLink über Ser2Net / Fhe...
Letzter Beitrag von presskopf - 22 Februar 2026, 12:39:52
Meine FHEM-Installation ist aktuell.
Der Output ist relativ überschaubar (JeeLinker hat noch Verbose 5):
Code Auswählen
2026.02.22 11:35:24 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
2026.02.22 11:35:24 1: DevIo JeeLinker JustClosed
2026.02.22 11:35:24 1: DevIO JeeLinker NEXT_OPEN:
2026.02.22 11:35:24 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)FHEM blockt auch mit dieser DevIo.pm


Ich habe das Problem mal der künstlichen Intelligenz geschildert und die 36_JeeLink.pm zur Analyse mitgegeben. Dabei kam folgendes raus:
Eine modifizierte 36_JeeLink.pm, die tatsächlich FHEM verfügbar / präsent hält. Der FHEM-Prozess springt zwar für einige Sekunden auf 100 % aber man kann im WebUI weiterarbeiten, sobald der JeeLink disconnected ist. Der Reconnect findet dann anhand des angegebenen Intervalls im timeout-Attribut statt.

Scheint eine mögliche Lösung des Problems. Ob man sich damit nicht andere Probleme einschleift und ob die vorgeschlagene Code-Änderung smart ist, kann ich nicht beurteilen. Das könnt vermutlich nur Ihr; in diesem Fall Du und @justme1968, ggfs. weitere Experten.

Die Änderungen stehen unten und die modifizierte 36_JeeLink.pm(.patched_timer) ist angehängt. Vielleicht kann das noch jemand mit identischen Problemen testen?

KI:

ZitatProblem: FHEM 100% CPU bei JeeLink über TCP (ser2net), sobald der Port kurz weg ist

Setup: JeeLink in FHEM als host:port (z.B. 192.168.0.143:1002), serielle Seite auf einer entfernten VM via ser2net.
Sobald der ser2net-Dienst kurz nicht verfügbar ist (Restart/Port weg), läuft FHEM in eine Schleife mit 100% CPU.

Symptom im Log (typisch):

  • ... disconnected, waiting to reappear (JeeLinker)
  • Stacktrace zeigt Pfad über DevIo_Disconnected / DevIo_SimpleRead und anschließend JeeLink_Ready → DevIo_OpenDev ...

Ursache (Root Cause)

Busy-Loop über %readyfnlist
Wenn das IODevice "disconnected" ist, landet es in FHEM in der readyfnlist. Dann ruft der Mainloop extrem häufig JeeLink_Ready() auf.
Wenn JeeLink_Ready() bei STATE=disconnected sofort wieder DevIo_OpenDev() startet (oder auch nur stumpf return 0 macht, aber im readyfnlist-Spin bleibt), kann FHEM praktisch ohne Schlaf laufen → 100% CPU.

Lösung/Änderungen
A) Reconnect throttlen ist nötig, aber allein nicht genug

Ein simples reopenDelay (z.B. 10s) in JeeLink_Ready() verhindert zwar den "Connect-Hammer", aber FHEM kann trotzdem 100% CPU ziehen, weil es während der Wartezeit weiter im readyfnlist-Spin steckt.

B) Finaler Fix: raus aus readyfnlist + Timer-basiertes Reopen
  • Implementiert in 36_JeeLink.pm:
  • neues Attribut: reopenDelay (Sekunden, Default 5)
  • bei STATE=disconnected:
    • aus %readyfnlist entfernen
    • Reconnect über InternalTimer(now+reopenDelay, "JeeLink_Reopen", ...) planen
  • neue Funktion JeeLink_Reopen() ruft dann einmal DevIo_OpenDev() auf
  • nach erfolgreichem Reconnect (JeeLink_DoInit):
    • Timer entfernen (RemoveInternalTimer)
    • Backoff/Next-Open löschen
Ergebnis: Während reopenDelay ist FHEM nicht mehr "hot", CPU bleibt normal.

Ergebnis nach Fix
Kein 100%-CPU-Loop mehr bei ser2net restart
Reconnect-Versuche nur noch alle reopenDelay Sekunden
Reconnect blockiert nicht mehr ewig, wenn timeout reduziert wird
System bleibt während Ausfall stabil/bedienbar


Code Auswählen
--- a/FHEM/36_JeeLink.pm
+++ b/FHEM/36_JeeLink.pm
@@ -1,6 +1,7 @@
 #!/usr/bin/perl
 use strict;
 use warnings;
+use Time::HiRes qw(gettimeofday);

@@
 sub JeeLink_Initialize($)
 {
   my ($hash) = @_;
@@
-  $hash->{AttrList} = "do_not_notify:1,0 dummy:1,0 showtime:1,0 "
+  $hash->{AttrList} = "do_not_notify:1,0 dummy:1,0 showtime:1,0 "
                       ." initCommands"
                       ." flashCommand"
                       ." timeout"
+                      ." reopenDelay"
                       ." DebounceTime BeepLong BeepShort BeepDelay"
                       ." tune " . join(" ", map { "tune_$_" } keys %RxListJeeLink)
                       ." $readingFnAttributes";
 }

@@
 sub JeeLink_DoInit($)
 {
   my ($hash) = @_;
@@
   JeeLink_Clear($hash);

   readingsSingleUpdate($hash, "state", "opened", 1);
+  delete($hash->{NEXT_OPEN});
+  RemoveInternalTimer($hash, "JeeLink_Reopen");

   # Reset the counter
   delete($hash->{XMIT_TIME});
@@
 }

@@
 sub JeeLink_Ready($)
 {
   my ($hash) = @_;

-  return DevIo_OpenDev($hash, 1, "JeeLink_DoInit")
-                if($hash->{STATE} eq "disconnected");
+  if($hash->{STATE} eq "disconnected") {
+    my $name  = $hash->{NAME};
+    my $delay = AttrVal($name, "reopenDelay", 5);
+    $delay = 5 if(!defined($delay) || $delay !~ /^\d+(?:\.\d+)?$/ || $delay < 0.1);
+
+    my $now  = gettimeofday();
+    my $next = $hash->{NEXT_OPEN} // 0;
+    $next = $now + $delay if($next <= $now);
+    $hash->{NEXT_OPEN} = $next;
+
+    # IMPORTANT: avoid busy loop in %readyfnlist.
+    # Remove from readyfnlist and schedule a timer-based reopen attempt.
+    delete($readyfnlist{$name});
+    RemoveInternalTimer($hash, "JeeLink_Reopen");
+    InternalTimer($next, "JeeLink_Reopen", $hash, 0);
+
+    return 0;
+  }

   # This is relevant for windows/USB only
   my $po = $hash->{USBDev};
   my ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags);
   if($po) {
     ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags) = $po->status;
   }
   return ($InBytes && $InBytes>0);
 }

+sub JeeLink_Reopen($)
+{
+  my ($hash) = @_;
+  return if(!$hash || !defined($hash->{NAME}));
+  return if($hash->{STATE} ne "disconnected");
+  DevIo_OpenDev($hash, 1, "JeeLink_DoInit");
+}

#42
Multimedia / Aw: [Neues Modul] BOSE SoundTo...
Letzter Beitrag von Mad - 22 Februar 2026, 12:35:52
Sollte auch mehr einen Zwischenstand darstellen.

Es klang danach, dass das Problem zwischen Bose und Fritzbox nicht an den unterschieldlichen Versionen liegt.
#43
Multimedia / Aw: [Neues Modul] BOSE SoundTo...
Letzter Beitrag von Prof. Dr. Peter Henning - 22 Februar 2026, 12:16:19
Details zu Problemen des soundcork-Servers bitte im github-repository als "Issue" posten.

LG

pah

P.S.: Was bitte ist mit "verifiziert" gemeint?
#44
Automatisierung / Aw: Benachrichtigung, wenn ein...
Letzter Beitrag von juergen012 - 22 Februar 2026, 12:09:41
MOIN!
meine DOIF Definition:
Code Auswählen
defmod di_ReadingsWatcher DOIF ([ReadingsWatcher:dead] > 0) (msg Störung: [ReadingsWatcher:deadDevs])\
DOELSE()
attr di_ReadingsWatcher DbLogExclude .*
attr di_ReadingsWatcher do always
attr di_ReadingsWatcher repeatcmd 3600
attr di_ReadingsWatcher repeatsame 10
attr di_ReadingsWatcher room DOIF
attr di_ReadingsWatcher verbose 2
attr di_ReadingsWatcher wait 10
#45
Multimedia / Aw: [Neues Modul] BOSE SoundTo...
Letzter Beitrag von Mad - 22 Februar 2026, 12:05:29
Wenn dies verifiziert ist, muss es ja dann ein individuelles Problem sein.

Die Dockerlösung für Soundcork tut sich bei mir auch noch etwas schwer. Über das Webui von Soundcork kann ich die Box ansteuern (Lautstärke, Presets ändern). Das Abspielen wird bei Preset von TuneIn und lokalen Radio mit Speaker Error 500 quitiert. An der Box erscheint auch kurz das jeweilige Preset ohne jedoch abgespielt zu werden. Eine Playlist über die spotify app lässt sich abspielen, auf ein Preset ablegen und darüber auch abrufen.
#46
FHEM Development / VERSCHOBEN: HttpUtils_Nonblock...
Letzter Beitrag von Dr. Boris Neubert - 22 Februar 2026, 11:54:39
Dieses Thema wurde nach Automatisierung verschoben.

https://forum.fhem.de/index.php?topic=143975.0
#47
Automatisierung / Aw: HttpUtils_NonblockingGet: ...
Letzter Beitrag von rudolfkoenig - 22 Februar 2026, 11:51:42
Alternativ setzt man kein data und Content-Type im initialen hash bzw. man haelt sich an meinem Beispiel :)


Zitatpassibe (DANKE!) hatte mir gestern noch souffliert:
Waere das nicht ein Grund das Thema dahin zu verschieben, wo auch andere mitreden koennen?
Ist meiner Ansicht nach jetzt wirklich kein Thema nur fuer Entwickler.
#48
Codeschnipsel / Aw: Räume room hinzufügen/entf...
Letzter Beitrag von rudolfkoenig - 22 Februar 2026, 11:45:45
Alternativ koennte man auch attr -a verwenden: https://fhem.de/commandref_modular.html#attr


Fuer die Ueberlagerung von Befehlen gibt es auch eine Alternative: cmdalias: https://fhem.de/commandref_modular.html#cmdalias
#49
Automatisierung / Aw: Benachrichtigung, wenn ein...
Letzter Beitrag von Icinger - 22 Februar 2026, 11:40:56
ZitatTeilweise muss man sehr komplexe Programmierarbeit leisten, um mit FHEM solch einen Standard-Anwendungsfall abzudecken.

Hmm, was spricht wirklich gegen den readingsWatcher?
Einmal definiert, dann bei jedem gewünschten Device noch ein
Code Auswählen
attr xyz 3600,,temperaturehinzugefügt.

Dann kannst du mit einem Notify|DOIF|ähnlichem auf
Code Auswählen
rw_ReadingsWatcher:deadDevs reagieren zB mittels
Code Auswählen
(msg push @rr_Stefan Dead Devices: [rw_ReadingsWatcher:deadDevs]
lg, Stefan
#50
FHEMapp / Aw: FHEMAPP-Modul - Releases
Letzter Beitrag von Benni - 22 Februar 2026, 11:37:46
Wichtiger Hinweis zum FHEM-Modul (02_FHEMAPP.pm):

Ich habe eben eine neue "Version" eingecheckt, die keine funktionalen Änderungen enthält und auch keine neue Versionsnummer mitbringt.

Mit diesem Check-In geht das Maintaining des Moduls auf Jens (jemu75) über.
Er hat sich bereiterklärt, das zu übernehmen, auch wenn er kein Perl-Entwickler ist.

Ich bin mir sicher, er kann hier im Forum auf die Ünterstützung von anderen erfahrenen Developern bauen. Und natürlich bin ich ja auch noch erreichbar ;)

Danke Jens, dass ich teil dieses coolen Projekts sein durfte!!!


gb#
Seiten 1 ... 3 4 5 6 7 ... 10