Best Practice: FUUID vs. IODev

[jw2013]

Ich hätte eine generelle Frage zu FHEM Modulen, welche über ein gemeinsames Gateway-Modul laufen, so wie bei Homematic-Wired oder Modbus-RTU.

In dem Modul für Homematic-Wired findet die Verknüpfung von Gerät zu Gateway über IODev statt, die Verknüpfung von Kanal zu Gerät hingegen über den Namen. Bei den Modbus-RTU Modulen findet die Verknüpfung ebenfalls über IODev statt.

Dann wurde irgendwann FUUID eingeführt. Sollten neue Module derartige Verknüpfungen bevorzugt über FUUIDs implementieren, oder bleibt das Attribut 'IODev' Mittel der Wahl?

Leider finde ich dazu weder im Wiki noch im Forum eine Antwort.
Die Frage gehört evtl. eher in das "FHEM Development" Board, ich darf dort aber nicht posten.

[betateilchen]

Die FUUID wurde meines Wissens nach nicht für den von Dir skizzierten Zweck eingeführt.
Dafür ist die FUUID einfach auch nicht robust genug.

Verknüpfungen zwischen Geräten und Gateways sollten immer über IODev hergestellt werden, dafür stellt FHEM intern auch geeignete Funktionen bereit, die zuverlässig arbeiten und z.B. auch Reihenfolgeprobleme bei der Zuordnung lösen.

[jw2013]

Danke, genau das wollte ich wissen!

Dafür ist die FUUID einfach auch nicht robust genug.

Was genau ist mit "nicht robust genug" gemeint? Kann sich die FUUID ändern oder verloren gehen?

[betateilchen]

Kann sich die FUUID ändern oder verloren gehen?

Natürlich, da kann man reinschreiben, was man will:

Code Auswählen Erweitern

Internals:
   FUUID      heute_ist_ein_schoener_tag
   NAME       d1
   NR         90
   STATE      ???
   TYPE       dummy
Attributes:

Dafür gibt es sogar einen Befehl:

Code Auswählen Erweitern

{$init_done = 0;; fhem('setuuid d1 blub')}

Ergebnis:

Code Auswählen Erweitern

Internals:
   FUUID      blub
   NAME       d1
   NR         90
   STATE      ???
   TYPE       dummy
Attributes:


[jw2013]

Hab verstanden:

FUUID nicht als interne Referenz auf andere Geräte oder Gateways verwenden, sondern nur als anonymisierte ID zur Erfüllung externer {Verknüpfungs|Tracking}-Anforderungen.

Quasi die /etc/machine-id von FHEM Defs

[Wernieman]

Ist es nicht eher, damit die FUUID gleich bleibt, wenn der Name sich ändert? Also wenigstens "eine" feste Größe zu haben?

[betateilchen]

Es ist wie bei einer ganzen Reihe anderer "Relikte" in FHEM:

An sich war es vor (ziemlich genau fünf Jahren) eine gute und fortschrittliche Idee, aber halbherzig umgesetzt, unzuverlässig und deshalb nicht wirklich sinnvoll nutzbar.

Wer sich für die Geschichte interessiert:
https://forum.fhem.de/index.php?topic=95902.0

[jw2013]

Ich warte dann mal noch mit dem Umschreiben meiner Module...

(Da steh' ich nun, ich armer Tor...)

Hintergrund der Frage:
Ich hatte vor längerer Zeit ein Framework für verdrahtete Messeinrichtungen geschrieben, und mich vom Aufbau an dem für Modbus orientiert. Also IODdev Attribut verweist auf das M-BUS Gateway, und irgendwie passt das so auch ganz gut.

Später kamen dann noch Module für verschiedene Wiegand-Controller (RFID/PIN Türsteuerung) dazu. Weil ich zwischenzeitlich über die Existenz von FUUIDs erfahren hatte, sind die dort notwendigen Objekte (Türen, Berechtigungen, Alarme etc.) über ebendiese mit dem Controller-Gerät verknüpft, statt über IODev.

Schaut dann z.B. so aus:

defmod DoorControlRoom AOPU_AccessController 649ca73a-f33f-62d6-ea28-df6af68686df288e door 2

'AOPU_AccessController' wäre der Modul-Name, '649ca73a-f33f-62d6-ea28-df6af68686df288e' die FUUID vom eigentlichen Controller, 'door' die Entity-Klasse, und '2' der Index der Tür im Controller.

Das sind also im eigentlichen Sinne keine weiteren Geräte an einem Gateway, sondern Kanäle(?) des Controllers selbst. Also ähnlich den Kanälen bei den Homematic-Wired Geräten.

Bevor ich jetzt weiteren Code schreibe und freigebe, würde ich gerne alles auf einen sauberen Stand bringen.

[jw2013]

An sich war es vor (ziemlich genau fünf Jahren) eine gute und fortschrittliche Idee, aber halbherzig umgesetzt, unzuverlässig und deshalb nicht wirklich sinnvoll nutzbar.

Wer sich für die Geschichte interessiert:
https://forum.fhem.de/index.php?topic=95902.0

Den Beitrag hatte ich damals schon gelesen, für eine gute Idee gehalten, und angefangen, FUUIDs zu verwenden.
Sehe aber auch, dass die Verwendung in 'offiziellen' Modulen recht mager ausfällt...

Warum schreibst Du, die wären unzuverlässig und deshalb nicht wirklich sinnvoll nutzbar? Gehts es nur um die von Dir gezeigte Änderungsmöglichkeit über setuuid, oder gibt es weitere Probleme, bzw. Pläne FUUIDs wieder zu entfernen?

Ist es nicht eher, damit die FUUID gleich bleibt, wenn der Name sich ändert? Also wenigstens "eine" feste Größe zu haben?

Genau sowas hatte ich auch erhofft. Um beim Beispiel der Zugriffs-Verwaltung zu bleiben: Beim dem Wiegand-Controller können z.B. 30000 Benutzer (RFIDs) angelegt werden, die werden in FHEM als einzelne Defs geführt.
Bei jedem Rename vom Controller-Objekt müssten dann alle assoziierten Objekte geupdated werden (z.B. Update auf IODev Attribut). Bei der Verwendung von FUUIDs hingegen betrifft es die assoziierten Objekte erstmal nicht.

Andere Überlegung, anhand von Datenbank-Tabellen:
Meistens beginnt man ja mit "int AUTOINCREMENT" etc. als Primärschlüssel.
Je nach Anwendung ersetzt man das "int" aber gegen eine UUID, da besser für DB-Cluster und DB-Sharding, nicht fortlaufend, sinnvoll für Datenschutz etc.

Die Daten in den restlichen Spalten jeder Zeile können jederzeit geändert werden, der Primärschlüssel bleibt (idR) fix.

Selbst wenn es Spalten gibt (z.B. email_address), welche als UNIQUE deklariert sind, würde man für Referenzen immer ein anderes Feld als Primary Key bevorzugen, sofern vorgesehen ist, dass sich die Daten in der UNIQUE deklarierten Spalten ändern können.

Macht das für Euch Sinn, was ich schreibe?

[M.Schulze]

Natürlich, da kann man reinschreiben, was man will:

Das wurde so nie kommuniziert. Welches Modul überschreibt denn aktuell die  FUUID mit einer UID der Hardware?

MfG

[betateilchen]

Das wurde so nie kommuniziert.

Vermutlich verwechselt hier gerade jemand "können" (im Sinne von 'es besteht die Möglichkeit') mit "sollen" oder "dürfen".

Welches Modul überschreibt denn aktuell die  FUUID mit einer UID der Hardware?

Keines. Das wäre auch überhaupt nicht sinnvoll.
Entwickler und Module sind hier aber gar nicht das Thema.

Aber Du glaubst gar nicht, auf welche Ideen die Anwender kommen. Da gibt es tatsächlich welche, die nach jedem "save" die gespeicherten FUUID aus ihrem Konfigurationsfile per "sed" rausschmeißen. Warum auch immer. Diesbezüglich habe ich schon sehr viel Elend gesehen.

[jw2013]

Ja, es gibt halt sehr spezielle Anwendungsfälle   

@betateilchen, solange ich als Entwickler oder Anwender kein 'sed' oder anderes Elend auf die FUUIDs loslasse, kann ich aber davon ausgehen, dass die dauerhaft erhalten bleiben, und die insbesondere nicht 'deprecated' sind?

[betateilchen]

deprecated sind die nicht.

Aber Du kannst als Entwickler halt nicht wissen, was die Anwender sich alles einfallen lassen.
Grundsätzlich ist die FUUID dafür konzipiert, dauerhaft erhalten zu bleiben, es ist aber durch nichts sichergestellt.