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.