Nochmal: Module überschreiben die fhem.cfg

[topfi]

Ich mir ein paar HUE-Devices gegönnt und in FHEM eingebunden. Daraufhin ist es mehrfach passiert, dass meine fhem.cfg bei Neustarts ungewollt von FHEM modifiziert und überschrieben wurde. Passieren kann das beispielsweise, wenn man (unabhängig von FHEM) mit der Philips-App einen neuen Raum in der Hue-Bridge anlegt. Dann möchte das Modul diese Räume auch in FHEM anlegen und versucht, das abzuspeichern. Leider betraf das aber auch Dinge, die mit HUE überhaupt nichts zu tun haben, beispielsweise fehlten bei Floorplans die Attribute für das Anordnen der (aller!) Symbole.

Ich habe hier den thread in diesem Unterforum vom Herbst 2017 gelesen und konnte nun eingrenzen, wieso das Modul überhaupt in die fhem.cfg schreiben durfte (durfte sie nämlich eigentlich gar nicht): 

Gebe ich in FHEM die Abfrage ein:

Code Auswählen Erweitern

{( AttrVal( "autocreate", "autosave", 1 ) )}

kommt als Antwort "1" , also wahr! Das dürfte nicht sein, denn autocreate ist in meiner FHEM-Konfiguration überhaupt nicht angelegt oder definiert. Das mache ich nur temporär, wenn ich ein neues Gerät anlernen möchte.

Als Workaround probiere ich nun, stattdessen ein "autocreate" wie folgt zu definieren:

Code Auswählen Erweitern


define autocreate autocreate
attr autocreate autosave 0
attr autocreate disable 1


Eine Abfrage

Code Auswählen Erweitern

{( AttrVal( "autocreate", "autosave", 1 ) )}

liefert nun als Antwort richtig: "0" Ich hoffe, dass das Problem damit erledigt ist und werde berichten, falls nicht. Oder mache ich vielleicht einfach nur einen Denkfehler?

[JoWiemann]

Hallo,

da das Attribut autocreate nicht angelegt ist, gibt Dir AttrVal den vorgegebenen Defaultwert zurück. Hier die 1. Also alles richtig. Ob der Defaultwert im benutzten Zusammenhang richtig gewählt ist, ist eine ganz andere Frage.

Grüße Jörg

[topfi]

Danke für die Erklärung. Dann werde ich wohl mit dem Workaround leben.

[rudolfkoenig]

Seit einiger Zeit wird ein vom Modul ausgeloestes save verweigert, wenn "attr global autosave 0" ist.
Auf loglevel 4 wird gemeldet:

Skipping save, as autosave is disabled

Falls beim FHEM-Initialisieren ein Fehler aufgetreten ist, dann wird "attr global autosave 0" gesetzt, mit der loglevel 1 Meldung:

Autosave deactivated

[topfi]

Ah, Danke. Das globale Attribut autosave kannte ich noch gar nicht.

Mein fhem ist nicht ganz aktuell, das Attribut gibt es aber schon. Ich habe es jetzt gesetzt, das sollte helfen.

[Markus Bloch]

Eine Abfrage

Code Auswählen Erweitern

{( AttrVal( "autocreate", "autosave", 1 ) )}

liefert nun als Antwort richtig: "0" Ich hoffe, dass das Problem damit erledigt ist und werde berichten, falls nicht. Oder mache ich vielleicht einfach nur einen Denkfehler?

Ich glaube Du hast den Jörg falsch verstanden.

Deine Abfrage hat vorher eine 1 zurückgeliefert. Das liegt daran, dass Du in deiner Abfrage den Wert "1" als Default-Rückgabewert angegeben hast, sollte das Attribut "autosave" in der Definition "autocreate" nicht gesetzt sein. Da es zu diesem Zeitpunkt nicht gesetzt war, gibt dein Ausdruck den Wert 1 als Ergebnis zurück, da du ja auch 1 als Default-Wert mitgegeben hast: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#AttrVal

Viele Grüße

Markus

[topfi]

Du hast recht.

Diese Abfrage steht so als Bedingung für das Überschreiben der Konfigurationsdatei beispielsweise in der 30_HUEBridge.pm. Es war mir tatsächlich nicht klar, ich hätte aber aus Äquivalenzbetrachtungen selbst darauf kommen können  , dass die 1 die Defaultantwort für "undefiniert" ist. Danke für den Hinweis.

Aber sollte in den Modulen dann nicht besser auf

Code Auswählen Erweitern


{( AttrVal( "autocreate", "autosave", 0 ) )}


geprüft werden?

[Markus Bloch]

Da dieses Problem in letzter Zeit häufiger bei verschiedenen Usern auftrat wurde mit Revision 15377 (01.11.2017) eine Prüfung auf das Attribut "autosave" direkt in CommandSave() eingeführt:

Code Auswählen Erweitern

  if(!$cl && !AttrVal("global", "autosave", 1)) { # Forum #78769
    Log 4, "Skipping save, as autosave is disabled";
    return;
  }

Viele Grüße

Markus

[CQuadrat]

Wäre da ein höherer Log-Level nicht angebracht?

Ich bin auch darüber gestolpert; mit Loglevel 3 hätte ich mir aber einiges Stirnrunzeln erspart.

[rudolfkoenig]

Ich vermute, dass verbose 3 viele Benutzer, die autosave absichtlich abgeschaltet haben, nerven wuerde.
Bin aber offen.