Liebe alle,
ich kann im FHEM-Frontend nicht mehr die fhem.cfg editieren und speichern, ohne das sich FHEM vollständig aufhängt. Starte ich dann FHEM komplett neu, sind die versuchten Änderungen wie beabsichtigt gespeichert.
Im Eleminationsverfahren konnte ich rausfinden, dass es an diesem Eintrag liegt:
#Unwetterwarnungen
define BS_Unwetter UWZ DE 38102 600
attr BS_Unwetter event-on-change-reading .*
attr BS_Unwetter icon weather_storm
attr BS_Unwetter room Aussen,System
Lasse ich diesen Eintrag weg, kann ich im FHEM-Frontend ohne Probleme die fhem.cfg editieren und speichern. Kopiere ich diese Zeilen im Frontend wieder in die fhem.cfg rein und klicke auf speichern, stürzt FHEM vollständig ab... Wenn die Zeilen aber wie nach dem notwendigen harten Neustart schon da sind, startet FHEM normal und die Unwetterwarnungen funktionieren auch.
Vielleicht hat der Bug sich mit einem der letzten Updates eingeschlichen? Diesen Eintrag habe ich schon ziemlich lange in meiner fhem.cfg und hatte bisher nie Probleme, die fhem.cfg zu editieren. (Mache ich vorwiegend, um sie mit #Kommentaren für mich etwas lesbarer zu machen, falls ich doch einmal schnell was suchen will.)
Habt ihr eine Idee?
Das ist kein Bug von FHEM. Den Bug wirst Du Dir durch irgendein manuellen Eintrag in die fhem.cfg geholt haben.
Lösche das Device einmal komplett über das FHEMWEB, nicht über editieren der cfg sondern durch den delete im FHEMWEB und speichere dann ab. Was passiert?
Danke CoolTux für die schnelle Antwort. Das habe ich schon versucht - und ganz so einfach ist die Erklärung anscheinend leider nicht. Hier nochmal, was ich gemacht habe und reproduzieren kann:
- Unwetterdevice über "delete" löschen
- Save config im Frontend
- Test: editieren und speichern -> funktioniert
- Unwetterdevice über "define BS_Unwetter UWZ DE 38102 600" neu anlegen und konfigurieren
- Save config im Frontend
- Test: editieren und speichern -> FHEM stürzt ab
- Neustart FHEM -> Unwetterdevice funktioniert
- Test: editieren und speichern -> FHEM stürzt ab
- Neustart FHEM -> Unwetterdevice funktioniert
- Unwetterdevice über "delete" oder direkt im Frontend löschen -> speichern funktioniert, FHEM stürzt nicht ab
Ich würde ja sagen lass das blöde editieren. Dennoch interessiert mich was als letztes im Log steht beim Absturz. Also das FHEM Log.
Ich hab Deinen Eintrag in der Signatur schon gesehen ;)
Danke, dass Du dennoch antwortest. Ich fand es beim Start mit FHEM tatsächlich leichter, direkt in der fhem.cfg zu arbeiten, um zu verstehen, wie FHEM funktioniert. Das habe ich aber schon eine ganze Weile nicht mehr gemacht, da ich inzwischen nur noch über die Eingabezeile und das Frontend damit arbeite. Dennoch strukturiere ich mir weiterhin die fhem.cfg mit #Kommentaren, um sie bei Bedarf besser lesen zu können.
Ich habe FHEM jetzt ein paar mal abstürzen lassen (mit Verbose 4): Dabei fällt auf, dass die letzten Einträge vor dem Ende immer gleich sind. Anscheinend arbeitet FHEM irgend was ab und hängt sich dann auf:
2019.07.17 23:57:05 1: Including /opt/fhem/log/fhem.save
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmList({})
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmListIDs()
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmListVersion(RINCON_7828CAB8DFB801400:0)
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->presence(appeared)
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmList({})
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmListIDs()
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmListVersion(RINCON_7828CAB8DFB801400:0)
2019.07.17 23:57:06 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->presence(appeared)
2019.07.17 23:57:06 4: FB_CALLLIST (Anrufliste) - cleaning up call list
2019.07.18 00:04:12 1: Including /opt/fhem/log/fhem.save
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmList({})
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmListIDs()
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmListVersion(RINCON_7828CAB8DFB801400:0)
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->presence(appeared)
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmList({})
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmListIDs()
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmListVersion(RINCON_7828CAB8DFB801400:0)
2019.07.18 00:04:12 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->presence(appeared)
2019.07.18 00:04:12 4: FB_CALLLIST (Anrufliste) - cleaning up call list
2019.07.18 00:08:46 1: Including /opt/fhem/log/fhem.save
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmList(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmListIDs(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->AlarmListVersion(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Esszimmer->presence(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmList(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmListIDs(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->AlarmListVersion(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: SONOSPLAYER0: StateFn-Call. Ignore the following Reading: Sonos_Wohnzimmer->presence(~~NotLoadedMarker~~)
2019.07.18 00:08:47 4: FB_CALLLIST (Anrufliste) - cleaning up call list
Und mehr steht da nicht?
Leider werde ich daraus nicht schlau. Wenn Du das UWZ komplett raus lässt passiert nichts? Du kannst also dann ganz normal speichern? Und es passiert nur was beim cfg speichern? Normales ändern im Frontend und dann save gibt keine Probleme? Also UWZ drin lassen und ein Attribut über das Frontend ändern und dann save machen klappt zum Beispiel?
Ich bin leider auch nicht weiter gekommen: Das Log-File bricht einfach ab und beginnt erst wieder beim Neustart.
Wenn ich das Unwetter Device anlege oder es nach einem Neustart bereits angelegt ist, kann ich alles damit machen. Änderungen mit dem Save-Knopf zu speichern führt auch nicht zu Problemen.
Ich kann nur nicht im FHEMWEB die fhem.cfg solange nicht editieren, wie das Device da drin steht...
Eigentlich ist es Unsinn. Aber egal. Lösche bitte einmal das UWZ über FHEMWEB. Danach gehst Du über die Linux Shell in die
/opt/fhem/log/fhem.save
Und suchst nach dem Namen des UWZ Devices welches Du gelöscht hast. Ich hoffe Du kennst Dich bisschen mit Linux und vi aus. Oder wegen meiner auch mit nano.
Eigentlich solltest Du nichts finden, wenn aber doch dann lösche bitte alle Einträge die den UWZ Namen enthalten und speichere die save Datei. Bitte nicht mit irgendwelchen Windows Editoren arbeiten.
Ich gehe jetzt erstmal schlafen. Wir lesen uns in ein paar Stunden wieder.
Danke - probiere ich. Gute Nacht
Ich habe es nochmal fix überprüft: In der fhem.save Datei ist das Unwetter-Device nach dem Löschen im FHEM-Frontend nicht zu finden.
Guten Morgen,
Mehr fällt mir zu dem Thema leider nicht ein.
Grüße
Trotzdem Danke für Deine Hilfsbereitschaft!
Vielleicht hat ja noch jemand anderes eine Idee...
Das hört sich evtl. nach einer defekten SD-Speicherkarte an.
Fast das gleiche Verhalten hatte ich bei einer def- SD-Karte im Raspberry.
Alle Änderungen waren nach erfolgreichem speichern und Neustart weg.
VG
Olaf
Lieber Olaf,
Danke für die Idee. Bei mir läuft FHEM in einem Docker auf meiner Synology. Daher würde ich davon ausgehen, dass es erstmal nichts mit dem Speicher(platz) zu tun hat.
Viele Grüße
Phillip
Könnte es nicht auch am Docker Container liegen? Verlinke mal bitte diesen Thread im Docker Thread von Julian. Mal schauen was er dazu sagt.
Ich kann das von Rudibarani beschrieben Verhalten auf meinem Testsystem bestätigen
Kann jemand bitte FHEM mit "perl fhem.pl -d fhem.cfg" in der Konsole starten, und Konsolenoutput kurz vor dem Absturz hier anhaengen?
Zitat von: Wzut am 18 Juli 2019, 08:34:25
Ich kann das von Rudibarani beschrieben Verhalten auf meinem Testsystem bestätigen
Jetzt wird es interessant. Ist das Verhalten bei Dir auch in Verbindung mit UWZ?
@Ralf
Bei Dir auch im Container oder hast Du ein richtiges System darunter?
Guten morgen,
Nachdem ich das hier lese fällt mir ein ich habe auch mit UWZ Probleme. Konnte es aber aus Zeitmangel noch nicht weiter untersuchen. Ich melde mich wieder mit genaueren Angaben, jetzt bin ich nur mit Handy online.
Gruss
Manuel
Gesendet von meinem SM-G935F mit Tapatalk
Zitat von: rudolfkoenig am 18 Juli 2019, 08:42:03
Kann jemand bitte FHEM mit "perl fhem.pl -d fhem.cfg" in der Konsole starten, und Konsolenoutput kurz vor dem Absturz hier anhaengen?
Bitte sehr :
2019.07.18 09:02:20 5: Starting notify loop for global, 1 event(s), first is REREADCFG
2019.07.18 09:02:20 5: createNotifyHashdanach erfolgt keine weitere Ausgabe in der Konsole.
Die fhem.cfg habe ich zuvor fast leer gemacht und nur die UWZ als einizges Device drin.
Zitat von: MaMi7880 am 18 Juli 2019, 08:58:30
Guten morgen,
Nachdem ich das hier lese fällt mir ein ich habe auch mit UWZ Probleme. Konnte es aber aus Zeitmangel noch nicht weiter untersuchen. Ich melde mich wieder mit genaueren Angaben, jetzt bin ich nur mit Handy online.
Gruss
Manuel
Gesendet von meinem SM-G935F mit Tapatalk
Hallo Manuel,
Aber bitte nur wenn es etwas direkt mit den hier genannten Problem/Beobachtung zu tun hat.
Grüße
@coolTux
anbei das komplette -d Log , ab FHEM Start bis zum drücken von save.cfg
Ich konnte leider nichts finden. Rudi hat bestimmt mehr Glück.
Und noch mal die Frage an Dich.
Auch Container???
Nein, das Testsystem läuft ganz normal unter Ubuntu auf meinem Desktop PC
Zitat von: CoolTux am 18 Juli 2019, 09:09:24
Hallo Manuel,
Aber bitte nur wenn es etwas direkt mit den hier genannten Problem/Beobachtung zu tun hat.
Grüße
Natürlich...
Gesendet von meinem SM-G935F mit Tapatalk
Ich habe nochmal mein Backup angeschaut, da das UWZ Device Anfang Juli aktualisiert wurde: Der Fehler hängt eindeutig mit der neuen Version zusammen, da mit der alten Version der Fehler nicht auftritt. Stelle ich dann die neue Version wieder her, tritt der Fehler wieder auf.
Man kann also entweder das alte UWZ Device als Workaround installieren, oder das neue behalten und vorübergehend mit disable 1 inativieren, wenn man die fhem.cfg über das Frontend editieren möchte. Beides funktioniert.
Vielleicht hilft das ja, die Fehlerquelle einzugrenzen und rauszufinden, wieso das aktualisierte UWZ Device FHEM ohne jede Log-Meldung zum Stillstand bringen kann (und darf).
ZitatSpeichern der fhem.cfg via FHEMWEB führt zum Absturz
Es fuehrt nicht zum Absturz, FHEM wartet nur 10 Minuten, weil UWZ.pm in Zeile 882 das so bestellt hat:
ZitatInternalTimer( gettimeofday() + $hash->{INTERVAL},
"UWZ_Start", $hash, 1 );
Das 1 steht fuer waitIfInitNotDone, d.h. wenn fhem.cfg noch nicht _komplett_ eingelesen wurde.
Warum das nur beim rereadcfg ein Problem ist, ist mir noch unklar, das kann aber gerne so bleiben :)
Ach man Rudi Du bist ne olle Petze. ;D
Habe mir so viel Mühe gegeben es zu verstecken.
Lach
Ne Spaß bei Seite. Der Code würde seit Jahren an der Stelle nicht mehr angerührt. Zu mindest nicht bewusst.
Meine persönliche Empfehlung. Finger weg vom editieren der Konfig bis ich Lust finde das eventuell vielleicht mal sehen zu bereinigen.
Grüße aus dem sächsischen Urlaub.
Vielen Dank allen für die schnelle Klärung, woran es liegt.
Das FHEM 10 Minuten keinen Input über die Webseite annimmt und so lange hängt, bis das durch ist, ist nicht schön - aber ohne editieren der Config zumindest erstmal vermeidbar...
Allen einen schönen Urlaub bzw. ein schönes Wochenende
Ich habe es gefixt und steht ab morgen früh per FHEM update zur Verfügung
...und das im Urlaub. Herzlichen Dank!
Viele Grüße
Zitat von: Rudibarani am 20 Juli 2019, 21:41:32
...und das im Urlaub. Herzlichen Dank!
Viele Grüße
Der Urlaub (weg fahren) ist heute zu Ende, naja der halbe. Ich fahre am Dienstag noch mal für ein paar Tage ;D
Bitte gerne