Hallo zusammen,
mein Master Pi mit FHEM steht im Keller, daher möchte ich einige meiner Interfaces (CUL/FS20 und JeeLink/LaCrosse) via ser2net im Haus verteilen, um die Reichweite zu verbessern.
Die Umstellung hat soweit auch reibungslos funktioniert. Wenn allerdings ein Remote Device ausfällt (wie z.B. in den letzten Tagen durch Blitzschlag oder schlicht Wackelkontakt...) hängt sich FHEM auf.
Auch wenn das Remote-USB-Device wieder verfügbar ist, fängt sich FHEM nicht wieder und muss von Hand neugestartet werden.
Hat jemand eine Idee woran das liegen könnte oder wie ich das verhindern kann. Timout Parameter bei der Definition o.ä.?
Meine Definition in /etc/ser2net.conf sieht so aus
#JeeLink
2003:raw:0:/dev/ttyUSB0:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
Die Device Definition in FHEM folgendermassen:
define Remote.JeeLink JeeLink 192.168.178.25:2003
attr Remote.JeeLink flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr Remote.JeeLink group Gateways
attr Remote.JeeLink room SYSTEM
Bin für jede Hilfe dankbar...
Gruß,
Ralf
EDIT: Sobald das Remote USB Device abgezogen wird friert FHEM ein und lässt sich dann auch über "sudo /etc/init.d/fhem stop" nicht stoppen oder neu starten
... bin ich denn wirklich alleine mit diesem Problem?
Habe gesehen dass es unter RFXtrx ein ähnliches Verhalten gab https://forum.fhem.de/index.php/topic,15137.msg97910.html#msg97910
(https://forum.fhem.de/index.php/topic,15137.msg97910.html#msg97910)Hier hat eine kleine Anpassung des Moduls 45_TRX.pm von Willi das Problem anscheinend gelöst.
Für den Fall dass ich mit dieser Fragestellung in einem Themenbereich (z.B. SlowRF oder CUL) besser aufgehoben bin, könnte dann einer der Moderatoren den Beitrag bitte verschieben?
Danke und Grüße,
Ralf
Nicht nur beim RFXtrx sondern auch beim KM271:
https://forum.fhem.de/index.php/topic,23278.msg446077.html#msg446077 (https://forum.fhem.de/index.php/topic,23278.msg446077.html#msg446077)
Das scheint ein generelles Problem mit per ser2net eingebundenen IO-Devices zu sein.
Hi Christoph,
danke für Dein Feedback aber meine CUL laufen stabil über ser2net bzw. verursachen beim Abziehen keinen FHEM Freeze.
Deshalb und aufgrund der zitierten RFXtrx Threads vermute ich, dass es eher das LaCrosse Modul bzw. in Deinem Fall das
KM271 Modul die Übeltäter sind.
Daher bin ich zum Schluss gekommen dass meine Frage hier wohl im flaschen Forum gelandet ist.
Könnte einer der Moderatoren den Beitrag bitte in den LaCrosse/JeeLink Bereich (Sonstige Systeme?) verschieben ?
Danke!
Ralf
ich habe an einem remote rasberry pi drei unterschiedliche cul, einen jeelink und einen panstamp.
das geschilderte problem ist bis jetzt weder beim abziehen noch beim neu starten des rasberry aufgetreten.
kannst du mal ein strace -p <pid> an das nicht reagierende FHEM hängen und schauen was genau passiert?
gruss
andre
Hallo Andre,
danke für Deine Unterstützung.
Was genau meinst Du mit
Zitatschauen was genau passiert?
Die Console generiert mit strace -p <PID> eifrig Output (was auch immer...?).
Aber sobald ich den Jeelink abziehe geht nichts mehr!
Dann hilft nur noch sudo kill <pid>
Oder wolltest Du einen bestimmten Auszug des Consolen Outputs?
CU,
Ralf
ja. genau. was genau gibt das strace aus wenn du den cul oder jeelink abziehst.
... hmmm - gar nicht so einfach den Teil zu extrahieren der ab dem Zeitpunkt geschrieben wird nachdem ich den JeeLink abziehe.
Ich hoffe der für Dich wichtige Teil ist enthalten. Bin echt mal gespannt was du da rauslesen kannst... ;)
Btw. Wie bereits beschrieben tritt das Problem nur mit meinem JeeLink auf. Der CUL geht zwar auch auf state:disconnected kann
aber mit reopen problemlos wiederbelebt werden. Ein FHEM Freeze verursacht der CUL zumindest nicht.
read(33, "", 4096) = 0
select(40, [33], NULL, NULL, {1, 0}) = 1 (in [33], left {0, 999989})
read(33, "", 4096) = 0
gettimeofday({1465932712, 42904}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 44000}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(4, "2016.06.14 21:31:52 1: 192.168.1"..., 94) = 94
close(33) = 0
gettimeofday({1465932712, 46928}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 48089}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 64214}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 66086}, NULL) = 0
select(40, [6 7 8 9 11 12 13 22 25 31 36], [36], NULL, {0, 43488}) = 1 (out [36], left {0, 43435})
write(36, "\27\3\3\0\220W0\306W8\352\255\307>gC'\361rMQCn\24\320\340&{4\212\331\355"..., 149) = 149
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ea56384) = -1 ENOTTY (Inappropriate ioctl for device)
_llseek(5, 0, 0x7ea563d0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ea56384) = -1 ENOTTY (Inappropriate ioctl for device)
_llseek(5, 0, 0x7ea563d0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.178.25")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(8, NULL, [5], NULL, {3, 0}) = 1 (out [5], left {2, 999986})
connect(5, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.178.25")}, 16) = 0
fcntl64(5, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(5, F_SETFL, O_RDWR) = 0
setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
gettimeofday({1465932712, 75706}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 76704}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(4, "2016.06.14 21:31:52 1: 192.168.1"..., 71) = 71
gettimeofday({1465932712, 78715}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
select(8, [5], NULL, NULL, {1, 0}) = 1 (in [5], left {0, 999986})
read(5, "", 4096) = 0
select(8, [5], NULL, NULL, {1, 0}) = 1 (in [5], left {0, 999989})
read(5, "", 4096) = 0
gettimeofday({1465932712, 81561}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 82542}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(4, "2016.06.14 21:31:52 1: 192.168.1"..., 94) = 94
close(5) = 0
gettimeofday({1465932712, 85349}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 86511}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
gettimeofday({1465932712, 100525}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
das schaut zumindest auf der ersten blick noch nicht auffällig aus...
kannst du mal ein fhem nur mit dem jeelink konfigurieren und es dort testen? siehst du einen unterschied in der ausgabe vor und nach dem abziehen ?
an welcher stelle hast du etwa abgezogen?
gruss
andre
Zitatkannst du mal ein fhem nur mit dem jeelink konfigurieren und es dort testen?
... so, damit alles isoliert nachvollziehbar ist habe ich ein jungfreuliches FHEM aufgesetzt und nur den Remote JeeLink konfiguriert.
Leider das gleiche Bild >:( JeeLink abgezogen -> FHEM tot !Zitatan welcher stelle hast du etwa abgezogen?
... ziemlich genau an der Stelle als diese Zeile in der Konsole angezeigt wurde:
Zitatselect(40, [33], NULL, NULL, {1, 0}) = 1 (in [33], left {0, 999989})
also ganz am Anfang des Konsolenauszuges den ich an angehängt habe.
Zitatsiehst du einen unterschied in der ausgabe vor und nach dem abziehen ?
Die Ausgabe hört sofort mit Abziehen des JeeLink auf, es gibt also keinen Unterschied zu erkennen :o
Um ausschließen zu können, dass mein JeeLink der Übeltäter ist habe ich das ganze Szenario auch mit einem anderen Stick (JeeLink Clone) ausprobiert
- > Leider gleiches Ergebnis d.h. es liegt nicht am Stick und ob original JeeLink oder Clone macht auch keinen Unterschied.
Ich hoffe das hilft dir trotzdem weiter. Auf jeden Fall trotzdem schon mal vielen Dank für Deine Hilfe!!!
CU,
Ralf
Zur Sicherheit habe ich eben noch mal schnell den JeeLink lokal angelegt um zu sehen wir es sich dort verhält.
Also wenn ich den lokal definierten JeeLink abziehe passiert gar nichts! D.h. er geht nur auf state:disconnected.
Sobald ich den Stick wieder einstecke wechselt er sofort wieder auf state:initialized und kann genutzt werden.
Works as expecteted ...strange!!
CU,
Ralf
Oben genanntes Testszenario auch nochmal mit CUL nachgesetellt. D.h. Plain FHEM via ser2net mit CUL verbunden und dann CUL abziehen
-> FHEM stürtzt in diesem Fall NICHT ab - der CUL geht nur in denZustand "disconnected" über (was ja OK ist)
-> Nach Wiedereinstecken des CUL bleibt dieser zwar im state:disconnected , kann aber über ein reopenwieder aktiviert werden
Allem Anschein nach scheint es wohl doch eher ein Problem des JeeLink-Moduls zu sein. @justme1968 oder hast Du aus dem Konsolenmitschnitt was rasulesen können?
CU,
Ralf
ich schaue es mir in ruhe an wenn ich zuhause bin.
gruss
andre
... super!
Danke Dir schon mal im Voraus...
Ich habe DevIo.pm wg. ser2net gerade geaendert, siehe https://forum.fhem.de/index.php?topic=54732
Hoffentlich bedeutet das nicht, dass FHEM mit CUL jetzt auch abstuerzt :), bei mir ist das bisher nicht der Fall.
... danke für Warnung Rudi!
Werde es gleich mal testen.
CU,
Ralf
@Andre:
Konntest Du aus dem Konsolen Mitschnitt was rauslesen?
Mittlerweile habe ich festgestellt, dass das Phänomen des Einfrierens nicht auftritt, wenn der RasPi mit dem Remote JeeLink zuvor sauber runtergefahren ist.
D.h. ist der Remote.JeeLink nicht verfügbar weil das gesamte Hostsystem down ist, passiert nichts - zieht man nur den JeeLink ab, stürzt die Master Kiste ab.
Sieht für mich immer noch nach einen Kommunikationsproblem auf Modulebene aus ?!
Wenn du noch irgendwelche Debugging Informationen von mit benötigst gib´Bescheid.
CU,
Ralf
ich bin noch nicht weiter zum testen gekommen. beim ersten drüber schauen ist es noch nicht auffällig.
vermutlich komme ich erst am wochenende dazu ads ganze nachzustellen. ich bin aber noch dran.
gruss
andre
ps: achtung bei der wort wahl: absturz und hängen bleiben sind unterschiedliche dinge mit unterschiedlichem vorgehen. beendet sich fhem wirklich? dann sollte im log etwas zu sehen sein.
Ich habe ein ähnliches (gleiches) Problem. Ich hatte gestern ein Problem, dass mein FHEM nicht mal mehr starten wollte. Der Service lief, aber ich kam nicht ins FHEM. Im Log stand nur:
2016.06.22 19:52:26 1: telnetPort: Can't open server port at 7072: Die Adresse wird bereits verwendet. Exiting.
Nach einigen Neustarts ging es wieder. Ich hatte vemutet, dass das eventuell was mit den USB-Devices über ser2net zu tun haben könnte, was ich vor drei oder vier Tagen umgestellt habe (von fhem2fhem).
Nach dem ich diesen Post gelesen habe, dachte ich mir, ich versuche es auch mal und haben meinen JeeLink abgezogen. Die Folge ist, dass beide FHEMs (Haupt- und Remote-FHEM) nicht mehr erreichbar sind. Der Service läuft aber noch. Nach einem Neustart von FHEM steht im Log einzig und allein die obige Meldung. Kurz vom Absturz wird kein Eintrag erzeugt.
Die Probleme und Meldungen betreffen wie gesagt beide FHEM-Server.
Um überhaupt wieder FHEM zum Laufen zu kriegen, muss ich erst den Remote-FHEM neustarten. Und zwar das komplette Linux. Nur Service neustarten reicht nicht. Wenn dann der Remote-FHEM wieder läuft, kann ich den Main-FHEM neustarten (auch wieder das komplette Linux-System). Starte ich erst den Main-FHEM neu, bleibt das Problem weiterhin erhalten.
Nach der kompletten Prozedur läuft es wieder. Der Eintrag im Log lässt vermuten, dass der telnet-Port nicht richtig geschlossen wird, wenn der JeeLink abgezogen wird, und durch den Versuch, die Verbindung neuaufzubauen, erfolgt das einfrieren.
Bei Gelegenheit werde ich mal testen, was der CUL macht.
Das Problem könnte natürlich auch am ser2net liegen und nicht an FHEM.
Ich hoffe, dass das hilft, um auch das Problem von fast-eddy zu lösen und nicht nur noch ein weiteres Problem dazu kommt ^^
Hi,
ich habe mein System jetzt auch mit einem Pi erweitert und dort 2 JeeLinks und einen CUL angeschlossen und per ser2net weitergeleitet.
So wie es aussieht, liegt es bei mir auch an den JeeLinks. Wenn ich einen von ihnen abziehe oder beispielsweise den ganzen Pi vom Netzwerk trenne, stürzt die Hauptinstanz von FHEM (bei mir leider auf Windows) ab.
Der CUL ist nicht so zickig. Ihn kann man abstecken, wieder anstecken und mit reopen weiter nutzen - wie oben schon geschrieben.
Gibt es hier schon etwas Neues, das ich testen könnte?
Gruß
Spiff.
ich verwende das ganze unter linux und mein fhem stürzt nicht ab.
da ich windows nicht benutze muss das leider jemand anders rausfinden.
Sorry für das Leichenschänden, aber ein neuer Thread bringt's m.E. nicht... :D
Ich sehe bei mir gerade das gleiche Phänomen.
fhem im lxc (seit Jahren ohne Murren und stabil)
Jeelink auf einer entfernten Instanz.
Beides ist Debian Linux.
Sobald ich auch nur einen Augenblick die Verbindung zwischen beiden (fhem und Jeelink) trenne, läuft fhem auf 100 % cpu und wartet sich einen ab.
Im log steht nur:
2026.02.19 23:12:43 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
2026.02.19 23:12:43 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
Allerdings verharrt fhem in der Endloswarteschleife, obwohl der Jeelink wieder da ist.
Gibt es für das Problem keine Lösung.
Hier noch mein List der Vollständigkeit halber:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.0.143:1002
DeviceName 192.168.0.143:1002
FD 34
FUUID 5c4b0d8f-f33f-bfeb-45a8-fae59560edf5d29d
JeeLinker_MSGCNT 36
JeeLinker_TIME 2026-02-19 23:21:15
NAME JeeLinker
NR 785
PARTIAL
RAWMSG OK 9 41 1 4 137 49
STATE initialized
TYPE JeeLink
eventCount 2
initMessages
model LaCrosseITPlusReader.10.1sJo
settings (RFM69CW f:868320 r:17241)
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2026-02-19 23:21:15 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 1m 868320f v
room LaCrosse
timeout 60,15
verbose 2
Da ich kein JeeLink habe: kannst Du bitte die Ausgabe einer verbose 5 Log zwischen den beiden "reappear" Meldungen zeigen?
Alternativ FHEM/DevIo.pm anpassen, und vor der "reappear" Ausgabe (Zeile 772) folgende Zeile einfuegen:
stacktrace();und dann bitte diese Ausgabe im Problemfall hier zeigen.
Habe den JeeLink auf Verbose 5 gesetzt und die stacktrace-Zeile ergänzt.
Punkt 10:54 habe ich das ser2net, an dem der JL hängt, restartet. Fhem geht auf 100 % CPU und ist nicht mehr ansprechbar; fhem.log:
2026.02.21 10:53:47 5: JeeLinker: dispatch OK 9 41 1 4 135 50
2026.02.21 10:54:00 5: JeeLink/RAW: /OK 9 28 1 4 26 106
2026.02.21 10:54:00 5: JeeLinker: dispatch OK 9 28 1 4 26 106
2026.02.21 10:54:00 4: LaCrosse: Unknown device 1C, please define it
2026.02.21 10:54:00 5: JeeLink/RAW: /OK VALUES WH24 243 Temperature=4.80,Humidity=95,Rain=129.30,Wind
2026.02.21 10:54:00 5: JeeLink/RAW: OK VALUES WH24 243 Temperature=4.80,Humidity=95,Rain=129.30,Wind/Speed=3.64,WindDirection=291.00,WindGust=5.60,UV=0.00,LowBattery
2026.02.21 10:54:00 5: JeeLink/RAW: OK VALUES WH24 243 Temperature=4.80,Humidity=95,Rain=129.30,WindSpeed=3.64,WindDirection=291.00,WindGust=5.60,UV=0.00,LowBattery/Flag=1,
2026.02.21 10:54:00 5: JeeLinker: dispatch OK VALUES WH24 243 Temperature=4.80,Humidity=95,Rain=129.30,WindSpeed=3.64,WindDirection=291.00,WindGust=5.60,UV=0.00,LowBatteryFlag=1,
2026.02.21 10:54:03 1: stacktrace:
2026.02.21 10:54:03 1: main::DevIo_Disconnected called by ./FHEM/DevIo.pm (96)
2026.02.21 10:54:03 1: main::DevIo_SimpleRead called by ./FHEM/36_JeeLink.pm (665)
2026.02.21 10:54:03 1: main::JeeLink_Read called by fhem.pl (4007)
2026.02.21 10:54:03 1: main::CallFn called by fhem.pl (789)
2026.02.21 10:54:03 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
2026.02.21 10:54:03 1: stacktrace:
2026.02.21 10:54:03 1: main::DevIo_Disconnected called by ./FHEM/DevIo.pm (96)
2026.02.21 10:54:03 1: main::DevIo_SimpleRead called by ./FHEM/36_JeeLink.pm (524)
2026.02.21 10:54:03 1: main::JeeLink_ReadAnswer called by ./FHEM/36_JeeLink.pm (457)
2026.02.21 10:54:03 1: main::JeeLink_Clear called by ./FHEM/36_JeeLink.pm (474)
2026.02.21 10:54:03 1: main::JeeLink_DoInit called by ./FHEM/DevIo.pm (400)
2026.02.21 10:54:03 1: main::__ANON__ called by ./FHEM/DevIo.pm (640)
2026.02.21 10:54:03 1: main::DevIo_OpenDev called by ./FHEM/36_JeeLink.pm (876)
2026.02.21 10:54:03 1: main::JeeLink_Ready called by fhem.pl (4007)
2026.02.21 10:54:03 1: main::CallFn called by fhem.pl (855)
2026.02.21 10:54:03 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
Danke, dass Du Dir Zeit für eine "Biopsie" nimmst. :)
Für den Fall der Fälle. Ich kann ja Fehler bei meinem Setup nicht ausschließen, hier zur Ergänzung mein ser2net.yaml-Auszug:
connection: &jeelink1002
accepter: tcp,0.0.0.0,1002
enable: on
connector: serialdev,
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04PG3P-if00-port0,
57600n81,local
options:
kickolduser: true
Kannst Du bitte in 36_Jeelink.pm in der Funktion JeeLink_Ready die Zeile 876
if($hash->{STATE} eq "disconnected");
gegen
if(DevIo_getState($hash) eq "disconnected");
austauschen, und erneut testen?
Das Verhalten ist identisch.
2026.02.21 17:00:33 5: JeeLinker: dispatch OK 9 36 1 4 46 81
2026.02.21 17:00:34 3: CUL_HM set FBH_OG getConfig noArg
2026.02.21 17:00:35 1: stacktrace:
2026.02.21 17:00:35 1: main::DevIo_Disconnected called by ./FHEM/DevIo.pm (96)
2026.02.21 17:00:35 1: main::DevIo_SimpleRead called by ./FHEM/36_JeeLink.pm (665)
2026.02.21 17:00:35 1: main::JeeLink_Read called by fhem.pl (4007)
2026.02.21 17:00:35 1: main::CallFn called by fhem.pl (789)
2026.02.21 17:00:35 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
2026.02.21 17:00:35 1: stacktrace:
2026.02.21 17:00:35 1: main::DevIo_Disconnected called by ./FHEM/DevIo.pm (96)
2026.02.21 17:00:35 1: main::DevIo_SimpleRead called by ./FHEM/36_JeeLink.pm (524)
2026.02.21 17:00:35 1: main::JeeLink_ReadAnswer called by ./FHEM/36_JeeLink.pm (457)
2026.02.21 17:00:35 1: main::JeeLink_Clear called by ./FHEM/36_JeeLink.pm (474)
2026.02.21 17:00:35 1: main::JeeLink_DoInit called by ./FHEM/DevIo.pm (400)
2026.02.21 17:00:35 1: main::__ANON__ called by ./FHEM/DevIo.pm (640)
2026.02.21 17:00:35 1: main::DevIo_OpenDev called by ./FHEM/36_JeeLink.pm (875)
2026.02.21 17:00:35 1: main::JeeLink_Ready called by fhem.pl (4007)
2026.02.21 17:00:35 1: main::CallFn called by fhem.pl (855)
2026.02.21 17:00:35 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
Ich glaube, ich werf das Problem mal parallel in die KI.
Da sind die kWh besser aufgehoben als dämliche Videos-generieren.
Ich habe bei mir dem JeeLink Modul ein ZWave Dongle als IO gegeben (ueber ser2net).
Das Modul akzeptiert das Geraet (???), und ich kriege keine Endlosschleife, wenn ich ser2net kurz beende.
Reconnect funktioniert auch.
Ich vermute ein Problem mit den uebrigen Definitionen.
Ich habe eine leicht modifizierte DevIo.pm angehaengt: kannst Du bitte das Experiment damit durchfuehren, und die Ausgaben zeigen.
Ist die FHEM Installation auf dem aktuellen Stand?
Meine FHEM-Installation ist aktuell.
Der Output ist relativ überschaubar (JeeLinker hat noch Verbose 5):
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
--- 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");
+}
Ich meine das Problem liegt nicht in der Unterbrechung der Netzwerkverbindung, sondern dass ser2net die Verbindung zum Jeelink verliert.
JeeLink_ReadAnswer liefert dann "No data" oder "NO FD" zurueck
JeeLink_Clear akzeptiert nur Timeout oder kein Fehler, und ruft JeeLink_ReadAnswer in Endlosschleife auf => 100% CPU.
Mein Patch-Vorschlag:
--- FHEM/36_JeeLink.pm (revision 30843)
+++ FHEM/36_JeeLink.pm (working copy)
@@ -455,7 +455,7 @@
$hash->{RA_Timeout} = 1;
for(;;) {
my ($err, undef) = JeeLink_ReadAnswer($hash, "Clear", 0, undef);
- last if($err && $err =~ m/^Timeout/);
+ last if($err);
}
delete($hash->{RA_Timeout});
}
Die Loesung der KI ist interessant: ich wuerde es mit dem Einbau eines zusaetzlichen Rades bei einer Reifenpanne vergleichen: Funktioniert, aber irgendwie unschoen.
Welche KI war das?
Warten wir ab, ob mein Verschlag funktioniert: ich kann es ja auch nicht unter realen Bedingungen testen.
Das war ChatGPT 5.2 Thinking.
Ich probiere nachher Deinen Vorschlag aus.
2026.02.22 17:28:25 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
2026.02.22 17:28:25 1: DevIo JeeLinker JustClosed
2026.02.22 17:28:25 1: DevIO JeeLinker NEXT_OPEN:
2026.02.22 17:28:25 1: 192.168.0.143:1002 disconnected, waiting to reappear (JeeLinker)
2026.02.22 17:28:25 1: 192.168.0.143:1002 reappeared (JeeLinker)
2026.02.22 17:28:49 2: After sleep: DatenHolen requested, watch readings
2026.02.22 17:28:49 2: After sleep: DatenHolen requested, watch readings
2026.02.22 17:28:58 1: DevIo JeeLinker JustClosed
2026.02.22 17:29:08 3: Opening JeeLinker device 192.168.0.143:1002
2026.02.22 17:29:08 1: DevIO JeeLinker NEXT_OPEN:
2026.02.22 17:29:09 3: JeeLinker device opened
2026.02.22 17:29:11 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1sJo (RFM69CW f:868300 r:17241)]
2026.02.22 17:29:11 5: SW: 1m
2026.02.22 17:29:11 5: SW: 868320f
2026.02.22 17:29:11 5: SW: v
2026.02.22 17:29:11 5: JeeLink/RAW: /
[LaCrosseITPlusReader
2026.02.22 17:29:11 5: JeeLink/RAW: [LaCrosseITPlusReader/.10.1sJo (RFM69CW f:868320 r:17241)]
2026.02.22 17:29:11 5: JeeLink/RAW: /OK 9 36 1 4 77
2026.02.22 17:29:11 5: JeeLink/RAW: OK 9 36 1 4 77 /83
2026.02.22 17:29:11 5: JeeLinker: dispatch OK 9 36 1 4 77 83
Das funktioniert ebenfalls! :)
Der FHEM-Prozess springt für ca 18 s schon auf 100 %, aber bleibt voll erreichbar.
ZitatDer FHEM-Prozess springt für ca 18 s schon auf 100 %, aber bleibt voll erreichbar.
Wuesste gerne, wieso das passiert.
Eine bessere Loesung waere ser2net beizubringen, den Port solange nicht zu anzubieten, bis das das Geraet nicht erreichbar ist.
Soweit ich sehe, wird stattdessen der String
Device open failure: OS error, see logs
zurueckgeliefert, und die Verbindung geschlossen.