Ordnerstruktur änderbar ohne ID zu ändern

[ldittmar81]

Ein der Gründe ein Alias zu erzeugen, ist dass die ID immer gleich bleibt, auch wenn das Gerät sich ändert. Leider lässt diese Tatsache auch nicht zu, dass man die Datenstruktur unterhalb von Alias ändert, denn diese ist ja Teil der ID.

Es wäre cool, wenn man die Struktur ändern könnte, aber ohne die ID zu ändern. Dazu würde im DP noch ein Feld "folder" hinzugefügt, der dazu dient den aktuellen Ordner für die Anzeige zu ermitteln. Bsp.: Die ID ist "alias.0.Licht.Küche.SET" im folder könnte aber stehen Licht.Erdgeschoss.Küche das heisst, dass der DP mit der ID alias.0.Licht.Küche.SET im Ordner Licht.Erdgeschoss.Küche sichtbar wäre.

[Diginix]

Das ist keine schlechte Idee nur die ObjektID selbst eindeutig zu haben, nicht aber ihren Pfad der Ablage mit im Skript zu benötigen. Jedes Objekt erhält eine UID und nur diese wird im Skript verwendet ohne Strukturinformationen. Das Objekt kann so unterhalb von alias.0 oder 0_userdata.0 liegen wo es will.
So könnte man später umsortieren usw. ohne Skripte nochmal anfassen zu müssen.
Unter alias.0 müsste man ansonsten komplett auf eine Struktur verzichten und tatsächlich für jedes 0_userdata Objekt welches man ggf. mal verschiebt ein alias Objekt erstellen. Deswegen fände ich das für 0_userdata fast wichtiger. Denn dort dient die Struktur dem Überblick. In alias.0 könnte eine flache Hierarchie funktionieren.

[Apollon77]

Und der "Name" des Objekts kann das nicht schon abbilden?

[ldittmar81]

Leider nicht. Es geht um die gesamte Ordnerstruktur. Wenn die mal steht, dann können Datenpunkte nicht mehr bewegt werden. Das ist aber nur für die Ordnungsfanatiker wichtig.
Beispiel: Ich habe normale Lichter und RGBS alle zusammen unter Haus.Lichter ... wenn es irgendwann doch zuviele werden, möchte ich vielleicht diese unterteilen in Haus.Lichter.Normal und Haus.Lichter.RGB .... dann fällt mir ein, dass RGB nicht die richtige Bezeichnung wäre, und ich hätte lieber Haus.Lichter.Deko_Beleuchtung .... das ist das Problem.

Also... die ID sollte nicht von der Ordnerstruktur abhängig sein. Das wäre echt mega toll!! Man könnte die Objekte hin und her bewegen und alle Verknüpfungen würden trotzdem passen. Das einzige was bleiben sollte ist die Instanz.. also alias.0 oder 0_userdata.0 ... darunter aber sollten die IDs Strukturunabhängig sein. Dann wäre z.B. alias.0.jdfhjh8787897394jhh364783 auch eine mögliche ID, die dann durch Name und Folder erkannt werden würde

[AlCalzone]

Ist das nicht noch verwirrender, wenn man aus der Struktur nicht mehr die ID des Objekts ablesen kann, um sie z.B. in Skripten zu verwenden?

[ldittmar81]

Jain... Beim Blockly wird automatisch den Namen des Objektes angezeigt. Da ist die ID also egal... Beim Skripten hat man diesen Komfort nicht. Hmm... Man könnte den Skript Adapter so anpassen, dass es beim Mausover den Namen der ID zeigt... Außerdem wäre es durch möglich als selector [adapter].[instanz].[folder].[name] einzugeben. Also: ID = alias.0.sfhjksfkhsjdhfkjhfskd als Selector für die Skript-Programmierung "alias.0.haus.party.Wand Beleuchtung" ....Hmm... Theoretisch könnte man die aktuelle Version so lassen und ein neues Feld UID hinzufügen. Dann wäre die ID änderbar, aber das Objekt hätte noch eine nicht änderbare ID, die IMMER gültig ist.

[paul53]

Beim Skripten hat man den Komfort sehr wohl, wenn man die ID per Select-ID einfügt: Als Kommentar hinter der ID. Wenn über den Namen zugegriffen werden soll, kann man es mittels getIdByName(name) machen, was allerdings eindeutige Namen voraussetzt.

[ldittmar81]

Beim Skripten hat man den Komfort sehr wohl, wenn man die ID per Select-ID einfügt: Als Kommentar hinter der ID.
Der Kommentar wird aber nicht aktualisiert, wenn der Name des Objektes sich ändert...

Hmm... damit die Kompatibilität zum alten bleibt, könnte man doch wirklich ein neuen Feld UID hinzufügen und dafür die eigentliche ID bearbeitbar machen, oder? Würde was dagegen sprechen? Wenn es dann soweit wäre, würde die neue Version des JS-Controllers zu jedem Objekt eine UID hinzufügen bestehend aus adapter.instanz.UID ... also alias.0.njf8778r4n3fn3hqhq. Diese würde sich nie wieder ändern und man könnte dann die normale ID weiterhin so nutzen, nur dass man es dann auch ändern kann. Alle Skripte die auf diese UID aufgebaut werden, würden dann immer funktionieren.

[AlCalzone]

Kompatibilität

Das wäre einer der tiefsten Eingriffe in die Objektstruktur von ioBroker schlechthin. Die derzeitige ID ist die UID.

Sinnvoller finde ich da eher den Vorschlag aus deinem OP, ein weiteres Feld bei der Anzeige im Admin hinzuzuziehen. Verwirrend fände ich es aber trotzdem, wenn dieses Feld z.B. von Adaptern automatisch gesetzt wird, ohne dass man das als User sieht oder optisch eindeutig erkennen kann.

[ldittmar81]

Klar... ein Feld "folder", der nur für die Ansicht zuständig ist, ist die "einfache" Variante. Das Feld müsste dann nicht zwingend da sein und nur beim Verschieben von Objekten würde es rein kommen. Ist zwar auch viel Arbeit, aber nicht so kritisch...

Es gibt da aber ein Problem... nehmen wir an man macht ein DP mit de ID SET im Ordner xy... dann wird SET nach zz verschoben. DIe ID zeigt aber immer noch auf xy... man könnte kein neuen SET in xy erstellen. In zz ist nur das verschobene SET und man könnte theorotisch noch ein SET da rein machen. die ID wäre dann aber zz.SET und das verschobene xy.SET ... Hmm... strange