While OH gives the option to add a new Thing from Inbox with custom ID, if doing so, the Thing will remain in the Inbox with the system generated UID. By itself this is just annoying in the sense that you have to set Ignore for that certain Thing, and I understand you cannot do this in other way.
BUT, my question is: giving a custom UID to the Thing, is having any advantage whatsoever other than, I presume, if the hardware became faulty and need to be replaced, you will have the possibility to give the same UID for the new hardware too.
In other words, the UID has only the role of unique identification of Things or it has impact on, Channels, Items and Rules? If the first, than I presume it doesn’t have any relevance the UID in the OH environment (mainly Rules and Scritps), but the Label.
Alright, but apart of this, as a general approach, it has sense to „bother” naming UID yourself in order to avoid the automation rules/scripts malfunction in the event of a hardware replacement (by adding the new hardware with the same UID as the broken one)?
Most rules should usually not be dependent on the thing UID so I don’t sees big issue there.
However the channel links to items is something to consider. I never took the effort to create custom uids. When e.g. a Shelly device dies (has only happened to me twice I guess) I add the new device and have to link the channels back to the old items. This would be easier if I had custom uids. But then this does not happen very often. I would guess that the effort of giving custom ids (that ideally I can remember) would probably be in balance with the effort of replacing a device every couple of years. But of course this might not be representative for other installations/setup.
It has inpact in that when you supply your own ID that ID is usually much more meaningful when you see errors in the logs, links to Channels, Channel event triggers, etc.
Yes.
The Thing ID is included in the Channel ID so the Thing ID does have impact on Channel triggers to rule. It’s also used when invoking a Thing Action and therefore has impact there as well. Creating a new replacement Thing with a new ID will require those to be changed. And for human maintainability a meaningful UID is better than a randome one.
You don’t necessarily need custom uids for this. If you save off the uid of the old broken Thing, remove it, and then add the new one using the old uid all your Links and such would continue to work unmodified.
I think having meaningful logs, error messages, and easy tracability is well worth the effort of using meaningful uids for everything. Why add that extra step to have to map “cf985c10b8” to “the smart plug in the living room near the door”?
If the Things are still in the Inbox after adding them using a custom ID, that’s a bug that needs to be fixed, not a reason for or against supplying your own uids when creating the Thing.
The impact is probably bigger that I thought (forgot about the thing actions for example) especially when you use these features a lot. For me the problem always was to memorise my own naming conventions (e.g. was it kitchenlight or kitchenlamp or lightingkitchen?) So I had to look it up anyway and decided to give up upon naming conventions for things at some point. But if you are able to keep this consistent while your installation evolves I agree that this has quite a few advantages.
The Developer Sidebar is great for this and it works even better if you use meaningful UIDs because the search looks at uids as well as names, labels, etc. So you could bring up the sidebar (alt-shift-d) search for “kitchen” and your Thing will show up. You can pin it and anything else you need that you are working with and then there’s a nice “copy” icon to get the ID on the clipboard.
Yes it’s definitely a game changer. Even without meaningful thing uids just with my thing labels as well as item names and labels it helps a lot to develop new rules
Even if you had to look it up when writing the code, but when you’re later on reading the code, it would make more sense without even resorting to adding comments.
And besides, the issue of inconsistent naming convention is a separate issue, and not the problem of “having a human-friendly uid”
. Now it is clear!