lock config files and prevent fhem to change them

[immi]

FHEM is modifying my config files if someone press "save" or something goes wrong starting a module.
Is there a parameter to lock the config files and prevent fhem to change them?

please do no blame me, I know that FHEM is going in the opposite direction, but I am quite oldfashon and I prefer to modify my configuration after shutting down FHEM.

immi

[rudolfkoenig]

FHEM is modifying my config files if someone press "save"

??? Why are you pressing save, if you dont want it?

You can hide the save button in the frontend, and disable th autocreate feature, this should be enough.
If you want a second layer of security, you can disable save with cmdalias.

[Virsacer]

Or you coud just set the permissions (for the fhem user) to read-only on the filesystem

[immi]

Hi Rudolf
thanks for the answer: I try to explain better.
I set Autocreate "off" after configuring all my 45 enocean  appliances, 2 years ago.
My save button is hidden (for port 8085)  .... since my wife began using FHEM  (same timeframe)

For me, it is  the second point more relevant. When a module has a problem, FHEM edits my config files without asking .. and I do not really like it.
It happens, when I test my module on the productive system or when an update goes wrong..
My trivial solution: I keep valid config files somewhere else and the fhem-startup-script copies in FHEM directory before starting FHEM.

My workaround is perfectly OK for me. But, for sure, it is not for everyone.
There are and will be lots of users who set-up fhem and let it run for years without changing anything.

If something goes wrong, reinstalling from internet FHEM takes 5 minutes. Finding out that FHEM changed line 327 of the config, can be really annoying.

A solution for everyone could be:
1) FHEM changes the config file only if you press or type SAVE
2) a "diff" old config / new config could be displayed before letting the user approve the change (optional/nice-to-have)

my 2 cents
immi

[rudolfkoenig]

Can you give me examples of a module saving fhem.cfg?
I'm aware only of autocreate, and there you can turn it off with "attr autocreate autosave 0", or you can disable autocreate altogether.

Something like diff is available when you click on the ominous red question mark in FHEMWEB beside the Save link or when you type save ?

[immi]

Something like diff is available when you click on the ominous red question mark in FHEMWEB beside the Save link or when you type save ?

I haven´t seen it, because I always hide the save button; sorry for asking you.

Can you give me examples of a module saving fhem.cfg?

I do not know what is changing the fhem.cfg, otherwise I would have already proposed a patch.
I repeatedly saw that when a module crashes or has a failure, fhem.cfg is edited.
e.g.
1) take 00_THZ (or something else) and define it in fhem.cfg
2) include a perl error in 00_THZ e.g. a "typo" or a missing ";"
--> then FHEM prevents 00_THZ to be loaded (which is OK)
--> but FHEm also removes all definition/attributes of THZ from the fhem.cfg (which is NOT OK)

immi

[rudolfkoenig]

Not without an explicit save...

I should know, I'm including regularly errors in my FHEM-modules, and I dont have to fix each time the test-configuration.

[fruit]

Why not keep a local or remote backup of your config?
You can then restore in seconds rather than 5 minutes.

[rudolfkoenig]

You can even automate it, e.g. like this.

[immi]

Not without an explicit save...
I should know, I'm including regularly errors in my FHEM-modules, and I dont have to fix each time the test-configuration.

just reproduced without an explicit save on the QNAP: I have included an error to 00_THZ.pm, FHEM disabled the module and FHEM messed up with the config file.

after that I tried the same thing on MACOS: I have included the same error to 00_THZ.pm, FHEM disabled the module and FHEM did not change  config file.

Tomorrow, I just have to find out the difference between my QNAP and my MACOS setup.
immi

[immi]

Hi Rudolf
I think I got it: 3 modules use

CommandSave(undef,undef);

without checking the autosave parameter

to my opinion the correct way would be:

Code Auswählen Erweitern


CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );

What do you think Rudolf?
I will contact in PM Klaus.
immi

[rudolfkoenig]

I've just counted 13 modules, and this was new to me.

Andres modules check the autocreates attribute before executing save, probably with the argumentation, that if you have activated autosave in autocreate, then you expect structureal changes to be saved automatically. If these changes are also stored in the hardware, than I accept the solution.

EnOcean uses save after a teach-in took place. I'm still undecided, if this is the right thing to do.

And I dont think that the use of CommandSave in the 00_TCM.pm module is justified.

[klaus.schauer]

Folgende Änderungen werden eingepflegt:
00_TCM: CommandSave entfällt
10_EnOcean: Abfage des Attributes "autosave" von autocreate wird durchgeführt.

55_PIFACE bleibt unverändert, da sonst die restart-Funktionen nicht in allen Fällen gewährleistet werden können.

[immi]

excellent klaus; this fixes my issue, I do not use piface.

now, 2 more philosophical questions:

1) shoudl the attribute "autosave" be part of autocreate or should be a global attribute, considering several modules use it?
2) Should it be default-on or default-off? to my opinion it makes sense that autosave is allowed only if explicitely defined to 1. Default should be deactivated.

immi

[rudolfkoenig]

1. probably yes, but I hate having more global attributes.
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.