FHEMWEB: save config speichert angabegemäß deleteattr nicht

[justme1968]

beim setzen geht wenigstens (fast) nichts kaputt.

viel problematischer finde ich das ein vergessener attribut name beim deleteattr dafür sorgt das alle attribute weg sind.

[Dr. Boris Neubert]

Hmm. Irgendwie sind wir in eine Grundsatz-/Methoden-/Standarddiskussion geraten und meine Erfahrung lehrte mich, dass dies nicht zu einer grundsätzlichen Änderung führt.

On-Topic:

Attribute können nicht gesetzt sein, gesetzt sein, und auf einen Wert gesetzt sein. Die Verwendung von AttrVal($name, $attribut, $default) ist nicht für den Fall geeignet, dass ein nicht gesetztes Attribut als getrennter dritter Zustand in Unterschied zu gesetztem oder auf Wert gesetzten Attribut verstanden wird. Die Schwierigkeit entsteht durch die Vermengung der Aussagen.

Ich schließe mich Rudi an, dass die Form "Attribut ist gesetzt aber ohne Wert/Wert ist egal" probat ist. Er ist auch nicht problematisch, weil der Anwender ein z.B. per AttrVal($name, $attribut, 1) defaultmäßig gesetztes Attribut mit attr <name> 0 abschalten kann. Aber auch nur, wenn im Code mit if(...) und nicht mit if(defined(...)) geprüft wird, was ein Entwickler tun würde, wenn er AttrVal($name, $attribut, undef) verwendet. Ich habe mir gerade mal einen Querschnitt durch die Verwendung von AttrVal angesehen und da gibt es alle möglichen Varianten für den dritten Parameter: 0, 1, "1", undef, "eintext", ...

Die semantische Lücke entsteht dadurch, dass der Anwender ein Attribut nicht auf "nicht gesetzt" konfigurieren kann, wenn der Default "auf einen Wert gesetzt" ist. Ein naives attr <name> (ohne Angabe eines Wertes) wäre die semantische Entsprechung von deleteattr <name>. Aber leider ist das schon mit attr <name> 1 vorbelegt. Es ließe sich zwar in der AttrFn überschreiben, aber diese Inkonsistenz ist hässlich.

Fazit: wir stecken tief im Sumpf und der Default in meinem Modul muss sich ändern und dieses Thema in die Wikiabteilung FHEM-Development für Fortgeschrittene.

Viele Grüße
Boris

[justme1968]

eigentlich inzwischen etwas off toppic... aber vielleicht nützt es ja doch noch jemandem.

ja. solche diskussionen führen selten zu grundsätzlichen änderungen im bestehenden. aber sie können helfen das ein entwickler bei einem neuen modul nicht wieder in genau die selben probleme läuft.


ich würde sagen es gibt in der aktuellen implementierung keine drei zustande sondern nur zwei. nicht gesetzt oder auf einen wert gesetzt. ein teil der probleme kommen daher das man manchmal drei zustände möchte, es aber eben nur zwei gibt.

das die 0 semantisch bei manchen datentypen einem nicht gesetzten attribut gleich kommt ist mehr oder weniger zufall denn man natürlich konkret ausnutzen kann. aber eben nicht immer problemlos und abhängig on der verwendung des attributs.

ein anderer teil der probleme kommt daher das entwickler der dritten parameter mit etwas anderem als undef verwenden. das sollte eher dem endanwender überlassen sein. für entwickler ist es besser beim initialen define eines moduls (ob von hand oder durch autocreate) attribute mit den gewünschten defaults vorzubelegen. das ist zum einen da verhalten für den endanwender sichtbar und zum anderen kann er das attribut anpassen und löschen und wird von unsichtbaren modul internen defaults nicht überstimmt.

das fhem default verhalten zu ändern würde vermutlich alle möglichen probleme mit bestehenden modulen verursachen. deshalb ist es glaube ich besser die obige vorgehensweise zu empfehlen d.h. das im modul der dritte parameter von AttrVal in der regel undef sein sollte und statt dessen im initialen ersten define nötige attribute vorbelegt werden.

gruss
  andre

[Loredo]

das fhem default verhalten zu ändern würde vermutlich alle möglichen probleme mit bestehenden modulen verursachen. deshalb ist es glaube ich besser die obige vorgehensweise zu empfehlen d.h. das im modul der dritte parameter von AttrVal in der regel undef sein sollte und statt dessen im initialen ersten define nötige attribute vorbelegt werden.

Und wie komme ich dann zu meinem internen Default-Wert, wenn der User aus Unwissenheit oder auch Absicht das Attribut löscht, sich aber 5min später nicht mehr erinnern kann und sich beschwert, dass das Modul gar nicht mehr funktioniert, weil ihm ein Wert für die Funktion fehlt? Ich bin der Meinung, dass hier ein interner, auch nicht sichtbarer Default-Wert völlig ok ist und den User keineswegs einschränkt, denn mit setzen des Attributes kann er es ja nach wie vor anpassen und überschreiben. Ob man die internen Default-Werte unbedingt immer als Attribute anlegen muss ist eine Geschmacksfrage. Ich hab es nach einem Define lieber aufgeräumter (ja, ich bin trotzdem ein Fan devStateIcon u.ä. beim 1. define vorzubelegen). Es ist vermutlich wie so häufig: Die Autoren lieben ihre eigenen Module und leben mit den in ihren Augen seltsamen Verhalten der anderen Module, sofern sie sie benutzen müssen/wollen.

[justme1968]

das oben bezog sich auf defaults/attribut bei denen es sinnvoll ist das ein anwender sie komplette löscht.

wenn es um dinge geht bei denen komplett löschen nicht sinnvoll ist passt das natürlich nicht ganz. ob man dann tatsächlich nur einen sinnvolle meldung ausspuckt oder sich die defaults von woanders holt (bis hin zum wieder setzen des attributes) hängt vom modul ab.

übrigens kann man das löschen eines attributes in der AttrFn auch verhindern.

[betateilchen]

übrigens kann man das löschen eines attributes in der AttrFn auch verhindern.

was dem Sinn eines dem Benutzer gehörenden Attributes allerdings völlig zuwiderlaufen würde...