Hallo,
mein Fhem auf RasPi ist nichtmehr wirklich erreichbar :-(
192.168.178.44:8083/fhem?room=all im browser ist nicht erreichbar. auch über smartphone/tablet oberfläche nicht. die andFHEM app kann auch nicht connecten. Im Router ist der rasppi unter der korrekten IP "Online". Über Putty SSH Port 22 auch nicht erreichbar (timeout).
Was komisch ist: beim tastendruck auf meinem Homematictaster zeigt die bestätigungsLED grün an (Virtueller Aktor bestätigt also "Signal empfangen"). Wenn ich den Raspi neustarte, zeigt die bestätigungsLED rot. also scheint FHEM irgendwie zu starten, aber bloß nicht wirklich in meinem netzwerk angemeldet zu sein.
bevor ich jetzt wild rumprobiere und vllt wirklich was zerschieße: habt Ihr ne Lösung?
Achja: ich hab "nix gemacht" ::) ehrlich. gestern war ich noch auf der FHEM Weboberfläche... seitdem hab ich nix "gebastelt"
vielen Dank schonmal
mikenike
Kannst du die IP anpingen, wenn nicht evtl. Netzwerk Problem.
VG
Frank
Hast du vorgestern ein Update gezogen?
Hast du evtl. "59_Twilight.pm" integriert?
nein, habe kein Update gezogen. ping geht, solange der Pi am Router gelistet ist. ich hab die FHEM Oberfläche mittlerweile noch ein paar mal erreicht, aber nach neusterts (über ssh reboot, oder einfach stecker ziehen) kommt die fhem oberfläche nur sporadisch wieder zum vorschein. nachdem es jetzt ein tag gelaufen ist, ist die oberfläche gerade wieder nichtmehr erreichbar -.- irgendwas ist faul. wenn ich jetzt 2-3 mal neustarte gehts bestimmt irgendwie wieder (für nen Tag).
Welche Logfiles oder analysen könnten weiterhelfen?
Hast du den Raspberry eine feste IP zugewiesen; hast du dem Router mitgeteilt dass dieses Gerät immer die gleiche IP bekommen soll !?
Auch wenn der Pi im Router mit der richtigen IP angezeigt wird, heißt dass noch lange nicht dass dieser auch wirklich online ist, es vergeht
eine Zeit bis der Status im Router richtig dargestellt wird.
Hast du den Pi über LAN oder WLAN angebunden ?
Ja, feste IP Adresse wird zugewiesen. Der Pi ist direkt am Router per Lankabel angebunden. Was mir aufgefallen ist: wenn der Pi zwar im Router gelistet ist, aber die FHEM Oberfläche nicht erreichbar ist, dann steht beim Status vom PI: "mit FRITZBOX verbunden , nicht im Internet" wenn die FHEM Oberfläche erreichbar ist steht dort: "mit FRITZBOX verbunden , im Internet".
was verbirgt sich daheinter?
Hallo, nur so eine Ahnung. Über IPV4 oder verbindet der Raspi vlt. Über IPV6, so ein ähnliches Problem hatte ich mit einem Debian Server und nach dem deaktiviren der IPV6 Verbindung waren die Verbindugsabbrüche weg.
VG
Frank
also im Router angekreuzt hab ich: "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." von IPv6 seh ich da nix.
wie bekomme ich herraus wie sich der Pi anmelden will? Ich kann per putty und ssh auf den pi zugreifen, ich weiß bloß nicht wie ichs rausfinde ;-)
Hallo, also ich hab damals einen Monitor an den Server angeschlossen und da dort eine grafische Oberfläche lief, war das schnell rauszufinden. Unter Linux, auf der Konsole kannst du mit Netstat und ifconfig sehen wie der raspi verbunden ist.
VG
Frank
Hi,
versuche Dich mal mittels "ssh" auf Deinem Raspi zu verbinden.
Wenn das geht, schau mal mittels dem Befehl "top" nach, was Dein Raspi
derzeit so treibt.
Hierbei ist wichtig, ob er irgendwie stark mit was beschaeftigt ist.
Wenn ja, dann kann man hier weiter pruefen, was zu machen ist.
Gruss R.
Hallo, per ssh eingeloggt:
top zeigt nix außergewöhnliches: cpulast in summe: 1,5% alle paar sekunden taucht kurz fhem mit 4-5% cpu last auf. Memory Grundauslastung sieht analog dazu ruhig aus (0,5% idle; fhem ca 4%).
netstat bringt für mich nichts außergewönliches.
ifconfig dies:
eth0 Link encap:Ethernet HWaddr b8:27:eb:2h:b2:51
inet addr:192.168.178.45 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:265963 errors:0 dropped:27 overruns:0 frame:0
TX packets:257816 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21790464 (20.7 MiB) TX bytes:24844367 (23.6 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.3 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:272 errors:0 dropped:0 overruns:0 frame:0
TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21360 (20.8 KiB) TX bytes:21360 (20.8 KiB)
zurzeit läuft aber auch wieder alles.gestern abend hab ich 3 mal hintereinander (hart) neugestartet, dann hat er sich wieder gefangen. zuvor hatte er sich wieder selbstständig aus dem Netzwerk verabschiedet :-\
Wenn die Oberfläche nicht mehr erreichbar ist, funktioniert dann der SSH-Zugriff noch?
Und auch mit top kontrolliert, dass fhem noch läuft?
Wenn ja, hilft es evtl., DHCP im Raspi auszuschalten und die IP fest einzutragen...
...das sollte dann aber auch eine sein, die nicht im DHCP Bereich der Fritzbox liegt (also standardmäßig unter 20)
inet addr:127.0.0.3 Mask:255.0.0.0
wie geht denn das?
Zitatinet addr:127.0.0.3 Mask:255.0.0.0
wie geht denn das?
Sollte eigentlich nicht so da drin stehen, aber alles was mit 127 anfängt ist local...
Hi,
Hast Du einen USB Hub für den CUL ?
Wenn ja, arbeite mal ohne den Hub.
Wenn nein, verwende mal einen anderen Port.
Welche CUL Version hast Du ?
Gruß R.
Sorry für die späten Antwort, war unterwegs.
Bisher ist das Problem komischerweise nicht mehr aufgetreten, nachdem es mich eine Woche am Stück genervt hat.
Ich benutze keinen HUB . CUL Version ist CULV3OEM CC1101USB Lite.
Wenn die FHEM Oberfläche nicht mehr erreichbar ist, kann ich auch nicht per SSH verbinden. Der RasPi wird dabei im Router als mit dem Netzwerk verbunden angezeigt, aber nicht mit dem Internet verbunden (alle anderen Netzwerkgeräte zu diesem Zeitpunkt schon). Mein Homematic Taster zeigt zu diesem Zeitpunkt mittels Kontroll LED(grün) aber an, dass Signale erfolgreich übermittelt wurden (an den virtuellen Aktor); meine HUE Lampen kann ich aber zu diesem Zeitpunkt nicht ein und ausschalten, dazu müsste ja was über das Netzwerk laufen. Reine Homematic Aktoren habe ich zur Zeit nicht, würde aber fast tippen, dass diese dann geschaltet werden könnten. Die gegen Probe zeit bei ausgeschaltetem Raspi, eine rote KontrollLED beim drücken der Tasten.
Daraus schleiße ich, dass der Raspi läuft und FHEM auch (virtueller Aktor reagiert), bloß im Netzwerk meldet er sich nicht richtig an.
2-3 mal (hart) neustarten hilft und es funktioniert wieder (Router zeigt den Raspi als mit dem Internet verbunden an).
naja, zur zeit gehts ja.
was ist an der 127.0.0.3 falsch?
Zitatnaja, zur zeit gehts ja.
was ist an der 127.0.0.3 falsch?
Standard ist localhost normalerweise 127.0.0.1
und die Frage ist , wer das geändert hat? wenn nicht du?
zumal du ja prob mit dem Netzwerk hast.... , und wer weiß was noch anders ist ;)
Die lokale Adresse ist normalerweise die 127.0.0.1.
Link encap:Local Loopback
inet addr:127.0.0.3 Mask:255.0.0.0
Bei mir:
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX packets:274613 errors:0 dropped:0 overruns:0 frame:0
TX packets:274613 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:58153867 (55.4 MiB) TX bytes:58153867 (55.4 MiB)
VG
Frank
Du warst schneller :)
Hi
bei mir ware es mal eine defekte SD Karte, welche mich auf ähnliche Weise
über Monate hinweg generft hat.
Aber auch die Spannungsversorgung hat so seine Tücken.
Du hast doch nicht irgendwelche starken Verbraucher, welche ab und zu eingeschaltet
werden und dadurch Störungen versachen.
Oder sitzt der Raspi in einem anderen Gebaeude wie der Router ?
Gruss R.
Hallo.
Hab das auch des öfteren. Ich kann mich per telnet zum Raspi verbinden, sehe das auch fhem läuft.
nur ein /etc/init.d/fhem stop und anschliessendem /etc/init.d/fhem start hilft wieder.
warum das webif hängt habe ich noch nicht eruiren können.
zumindest läuft es die letzten 14 tage reibungslos.
Hallo Leute.
Habe das problem, dass nach einem Reebot. FHEM nicht mehr erreichbar ist.
Habe verschiedenes ausprobiert. mit PUTTY und WinSCP alles gar kein Problem. der PI ist auch in netzwerk erreichbar.
Habe jetzt versucht manuell das perl zu starten und bekommen folgende Meldung
Zitat
Can't open ./log/fhem-2015-10.log: Keine Berechtigung at fhem.pl line 2272.
Wenn ich mir mit WINSCP das Verzeichniss anschauen steh FHEM als Besitzer drin und die Rechte sind rw-r--r--
Hatte auch schon mehrfach einen Neustart des Pi durchgeführt.
Irgendwie passiert nix mit FHEM. Pilight ist über das WEB erreichbar.
Danke schonmal im vorraus.
Sash
P.S.: auf ne Neuinstallation von FHEM habe ich im Moment keinen Nerv ;-)
Existiert das log-Verzeichnis und ist es "ausführbar"?
Wenn die Logdatei auch exisitert: Ist sie schreibbar?
Schreibbar ja. Ausführbar? Muss ich schauen. Aber warum sollten sich diese Attribute von alleine ändern? Habe fhem über shutdown runter gefahren. Und dann den pi über shutdown und dann den Stecker gezogen. Geändert hatte ich an der cfg nix mehr.
Gesendet von meinem C6603 mit Tapatalk
Die Attribute von der .cfg und .log sind alle auf schreiben gesetzt und ausführbar. Jetzt wird auch wieder in die log Datei geschrieben.
FHEM WEB ist aber immer noch nicht erreichbar.
Habe gestern heraus gefunden, das es mit /etc/init.d/fhem stoppen und wieder start nicht gebracht hatte.
Habe dann den PD herausgefunden und Task dann abgeschaltet. Danach wieder mit /etc/init.d/fhem Start wieder den Server gestartet.
FHEMWEB War dann wieder erreichbar und nach einer Stunde lief die Kiste wieder und meine logs wurden wieder geschrieben.
Ist das normal, dass das manuelle stoppen nix bringt und erst die kill Methode mit pid angegeben werden muss?
Greez
Sash
Zitat von: sash.sc am 16 Oktober 2015, 08:57:23
Ist das normal, dass das manuelle stoppen nix bringt und erst die kill Methode mit pid angegeben werden muss?
Wie schaut denn dein init script aus?
das init script von fhem ? oder ein anderes ? in welchem verzeichniss finde ich es, wenn es ein anderes ist?
ja das von fhem, /etc/init.d/fhem
#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert
### BEGIN INIT INFO
# Provides: fhem.pl
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: FHEM server
### END INIT INFO
set -e
cd /opt/fhem
port=7072
if test "$2" != "noaptmark"; then
apt-mark hold fhem > /dev/null
fi
case "$1" in
'start')
echo "Starting fhem..."
# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
# /opt/hmcfgusb/hmland -d -p 1234 -r 0
#
perl fhem.pl fhem.cfg
# if you want to use configDB for configuration,
# use this command to start fhem:
#
# perl fhem.pl configDB
#
# and remove/comment the above line including fhem.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem..."
# if you want to stop hmland during fhem stop:
# pkill hmland
pkill -U fhem perl
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem is not running"
else
echo "fhem is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
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.
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.
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
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)
-
cat ./log/fhem-2020-09.log sagt
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...)
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
ss -tulwZitatNetid 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
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
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Pr.C3.BCfen:_L.C3.A4uft_.C3.BCberhaupt_ein_FHEM-Prozess.3F (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.
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 ;)
hi,
was gibt Dir das zurück?
grep "define WEB" /opt/fhem/fhem.cfg
Gruß Otto
Ich tippe darauf, dass er in seinem System irgendwo eine Adresse im alten Netzwerk hart codiert hat.
LG
pah
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.
sudo perl fhem.pl -d fhem.cfghat 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
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 ;D.
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