FHEMWEB nicht erreichbar http://ip-fhem-server:8083

[heural]

Hallo,

ich habe das Problem, dass sich unter http://ip-fhem-server:8083 das FHEMWEB nicht mehr öffnet.
Es kommt kein 404-Fehler, der "Chrome Ladekreis" dreht sich nur ohne Ende.

Folgendes habe ich die letzten Tage gemacht:

- ebus-Hardware angeschlossen und in FHEM konfiguriert (https://wiki.fhem.de/wiki/EBUS), FHEM und eBus lieenf ohne Probleme bis auf ein paar Meldung von devices, welche noch angepast werden mussten
- ein "update check & update" gemacht, wie ich mich erinnere aber nicht gleich ein "shutdown restart" danach... erst einen Tag später, da kam es dann das erste Mal zu diesem Problem
- ich habe versucht, ein Backup vor der ebus-Installation ein zu spielen, selbes Verhalten - auch vorher den kompletten /opt/fhem-Ornder zu löschen
- ich habe FHEM komplett deinstalliert und neu (5.7.) installiert, selbes Verhalten (mit jungfräulicher FHEM.cfg)
- ich halte das System eigentl. immer aktuell (apt-get update & upgrade), die Tage hatte auch das raspian ein wohl größeres Update durchgeführt, ich befürchte es hat hier evtl. ein unkompatibles update (perl-www-module) gegeben
- Raspi ist im Netzwerk voll erreichbar, z.b. auch pilight
- FHEM-Server scheint auch zu laufen:
 

Code Auswählen Erweitern

fhem      6894  4.3  2.3  39108 23452 pts/0    S+   20:10   0:03 perl fhem.pl fhem.cfg

und

Code Auswählen Erweitern

tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN      999        27621       6894/perl
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN      0          11777       1417/pilight-daemon
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN      0          12712       1417/pilight-daemon
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      112        11221       1010/mysqld
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      0          11860       1471/smbd
tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN      999        27622       6894/perl
tcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN      999        27623       6894/perl
tcp        0      0 0.0.0.0:8085            0.0.0.0:*               LISTEN      999        27624       6894/perl
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          7650        552/sshd
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      0          10153       704/ebusd


Wer kann hier helfen, ich habe das Problem auch schon in div. anderen Posts durchgesehen und geprüft (BAckup einspielen, kompl. Deinstall/Install)

[heural]

Ich habe noch diesen Tipp befolgt

Code Auswählen Erweitern

# Der USB Check macht manchmal Probleme
attr initialUsbCheck disable 1

von hier: https://213.252.140.23/index.php?topic=64201.0

und FHEM läuft erstmal wieder in Minimal-Konfig.

Ich war bisher der Meinung, FHEM läuft doch recht stabil.
Das aber das Anschließen eines "USB-Gerätes" das Frontend blockiert, wäre ich nie drauf gekommen 

[heural]

Leider muss ich nun doch nochmal nachfragen,
folgendes Verhalten:

Wenn ich die Config ändere und ein rereadcfg oder shutdown restart mache, bleibt das Frontend nicht erreichbar.
Erst ein "service fhem stop & service fhem start" auf console bringt das Frontend wieder zum laufen.

Es hängt mit Sicherheit mit der fhem.cfg zusammen, bzw mit den Devices.
U.a. habe ich neu ECMD für den ebus drin, ich denke fast es hängt damit zusammen.

GRuß
Ralf

[heural]

Da sich durch die vorhergehende Deinstallation/Neuinstallation etc. vermutlich der FHEM-User auch verabschiedet hatte
und ich ihn heute neu angelegt habe, scheint rereadcfg und restart wieder zu funktionieren - also das Frontend ist wieder verfügbar

Code Auswählen Erweitern

sudo adduser fhem gpio

Darauf gekommen bin ich, das mein GPIO-Port des Gaszählers seit Tagen nichts mehr aufzeichnete.
Da laut gpio-readall der Port aber wie gehabt konfiguriert ist und funktionierte, musste es irgendwas zwischen FHEM <-> GPIO sein...