Conversation
|
I intentionally didn't do this because the user can freely change light names For example, if a user has Light1 it will default to the name "Hue color lamp 1" so the first ID under this change would be "Light1_Hue color lamp 1". Next, they set up this object to be part of their local system. Then, in the Hue App they want a better human readable name for where the light is so they rename it "Kitchen Light". Now the old object "Light1_Hue color lamp 1" is an orphaned object without any corresponding real nodes and there's a completely new object they have to set up again |
|
Makes sense. I would like to investigate this a bit more, because we do have the ability to rename nodes. What is happening is that once you create a node, it is always referenced by its initial ID and you can change the name to what ever you want on the go. I think we should do the same thing for objects. You initialize an object with the first name and from there you reference it by its ID. The only problem we have here is that we use the name for the folder as well. This way you could give the hue lights a UUID that is always linked to the folder however you can name the object to what ever it needs to be named. One could argue that it's then hard to find the folder where the object is saved, but I think we can solve that with a smart UI feature as well. Anyhow, the name / folder decoupling needs to happen before this can go live. |
|
... But I will give this a bit more time. I don't think its critical and the solution you found works very well. There are more timely things to do at the moment. |
Some idea for using the name of the lights also for the object name.
Its in the format:
<id>_<name>and
<id>_<name>_tool