[behoben] Bug? Speichern der fhem.cfg via FHEMWEB führt zum Absturz

[Rudibarani]

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:

Code Auswählen Erweitern

#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?

[CoolTux]

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?

[Rudibarani]

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

[CoolTux]

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.

[Rudibarani]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[CoolTux]

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?

[Rudibarani]

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...

[CoolTux]

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.

[Rudibarani]

Danke - probiere ich. Gute Nacht

[Rudibarani]

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.

[CoolTux]

Guten Morgen,

Mehr fällt mir zu dem Thema leider nicht ein.


Grüße

[Rudibarani]

Trotzdem Danke für Deine Hilfsbereitschaft!

Vielleicht hat ja noch jemand anderes eine Idee...

[ollir]

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

[Rudibarani]

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

[CoolTux]

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.