Attribut wird beim Start von fhem gelöscht - warum?

[willybauss]

Ich habe für meinen Stromzähler u.a. die beiden Attribute 'interval' und 'alignTime' gesetzt (und die Config gespeichert). Beim Start von fhem bekomme ich dennoch

Code Auswählen Erweitern

Messages collected while initializing FHEM:
configfile: OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified

... und alignTime wird gelöscht. interval ist aber nach wie vor gesetzt.

Im Config File sehe ich, dass alignTime vor interval steht  - vermutlich ist die Sortierung der Attribute alphabetisch, sieht jedenfalls so aus. Drehe ich die Reihenfolge manuell um, dann klappt beim nächsten Start alles: keine Fehlermeldung, kein gelöschtes Attribut. Aber irgendwann später (nach dem nächsten 'Save config'?) ist die Reihenfolge plötzlich wieder alphabetisch und beim nächsten Restart wird alignTime wieder gelöscht. Offenbar sortiert fhem die Attribute wieder um.

Dummerweise bin ich im OBIS-Thread der Einzige, der dieses Problem hat. Auch andere OBIS-Anwender haben alphabetisch sortierte Attribute, aber kein Problem beim Restart.

==> woran liegt das bzw. wie kann ich es korrigieren?

[dev0]

Da die gezeigte Meldung vom Modul und nicht von fhem.pl stammt, würde ich den Modul Maintainer direkt im passenden Forumsbereich fragen => Thread verschieben.

[CoolTux]

Lösche mal beide Attribute über das Webinterface. Speichere die Konfig starte FHEM neu. Setze dann die Attribute neu über das Webinterface und speichere ab. Schaue ob nach einem Neustart das Problem immer noch besteht.

[Icinger]

Das "Problem" liegt zu einem gewissen Teil an mir, weil im OBIS-Modul beim setzen der alignTime-Attributs getestet wird, ob das "interval"-Attribut schon gesetzt ist.
Ist das nicht der Fall, wird vom Modul eben die Meldung

Code Auswählen Erweitern

OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified
zurückgegeben.
Wird aus der setAttr-Routine aber was anderes als undef retourniert, wird dieses Attribut eben nicht gesetzt.

Habe das intern jetzt behoben, indem statt

Code Auswählen Erweitern

return <Meldung>
ein

Code Auswählen Erweitern

Log3 $hash,3,<Meldung>
abgesetzt wird und durch ein "return undef" das Attribut trotzdem gesetzt wird.

Die andere Frage ist aber: Ist es wirklich notwendig, die Attribute bei einem Save immer alphabetisch zu sortieren?

lg, Stefan

[dev0]

Ist es wirklich notwendig, die Attribute bei einem Save immer alphabetisch zu sortieren?

Zumindest hat man dann eine definierte Reihenfolge, wenn man schon Attribut x von y abhängig macht. Sonst wäre es Zufall ob es funktioniert oder nicht.

[betateilchen]

Die andere Frage ist aber: Ist es wirklich notwendig, die Attribute bei einem Save immer alphabetisch zu sortieren?

Das Sortieren ist vor allen Dingen notwendig, um sicherzustellen, dass möglicherweise vorhandene userattr vor anderen Attributen verarbeitet werden. Die alphabetische Reihenfolge ist mehr oder weniger ein Abfallprodukt davon. Aber man kann sich zumindest darauf verlassen.

[willybauss]

Ich sehe schon, das war doch keine Anfängerfrage, aber letztlich hat sich ja Alles zum guten gewendet. Besten Dank dafür.