Weboberfläche nicht erreichbar

Begonnen von manne44, 21 März 2019, 19:40:05

Vorheriges Thema - Nächstes Thema

manne44

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?
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

rudolfkoenig

Vielleicht steht eine Antwort auf diese Fragen im FHEM-Log, es waere zielfuehrend, diese hier anzuhaengen.

manne44

Ich hatte mir natürlich sofort das LOG-File angesehen, aber nichts als die von mir generierten Einträge gefunden. Deshalb hatte ich es auch gelöscht. Allerdings habe ich auch mit "attr global verbose 2" die Meldungsflut verringert, so dass vielleicht wichtige Einträge nicht sichtbar waren. Ich könnte das noch mal mit verbose 5 wiederholen und so prüfen, ob dieser Sachverhalt reproduzierbar ist.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

Wernieman

Ich würde Tippen auf USB (oder andere externe Geräte), welche nach einem Stromausfall noch nicht wieder da sind.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

manne44

An USB kann es nicht liegen, es sind keine USB-Ports belegt. Über I2C wird ein Arduino Nano abgefragt.
Da wartet nichts, denn FHEM läuft einwandfrei.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

sash.sc

Hallo zusammen.

Ich habe das  gleiche Problem.
Ich habe aber vor ein paar tagen versucht den unificontroller zu installieren. dies hat nicht geklappt.
Habe dann den unifi controller und das java deinstalliert. ich vermutet das dort ein paar module mit deninstalliert wurden, die für den zugriff auf fhem zuständig sind.

Habe die fhem.cfg bearbeitet und es auf log4 gestellt. ich kann jedoch nix feststellen, warum der webzugriff nicht mehr funktioniert !!!!

Wie kann man da  zur Fehlersuche vorgehen ?

Danke !
Gruß
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

sash.sc

Danke für den TIP.

Habe aber mal einen Neustart mit verbose4 in ein leeres logfile laufen lassen.
Der Startvorgang bleibt eine ganze Zeit bei folgendem hängen


2019.08.29 20:40:31 4: FHEM::Meta::__GetMetadata WARNING: Unregistered core module or package:
  FHEM/RTypes.pm has defined VCS data but is not registered in MAINTAINER.txt.
  Added acting maintainer with limited support status
2019.08.29 20:42:55 4: dewpoint_notify: cmd_type=dewpoint devname=installer dewname=dew_state, dev=installer, dev_regex=.* temp_name=temperature hum_name=humidity



Wenn ich in der Konsole unter TOP schaue, bleib die CPU Auslastung bei 100%. Aber FHEM scheint weiter zu laufen. Lichter gehen automatisch an, etc.

Jemand noch eine Idee, wo ich nach Fehlern suchen kann ?
Wenn ich ins LOG schaue, scheint FHEM normal weiter zu laufen.

Danke !

Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

CoolTux

Wie aktuell ist Dein FHEM? Ich meine Julian hatte vor ein paar Tagen für Meta eine Verbesserung ins SVN geladen das es nicht mehr so lange dauert.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

sash.sc

Kann man die Version ausserhalb vom WEBIF ausloesen ?

Letztes Update vor ein "paar" Tagen könnte auch letzte woche gewesen sein.  ::)
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

CoolTux

Sollte aber reichen. Wie ist es wenn du ihn etwas mehr Zeit gibst. So 5 min zum Beispiel. Dann sollte Meta locker fertig sein.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

sash.sc

Auch wenn ich warte, bleibt fhem nicht erreichbar (port 8083).
Habe mal über port 8085 und 8084 aus dem browser zugegriffen. Dort klappt der zugriff und das WEBIF wird dargestellt.

Unter der konsole bleibt aber weiterhin die Auslastung bei 100%.
Wenn ich in fhem unter sysmon schaue, bleibt die auslastung bei ca. 40%.

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

CoolTux

Dann starte FHEM mal im Debug Mode wie im Artikel geschrieben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

sash.sc

So, habe eine leere Log Datei ab dem Start mit verbose 5 laufen lassen. habe mir parallel in der konsole mal mit TOP angeschaut, wie lange das alles dauert.
Es dauert ca. 4 Minuten, dann geht die CPU Last von 100% auf ca. 15% im Schnitt runter und bleibt auch da.
Wenn ich jetzt den Webzugriff über Port 8083 starte, dann geht die Last für ca. 1 Minuten auf 100% und dann wieder runter. zugriff auf das WEBIF geht nicht.
Was auch auffällt unter TOP, dass beim Webzugriff eine 2. instanz geöffnet wird, die dann mit 100% Auslastung für ca. 1 Minute zu Buche schlägt.

In der LOG datei ist, soweit ich das beurteilen kann, auch nix zu finden, was den Zugriff über Port 8083 verhindert.

Danke und Gruß
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

sash.sc

Zitat von: CoolTux am 30 August 2019, 13:59:58


Habe ich auch gemacht. Dort war soweit nix zu sehen !!! Ausser dass das Terminal irgendwann für den Wust an Meldungen nicht mehr reicht !!  ;)
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

CoolTux

Dann weiß ich leider auch nicht.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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 !
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Wernieman

oder per copy&paste im RAW-Modus die Config nach FHEM "pusten" und immer wieder durch FHEM-Neustart Testen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

sash.sc

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


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'






Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

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
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

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

Zitat von: manne44 am 21 März 2019, 19:40:05
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 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 sudo /etc/init.d/networking restart wieder auf die Weboberfläche zugreifen. Das hat heute leider nicht geholfen. Aber ein 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

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

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

Zitat von: CarlMcCoy am 09 Januar 2020, 21:23:06
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 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 sudo /etc/init.d/networking restart wieder auf die Weboberfläche zugreifen. Das hat heute leider nicht geholfen. Aber ein 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

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

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

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Wernieman

Es kommt auch darauf an, was für eine DB .....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

NoPlan12

SQlite, aber nicht auf dem USB Stick sondern der SD Karte.  :-[