Hallo zusammen,
Fhem ist leider nicht mehr erreichbar. In den Logs finde ich nichts das auf einen ernsten Fehler aufweisen könnte. Im Log schließt Fhem den start ganz normal mit
ZitatServer started with 247 defined entities (fhem.pl:14634/2017-07-03 perl:5.020002 os:linux user:fhem pid:1251)
ab.
Fhem ist also nicht mehr per Web erreichbar, außerdem kann ich mit Wandtastern keine Lampen mehr schalten und über Telegram antwortet Fhem auch nicht.
Also Prinzipiell ist Fhem tot, obwohl im Log steht das alles gestartet ist. :o
Ich habe versucht über Telnet eine verbindung auf zu bauen, um zu schauen, ob wenigstens das geht. Leider habe ich das vorher noch nicht gemacht, eine Verbindung konnte ich aber trotzdem so herstellen, zumindest glaube ich das ;D
telnet localhost 7072Anschließend bekomme ich die Meldung, dass ich mit localhost verbunden bin. wie ich nun genau set/get befhele ausführe, habe ich nicht so ganz herausgefunden. :-X
Was ich zuletz am System geändert habe:
- dnsmasq konfiguriert zwecks PXE Boot im Netz. (Habe die conifg bereits komplett auskommentiert)
- Heute morgen ein Fhem Update gemacht
- Gestern Abend das Chart Frontend für Fhem installiert (zwischenzeitlich aber schon mehrere Reboots gemacht, bis jetzt immer wieder ohne Probleme gestartet)
Wie kann ich am besten herausfinden warum Fhem nicht startet, wenn keine Errors im Log stehen?
Besten Dank schon mal,
Fixel
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Zitat von: CoolTux am 27 Juli 2017, 18:29:17
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Danke dir!
Habe nun alles durch Probiert, bis auf "die Log ausgaben auf die Konsole umstellen" weil ich config.db verwende.
Alles davor war bei mir normal. Der Fhem prozess läuft und die CPU last ist nahe zu Null.
Gibt es sonst noch Ideen? ::)
Edit: gerade nach einem Neustart gemerkt, dass der perl prozess nach einem Raspi Neustart zwei mal da ist. Dies hat sich nach ein Paar Sekunden allerdings selbst geregelt und hat sich auf einen Prozess minimiert. :o
Und FHEMWEB bekommst du nicht geladen?
Wenn nicht dann den telnet Befehl von oben eingeben und zweimal enter drücken.
Dann mach mal list TYPE=FHEMWEB
Zitat von: CoolTux am 27 Juli 2017, 19:08:16
Und FHEMWEB bekommst du nicht geladen?
Wenn nicht dann den telnet Befehl von oben eingeben und zweimal enter drücken.
Dann mach mal list TYPE=FHEMWEB
pi@FHEM:~ $ telnet localhost 7072
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
list TYPE=FHEMWEB
Mhh,
habe das Gefühl, da passiert nicht viel.
Noch mal enter drücken?
Hast du zweimal enter gedrückt?
Zitat von: CoolTux am 27 Juli 2017, 19:13:38
Noch mal enter drücken?
Hast du zweimal enter gedrückt?
Ja, habe mehrmals enter gedrückt.
Passiert aber nichts.
Edit: Was mir noch auffällt ich komme nicht mehr aus der Telnet session raus, weder mit strg C noch mit quit oder exit.
Edit2: Ist denn der Fhem telnet Port standardmäßig offen und definiert?
Dann hängt Dein FHEM würde ich mal sagen. Und der FHEM Prozess ist wirklich nicht bei 100 oder 99 Prozent?
Einmal die System Auslastung:
top - 19:41:00 up 40 min, 1 user, load average: 0.05, 0.04, 0.01
Tasks: 139 total, 1 running, 138 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 0.2 sy, 0.0 ni, 98.5 id, 0.6 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 945512 total, 388844 used, 556668 free, 26364 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 195328 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1778 pi 20 0 5240 2592 2152 R 11.3 0.3 0:00.05 top
94 root 20 0 0 0 0 S 5.6 0.0 0:00.18 jbd2/mmcblk0p2-
1 root 20 0 5416 3856 2724 S 0.0 0.4 0:03.25 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.06 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.09 kworker/u8:0
7 root 20 0 0 0 0 S 0.0 0.0 0:00.40 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/0
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
13 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
14 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
18 root rt 0 0 0 0 S 0.0 0.0 0:00.01 migration/2
19 root 20 0 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/2
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
23 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/3
24 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/3
26 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/3:0H
27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
28 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
29 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
30 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
31 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
32 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompactd0
33 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto
34 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
35 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kblockd
36 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 watchdogd
37 root 20 0 0 0 0 S 0.0 0.0 0:00.66 kworker/0:1
38 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 rpciod
39 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 xprtiod
40 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0
41 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 vmstat
42 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 nfsiod
52 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kthrotld
53 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
Und hier der "Beweis" das Fhem läuft:
pi@FHEM:~ $ ps ax | grep perl
932 ? Ssl 0:09 /usr/bin/perl /opt/fhem/script/lepresenced --loglevel LOG_EMERG -d
1259 ? S 0:15 perl fhem.pl configDB
1789 pts/0 S+ 0:00 grep --color=auto perl
Sollte doch alles so passen oder Irre ich mich da gewaltig?
So langsam gehen mir die Ideen aus
/usr/bin/perl /opt/fhem/fhem.pl 7072 "list TYPE=FHEMWEB"
Kannst du noch mal die letzten 30 Zeilen vom Log hier posten
Zitat von: CoolTux am 27 Juli 2017, 20:10:40
So langsam gehen mir die Ideen aus
/usr/bin/perl /opt/fhem/fhem.pl 7072 "list TYPE=FHEMWEB"
Kannst du noch mal die letzten 30 Zeilen vom Log hier posten
Leider passiert auch nach 2 Minütigen Warten nichts. Die Log Einträge haben sich auch nicht geändert.
Wenn irgendjemand noch Ideen hat würde ich mich freuen.
Zur Not Spiele ich morgen ein BackUp ein.
Ob das Hilft weiß ich nicht. Vielleicht muss auch ein SystemBackup her :o Nicht nur Fhem Backup.
Das wäre aber nur die Not Lösung, besser wäre es den Fehler zu finden.
Wie verbindet sich fhem überhaupt
sudo netstat -lntp | grep perl
Gehe mal vor wie ...
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373 (https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373)
Kannst Du überhaupt in der Telnetkonsole einen Befehl absenden?
Geht auch direkt auf er Shell (ohne erst manuell in telnet)
echo "list" | nc localhost 7072
Zitat von: Wernieman am 27 Juli 2017, 21:43:52
Wie verbindet sich fhem überhaupt
sudo netstat -lntp | grep perl
Gehe mal vor wie ...
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373 (https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373)
Kannst Du überhaupt in der Telnetkonsole einen Befehl absenden?
Geht auch direkt auf er Shell (ohne erst manuell in telnet)
echo "list" | nc localhost 7072
Das kommt als Ausgabe raus, sollte richtig sein? :o
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 2561/perl
tcp 0 0 0.0.0.0:8084 0.0.0.0:* LISTEN 2561/perl
tcp 0 0 0.0.0.0:8085 0.0.0.0:* LISTEN 2561/perl
tcp 0 0 0.0.0.0:5333 0.0.0.0:* LISTEN 932/perl
tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 2561/perl
tcp 0 0 0.0.0.0:7072 0.0.0.0:* LISTEN 2561/perlecho "list" | nc localhost 7072geht bei mir genauso wenig wie alles anders was mit Telnet zu tun hat... :(
wget localhost:8083 -Obekomm eich als Rückmeldung das hier:
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
Sieht wohl eher schlecht aus....
also .....
mach erstmal ein Backup Deines /opf/fhem Verzeichnis
kannst Du bitte mal fhem mit der "ausgelieferten Standard-Demo-cfg" starten?
Mich wundert, das fhem keine CPU-Last, aber auch nicht reagiert ...
Nur am Rande:
Zitatdnsmasq konfiguriert zwecks PXE Boot im Netz
Hast du eine Firewall eingerichtet oder was daran geändert?
Zitat von: Wernieman am 28 Juli 2017, 08:17:05
also .....
mach erstmal ein Backup Deines /opf/fhem Verzeichnis
kannst Du bitte mal fhem mit der "ausgelieferten Standard-Demo-cfg" starten?
Mich wundert, das fhem keine CPU-Last, aber auch nicht reagiert ...
Gesagt, getan. Die Fhem Demo läuft erstaunlicherweise! Somit sollte zumindest ein Fhem Backup helfen, da ein Linux System-Problem ausgeschlossen werden kann?
Edit:
Noch eine kurze Info, ich nutze bei mir https, da die demo ohne https ist ist, könnte das vielleicht eine Fehlerquelle sein?
Zitat von: darkness am 28 Juli 2017, 08:22:40
Nur am Rande:
Hast du eine Firewall eingerichtet oder was daran geändert?
Ich habe eigentlich nur in der Config von dnsmasq rum gespielt und versucht diesen als DNS proxy ein zu richten, um meine Diskstation als TFTP Server bekannt zu machen.
Nach dem ich gemerkt habe, dass Fhem nicht mehr geht habe ich alles aus der Config aus kommentiert. und den Pi auch mehrere Male neu gestartet.
Mit Iptables habe ich vor ewigkeiten mal rum gespielt, es aber dann doch gelassen.
Iptables -L zeigt mir auch keine Einträge.
also mit der Demo funzt?
- HTTP
- Telnet
Jetzt könntest Du schrittweise von der alten cfg die Daten in die neue schreiben (bzw. per FHEM-Weboberfläche)
Was mir aber, wegen aktuellem Hinweis, noch einfällt:
Hast Du Netzwerkdevice/Zugriffe in FHEM definiert?
z.B. FritzBox, CCU2, Wetterdienste etc.?
Zitat von: Wernieman am 28 Juli 2017, 09:10:47
also mit der Demo funzt?
- HTTP
- Telnet
In der Demo funktioniert http sowohl auch telnet.
Zitat von: Wernieman am 28 Juli 2017, 09:10:47
Jetzt könntest Du schrittweise von der alten cfg die Daten in die neue schreiben (bzw. per FHEM-Weboberfläche)
Das geht leider nicht, da ich configDB verwende.
Zitat von: Wernieman am 28 Juli 2017, 09:10:47
Was mir aber, wegen aktuellem Hinweis, noch einfällt:
Hast Du Netzwerkdevice/Zugriffe in FHEM definiert?
z.B. FritzBox, CCU2, Wetterdienste etc.?
Klar, ich habe eine Menge.
Wetter Dienste, Staubsaugroboter anbindung über Internet, Fritzbox, HUE, Lightify, HMLAN usw. ...
Aber diese gehen auch nicht wenn Fhem gestartet ist, sprich der HM Taster an der wand lässt meine Lampen nicht erleuchten.
Wie gesagt, ich habe immer noch aktuelle Backups vom Vortag, vielleicht tuen die es auch schon. Will das aber nicht mahchen wenn es nicht hilft. Was denkt ihr, wie stehen die Chancen?
Könnt ihr denn schon eingrenzen wo der Fehler liegt, anhand der aktuellen Situation?
Edit: Eine Sache noch: Ich habe mehrere httpMod Fehlermeldung, weil ich alte Attribute verwende, diese sollten laut Fehlermeldung geändert werden.
Habe es bisher nich erwähnt, weil es mir nicht als zu Wichtig vorkam. Denke aber weiterhin das ist nicht die Ursache. ???
the attribute readingsName_Diesel should no longer be used. Please use reading01Name syntax instead
For most old attributes you can specify enableControlSet and then set device upgradeAttributes to automatically modify the configuration
Ich würde einfach mal mit einer älteren Config neu starten. Für sowas gibt es ja die configdb
Also starten mal mit einer Vorversion
Zitat von: CoolTux am 28 Juli 2017, 10:00:27
Ich würde einfach mal mit einer älteren Config neu starten. Für sowas gibt es ja die configdb
Also starten mal mit einer Vorversion
Also aus nem vorherigen Backup einfach die config.db nehmen und durch die jetzige ersetzen?
Davor besten falls die jetzige noch sichern?
Äh nein. Du hast ein Versionierungssystem in der configdb. Du kannst also mit einer früheren Version Deiner Konfiguration (nicht der Configdb) neustarten
Hier hat Udo das Vorgehen mal beschrieben (https://forum.fhem.de/index.php/topic,46538.msg603116.html#msg603116)
Zitat von: CoolTux am 28 Juli 2017, 10:22:57
Hier hat Udo das Vorgehen mal beschrieben (https://forum.fhem.de/index.php/topic,46538.msg603116.html#msg603116)
Danke!!
Habe mir das angeschaut, mit der minimal config zu starten ist wieder kein Problem. Allerdings habe ich wohl nur zwei Version der configDB.
configdb listbekomme ich die config gelistet.
Mit
configdb list 1 bekomme ich allderdings nur einen Bruchteil meiner config die eher unrelevant ist (gerade mal 78 Zeilen)
Wie und wann werden die versionen erstellt?
Die jetzige configdb mit einer älteren zu ersetzen, wäre trotzdem eine alternative, oder nicht?
meinst du das modul? wüsste nicht wieso die Moduldatei da was machen kann.
Oder meinst eine ältere datenbankversion? Was genau nimmst du denn. sqlite, mysql?
Ich habe damals configDB mit Betateilchens Workshop eingerichtet. Sprich ich verwende sql lite.
In dem Ordner Fhem befindet sich die configDB.db. Ist dies nicht der die DB Datei, die die config speichert? Diese Datei würde ich einfach gegen eine ältere Datei austauschen.
Gibt es denn eine Möglichkeit die configDB zu bearbeiten und gewisse Zeilen aus der config zu löschen? Dann würde ich versuchen die httpmod Zeilen zu löschen, da diese noch Fehlermeldungen bei jedem Start produzieren.
Zitat von: Fixel2012 am 28 Juli 2017, 11:31:13
Ich habe damals configDB mit Betateilchens Workshop eingerichtet. Sprich ich verwende sql lite.
In dem Ordner Fhem befindet sich die configDB.db. Ist dies nicht der die DB Datei, die die config speichert? Diese Datei würde ich einfach gegen eine ältere Datei austauschen.
Gibt es denn eine Möglichkeit die configDB zu bearbeiten und gewisse Zeilen aus der config zu löschen? Dann würde ich versuchen die httpmod Zeilen zu löschen, da diese noch Fehlermeldungen bei jedem Start produzieren.
Es gibt möglichkeiten, aber dazu muß man sich damit auskennen.
Ja die configDB.db klingt nach der DB. Kannst also versuchen gegen eine ältere Version aus zu tauschen.
ZitatAber diese gehen auch nicht wenn Fhem gestartet ist, sprich der HM Taster an der wand lässt meine Lampen nicht erleuchten.
Steuerst Du über fhem oder sind die Geräte direkt gekoppelt?
Zitat von: Wernieman am 28 Juli 2017, 12:13:53
Steuerst Du über fhem oder sind die Geräte direkt gekoppelt?
Leider über Fhem :P
Dann ist es logisch, das es nichts funzt ....
Sorry, aber kann Dir (wegen configdb) aktuell nicht mehr weiterhelfen ....
Frage an die Spezialisten:
Kann man aus der ConfigDB (hier sql-light) unabhängig von FHEM ein Config-File generieren lassen? Würde (in diesem Falle) das Debugging vereinfachen ...
Zitat von: Wernieman am 28 Juli 2017, 12:18:56
Dann ist es logisch, das es nichts funzt ....
Sorry, aber kann Dir (wegen configdb) aktuell nicht mehr weiterhelfen ....
Frage an die Spezialisten:
Kann man aus der ConfigDB (hier sql-light) unabhängig von FHEM ein Config-File generieren lassen? Würde (in diesem Falle) das Debugging vereinfachen ...
Ja, ich habe das damals auch nur zu Testzwecken gemacht. Da es ging habe ich es so gelassen. Aber die Fhem.cfg hat für Anfänger eben doch enorme Vorteile.
Zitat von: Wernieman am 28 Juli 2017, 12:18:56
Frage an die Spezialisten:
Kann man aus der ConfigDB (hier sql-light) unabhängig von FHEM ein Config-File generieren lassen? Würde (in diesem Falle) das Debugging vereinfachen ...
Mir nicht bekannt. Ich kenne nur die Variante wo Du aus FHEM heraus das ganze machen kannst.
Hilft die Beschreibung im Thread [configDB] fhem im rescue-Modus starten (https://forum.fhem.de/index.php/topic,46538.msg603116.html#msg603116) evtl. weiter?
Zitat von: ph1959de am 28 Juli 2017, 13:48:08
Hilft die Beschreibung im Thread [configDB] fhem im rescue-Modus starten (https://forum.fhem.de/index.php/topic,46538.msg603116.html#msg603116) evtl. weiter?
Hat mir Cooltux bereits verlinkt gehabt. Da in meiner conifDb aus irgend einem Grund aber leider nur 2 Versionen vorliegen und die eine völliger quatsch ist, geht das so leider nicht.
Aber Danke an allen die bisher geholfen haben! :'(
Suche immer noch nach dem entscheidenden Tipp.
Es muss ja irgendwie mit der fhem config was zu tun haben.
Denke der beste weg wäre tatsächlich die configDB wenn möglich wieder zurück in die fhem.cfg zu wandeln. (Hoffentlich machbar, auch wenn Fhem nicht erreichbar ist.)
Rückmeldung zum einspielen von älteren configDB.db files:
Hat leider nicht geklappt! Auch da habe ich das gleiche Phänomen wie vorher. Laut log startet alles normal, aber weder per telnet noch per Web erreichbar.
Die Fehlermeldungen von HttpMod waren nach dem zurücksetzen auf eine ältere DB datei damit auch weg, aber anscheiend liegt es nicht an den Fehlermeldungen die dort sichtbar waren.
Dann tippe ich auf Netzwerk.
zeig mal
/etc/hosts
und dann noch
iptables -vnL
Zitat von: CoolTux am 28 Juli 2017, 14:31:45
Dann tippe ich auf Netzwerk.
zeig mal
/etc/hosts
und dann noch
iptables -vnL
Einmal Iptables:
pi@FHEM:~ $ sudo iptables -vnL
Chain INPUT (policy ACCEPT 647K packets, 674M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 380K packets, 45M bytes)
pkts bytes target prot opt in out source destination
Und hier die hosts:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 FHEM
Wie gesagt, ich habe an dem Tag wo Fhem nciht mehr ging mit Dns, proxy DHCP auf dem pi rum gemacht....
Da wundert es mich aber wiederum, dass die Fhem Demo ging...
weil Dein fhem ja startet, die Sockets auch öffnet, dann aber nix macht:
Ich vermute das Du
a: irgendein modul einsetzt was schlecht programmiert ist (und jetzt blockiert. blockiert meint: das wartet auf irgendwas was nicht eintritt und blockiert das ganze andere fhem)
b: ein dazugehöriges externes Gerät nicht verfügbar ist/nicht antwortet (aus, andere IP, kaputt, doof, Netzwerksegment weg, Repeater aus...)
Überlege mal ob sich im fraglichen Zeitraum etwas externes geändert hat was im weiteren Sinn zu (B) passt.
Wenn Du jetzt eine cfg hättest könntest Du modul für modul auskommentieren. aber das nur am Rande.
vg
joerg
Zitat von: herrmannj am 28 Juli 2017, 14:51:03
weil Dein fhem ja startet, die Sockets auch öffnet, dann aber nix macht:
Ich vermute das Du
a: irgendein modul einsetzt was schlecht programmiert ist (und jetzt blockiert. blockiert meint: das wartet auf irgendwas was nicht eintritt und blockiert das ganze andere fhem)
b: ein dazugehöriges externes Gerät nicht verfügbar ist/nicht antwortet (aus, andere IP, kaputt, doof, Netzwerksegment weg, Repeater aus...)
Überlege mal ob sich im fraglichen Zeitraum etwas externes geändert hat was im weiteren Sinn zu (B) passt.
Wenn Du jetzt eine cfg hättest könntest Du modul für modul auskommentieren. aber das nur am Rande.
vg
joerg
Danke,
mir fällt nichts ein was ich zu dem Zeitpunkt gemacht haben könnte. Wenn überhaupt Tankstellenpreise mit dem httpmod Modul. Aber ich bin jetzt schon auf eine conifgDB version zurück, wo dieses nicht mehr definiert ist.
Müsste wenn Fhem auf ein Gerät oder Modul wartet nicht die Auslastung der CPU hoch gehen?
Theoretisch könnte ich Fhem auch mit meiner noch vorhandenen Fhem.cfg starten. (diese ist allderdings 6 Monate alt, imzwischen hat sich alles verändert!)
Eigentlich wird doch auch "nur" per sql-Befehle durch FHEM aus der config.db die COnfig ausgelesen. Kennt jemand diese Befehle? Denn damit könnte man versuche an die Daten zu kommen ...
Nur mal als IOdee ... mache mal eine Kopie Deines DB-Files.
Lies Dir durch:
https://wiki.ubuntuusers.de/SQLite/ (https://wiki.ubuntuusers.de/SQLite/)
Und jetzt mal gucken, ob eventuell das DBFile einen "Knacks" hat:
sqlite3 DeinDBFile-Copy
.tables
Hinweis: Alles Ungetestet das kein ConfigDB, deshalb auch "mache Copie"
Zitat von: Wernieman am 28 Juli 2017, 15:44:17
Eigentlich wird doch auch "nur" per sql-Befehle durch FHEM aus der config.db die COnfig ausgelesen. Kennt jemand diese Befehle? Denn damit könnte man versuche an die Daten zu kommen ...
Nur mal als IOdee ... mache mal eine Kopie Deines DB-Files.
Lies Dir durch:
https://wiki.ubuntuusers.de/SQLite/ (https://wiki.ubuntuusers.de/SQLite/)
Und jetzt mal gucken, ob eventuell das DBFile einen "Knacks" hat:
sqlite3 DeinDBFile-Copy
.tables
Hinweis: Alles Ungetestet das kein ConfigDB, deshalb auch "mache Copie"
Jup, das geht.
Meine conifg ist gerade eine Minute lang im Terminal runtergerattert ;D
Was ist der nächste Schritt? Ich kann mit Putty loggen und anschließend mit daraus meine Fhem.cfg extrahieren.
Klappt das, wenn ich die config die mir aufgelistet wurde einfach komplett in die fhem.cfg kopiere?
Natürlich verliere ich dann die ganzen states in fhem usw. die müssten man sich auch noch ziehen.
Ob das im Endeffekt hilft das Problem zu lösen, weiß man natürlich nicht :(
Ich hatte auch das Problem jedoch auf meinem Raspberry Pi..
Konnte das lösen indem ich folgende Datei bearbeitet habe:
nano /etc/init.d/fhem
und dort in die erste Zeile des Codes
sleep 10
eingefügt habe. Nach einem Neustart war fhem dann wieder erreichbar :)
Zitat von: SST am 28 Juli 2017, 18:02:42
Ich hatte auch das Problem jedoch auf meinem Raspberry Pi..
Konnte das lösen indem ich folgende Datei bearbeitet habe:
nano /etc/init.d/fhem
und dort in die erste Zeile des Codes
sleep 10
eingefügt habe. Nach einem Neustart war fhem dann wieder erreichbar :)
Glaube eher weniger, dass das hilft, da das starten von Fhem direkt ohne init.d ja schon nicht funktioniert.
Aber dank dir!
Update:
Egal welches Fhem-Backup ich einspiele (gesamtes Fhem Verzeichnis) es ging nichts, auch bei mehreren Wochen alten Backups.
Was mich immer noch wundert, ist warum die minimal config (configdb) und die fhem demo liefen.
Ich werde als nächstes ein komplettes image (ein Monat alt) ein spielen und anschließend das aktuellste Fhem backup nochmals ein spielen.
Ich werde berichten, wie es weiter geht und ob es funktioniert. Sollte das nicht der fall sein weiß ich nicht mehr weiter :'(
Edit:
Ich denke herrmannj hat mit seiner Vermutung Recht, dass irgend eine Netzwerk Komponente nicht erreichbar ist oder sonstiges.
Was anderes fällt mir da nicht ein, da selbst mit dem ein Monate alten image Fhem startet aber auch nicht erreichbar ist.
Hat jemand Tipps zum debuggen des Problems? :-[
Ich werde nun mal versuchen alle Netzwerk Komponenten, die in Fhem eingebunden sind einmal durch zu starten. Keine Ahnung ob das hilft... :(
Wenn Du eine fhem.cfg hättest, würde ich großzügig defices löschen .. und wenn diese Minimallösung geht, schrittweise bis zum nichtgehen wieder einfügen. Alternativ eine Minimal.cfg nehmen und schrittweise die Vorhandenen Daten eingeben und schauen ... in der fhem.cfg stehen ja "praktisch" die einzugebenen Befehle drin. Aber bei configdb weiß ich es eben nicht :o(
Zitat von: Wernieman am 29 Juli 2017, 15:44:06
Wenn Du eine fhem.cfg hättest, würde ich großzügig defices löschen .. und wenn diese Minimallösung geht, schrittweise bis zum nichtgehen wieder einfügen. Alternativ eine Minimal.cfg nehmen und schrittweise die Vorhandenen Daten eingeben und schauen ... in der fhem.cfg stehen ja "praktisch" die einzugebenen Befehle drin. Aber bei configdb weiß ich es eben nicht :o(
So würde ich auch vorgehen, wenn ich die fhem.cfg hätte... >:(
ARGH....
Hat jemand weitere Tipps? :-X
Sprich bitte mal betateilchen an, ob er noch eine Lösung weiß ....
Eigentlich müsste man mit passenden sql-Befehlen die Daten aus der Datenbank kriegen ...
Warum nicht den einfachsten aller Wge gehen und FHEM mit configDB im rescue-Modus starten? Damit hat man zumindest wieder Zugriff auf alle in der Datenbank gespeicherten Konfigurationen.
Und warum nicht im richtigen Unterforum fragen? Das ist doch keine Anfängerfrage.
Erst ein mal danke, dass du dich so schnell meldest!
Zitat von: betateilchen am 29 Juli 2017, 21:15:25
Und warum nicht im richtigen Unterforum fragen? Das ist doch keine Anfängerfrage.
Mir war nicht bewusst, dass das Thema so Umfangreich und schwer zu lösen sein wird. Aber du hast natürlich Recht, in einem anderen Unterforum ist es besser aufgehoben!
Zitat von: betateilchen am 29 Juli 2017, 21:15:25
Warum nicht den einfachsten aller Wge gehen und FHEM mit configDB im rescue-Modus starten? Damit hat man zumindest wieder Zugriff auf alle in der Datenbank gespeicherten Konfigurationen.
Dies habe ich Dank CoolTux schon gemacht gehabt. Aber wie gehe ich weiter vor?
Meine eigentliche Config, sprich die Definitionen kann ich so doch nicht bearbeiten, oder irre ich mich?
Zitat von: Fixel2012 am 29 Juli 2017, 22:49:11
Aber wie gehe ich weiter vor?
Meine eigentliche Config, sprich die Definitionen kann ich so doch nicht bearbeiten, oder irre ich mich?
ICH habe mir die Mühe gemacht, eine Doku zu schreiben.
DU solltest Dir jetzt fairerweise die Mühe machen, die Doku auch zu lesen und zu verstehen.
Es gibt auch schon diverse Threads hier im Forum, die sich mit ähnlichen Aufgabenstellungen beschäftigen und in denen Lösungswege beschrieben sind.
Noch ein gut gemeinter Tipp:
Rumpfuschen per SQL in der Datenbank hilft auf keinen Fall weiter. Damit richtest Du mehr Schaden an, als dass Du einer Lösung näher kommen würdest.
Wenn Du es geschafft hast, Dein FHEM im rescue Modus zu starten, kannst Du Dir mit
configdb list % <version>
jede beliebige Version in der Konfigurationsdatenbank ausgeben lassen. Im Prinzip kannst Du Dir daraus manuell eine fhem.cfg bauen, wenn Du glaubst, dass Dir das hilft (oder wenn Du Dir diesen Irrglauben hier im Thread einreden läßt)
Mit
configdb recover <version>
kannst Du auch eine gespeicherte Version aktivieren und rausfinden, welche Version noch funktionert.
Alles klar, danke dir soweit.
Noch eine Frage an die Allgemeinheit:
Reicht es denn wenn ich die Definitionen aus der configDB mir ausgeben lasse, in den fhem.cfg file kopiere und anschließend über perl fhem.pl fhem.cfg
starte.
Würde dann so oft das fhem stoppen -> Definitionen auskommentieren -> fhem starten, bis Fhem wieder per Web erreichbar ist.
Würde das so funktionieren?
Nochmal danke an alle!
Zitat von: Fixel2012 am 30 Juli 2017, 01:43:59
Würde das so funktionieren?
Höchstwahrscheinlich nicht. Zu einer lauffähigen FHEM Installation gehört ein bisschen mehr als das, was in der fhem.cfg steht.
Deshalb hatte ich oben geschrieben
Zitat von: betateilchen am 30 Juli 2017, 00:51:12
Im Prinzip kannst Du Dir daraus manuell eine fhem.cfg bauen
Aber wie ich ja schon versucht habe, klarzumachen: wenn Dein Problem wirklich von einer "defekten" Konfiguration herrührt, brauchst Du Dir diesen ganzen Krampf überhaupt nicht anzutun. Dafür hat configDB alle Tools im Bauch, um ein System wieder zum Laufen zu bringen.
So nach ausgiebigen Testen, lesen und ausprobieren die Erkenntnis:
Selbst das letze (04.01.2017) Backup was in der configdb vorhanden ist hat die gleichen Erscheinungen wie bisher beschrieben (laut Log erfolgreich gestartet, aber nicht per web und telnet erreichbar...)
Ich kann mir das ganze langsam nicht mehr erklären und bin ziemlich frustriert :'( Frage mich langsam warum ich jeden Tag Backups gemacht habe... ;D :-\
Ohne eure Hilfe habe ich nun keine Ahnung mehr wie ich weiter vorgehen soll.
Was ich meiner Meinung nach ausschließen kann ist ein System Fehler (linux), da ich schon alte Systembackups ausprobiert habe und das gleiche Phänomen auftritt.
Das einzige was meiner Meinung nach in Frage kommt ist ein Fehler in der Fhem config (hier bei mir configDB), da die Fhem standard und Demo configs funktionieren. Es können aber keine kurzfristig geänderten Sachen in der fhem config sein, da selbst eine 6 Monate alte config nicht läuft.
Es muss sich also etwas außerhalb (Internet oder Intranet abfragen von Devices. USB Sticks und co habe ich breits schon ausschließen können.) der fhem config geändert haben die nun irgend einen Fehler innerhalb Fhem produziert, so dass fhem nicht mehr erreichbar ist! (was das genau ist weiß ich nicht! Das ist denke ich die große Herausforderung, dies heraus zu finden.)
Soweit meine Vermutungen und Erkenntnisse! Was ich hiervon nun richtig heraus analysiert habe weiß ich nicht genau. Falls hier etwas falsch beschrieben sein sollte, verbessert mich bitte umgehend!!
Ich hoffe weiterhin auf eure Hilfe und Ideen (hoffe ihr habt da noch was ;D) :)
Grüße,
Felix
Hast Du schon versucht, ./log/fhem.save umzunennen, und dann fhem zu starten?
Zitat von: amenomade am 31 Juli 2017, 01:24:38
Hast Du schon versucht, ./log/fhem.save umzunennen, und dann fhem zu starten?
nein, werde ich testen :o
Gehen tut es auch nicht, aber sollte nicht ein neues Fhem.save file erstellt werden? oder erst bei einem neustart von Fhem?
Zitat von: amenomade am 31 Juli 2017, 01:24:38
Hast Du schon versucht, ./log/fhem.save umzunennen, und dann fhem zu starten?
Das wird leider nichts bringen.
Die Datei findet bei configDB keine Verwendung mehr. Die Daten werden ebenfalls in der DB gespeichert.
ZitatWas ich meiner Meinung nach ausschließen kann ist ein System Fehler (linux), da ich schon alte Systembackups ausprobiert habe und das gleiche Phänomen auftritt.
Das klingt aber noch unsicher. Ich würd, vergleichbar zu Werniemanns Vorschlag, es mal mit der demo.cfg versuchen. Und dann mal die üblichen Verdächtigen mit Zugriff über die Rechnergrenzen hinaus testen.
Ich würde auch mal versuchen alles vom Pi ab zu klemmen was man nur abklemmen kann. Sämtliche USB und Aufsteckmodule, wenn möglich Netzwerk lahm legen und per Tastatur und Monitor/Fernsehr arbeiten.
Funktioniert der Zugriff über telnet auch dann nicht, wenn Du das lokal probierst?
Also per ssh auf den Pi verbinden und dann von Konsole aus das FHEM per "telnet localhost 7072" aufrufen.
Zitat von: betateilchen am 31 Juli 2017, 13:26:14
Funktioniert der Zugriff über telnet auch dann nicht, wenn Du das lokal probierst?
Also per ssh auf den Pi verbinden und dann von Konsole aus das FHEM per "telnet localhost 7072" aufrufen.
Nein, funktioniert nur mit der demo.cfg und der rescue configDB version. :-\
Zitat von: KölnSolar am 31 Juli 2017, 08:54:30
Das klingt aber noch unsicher. Ich würd, vergleichbar zu Werniemanns Vorschlag, es mal mit der demo.cfg versuchen. Und dann mal die üblichen Verdächtigen mit Zugriff über die Rechnergrenzen hinaus testen.
Was genau versuchen? Die demo.cfg läuft einwandfrei ??? Ebenso die rescue config DB version. Nur eben meine eigene config nicht.
Zitat von: CoolTux am 31 Juli 2017, 09:19:59
Ich würde auch mal versuchen alles vom Pi ab zu klemmen was man nur abklemmen kann. Sämtliche USB und Aufsteckmodule, wenn möglich Netzwerk lahm legen und per Tastatur und Monitor/Fernsehr arbeiten.
Alles bis auf LAN und strom hatte ich bereits ab. Werde nun nochmal testen ob ich mit Tastatur und hdmi am Monitor Fhem per Telnet erreichen kann.
Ok. So wird das nichts.
Ich weiß jetzt schon das mich Udo dafür maßregeln wird, aber wir kommen ja eh nicht voran.
Gehe in /opt/fhem/
cd /opt/fhem
hier sollte Deine configDB.db liegen
Verbinde dich mit der DB
sqlite3 configDB.db
Schau nach ob Du das Device initialUsbCheck hast
select * from fhemconfig where device='initialUsbCheck';
Wenn nicht! mit
.quit
kommst du wieder raus.
Wenn Du es hast. Löschen wir es.
delete from fhemconfig where device='initialUsbCheck';
Das ist der Anfang. Sollte das nicht fruchten müssen wir weiter über legen was wir machen
Zitat von: CoolTux am 31 Juli 2017, 14:00:13
Ok. So wird das nichts.
Ich weiß jetzt schon das mich Udo dafür maßregeln wird, aber wir kommen ja eh nicht voran.
Gehe in /opt/fhem/
cd /opt/fhem
hier sollte Deine configDB.db liegen
Verbinde dich mit der DB
sqlite3 configDB.db
Schau nach ob Du das Device initialUsbCheck hast
select * from fhemconfig where device='initialUsbCheck';
Wenn nicht! mit
.quit
kommst du wieder raus.
Wenn Du es hast. Löschen wir es.
delete from fhemconfig where device='initialUsbCheck';
Das ist der Anfang. Sollte das nicht fruchten müssen wir weiter über legen was wir machen
USB check habe/sollte ich bereits disabled haben, hatte damit schonmals Probleme.
Was ist der Hintergrund warum ich dies machen soll, ein Paar Infos wären schön, man will ja schließlich da zu lernen ;)
wenn das eine sqlite Datenbank ist, dann schick mir die doch einfach mal per email.
Zitat von: CoolTux am 31 Juli 2017, 14:00:13
Gehe in /opt/fhem/
...
hier sollte Deine configDB.db liegen
das hoffst/vermutest Du aber nur...
Zitat von: betateilchen am 31 Juli 2017, 14:04:39
wenn das eine sqlite Datenbank ist, dann schick mir die doch einfach mal per email.
Darüber hatte ich auch schon nachgedacht. Finde ich gut das Angebot.
Zitat von: CoolTux am 31 Juli 2017, 14:00:13
Das ist der Anfang.
ich würde das nicht empfehlen...
ähhm... Ich bin verwirrt!
Fhem geht wieder... Ich habe keine Ahnung warum! Habe nachdem testen mit usb Tastatur (was auch nicht ging), fhem einfach mit allen USB devices wieder ans Strom Netz gehängt und Plötzlich ging mein Fernseh licht an (prescence des Fernsehers).
Web und Telnet ist nun ganz normal erreichbar :-\ :o
Wollte Betateilchen gerade meine config DB schicken...
Wie soll ich weiter vorgehen? Das nun alles aus einem unerklärlichen Grund wieder geht ist ja super, aber warum geht es nun wieder und wird es so bleiben?
Zitat von: betateilchen am 31 Juli 2017, 14:09:02
ich würde das nicht empfehlen...
Ich weiß. Aber irgendwie müssen wir ja irgendwo anfangen. Wobei ich da jetzt aber auch warten würde ob Du nicht etwas in der zugeschickten db findest. Sofern der Fragesteller damit einverstanden ist.
Ich habe mir die Mühe am WE gemacht und versucht einen einfachen weg zu finden die db in ein Configfile zu bekommen. Aber da muß man so viel filtern und nacharbeiten das kann kein Anfänger wirklich sauber.
Habe extra auf ner VM ein Test FHEM auf gebaut ;D
Hattest Du zwischen dem ganzen FHEM testen mal den ganzen Pi neu gestartet gehabt und FHEM aus der init Routine genommen. So das FHEM von Hand gestartet werden muß?
Zitat von: CoolTux am 31 Juli 2017, 14:28:36
Hattest Du zwischen dem ganzen FHEM testen mal den ganzen Pi neu gestartet gehabt und FHEM aus der init Routine genommen. So das FHEM von Hand gestartet werden muß?
neu gestartet ja, init routine nicht, aber den service beendet und danach nochmal perl gekilled. Anschließend immer per Hand.
Traue mich nicht Fhem oder Pi nochmal durch zu starten, jetzt wo es geht... ;D :-[
Ah ok.
Ich tippe ein bisschen immer noch auf den USB Scan, aber genau wird man das wohl nicht sagen können. Leider.
Zitat von: CoolTux am 31 Juli 2017, 14:31:02
Ah ok.
Ich tippe ein bisschen immer noch auf den USB Scan, aber genau wird man das wohl nicht sagen können. Leider.
Internals:
CFGFN
DEF global:INITIALIZED usb create
NAME initialUsbCheck
NOTIFYDEV global
NR 12
NTFY_ORDER 50-initialUsbCheck
REGEXP global:INITIALIZED
STATE disabled
TYPE notify
READINGS:
2017-07-31 14:16:57 state disabled
Attributes:
disable 1 Ist bei mir schon seit einiger Zeit disabled.
Soll ich es wagen und mal Fhem oder Pi durch starten?
Mach mal, oder willst das Teil ein leben lang nicht mehr anrühren ;D
Zitat von: CoolTux am 31 Juli 2017, 14:37:12
Mach mal, oder willst das Teil ein leben lang nicht mehr anrühren ;D
Am liebsten, ja :D
Dann mach doch einfach vorher mal ein "list" der Devices ....
Scherz:
Scheinbar hat Dein FHEM Angst, das Seine config zu betateilchen geschickt wurde ....
Edit:
Damit mich keiner falsch versteht, ich fand das Angebot von ihm sehr zuvorkommend!
Ein Shutdown restart ist erfolgreich geglückt, der Raspi Reboot ebenso!
Das freut mich alles ungemein, aber die will natürlich eigentlich wissen warum es nun geht und vorher nicht...
Ebenso stelle ich mir die Frage ob configDB das richtige für mich ist ;D Eingelesen habe ich mich in die Funktionalitäten, aber im Notfall mal eben in der fhem.cfg etwas aus zu kommentieren fehlt hier einfach. Was ist eure Meinung dazu? Sollte ich bei configDB bleiben?
So zu guter letzt nochmal ein RIESEN LOB an alle die so fleißig geholfen haben den Fehler zu finden (auch wenn wir ihn immer noch nicht gefunden haben ;D :-X)!
Hoffen wir mal das Fhem am laufen bleibt und nicht nach dem nächsten Neustart wieder in die Knie geht...
Riesen Dankende Grüße,
Felix
Zitat von: Wernieman am 31 Juli 2017, 14:48:58
Dann mach doch einfach vorher mal ein "list" der Devices ....
Scherz:
Scheinbar hat Dein FHEM Angst, das Seine config zu betateilchen geschickt wurde ....
Edit:
Damit mich keiner falsch versteht, ich fand das Angebot von ihm sehr zuvorkommend!
Ich fand das Angebot ebenso einfach nur klasse! Sowas findet man nicht in jedem Forum. Aber habe ihm dann wohl doch die Arbeit ersparen können! :P
Persönliche Meinung: Ich würde bei configDB bleiben und versuchen mir auf Basis dessen was hier passiert ist Wissen an zu eignen es beim nächsten mal in den Griff zu bekommen.
Dummerweise bräuchte man dazu am besten den tatsächlichen Fehler.
Aber bau Dir doch ein Testsystem auf. Heut zu Tage ist das doch kein Problem mehr. Und damit übst Du. Habe ich doch am WE genau so gemacht wie ich Dein Problem nachstellen wollte.
Zitat von: CoolTux am 31 Juli 2017, 15:00:51
Persönliche Meinung: Ich würde bei configDB bleiben und versuchen mir auf Basis dessen was hier passiert ist Wissen an zu eignen es beim nächsten mal in den Griff zu bekommen.
Dummerweise bräuchte man dazu am besten den tatsächlichen Fehler.
Aber bau Dir doch ein Testsystem auf. Heut zu Tage ist das doch kein Problem mehr. Und damit übst Du. Habe ich doch am WE genau so gemacht wie ich Dein Problem nachstellen wollte.
Da hast du eigentlich Recht! Eine VM reicht ja eigentlich auch schon aus. Werde mir mal bei gelegenheit ein Test System zusammen bauen. ???
Nochmals vielen Dank an alle!
Zitat von: Fixel2012 am 31 Juli 2017, 14:55:48
aber im Notfall mal eben in der fhem.cfg etwas aus zu kommentieren fehlt hier einfach.
Gegenfrage:
Inwiefern hätte Dir die Möglichkeit, in Deiner Konfiguration etwas auskommentieren zu können, im vorliegenden Fall weitergeholfen? Du hast doch gerade selbst den Beweis erbracht, dass ein Auskommentieren für die Lösung des Problems überhaupt nicht nötig war.
Zitat von: Wernieman am 31 Juli 2017, 14:48:58
Scheinbar hat Dein FHEM Angst, das Seine config zu betateilchen geschickt wurde ....
... und dabei rauskäme, dass einmal mehr NICHT die configDB die Ursache der Probleme ist.
Zitat von: betateilchen am 31 Juli 2017, 15:36:21
Gegenfrage: Inwiefern hätte Dir die Möglichkeit, in Deiner Konfiguration etwas auskommentieren zu können, im vorliegenden Fall weitergeholfen? Du hast doch gerade selbst den Beweis erbracht, dass ein Auskommentieren für die Lösung des Problems überhaupt nicht nötig war.
... und dabei rauskäme, dass einmal mehr NICHT die configDB die Ursache der Probleme ist.
Ich weiß nicht warum es nun geht, vielleicht hat sich irgendwas außerhalb Fhem geändert was dazu führt das fhem nun keine Probleme mehr hat.
inwiefern mir das nun geholfen hätte weiß ich nicht.
Was mir bei solchen Fragen immer in dem Kopf kommt:
Es ist doch ein RasPi?
- stimmt die Stromversorgung
- Defekt in der SDCard?
Zitat von: Wernieman am 31 Juli 2017, 16:01:36
Was mir bei solchen Fragen immer in dem Kopf kommt:
Es ist doch ein RasPi?
- stimmt die Stromversorgung
- Defekt in der SDCard?
SD Karte erst erneuert und strom habe ich auch verschiedene ausprobiert :)
das passt auch nicht damit zusammen das Du Dich per Telnet verbinden konntest, telnet aber stumm blieb.
Ich meine in diesem Fall haette "attr global logfile -" mit "attr global verbose 5" am ehesten zur Eingraenzung des Problems beigetragen. Ich habe jetzt fhem.pl mit der Option "-d" erweitert, dabei werden diese beiden Attribute immer auf die erwaehnten Werte gesetzt. D.h. man muss fhem.pl im Terminal starten, mit
perl fhem.pl -d fhem.cfg
oder
perl fhem.pl -d configDB
gute Idee :)
Hier hänge ich mich mal dran, gleiches Problem bei mir: im Browser ist FHEM nicht erreichbar.
FHEM fährt laut log sauber hoch, öffnet die FHEMWEB Ports sowie telnet. telnet auf den Port geht durch, nimmt aber keine commands an.
netstat:
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 17568/perl
tcp 0 0 0.0.0.0:8084 0.0.0.0:* LISTEN 17568/perl
tcp 0 0 0.0.0.0:8085 0.0.0.0:* LISTEN 17568/perl
tcp 0 0 0.0.0.0:7072 0.0.0.0:* LISTEN 17568/perl
Backup von vor dem Update eingespielt: gleiches Verhalten.
Starten mit fhem.cfg.demo funktioniert einwandfrei.
Letzten Zeilen des aktuellen logs auf global verbose 5:
[...]
2018.02.23 19:34:42.419 4: Ignoring CUL_TCM97001_117
2018.02.23 19:34:42.419 4: Ignoring CUL_TCM97001_164
2018.02.23 19:34:42.422 4: Ignoring IT_00000FFFFF
2018.02.23 19:34:42.440 5: End notify loop for global
2018.02.23 19:34:42.440 0: Featurelevel: 5.8
2018.02.23 19:34:42.440 0: Server started with 286 defined entities (fhem.pl:16107/2018-02-07 perl:5.020002 os:linux user:root pid:17568)
2018.02.23 19:34:42.639 4: [Wetter.Twilight] sr_astro 2018-02-23 05:38:33 ( 1/1/-18.0°/0) ===> sr_naut 06:16:10
2018.02.23 19:34:42.641 4: [Wetter.Twilight] sr_naut 2018-02-23 06:16:10 ( 2/2/-12.0°/0) ===> sr_civil 06:53:53
2018.02.23 19:34:42.643 4: [Wetter.Twilight] sr_civil 2018-02-23 06:53:53 ( 3/3/ -6.0°/0) ===> sr 07:32:20
2018.02.23 19:34:42.645 4: [Wetter.Twilight] sr 2018-02-23 07:32:20 ( 4/4/ +0.0°/0) ===> sr_indoor 09:59:43
2018.02.23 19:34:42.647 4: [Wetter.Twilight] sr_weather 2018-02-23 07:32:20 ( 6/6/ +0.0°/0) ===> ss_weather 17:54:39
2018.02.23 19:34:42.649 4: [Wetter.Twilight] sr_indoor 2018-02-23 09:59:43 ( 5/5/+20.0°/0) ===> sr_weather 07:32:20
2018.02.23 19:34:42.651 4: [Wetter.Twilight] ss_indoor 2018-02-23 15:27:08 ( 8/4/+20.0°/0) ===> ss 17:54:39
2018.02.23 19:34:42.652 4: [Wetter.Twilight] ss_weather 2018-02-23 17:54:39 ( 7/5/ +0.0°/0) ===> ss_indoor 15:27:08
2018.02.23 19:34:42.654 4: [Wetter.Twilight] ss 2018-02-23 17:54:39 ( 9/3/ +0.0°/0) ===> ss_civil 18:33:09
2018.02.23 19:34:42.656 4: [Wetter.Twilight] ss_civil 2018-02-23 18:33:09 (10/2/ -6.0°/0) ===> ss_naut 19:10:57
2018.02.23 19:34:42.658 4: [Wetter.Twilight] ss_naut 2018-02-23 19:10:57 (11/1/-12.0°/0) ===> ss_astro 19:48:41
2018.02.23 19:34:42.659 1: Perfmon: possible freeze starting at 19:34:08, delay is 34.659
Wo kann ich im Log sehen, was der Grund für das Verhalten sein könnte?
Muss doch möglich sein, sowas schnell zu finden..
Sorry, aber könntest Du dafür einen Neuen Thread aufmachen? Von August 2017 zu Februar 2018 ist doch schon einige Zeit ....
Und bitte:
- Rechner ist erreichbar (Ping, ssh)
- FHEM läuft (ps aux | grep [f]hem)
- FHEM braucht NICHT 100% CPU? (s.o.)
- Du hast man fhem manuel mit -d gestartet? Output?
Nunja, thematisch ist es 100% identisch, nur ich habe noch keine Lösung. ::)
FHEM läuft auf dem Pi, bereits lange Zeit und ohne Ausfälle.
Ping + ssh funktionieren.
(root@Pi2:~ $) ps aux | grep [f]hem
fhem 20705 13.7 9.5 96836 90684 pts/0 S+ 19:52 0:23 perl fhem.pl -d fhem.cfg
top:
top - 19:56:30 up 20:23, 2 users, load average: 0.23, 0.13, 0.10
Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 0.5 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 945516 total, 893724 used, 51792 free, 51532 buffers
KiB Swap: 102396 total, 732 used, 101664 free. 378344 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21296 root 20 0 5248 2632 2168 R 1.3 0.3 0:00.35 top
[..]
Ja, mit -d gestartet, sieh die ps Ausgabe oben.
Mir scheint es, das fhem zwar läuft, aber eben nicht funktioniert. Das Log wird nicht weitergeschrieben als oben gelistet.
Wenn Du Dich mit telnt verbindest und danach NOCHMALS Enter drückst ... passiert nichts?
Und ich binn immer noch der Meinung, mach einen neuen Tread auf .... gerne mit Verweis auf diesen ...
Alles klar, neuer Thread dann hier entlang: https://forum.fhem.de/index.php/topic,84847.0.html