vorschlag: eindeutige id für jedes fhem device

[betateilchen]

Das war nach meinem Geschmack etwas zu schnell, ich wollte dich noch ueberreden die GetDefAndAttr() Funktion zu verwenden.
Aber vielleicht ist es nicht zu spaet...

Es ist nie zu spät. Aber bevor ich GetDefAndAttr() in configDB verwenden kann, müsste die Behandlung von Attributen, die NICHT gespeichert werden dürfen, noch angepasst werden. Patch folgt.

[betateilchen]

Code Auswählen Erweitern


Index: fhem.pl
===================================================================
--- fhem.pl     (revision 18313)
+++ fhem.pl     (working copy)
@@ -1619,13 +1619,15 @@
   push @ret, "setuuid $d $defs{$d}{FUUID}"
         if($dumpFUUID && defined($defs{$d}{FUUID}) && $defs{$d}{FUUID});

+# exclude attributes, format <deviceName>:<attrName>, space separated list
+  my @dontSave = qw(configdb:rescue configdb:nostate configdb:loadversion
+                    global:configfile global:version);
   foreach my $a (sort {
                    return -1 if($a eq "userattr"); # userattr must be first
                    return  1 if($b eq "userattr");
                    return $a cmp $b;
                  } keys %{$attr{$d}}) {
-    next if($d eq "global" &&
-            ($a eq "configfile" || $a eq "version"));
+    next if (grep { $_ eq "$d:$a" } @dontSave);
     my $val = $attr{$d}{$a};
     $val =~ s/;/;;/g;
     $val =~ s/\n/\\\n/g;


Auf meinem Testsystem habe ich gerade eine so gepatchte fhem.pl und eine configDB, die GetDefAndAttr() verwendet, erfolgreich getestet. Die FUUID werden alle angelegt und nach einem Neustart wiederhergestellt.

[betateilchen]

Mir ist gerade aufgefallen, dass GetDefAndAttr() in den Forward-Deklarationen der fhem.pl noch fehlt.

[betateilchen]

dann sollte man auch überlegen eine routinen für name -> uuid und uuid -> name einzubauen.

das geht grundsätzlich auch jetzt schon...

Code Auswählen Erweitern

{(defInfo('FUUID=5c41b807-f33f-01d2-8853-63bca4a2bcd43a69','NAME'))[0]}

liefert bei mir korrekt den deviceName oc_test

und umgekehrt liefert

Code Auswählen Erweitern

{(defInfo('NAME=oc_test','FUUID'))[0]}

5c41b807-f33f-01d2-8853-63bca4a2bcd43a69

[rudolfkoenig]

@betateilchen: hab dein Patch + Forward-Deklaration eingecheckt.

Ich frage mich, wieso wir beide fuer nicht zu speichernde Internal Values Attribute verwenden.
Leider wird global version und global configfile auch von anderen Modulen geprueft, sonst haette ich es jetzt ausgebaut.

[betateilchen]

Zumindest für das globale Attribut "configfile" kann ich Dir Deine Frage beantworten.

Es ist die einzige Chance für einen configDB Nutzer, aus seiner Konfiguration wieder eine lauffähige fhem.cfg zu erzeugen.

• FHEM wird mit configDB gestartet
• User setzt das globale Attribut configfile auf fhem.cfg (oder einen anderen Dateinamen)
• ein nachfolgendes "save config" erzeugt eine Konfigurationsdatei

Auch wenn es m.E. keinen Grund gibt  von der configDB wieder zurück zu den altertümlichen Textdateien zu wechseln, sollte man den Usern diesen Weg nicht versperren, indem man dieses Attribut ausbaut. Man könnte den Rückweg natürlich auch anders bauen, aber diese Möglichkeit ist zumindest die logischste und sie ist bereits vorhanden, dokumentiert und bewährt.

Den Sinn des "version" Attributes habe ich allerdings noch nie verstanden.

[betateilchen]

@betateilchen: hab dein Patch + Forward-Deklaration eingecheckt.

Danke, ich habe eben die dazu passende configDB.pm eingecheckt.

[herrmannj]

Da klemmt es noch irgendwo: https://forum.fhem.de/index.php/topic,96172.0.html

[betateilchen]

noch ein Grund mehr, rereadcfg zu entsorgen

[betateilchen]

Macht es eigentlich in jedem Fall Sinn, dass ein device seine FUUID behält, wenn man die DEF (ggf. komplett) ändert?

Meiner Meinung nach: eher nicht.

[justme1968]

ich denke in den meisten fällen schon.

das lässt sich nicht wirklich automatisch entscheiden.

wenn es tatsächlich mal probleme gibt: löschen und neu anlegen.

[CoolTux]

Warum nicht? Das Device an sich bleibt ja existent. Es ändern sich nur Eigenschaften.
Ähnlich wie bei einem Objekt.