FHEM Oberfläche nicht mehr erreichbar!?

rapster · 16 Oktober 2015, 10:51:09

Dein Fhem wird i.M. bei einem "/etc/init.d/fhem stop" mit diesem Befehl versucht zu beenden: pkill -U fhem perl

Du kannst mal versuchen ob das funktioniert wenn du den Befehl manuell auf der Kommandozeile ausführst, allerdings sehe ich das so bei fhem zumindest zum ersten mal

Bei mir zumindest beende ich fhem geregelt über ein "shutdown" am telnet interface, dazu kannst du dir mal mein anhängendes init-script anschauen, hier wird bei einem "stop" ein "perl fhem.pl telnetPort 'shutdown'" aufgerunfen.

sash.sc · 16 Oktober 2015, 10:58:39

An dem Script habe ich nix verändert. Bin dafür nicht firm genug.

Habe die fhem 5.6 installiert und danach ein update durchgeführt.
Habe einen shutdwon über die komandozeile von fhem durchgeführt. den pi manuell runtergefahren und den Stecker gezogen, wegen Standortveränderung des Pi.
Danach fing das ganze Desaster an.
Habe dann das perl über die PID gestoppt und fhem neu gestartet, danach war fhem wieder über den Browser erreichbar.

BassdoxXx · 27 Juli 2020, 12:59:38

Ich weiß, dass seit einiger Zeit hier nichts gechrieben wurde.

Was ich geändert habe an meinem netzwerk:
Ich bin von der Fritzbox auf das UNifi System umgestiegen und habe mir für verschieden Bereiche neue IP Ranges erstellt, so wie VLANs in mein Netzwerk integriert, sodass IoT, Gäste und DMZ getrennt sind.

Leider hatte ich danach das Problem, dass meine FHEM Oberfläche nicht erreichbar war. Fhem selber war aber up and running.
Ich habe Telegram Nachrichten von FHEM erhalten und die MQTT Verarbeitung hat auch super funktioniert, nur eben die Oberfläche auf Port 8083 nicht.
Ich habe mich durch alle möglichen Hilfe-Leitfäden gearbeitet, aber ohne Erfolg.
Also habe ich mich mal durch den LOG beim Starten gearbeitet, dabei ist mir aufgefallen, dass da verdammt oft Phillips Hue vorkam.

Anschienend flutet Phillips Hue Bridge Modul bei Nichterreichbarkeit FHEM so sehr, dass es nicht mehr richtig arbeiten kann.

Ich habe also in der Fhem.cfg die korrekte IP Adresse der Bridge eingetragen und siehe da - FHEM ist wieder ganz normal erreichbar.

Wollte das hier nur mal aufschreiben, falls jemand ein ähnliches oder gleiches Problem hat.

#philips #hue #fhem #start #oberfläche

M.K. · 26 September 2020, 15:55:29

Ich habe exakt das gleiche Problem und führe deswegen diese Thema weiter.

Vorgeschichte: Ich musste mein lokales Netzwerk von von 192.168.1.xx auf 192.168.20.xx ändern. Da kann doch eigentlich nicht so viel schiefgehen, denkt man...

Also, meine Checkliste

-der PC hat eine der neuen IPs, ist erreichbar, und ich kann mich per SSH einloggen (OK)
-

Code Auswählen

cat ./log/fhem-2020-09.log sagt

Code Auswählen

Server started with 372 defined entities (fhem.pl:22408/2020-07-16 perl:5.030000 os:linux user:fhem pid:94)

also keine fehler (OK) (ich hatte ja acuh nichts geändert...)

Code Auswählen

service fhem status sagt auch alles OK

Zitat● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-09-26 22:29:26 JST; 17min ago
Process: 91 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 94 (perl)
Tasks: 12 (limit: 16609)
Memory: 165.6M
CGroup: /system.slice/fhem.service
├─ 94 /usr/bin/perl fhem.pl fhem.cfg
└─101 homebridge

Warning: some journal files were not opened due to insufficient permissions.

-ports sind wie folgt aktiv

Code Auswählen

ss -tulw

ZitatNetid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
icmp6 UNCONN 0 0 *%eth0:ipv6-icmp *:*
udp UNCONN 0 0 0.0.0.0:33983 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:*
udp UNCONN 0 0 127.0.0.53%lo:domain 0.0.0.0:*
udp UNCONN 0 0 192.168.20.86%eth0:bootpc 0.0.0.0:*
udp UNCONN 0 0 [fe80::216:3eff:fed2:a207]%eth0:dhcpv6-client [::*
udp UNCONN 0 0 [::59069 [::*
udp UNCONN 0 0 [::mdns [::*
tcp LISTEN 0 32 0.0.0.0:8083 0.0.0.0:*
tcp LISTEN 0 32 0.0.0.0:8084 0.0.0.0:*
tcp LISTEN 0 32 0.0.0.0:8085 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
tcp LISTEN 0 32 0.0.0.0:8089 0.0.0.0:*
tcp LISTEN 0 32 0.0.0.0:7072 0.0.0.0:*
tcp LISTEN 0 511 *:36849 *:*
tcp LISTEN 0 511 *:51826 *:*
tcp LISTEN 0 511 *:46067 *:*
tcp LISTEN 0 128 [::ssh [::*
tcp LISTEN 0 511 *:38265 *:*
tcp LISTEN 0 511 *:8282 *:*
tcp LISTEN 0 511 *:39459 *:*
tcp LISTEN 0 511 *:44839 *:*

- Top zeigt auch keine hohe CPU last, wobei die CPU ein Rzyen ist

- wenn ich im Browser die adresse wie immer eingebe, kommt meistens nichts, aber manchmal wir der tab als "Home Sweet Home" überschreiben, als ob es doch eine Verbindung gäbe, aber es kommt nie das GUI

- ich habe auch probiert, wie von meinem Vorredner vorgeschlagen, mal die HUE Bridge abzuklemmen, aber das war es nicht.

Hat jemand eine Idee?? Ich tippe auf Netzwerk, aber mir sind die Ideen ausgegangen.

Martin

BassdoxXx · 26 September 2020, 16:01:01

Hi Martin,

Was sagt denn dein FHEM log ? Ich finde den immer unglaublich hilfreich. Weiter oben hier im Thread steht wie man ihn anzeigen lassen kann und ansatzweise auswertet. Leider bin ich grad nur am Handy, da ist das Suchen in Threads immer nicht schön. Aber falls du Philips Hue nutzt, schau mal, ob der post über deinem auch zutrifft.

Grüße
Bassdox

M.K. · 26 September 2020, 16:35:43

https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Pr.C3.BCfen:_L.C3.A4uft_.C3.BCberhaupt_ein_FHEM-Prozess.3F

Bin mit dem tip nun endlich weitergekkommen.

Code Auswählen

perl fhem.pl fhem.cfg.demo
geht und damit ist FHEM erreichbar. Es muss also noch irgendwo was nicht richtig gehen, obwohl kein Fehler im Log landet. Na dann, einen Tag WE hab ich ja noch

Otto123 · 26 September 2020, 19:16:23

hi,

was gibt Dir das zurück?

Code Auswählen

grep "define WEB" /opt/fhem/fhem.cfg

Gruß Otto

Prof. Dr. Peter Henning · 26 September 2020, 19:28:33

Ich tippe darauf, dass er in seinem System irgendwo eine Adresse im alten Netzwerk hart codiert hat.

LG

pah

M.K. · 27 September 2020, 02:48:05

Zitat von: Prof. Dr. Peter Henning am 26 September 2020, 19:28:33
Ich tippe darauf, dass er in seinem System irgendwo eine Adresse im alten Netzwerk hart codiert hat.

In der fhem.cfg nach allen 192... IPs zu suchen und zu ersetzen war ja naheliegend. Aber der Übeltäter hatte sich an anderer Stelle versteckt.

Code Auswählen

sudo perl fhem.pl -d fhem.cfg

hat mich auf die richtige Fährte gebracht.

Ich hatte noch eine DB.conf im fhem Ordner, in der noch eine alte IP der DB stand.

Danke für die Hilfe!

VG
Martin

alpine310 · 21 Mai 2021, 08:59:31

Hallo
Ich will hier noch eine Variante mit Lösung zu obigen Problem dokumentieren.

Ausgangslage:
Über Nacht (ja Abends gings noch am nächsten Morgen nicht mehr) war fhem über die
Web-Oberfläche nicht mehr erreichbar. Es gab keine Time-Out´s im Browser. Er hat nur
ständig weitergerödelt und es kam keine Anzeige.
Der Raspi war über ssh erreichbar. Mit top konnte man sehen daß er sich langweilte (Auslastung vielleicht 5%).
Speicherauslastung etc. alles im grünen Bereich.
df zeigte, daß auch genug Speicherplatz auf der SD-Karte vorhanden war.

Da ich immer wieder Probleme mit einer "voll werdenden" SD-Karte hatte, habe ich
einen großen USB-Stick angesteckt, auf dem alle Log-Dateien und "Messwert-Dateien"
gespeichert werden.

Für mein Meßwert-logging benutze ich DbLog mit SQLITE.

Lösung:
Irgenwann kam ich auch die Idee mir mein Log-Verzeichnis anzusehen. Der USB-Stick war
gerade mal mit 2% belegt. Allerdings hatte die Datenbankdatei inzwischen eine Größe
von 4GB erreicht!!
Der USB-Stick war mit VFat formatiert, das nur Dateigrößen bis 4GB zuläßt!!

Inzwischen habe ich den USB-Stick mit ext4 formatiert und jetzt läuft alles wieder
wie geschmiert

.

Erkenntnis:
Verhält sich fhem "komisch" dann ist es immer eine gute Idee beim Raspi nach Speicher-
belegung der SD-Karte sowie Menge und Größe der Log-Dateien und ähnlichem zu schauen!!

Gruß Martin