lock config files and prevent fhem to change them

[immi]

2. default should be yes, for an unexperienced user. Experienced users are more likely to find out how to change it, as the other way round.

Hi Rudolf,
To my opinion per-default "autosave" should be deactivated, especially for inexperienced user.

Inexperienced users have problems tracking changes: for sure they will not use the advanced versioning of configDB.
Inexperienced users will be confused by a save button, that is not really needed anymore, because the modules save when they want (read very often, if you have many devices).
Inexperienced users make failures, which will be very often saved: for sure they do not make so many backups.

immi

[justme1968]

i would say that not the autosave is the problem but that fhem 'forgets' the definitions for modulen that could not be loaded. this is the real sideffect that causes the problem.

but i habe no good idea Hof to fix this...

  andre

[rudolfkoenig]

@immi: I see your reasoning, but I do not agree.

FHEM has "plug&play" capability, where you start FHEM with a CUL connected, and FHEM collects data from sensors around which do not need pairing, without requiring you to do anything. If autosave is off by default,  you loose this data, unless you press the save button. The save button is still required for all the changes you do.

The configuration should not be arbitrarily saved, but it definitely makes sense if you make changes which are also stored in hardware, else fhem.cfg will not be in sync with the hardware. E.g. if you include a ZWave device, the ZWave module saves the config indirectly by creating a new device via autocreate, which in turn saves the config.

As andre pointed out, your problem stems not from the above behaviour, but from the case that one module won't load, and FHEM continues to work. Perhaps we should deactivate the autosave attribute temporarily if a module failes to load. The problem with this idea is, that there is no way yet in FHEM to temporarily disable an attribute.

[immi]

Hi Andre
Unfortunately, we cannot easily differentiate between user-requested save and fhem-requested saves.
But we could limit the fhem-requested saves to the module requesting.
E.g. when Enocean requests a save, only Enocean-related entities should be updated in the config-file. There is no need to save everything.

This solves also my original problem: FHEM forgets the definitions for modules that cannot not be loaded.
If a module cannot be loaded, for sure cannot commit a save, and with the new rule the other modules cannot change its definition.
immi

[rudolfkoenig]

@immi: it is easy to differentiate between user-requested and program requested save (the first parameter to CommandSave), but it is not easy to save just a certain type of data, at least not with the current architecture.

[justme1968]

@immi: you can differentiate between both. but i think you should not. there are a number of posts about lossing devices by accidentialy saving by the user.

@rudi: what about storing all failed define and attr command simular to the comments. so they can be written to the config file on save? this would avoid any losses.

commandDelete should maybe be allowed to remove these stored lines. so non funktional drvices would be remove by delete.

[rudolfkoenig]

This proposal needs more changes in the code that I initially thought:
- save failed defines as comments, and create a new hash for such definitions
- check if attr/setstate is for a failed define, and save it as a comment if yes
- implement dumping of failed lines in the statefile.

I am unconviced at the moment if the result is worth the effort, especially as it normally only affects developers on their development system. The exception is a FHEM-module introducing a dependency to a not yet installed Perl-Module, but I hope that this case can be handled more user-friendly by the module itself.

Any other opinions?

[immi]

Hi Andre and Rudolf
I understand the complexity.
let us stick to the minimum.
- "autosave" as global attribute
- the 13 modules using CommandSave will respect the attribute.

p.s. I would also suggest to move the thread in Developer, so that more developer will read it and be aware of the topic.
immi

[rudolfkoenig]

I introduced the global attribute autosave, and autocreate will use it, if it is set.
The autocreate autosave will override it, but it is documented as deprecated.

[immi]

thanks & just in time

the update of today (crashing 98_SVG) would have probably overwritten config-file deleting all my plots
Luckily autosave was deactivated, and when you fixed the module SVG everithing worked again.

immi