Weboberfläche nicht erreichbar

[sash.sc]

Habe ich auch gemacht. Dort war soweit nix zu sehen !!! Ausser dass das Terminal irgendwann für den Wust an Meldungen nicht mehr reicht !! 

[CoolTux]

Dann weiß ich leider auch nicht.

[sash.sc]

Habe dann FHEM mal mit der fhem.cfg.demo laufen lassen. da war fast sofort alles ereichbar und keine auslastung des pi laut TOP.
Muss mal eine ältere CFG zurück spielen !

[Wernieman]

oder per copy&paste im RAW-Modus die Config nach FHEM "pusten" und immer wieder durch FHEM-Neustart Testen ...

[sash.sc]

Habe gerade eine Update check gemacht. Habe da folgende Meldung bekommen.

Code Auswählen Erweitern


fhem https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: Bad hostname 'fhem.de:443'




[sash.sc]

Wollte mal eben bescheid geben. Fhem läuft wieder.
Konnte aber nicht das alte fhem zum laufen bringen.


Zum Glück lasse ich immerhin nachts ein komplette Backup von fhem machen.

Habe dann eine neue sd Karte genommen, das aktuelle Raspbian drauf gemacht.
Habe auch eine Datei, wo alle manuell installieren Module dokumentiert sind.
Die dann auch installiert.
Fhem installiert, alte Dateien (komplettes opt/fhem/) Verzeichnis zurück kopiert, rechte vergeben.

Und dann lief es wieder........
Bis auf alexa. Dies manuell nachinstsalliert, dann noch die rechte vergeben.

Ein Glück, dass das Modul über die Readings gesagt hat, was es will.

Und seitdem läuft wieder alles.

Zeitaufwand mit klüngeln ca. 1.5 Stunden.

Gruß Sascha

Gesendet von meinem MI 9 mit Tapatalk

[NoPlan12]

Hallo,
ich habe auch ein Problem, welches hier vielleicht rein passen könnte.
Ich habe ein paar Sensoren (Temperatur und Luft) über ein JeeLink Gateway in Fhem eingebunden. Die Sensoren funktionieren auch alle ohne Probleme. Diese habe ich in 2 Räume geschoben. Nachdem es ein paar Tage ohne zwischenfälle gelaufen ist, ist nun seit ein paar Tagen das Problem, daß ich in den einen Raum nicht mehr rein komme. So bald ich den anklicke sieht man das versucht wird diesen aufzurufen, was dann aber mit Meldung "Abbruch wegen Zeitüberschreitung" beendet wird.
In freezemon steht unter Anderem folgendes drin:
   
2020-01-09: s:18:17:55 e:18:19:26 f:91.684 d:cmd-get logdb CURRENT INT 2020-01-09_00:00:00 2020-01-09_23:59:59 LaCrosse_03:humidity LaCrosse_03:temperature(WEB) cmd-get logdb CURRENT INT 2020-01-09_00:00:00 2020-01-09_23:59:59 LaCrosse_04:humidity LaCrosse_04:temperature(WEB) cmd-get logdb CURRENT INT

Vielleicht kan mir jemand bei der Fehlersuche weiter helfen. Ich bin da ziemlich überfordert. 

Fhem läuft bei mir auf einem RPi3. Das system sollte aktuell sein.

[CarlMcCoy]

Das Thema wurde hier schon oft behandelt, aber so wie ich das alles durchgesehen habe, gab es für mein Problem keine Antwort:

• Der Netzspannung fällt aus.
• Netzspannung kommt wieder
• FHEM kann mit dem üblichen Aufruf weder intern noch extern erreicht werden, aber Zugriff über WinSCP oder Putty funktionieren tadellos. FHEM läuft.
• Wird über Putty ein Shutdown des BananaPi mit "shutdown -r now" ausgelöst, sind alle Probleme wie weg.

Also der BananaPi wird über eine SSD, die mit SATA angeschlossen ist, gebootet, also es kann kein Speicherkartenproblem sein.
Es kann auch kein csrfToken-Problem sein, denn es wird zwar FHEM 5.8 genutzt, aber mit "attr WEB csrfToken none" wird es ausgeschaltet.
Was kann denn bei einem harten Ausstieg (Netzspannung weg) und einem geordneten Ab-und Anschalten durch shutdown so anders sein, dass FHEM über die WEB-Oberflächen nicht mehr zu erreichen ist? Und was könnte man denn da machen, um das auszuschließen?

Hi,

ich habe auch seit einiger Zeit immer wieder mal das Phänomen, dass meine FHEMWEB Instanz unter dem Port 8083 nicht mehr erreichbar ist.
Per SSH konnte ich mich immer problemlos connecten. Die Logs auch unter verbose 5 waren unauffällig. Alle Automationen liefen auch noch.
Bisher musste immer eine schnelle Lösung her und ich habe einfach den Raspi neu gestartet und alles war wieder fein.
Heute war die Weboberfläche mal wieder nicht zu erreichen und habe ich mich mal rangesetzt und versucht das ganze zu debuggen, weil es auf Dauer schon nervig ist.

Als erstes htop gestartet. CPU Last nicht vorhanden, Ram nicht voll, HD auch genug Speicherplatz frei.
Netstat zeigte Verbindungen mit dem Port 8083 an. Leider war das nur die Verbindung zwischen homebridge und meinem fhem Raspi.
lsof zeigte auch keine offen gebliebenen Verbindungen an.
Service fhem status gab auch grünes Licht.
Soweit alles gut.

Mit Telnet verbunden konnte ich mit fhem kommunizieren und auch Befehle absetzen. Ein

Code Auswählen Erweitern

shutdown restart ergab keine Änderung. FHEMWEB war immer noch nicht erreichbar.
Ich glaube auch nicht, dass das Problem bei FHEM selbst liegt, sondern eher am System.
Vor einigen Wochen konnte ich mit

Code Auswählen Erweitern

sudo /etc/init.d/networking restart wieder auf die Weboberfläche zugreifen. Das hat heute leider nicht geholfen. Aber ein

Code Auswählen Erweitern

sudo ifconfig eth0 down && sudo ifconfig eth0 up & hingegen schon. Der Zugriff war sofort wieder da.

Ich habe derzeit das Problem noch nicht genau identifiziert, werde das aber weiter debuggen.

Grüße
CarlMcCoy

[NoPlan12]

Hi,
bei mir ist das nicht so wie bei CarlMcCoy. Ich erreiche alle Räume ohne weitere Verzögerung. Nur beim Versuch den einen Raum und den "Everything" natürlich noch, passiert nix mehr. Also es endet mit dem Fehler "Zeitüberschreitung". Danach kann ich fhem wieder normal aufrufen und es geht. Die Sensoren selbst scheinen nicht davon betroffen.


NoPlan12

[amenomade]

SVG Plots in dem Raum?

[NoPlan12]

Hallo amenomade,
ja SVG Plots sind auch drin. Wenn ich recht überlege wahrscheinlich nur noch die Plots. Hast du eine Idee wie ich das Problem los werde?

Gruß NoPlan12

[sash.sc]

Hi,

ich habe auch seit einiger Zeit immer wieder mal das Phänomen, dass meine FHEMWEB Instanz unter dem Port 8083 nicht mehr erreichbar ist.
Per SSH konnte ich mich immer problemlos connecten. Die Logs auch unter verbose 5 waren unauffällig. Alle Automationen liefen auch noch.
Bisher musste immer eine schnelle Lösung her und ich habe einfach den Raspi neu gestartet und alles war wieder fein.
Heute war die Weboberfläche mal wieder nicht zu erreichen und habe ich mich mal rangesetzt und versucht das ganze zu debuggen, weil es auf Dauer schon nervig ist.

Als erstes htop gestartet. CPU Last nicht vorhanden, Ram nicht voll, HD auch genug Speicherplatz frei.
Netstat zeigte Verbindungen mit dem Port 8083 an. Leider war das nur die Verbindung zwischen homebridge und meinem fhem Raspi.
lsof zeigte auch keine offen gebliebenen Verbindungen an.
Service fhem status gab auch grünes Licht.
Soweit alles gut.

Mit Telnet verbunden konnte ich mit fhem kommunizieren und auch Befehle absetzen. Ein

Code Auswählen Erweitern

shutdown restart ergab keine Änderung. FHEMWEB war immer noch nicht erreichbar.
Ich glaube auch nicht, dass das Problem bei FHEM selbst liegt, sondern eher am System.
Vor einigen Wochen konnte ich mit

Code Auswählen Erweitern

sudo /etc/init.d/networking restart wieder auf die Weboberfläche zugreifen. Das hat heute leider nicht geholfen. Aber ein

Code Auswählen Erweitern

sudo ifconfig eth0 down && sudo ifconfig eth0 up & hingegen schon. Der Zugriff war sofort wieder da.

Ich habe derzeit das Problem noch nicht genau identifiziert, werde das aber weiter debuggen.

Grüße
CarlMcCoy

Ich habe dies auch mal gehabt. Habe den raspi neu aufgesetzt und das Backup zurück gespielt. Und wieder das gleiche Problem.
Irgendwann per Zufall habe ich von einem svg Plot einen Eintrag gehabt der engen lang war. Warum auch immer.
Habe dann mal das betroffene Plot gelöscht und wieder neu angelegt. Danach lief es wieder oder Probleme.

Hoffe dies hilft weiter!

Gruß Sascha

Gesendet von meinem MI 9 mit Tapatalk

[NoPlan12]

Hallo @sash.sc,
der Tipp war gut. Nach dem Löschen der SVG Plots war der Raum wieder erreichbar. Prima.
Was mir aber aufgefallen ist, daß, so bald ich einen neuen Plot in den Raum stelle es wieder deutlich länger mit dem Zugriff dauert. Ich habe auch einen Unterschied bemerkt zwischen Plots mit Daten aus den File.logs oder einer DB.
Die DB ist auf einem Stick welcher per USB mit RPi verbunden ist. Das ist dann sicher der Grund für den unterschiedlichen Zugriff oder?

NoPlan12

[sash.sc]

Denke das die Zugriffs Zeiten mit Sicherheit anders sind. Da kann ich aber nix zu sagen, da ich ganz normal die sd Karte habe mit file log ohne db.

Gruß Sascha

Gesendet von meinem MI 9 mit Tapatalk

[Wernieman]

Es kommt auch darauf an, was für eine DB .....