vorschlag: eindeutige id für jedes fhem device

[justme1968]

für manche anwendungen ist es wichtig fhem device eindeutig zu identifizieren. auch nach einem neustart oder nach einem rename.

da nicht alle devices mit tatsächlich vorhandener hardware verknüpft sind kann man nicht auf eine eventuell vorhandene hardware id ausweichen.

ein typischer anwendungsfall: diverse sprach apis lassen sich über eine suche solche eindeutigen ids melden und verwenden diese dann in den events die erzeugt werden. diese ids müssen stabil bleiben auch wenn devices umbenannt werden und sollten keine konflikte erzeugen wenn man ein neues device mit gleichem namen anlegt.


mit dem angehängten patch wird jedem fhem device beim define eine stabile id zugewiesen.

die genauen eigenschaften sind:

• konstant auch nach restart und rename
• eindeutig genug im auch bei mehreren lokalen installationen sehr sehr sehr wahrscheinlich keine konflikte zu haben
• nur mit dieser einen id lässt sich kein bestimmte fhem installation identifizieren. d.h. nicht basierend auf uniqueid, mac, ip, ...
• mit der id eines devices lässt sich rückschluss auf das global device einer fhem installation treffen
• es lässt sich erkennen das mehrere devices vermutlich aus der gleichen fhem installation kommen

ein offener punkt:
das wiederherstellen der FUID nach einem neustart geschieht aktuell mit perl code im save file. das ist unschön. ich wollte aber auch keine globales setfuid kommando da die id nicht vom anwender verändert werden soll. hat jemand eine bessere idee?

[rudolfkoenig]

Spricht was gegen:
- einem Reading?
- einen "richtigen" UUID (Format XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX)?

[Thorsten Pferdekaemper]

Hi,
ich finde den Vorschlag prinzipiell gut.

Spricht was gegen:
- einem Reading?

Das müsste meiner Meinung nach dann aber vor "setreading" geschützt sein und vielleicht sogar unsichtbar in FHEMWEB.

- einen "richtigen" UUID (Format XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX)?

Das fände ich auch besser als die vorgeschlagene Implementierung. UUIDs bringen ja alle Anforderungen schon mit.
Gruß,
   Thorsten

[justme1968]

ja. ein reading ist nicht vor setreading geschützt.

wenn man es mit . versteckt ist es bei jsonlist2 nicht sichtbar.

copy kopiert alle readings. man bräuchte eine ausnahme.

es gibt devices die ein clear readings kommando haben.

außerdem ist es konzeptionell eher etwas internes und nichts das dem device gehört.


das format ist mir im prinzip egal.
wenn man einfach nur eine zufällig uuid erzeugt fehlt der zusammenhang zwischen den devices.

wenn man das berücksichtigt ist es kein problem.

[rudolfkoenig]

Alternative:
define/defmod kriegen eine Option --uuid <uuid>, und save erzeugt diese Option.
define mit --uuid uebernimmt es in einem Internal, ohne generiert eine Neue.

[justme1968]

ich glaube eine option ist nicht gut.

der user soll garnichts damit zu tun haben und er soll auch nicht aus versehen ‚mist‘ machen.

[Thorsten Pferdekaemper]

Hi,
es sieht so aus, als ob das "reading"-Konzept einiges an Aufwand nach sich ziehen würde.

wenn man einfach nur eine zufällig uuid erzeugt fehlt der zusammenhang zwischen den devices.

Meiner Meinung nach sollte man das trennen. Eine "eindeutige Id" sollte nichts weiter sein als eine eindeutige Id. Wenn man noch andere Eigenschaften oder Beziehungen braucht, dann sollte man die getrennt modellieren.
Oder verstehe ich da was falsch? Was genau meinst Du denn damit?

define/defmod kriegen eine Option --uuid <uuid>, und save erzeugt diese Option.
define mit --uuid uebernimmt es in einem Internal, ohne generiert eine Neue.

Theoretisch ist das gut, aber praktisch sehe ich jetzt schon 10 neue Threads pro "fhem.cfg-Editierer". Außerdem wird es bestimmt einige geben, die meinen, sie könnten das für irgendwas benutzen und dann prinzipell beim define direkt diese Option benutzen.
Anders gesagt: Meiner Meinung nach ist es zu einfach, damit Blödsinn zu machen.

Das Ding als Internal in die fhem.save zu packen finde ich gar nicht so schlecht. Was spricht denn dagegen?
Gruß,
   Thorsten

[rudolfkoenig]

Die Loesung mit {} in fhem.cfg passt mir nicht, die Argumente von Thorsten bei der Option gelten damit nur verstaerkt.

Ich biete an:
- define mit Option
- reading (mit Ausnahmeregelungen fuer copy  und deletereading)
- neu: extra Datei, nur mit UUID.

[justme1968]

@thorsten: eindeutige ids können (und sollen unter umständen) auch teile enthalten die für zusammengehörige devices (z.b. aus der gleichen FHEM installation) identische teile enthalten. z.b uuids die auf einem bestimmen namensraum basieren. d.h. alle uuids aus einer fhem installation haben z.b. den gleichen prefix. oder innen einen gleichen teil.

@ruid: dass {} war nur ein workaround um zu schauen ob alles geht.

wie wäre es einfach mit einem setuid kommando das analog zu setreading im save file verwendet wird.

kann man das bei help ausblenden?

reading ist glaube ich wirklich nicht gut.

[justme1968]

als format könnte man z.b. so etwas verwenden:

tttttttt-ffff-iiii-ddddddddddddddddd

t -> zeitstempel wir rfc
ffff -> egal aber immer und bei alle fhem installationen gleich -> dies ist eine fhem device id
iiii -> egal aber in jeder installation für alle device ids identisch
dddd -> für jedes device zufällig

[Thorsten Pferdekaemper]

ffff -> egal aber immer und bei alle fhem installationen gleich -> dies ist eine fhem device id

Was soll dann passieren, wenn man eine fhem-Installation auf einen anderen Rechner umzieht? Neue fhem-Id oder die alte belassen? Was soll passieren, wenn man zwei Installationen zusammenfasst oder eine in zwei aufteilt?
...solche Sachen meine ich, wenn ich sage, dass eine eindeutige Id nicht noch anderen Kram haben sollte.
Gruß,
   Thorsten

[justme1968]

wenn man beim umziehen das save file mit nimmt behalten alle devices ihre id

wenn man es nicht mit nimmt werden neue ids erzeugt.

das ist nicht anders wie das mit ebnen der unique id

ich sehe kein problem.

[zap]

Ich könnte mir folgende Attribute in einer UUID vorstellen:

- Zeitstempel UTC der ersten Erstellung eines Device
- Eindeutige ID für das verwendete Modul
- Zusätzliche Attribute aus einem Device, z.B. eine Serial oder Adresse, sofern vorhanden.

Leider sind wir noch sehr weit davon entfernt, dass jedes Gerät eine IPv6 Adresse hat. Sonst wäre die für mich ein heißer Kandidat, zumindest für einen Teil der UUID.

[justme1968]

den aktuellen device zustand sollte man nicht mit rein packen.


wir haben je gerade keine hardware bei dummys und co. deshalb brauchen wir etwas das nicht hardware basiert ist.

aber das format ist mit eigentlich ganz egal. so lange es kein reading wird

[herrmannj]

viele device sind doch überhaupt keine Netzwerk-device -> sowieso keine ip.

Für uuid gibt es doch genügend Standards. Ansonsten schlage ich einen Hash (sha) , gebildet über fhem unique ID + (ursprünglicher) device Name vor. Das ist immer einzigartig. Wenn das device "umzieht" zieht der Hash halt mit um. Gespeichert werden kann der in der fhem cfg, analog der def.