vorschlag: eindeutige id für jedes fhem device

[justme1968]

achso: automatische daten aus dem device wenn möglich.

ja. im prinzip schon.

aber: das was ich oben vorgeschlagen habe ist erst mal komplett unabhängig und geht führ jedes device.

im prinzip steht es einem device frei die von fhem vergebene id nachträglich teilweise zu ändern wenn es tatsächlich eine hardware id gibt.

man darf diese aber nicht 1:1 übernehmen. dann hätten zwei devices in zwei fhem installationen die die gleiche hardware steuern die gleiche fhem id. das soll nicht passieren.

[justme1968]

ich mache einen neuen patch vorschlag mit uuid format und setfuid.

ps: die if sollte im save file stehen. nicht im config file.  sonst ist das risiko sie aus versehen zu kopieren zu groß.

[rudolfkoenig]

ich mache einen neuen patch vorschlag mit uuid format und setfuid.

Nicht noetig, so kompliziert ist die Sache nicht. Wird aber bis morgen dauern.
Wir bleiben bei UUID nach dem vorgeschlagenen Muster (t,f,i,d), und setuuid Befehl, was explizit in fhem.cfg gespeichert wird.

[justme1968]

und ablage in internal

[justme1968]

bitte ins save file. nicht cfc. grund siehe oben

[Loredo]

Bei der Anbindung von 3rd Party Bridges (also z.B. Homematic), die ihre Geräte selbst eindeutig identifizieren, wäre es vielleicht doch auch ganz gut diese ID zu übernehmen statt eine neue UUID zu generieren?

[justme1968]

nein. weil du damit unter umständen zwei fhem devices mit der gleichen id bekommst. die fhem devices sollen aber eindeutig sein.

außerdem soll der code in fhem generell arbeiten und keine änderung an modulen erfordern.

[Loredo]

Hm, vielleicht geht dann eine Alias-Funktion o.ä.?
Es wäre ja schon sexy, wenn man auch über mehrere Gateways hinweg zumindest irgendeine einmalige ID hätte.

[betateilchen]

Denkt bitte daran, dass es neben fhem.cfg auch noch die configDB gibt.
Und das meiste, was bisher hier im Thread an Ideen geäußert wurde, würde mit der configDB nicht funktionieren.

[betateilchen]

Für uuid gibt es doch genügend Standards. Ansonsten schlage ich einen Hash (sha) ,

FHEM selbst ist schon lange in der Lage, uuid zu erzeugen.

Code Auswählen Erweitern

sub createUniqueId()

[justme1968]

der ansatz mit setfuid im state file sollte mit configDB problemlos gehen. du musst nur die eine zeile aus WriteStatefile entsprechend übernehmen cfgDB_SaveState. oder übersehe ich etwas ?

createUniqueId() erzeugt keine uuid im rfc format. das wollten die herren aber

[betateilchen]

Eigentlich will ich nur vermeiden, dass Rudi mit einem spontan Schnellschuss einmal mehr Inkompatibilitäten und Probleme verursacht.

Wenn ich sowas lese

Nicht noetig, so kompliziert ist die Sache nicht. Wird aber bis morgen dauern.

gehen hier schon die roten Alarmleuchten an. Wir können sowas gerne gemeinsam so implementieren, dass es in beiden "Konfigurationswelten" funktioniert. Aber wir sollten das dann auch in Abstimmung und möglichst zeitgleich tun. Diese Woche komme ich definitiv nicht mehr dazu.

[betateilchen]

oder übersehe ich etwas ?

Du übersiehst zumindest, dass es durchaus FHEM Installationen gibt, in denen kein statefile verwendet wird.

[betateilchen]

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

Wenn ein reading einen festgelegten Namen hat, wäre es überhaupt kein Problem, dieses reading vor einem Überschreiben/Ändern durch setreading zu schützen.

[justme1968]

das wäre aber eine sonderlocke. wenn die id in einem reading steckt sind an allen möglichen stellen sonderbehandlungen nötig (setreading, copy, clear readings...), man muss bei kopieren aufpassen und das prinzip das die readings dem device gehören wird verletzt.

in einem internal ist nirgends sonderbehandlung nötig sogar copy geht komplett automatisch inklusive einer neuen id. die internals gehören auch mindestens zum teil zum system.

ein fhem system ohne state speicher (egal ob file oder db) hält auch keine readings über den start hinweg. d.h. da gehen auch einige andere dinge nicht.