JeeLink über Ser2Net / Fhem friert ein wenn USB Device nicht verfügbar

[fast-eddy]

... danke für Warnung Rudi!
Werde es gleich mal testen.

CU,
Ralf

[fast-eddy]

@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

[justme1968]

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.

[thaliondrambor]

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:

Code Auswählen Erweitern

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 ^^

[Spiff]

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.

[justme1968]

ich verwende das ganze unter linux und mein fhem stürzt nicht ab.

da ich windows nicht benutze muss das leider jemand anders rausfinden.

[presskopf]

Sorry für das Leichenschänden, aber ein neuer Thread bringt's m.E. nicht... 

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:

Code Auswählen Erweitern

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

[rudolfkoenig]

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:

Code Auswählen Erweitern

stacktrace();und dann bitte diese Ausgabe im Problemfall hier zeigen.

[presskopf]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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


[rudolfkoenig]

Kannst Du bitte in 36_Jeelink.pm in der Funktion JeeLink_Ready die Zeile 876

Code Auswählen Erweitern

                if($hash->{STATE} eq "disconnected");
gegen

Code Auswählen Erweitern

                if(DevIo_getState($hash) eq "disconnected");
austauschen, und erneut testen?

[presskopf]

Das Verhalten ist identisch.

Code Auswählen Erweitern

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.