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
ZitatFHEM 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.
Or you coud just set the permissions (for the fhem user) to read-only on the filesystem :)
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
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 ?
Zitat von: rudolfkoenig am 14 August 2015, 12:03:38
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.
Zitat
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
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.
Why not keep a local or remote backup of your config?
You can then restore in seconds rather than 5 minutes.
You can even automate it, e.g. like this (http://forum.fhem.de/index.php/topic,30873.msg234412.html#msg234412).
Zitat von: rudolfkoenig am 14 August 2015, 15:03:19
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
Hi Rudolf
I think I got it: 3 modules use
ZitatCommandSave(undef,undef);
without checking the autosave parameter
to my opinion the correct way would be:
CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );What do you think Rudolf?
I will contact in PM Klaus.
immi
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.
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.
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
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.
Zitat von: rudolfkoenig am 17 August 2015, 07:27:17
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
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
@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.
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
@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.
@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.
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?
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
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.
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