Das Problem ist generell recht einfach erklärt, eventuell liegt das Problem auch im Design meiner Stuktur - kann sein.
Ich habe es folgendermaßen aufgebaut:
+ Steuerung (Kategorie)
+ Raum 1 (Kategorie)
+ Thermostat (Dummy)
+ Homematic Gerät A (Homematic Device, Hidden)
+ Homematic Variable A (mit Identifier versehen weil Variablenbezeichnung allein uneindeutig)
+ Link A von Variable Homematic Grät
+ Link B von Variable Skript A
+ Skripte (Kategorie, Hidden)
+ Skript A (Skript)
+ Variable zu Skript A (Variable mit Identifier)
Die Variablen zu Skript A werden automatisch angelegt wenn nicht vorhanden und mit einem Identifier versehen (lasse ich alle meine Skripte so machen).
Wenn ich alle meine Skripte die Variablen unter dem Parent $IPS_SELF anlegen lasse wäre das rein Logisch korrekt und bildet eine sinnvolle, schicke und geordnete Sache. Jedoch müsste ich dann, wenn ich diese Variablen angezeigt haben möchte, Links innerhalb des Visualisierten Bereich auf diese Variablen erzeugen. Wenn ich beispielsweise diese Links innerhalb des Skriptes sichtbar/unsichtbar schalten möchte, reicht es nicht den Ursprung zu verändern sondern ich muss an den Link direkt ran. Um an diesen Link zu kommen brauche ich zwingend einen Parent wenn ich nicht iterien will. Den Parent kenne ich aber garnicht, weil sich dieser bei jeder Person an anderer Stelle im Baum befinden kann (Stichwort: wartbarer und wiederverwendbarer Code).
Gleiches Problem bekomme ich, wenn ich von einem anderen Skript B die Variablen von Skript A auslesen/verändern möchte. Ich kenne den Parent (im dynamischen Kontext) nicht.
Identifier sind per Definition immer eineindeutig - ansonsten bräuchte ich keine Identifier, so wäre es auch wieder nur ein Name der in einem gewissen Kontext gültig und eindeutig ist. Bei IP-Symcon scheint es so, dass die Suche als Tiefensuche implementiert wurde und das die Identifier nur auf die Parentebene bezogen eindeutig sind - die Frage ist, was bringt der Identifier dann dann wenn ich den Parent nicht eineindeutig aus o.g. Gründen identifizieren kann ? Meiner Meinung nach nicht viel.
Ich müsste so immer ausgehend von der Kategorie „Skripte“ über dessen untergeordnete Objekte rekursiv iterieren bis ich die passenden Variablen finde. Und das gleiche von der obersten Kategorie wo ich die Objekte ablege die angezeigt werden sollen. Das sind Worst-Case Laufzeiten von O(2*(n^m))…
Der Hintergrund ist folgender:
Ich will meine Skripte so dynamisch wie möglich programmieren, ohne das ich irgendwo die statischen ID’s von Objekten hinterlegen muss - das ist einfach unschön und nicht wiederverwendbar. Schließlich sollen andere ebenfalls von den Skripten profitieren können ohne sich erstmal durch die Parameterisierung des Skripes wühlen zu müssen (jedenfalls was die Basisfunktionen erstellen, zugreifen von $Objekten betrifft).
Bin da gerne für Anregungen offen, möglicherweise liegt in meinem Design auch das Problem.
Bitte zeigt mir in dem Fall doch Möglichkeiten auf einen schnellen, wiederverwendbar dynamischen Code zu schreiben, ohne Iteration und ohne Parentgemurkse.
Ich bin im Moment leider davon überzeugt dass dies so garnicht möglich ist - und das wäre dann nicht so wirklich toll 
Bitte das Ganze jetzt nicht falsch verstehen, es soll keine Kritik an der Entwicklung des Systems sein, sondern Primär eine Verständnisfrage die eventuell Sekundär auch zur Verbesserung des Systems beitragen kann.
Ich würde mir einen immer gleichen sprechenden Identifier wünschen, der immer eindeutig ist, und mit dessen Hilfe man auf das Objekt einfach zugreifen kann. Den identifier kann man auch gerne nur über das Skripting setzen.
Man könnte auch quasi Minimalinversiv eine Methode bereitstellen, mit der man anhand eines Identifier das Objekt bekommt, sollten mehrere Objekte den gleichen Identifier haben, wird nur das erste zurückgegeben - oder ein Array von treffern, je nach Implementierungsaufwand. Wichtig ist die eliminierung des Parent Kontextes.
So eine Hilfsmethode habe ich mir programmiert, jedoch iteriere ich immer über alle Objekte im System um den Identifier zu finden…
Daniel
Auch davon sind hier einige dabei.