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
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 …
When manually creating a thing or approving it from inbox, the suggested UID can be overwritten…
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.
And of course once this has been added, the UID isn’t editable in the Things UI:
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?
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
I very much doubt it, since the API doesn’t allow it. @Lolodomo has proposed to change that, the issue is posted above.
Adding a Thing, or rather a Bridge, in PaperUI
Click (+) to add
Pick a binding
Pick an offered Thing type - in this case, a Bridge type
Get offered to configure it, note auto generated UID fragment
But you can type a meaningful replacement over that, before saving.
And we can make sure it really did create a Thing with that UID
Indeed, my bad, adding manually allows to set the id, but not while approving from inbox.
Sorry for bothering @ysc.
@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
No, that is the reverse, the representation property allows using any thing ID you want.
Upps, sorry for my misunderstanding
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
Any news on this topic?
I know it might be hard work accessing and changing DB directly.
But if it is possible I would appreciate to give us a totorial how to do (on own risk).
The other way (I played a lot with OH3 for now) is how to create a backup und reverse.
Might these backupfiles humam readable? If so is there a chance to manipulate the IDs there before restore?
I think that it happens many time that people who are new just creatings things, stashing their hw-devices in the wall and want to clean up their setup after (might) have understood most of the basics.
Especially that it is the ID(-string) you select an Item during Scripting. In my cas ‘ZWaveNode015FGS213SingleSwitch2_Switch1’
See OH 3 Tips and Tricks, scroll down to the “Editing the JSONDB, a last resort” section.
The JSON DB is where all the stuff you’ve created in the UI gets stored. They are text files in JSON format.