[gelöst] Einstellungen weg nach Neustart trotz neuer SD-Karte

Begonnen von grappa24, 14 Juni 2024, 22:08:33

Vorheriges Thema - Nächstes Thema

grappa24

ich freu mich zwar über den Halbzeitstand von 3:0 gegen Schottland, bin aber etwas gefrustet, weil mein FHEM - trotz Restore auf eine neue SD-Karte - nach dem Neustart immer wieder die gleichen Einstellungen verliert:

- Den aktuellen Wert eines dummys
- Das Attribut "userreadings" eines device
- ...

Was kann denn der Grund für diesen "Gedächtnisverlust" trotz neuer SD-Karte sein?

Grüße,
Dieter
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

Otto123

Hallo Dieter,

fhem.cfg ist nicht schreibbar? Berechtigung?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

grappa24

Zitat von: Otto123 am 14 Juni 2024, 22:50:02fhem.cfg ist nicht schreibbar? Berechtigung?
doch, meine fhem.cfg hat die Rechte 755 und gehört "fhem:dialout"
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

grappa24

P.S. Was hatte ich gemacht?
- Ein älteres, funktionierendes SD-Karten-Image auf eine neue SD-Karte kopiert (dachte die Karte hätte ne Macke)
- Vorher von dem laufenden System FHEM backup gesichert
- und das dann mit tar ... wieder auf das neue System/die neue Karte zurückgespielt
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

Otto123

Der aktuelle Wert eines Dummies sollte im statefile gespeichert sein. Das userreadings in der cfg. Das beschriebene Verhalten deutet darauf hin, das der Schreibvorgang nicht funktioniert. Steht was im Log dazu? Ein normaler Neustart sollte das statefile schreiben, ein save schreibt die cfg...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

grappa24

#5
Ich hab mal meine fhem.save geprüft.

Sie hat die Rechte 644 und den owner fhem:dialout

Nach einem "FHEM save config" steht da "setstate SimStopTime 22:15:00" drin.

Nach einem "FHEM restart" steht da "setstate SimStopTime 22:15:00" drin

In FHEM-WEB hat der dummy aber den Wert 21:15:00

und nach einem "FHEM save config" steht im statefile wieder "setstate SimStopTime 22:15:00"

Für mich sieht das so aus, als würde beim restart/FHEM-Web neuladen das statefile nicht (richtig) gelesen  :o

so sieht der dummy vor dem "save config" aus:
define SimStopTime dummy
attr SimStopTime readingList state
attr SimStopTime room AnwSim,GlobaleVariablen
attr SimStopTime setList setList state:20:00:00,20:15:00,20:30:00,20:45:00,21:00:00,21:15:00,21:30:00,21:45:00,22:00:00,22:15:00,22:30:00
attr SimStopTime webCmd state
#   FUUID      646ddc84-f33f-b5ae-950e-43416d88a352bc83
#   NAME       SimStopTime
#   NR         665
#   STATE      22:15:00
#   TYPE       dummy
#   eventCount 2
#   READINGS:
#     2024-06-15 10:20:19   state           22:15:00
#
setstate SimStopTime 22:15:00
setstate SimStopTime 2024-06-15 10:20:19 state 22:15:00


Und so nach einem FHEM-restart / FHEM-WEB neuladen:

define SimStopTime dummy
attr SimStopTime readingList state
attr SimStopTime room AnwSim,GlobaleVariablen
attr SimStopTime setList setList state:20:00:00,20:15:00,20:30:00,20:45:00,21:00:00,21:15:00,21:30:00,21:45:00,22:00:00,22:15:00,22:30:00
attr SimStopTime webCmd state
#   FUUID      646ddc84-f33f-b5ae-950e-43416d88a352bc83
#   NAME       SimStopTime
#   NR         665
#   STATE      21:15:00
#   TYPE       dummy
#   eventCount 1
#   READINGS:
#     2024-06-15 10:22:46   state           21:15:00
#
setstate SimStopTime 21:15:00
setstate SimStopTime 2024-06-15 10:22:46 state 21:15:00


Hat aber auch nix mit der Sommerzeit zu tun, egal auf welchen Wert ich den dummy setze, nach einem restart steht er immer wieder auf 21:15:00

FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

grappa24

oh mann, wie blöd muss man/ich denn sein .....

warum auch immer, ich hatte in global:INITIALIZED den dummy SimStopTime auf 21:15:00 gesetzt

o.k. gibt eine Runde in die Kaffeekasse  ;)
FHEM 6.3, 2 x RasPi 3B+, Debian Buster; KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200
Rollo-/Lichtsteuerung/-szenarien, T-Sensoren, Fensterkontakte, Heizungssteuerung, HEOS, Sprachsteuerung mit Alexa-FHEM, Netatmo, Nuki, ...

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!