vorschlag: eindeutige id für jedes fhem device

Begonnen von justme1968, 15 Januar 2019, 09:22:49

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: rudolfkoenig am 18 Januar 2019, 10:41:48
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen


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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Mir ist gerade aufgefallen, dass GetDefAndAttr() in den Forward-Deklarationen der fhem.pl noch fehlt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: justme1968 am 18 Januar 2019, 10:34:35
dann sollte man auch überlegen eine routinen für name -> uuid und uuid -> name einzubauen.

das geht grundsätzlich auch jetzt schon...

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

liefert bei mir korrekt den deviceName oc_test

und umgekehrt liefert

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

5c41b807-f33f-01d2-8853-63bca4a2bcd43a69
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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  8) 8) 8) 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: rudolfkoenig am 18 Januar 2019, 18:09:41
@betateilchen: hab dein Patch + Forward-Deklaration eingecheckt.

Danke, ich habe eben die dazu passende configDB.pm eingecheckt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj


betateilchen

noch ein Grund mehr, rereadcfg zu entsorgen :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Warum nicht? Das Device an sich bleibt ja existent. Es ändern sich nur Eigenschaften.
Ähnlich wie bei einem Objekt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net