Will it be possible to edit IDs in the OH3 UI?

Setup, Configuration and Use Items & Sitemaps
Tags: #<Tag:0x00007f174f7e53c0>
#1

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.

#2

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.

#3

No, UID’s are not editable through the UI after creation. Only solution, like in openHAB 2, is editing directly in the db.

1 Like
#4

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.

#5

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.

#6

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?

#7

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.

#8

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 …

#9
#10

When manually creating a thing or approving it from inbox, the suggested UID can be overwritten…

#11

When manually creating a thing or approving it from inbox, the suggested UID can be overwritten…

I don’t see how? Below is what I see when adding from the Inbox, as well as from the discovered items if I look at the hue binding only.

Screenshot 2020-11-10 at 11.56.56

And of course once this has been added, the UID isn’t editable in the Things UI:

Screenshot 2020-11-10 at 11.58.29
Screenshot 2020-11-10 at 11.58.291030×329 15.5 KB

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?

#12

You are right, when adding from inbox, the uid field is missing. This was definitely possible in PaperUI at openHAB 2.x

@ysc, is it possible to add this missing feature to MainUI ?

1 Like
#13

I very much doubt it, since the API doesn’t allow it. @Lolodomo has proposed to change that, the issue is posted above.

#14

Adding a Thing, or rather a Bridge, in PaperUI

Click (+) to add
thinguid-1

Pick a binding
thinguid-2

Pick an offered Thing type - in this case, a Bridge type
thinguid-3

Get offered to configure it, note auto generated UID fragment
thinguid-4

But you can type a meaningful replacement over that, before saving.
thinguid-5

And we can make sure it really did create a Thing with that UID
thinguid-6

#15

Indeed, my bad, adding manually allows to set the id, but not while approving from inbox.
Sorry for bothering @ysc.

#16

@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.

1 Like
#17

No, that is the reverse, the representation property allows using any thing ID you want.

#18

Upps, sorry for my misunderstanding

#19

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

#20

Any news on this topic?