When adding things through the UI, I end up with IDs like hue:bridge:0011234c6789 for my one bridge, which I’d rather call hue:bridge or hue:bridge:1 as per the plain files [examples](https://www.openhab.org/addons/bindings/hue/#thing-configuration. While I don’t need to do much wityh the bridge except when I need to figure out scenes through the openHAB console (which is where having an easy to remember name would be great), I do want to be able to trigger rules based on channel events and am stuck with names like hue:0830:0011234c6789:7:tap_switch for my channels, which makes writing rules tough, with lots of looking up in the UI (and a UI that only lets you select these names in few of the places where they’re displayed).
In the meantime, I could rename those in userdata/jsondb/ but it seems a bit delicate. Am I right in thinking that I would need to both rename, say hue:bridge:0011234c6789 and hue:0830:0011234c6789:7:tap_switch to something like hue:bridge:1 and hue:living_room:tap_switch but also find every UID that refer to those (as arrays of the strings in between the : delimiter) and change them too? That makes it very error prone and being able to change in the UI would be huge then. (I have the same desire to be able to rename things and items after creation, too…). I am also not sure about what, if anything, I should do about the discovery file if I renamed things.
I‘m pretty sure you have to edit the UID when it‘s created. As far as I tried (did only play a little bit with OH3 so far), it should be possible to change it through the yaml configuration.
They definitely aren’t right now. I guess I am asking if this could be considered? The same is true for names which cannot be edited even though it would be simple to do that in code by the UI, and much, much less error prone. For UIDs, the fact that they are represented with two formats in the DB makes them even more delicate for a user to edit.
We had this discussion before and came to the conclusion that renaming of UIDs is not going to be implemented, as it would be to complicated.
Just for example, changing a UID means changes to all channelIDs and all linked items.
So better pay attention when creating a thing, to get the UID right.
I agree, all these links make it even more complicated, especially by hand.
So could we get a chance to pick both UIDs and names when they get created in the UI? My issue here is that those have been chosen by bindings during discovery without me having any say. Maybe a good time to do this would be when one gets a Thing out of the Inbox?
I believe you have the option to set the UID for Things when manually creating them. After that point you cannot change them short of doing it manually by editing the database directly. I think this mainly becomes a problem for discovered bridge Things though. Non-bridge Things get their UID from the bridge UID so if you choose a reasonable ID for the bridge Thing, the Things under that bridge will also have reasonable IDs.
I don’t know where the UID comes from that is chosen for Bridge Things that are discovered. Understanding that will tell you which repo the issue needs to be filed on to request the ability to change the Thing UID when accepting it from the inbox.
One final thing worth noting is that when creating rule triggers using MainUI instead of in text files, the label is used instead of the raw Thing UID so in that case at least you never actually have to deal with the randomly created UID.
and rules, in the various rules systems that may listen to or manipulate Things.
And still someone would grizzle because they are using an external script with REST API and why didn’t it redirect the query to the new UID …
I wasn’t willing to risk deleting my bridge and losing my config to try with the bridge… I am willing to try, I guess I can just backup userdata/jsondb?
@Frenchman
After thinking a bit more about this I remembered a change introduced in openHAB3 regarding auto discovery.
Bindings now have to create the discovery result with a unique “represantation” identifier (serial number, UDN, etc…). This was not mandatory in openHAB 2.
Not using the representation identifier in the UID could cause some strage effects.
One might create a Thing with a custom ID and openHAB will not recon that the same Thing exists in the inbox.
So it is no good Idea to change the UID for auto discovered Things.
This change would be very useful in my case because the automatically discovered subdevices have a very long UID (and textual definition is not supported). What is the status of this modification? I’ve seen that some github issues were addressed but there are still some problems with the main UI: is there some fundamental problem that cannot be solved so that we should live with the automatically assigned ID?
Thank you for your attention
