I got it, way back when, but most do not. And no… I don’t have a better idea then Thing
Add-On and binding is my pet peeve. The two names for the same thing are freely interchanged on this forum and in the documentation but noobs don’t know that!
I think we should all endeavor to say Add-On when we mean binding. Add-On means something that is (sort of) meaningful. Binding sounds like something that holds your under britches up 
Binding is a subset of add-on
There’s Binding Addon, Automation Addon, Transformation addon, UI Addon, etc. So Binding and Addon aren’t equivalent.
Maybe
Add-ons → Extensions (like the term they use in Browsers)
Binding → Adapter ?
I said the same thing to a few of my colleagues too; slight the other way around: I use OH and its the best thing since, sliced bread; highly configurable and sh!toads of integrations, which you need, if you do not want to have umpteen apps on your phone, and when you put smarts into the system. You want to look at HA which might be simpler to use, but is arguably less powerful. I often get the reply: I never heard of OH, but HA. It s the latter crowd that goes for HA. Often telling me later that they had a look at OH but it seems complicated.
This is the biggest bug-bear for me too.
Naming is actually crucial when you want to use group rules and split on underscore to identify and modify other items by building names in rules.
I am in the process of buying 60 Zigbee RGBCW down lights for the house I am building. One can imagine, that a ‘standard’ naming convention will help immensely.
sometimes I start with one device; then add another; then realise I should have named them differently. When I migrated from OH2 to 3, I wanted to rename a bunch of similar devices to a ‘standard’ naming scheme. Guess what? It never happened, because of needing to recreate the things and items. Simply too error-prone.
I later read Rich’s commentary OpenHab Marketing is Lacking - #112 by rlkoshak to the above… Point taken, but still a pain in back side 
However, I never saw these two screens: ‘add item from things’ and ‘expert mode’ … oops.
I rename heaps on my OH. I didn’t want to recreate it all.
hmmm… good point, far enough
still confuses folks
ok, Greg… I didn’t watch your video yet… but, I did read the thread you linked to and thought it had AWESOME all over it
If your videos are anywhere as good, you’re the next francis ford coppola
On the topic of renaming, one of the many reasons I prefer file-based config / rules / anything. But I don’t see why UI based stuff can’t be renamed easily, and I don’t mean going to the json files to do it. It should be even more do-able because all the information and links are known. e.g. You rename a channel, it should be able to rename all the items / links using that channel for you automatically. It should even be able to check for name conflicts for you, so it should make it even easier than file-based.
It can also represent a service, so Device would probably be misleading.
Could it be considered a Virtual device?
Guys you’re getting off-topic.
And while some beginners might be confused, for sure naming isn’t the reason folks.
Let alone any renaming after ~8 yrs won’t happen anyway.
And the underlying complexity will remain. You have to understand stuff before use.
I agree that we are getting off-topic. Even if we take out complexity or find a more appropriate and easier terminology, the main issue remains: how to attract new users (and potentially new developers) by promoting openHAB (see title of this thread)
But I totally disagree with this:
This will keep off a big percentage of potential new users to simply start trying and playing around with openhab. A good software is intuitive and you get 80% of the things done simply be using it without studying the docs.
EDIT:
Which brings us back to the off-topic discussions, how to make openhab software easier to use, change terminology, etc.
But first things first. First we need a plan
then we should start acquiring volunteers. Let‘s adopt proven methodology of getting things done we all know from our professional job.
Imo, it’s pointless to do any marketing campaign if your product is just going to turn people off when they found it.
Fix the main issue with the product first before you go spend money (and/or effort) on marketing.
Agree. And you do not get substantial new users if you improve your software and nobody knows until they have decided for openhab anyway.
It needs to be both (as I have noted in my edit section of my post, probably at the same time you were writing your post)
So how about this: we set out to improve one aspect of user friendliness, then use it as a marketing highlight, then go back and improve another and so on.
Hey Jim,
sounds excellent - sounds like the beginning of a plan. At least now 2 of us who prefer a kind of planned approach
And that first improvement has to be the automatic discovery and creation of binding, things, and ultimately, Items (Binding/Things are just out of necessity for creating Items). Ready for new users to click / play around with.
Yeah, not exactly the easiest one, but we do have developers who are capable of achieving this (unfortunately I’m not one of them).
Which is also this kind of a rich (not Rich😂) improvement which can be greatly exploited for creating nice videos, eye-catcher for our home page, press releases, and it is a compelling reason for users who are a bit unhappy with other HA software to finally try OH…
I think, if we added a plan behind this, it will be by far easier to win more developers investing their precious time starting working on this.
When I suggested this, several posts above, @rlkoshak posted a link to github where this was discussed among some developers. Conclusion was that devices were so different that 100% automation was difficult to implement.
I do believe, however, that core team developers (I doubt that recently recruited developers can do it) should implement something, maybe not perfect at the beggining, but with contributions from binding developers eventually arrive 100% automatic discovery.
I’m not worried about thing naming (I was before start using UI) but I understand that people still using the conf folder (this will not be the case of new comers) are worried with it. But, frankly, I don’t see a way to make all happy and I would favour new users in detriment of who is still using the conf folder. Edit the label in each time (as it exists today) should be enough.
IMHO it’s easier to build the model bottom up. OH opted for top down, nothing against this, but I think that bottom up should be simpler to use. Users coming to OH probably used shelly cloud (or another IoT cloud) where rooms are created before the hierarchy, so they are used to bottom up. Or, what about model templates that new users could pick and customize ?
I’m not picking on you specifically. This sentiment has been said by lots of users on this thread.
I’ll preface that by saying I do think that some parts of OH can be made simpler. But this whole argument comes across as wanting to have our cake and eat it too.
HA is simpler because it is less complicated and therefore less flexible. If we want to turn OH into HA, we will have to make OH less complicated and less flexible too. And I’ve seen most say that it’s the flexibility of OH that attracts them to OH.
We can’t have it both ways. If we want dead simple we need to eliminate options and configurability. Choices breed complexity. OH is all about offering choices.
Just the Items. You don’t need to recreate the Things.
They are featured prominently in the Getting Started tutorial: Semantic Model | openHAB.
You can get to it from both directions. From the Thing or from the Model pages.
The names “Item”, “Rules”, “Sitemaps”, “Groups”, “Add-ons”, “Bindings”, etc. have been used as terms of art in OH since OH 1.x (maybe the very beginning?). The term “Thing” was added in OH 2.0. There is a history here that is not easy to just throw away. Renaming these is not as simple as just find and replace not to mention the confusion from users reading old posts. It would be a huge deal to rename core concepts in OH and it doesn’t really buy us much. They will still be terms of art with specific meanings in the OH context.
The way it works in file based configs is when a file is unloaded, everything defined in that file gets deleted from OH. When the file gets loaded, everything defined in that file gets created anew. It appears that you can easily change the UID in config files because you are constantly creating the deleting these entities.
And in managed configs you can rename things in the exact same way. Delete the entity and create it anew.
One thing to now that internally, the OH config is represented as a database. The UID of an entity (e.g. Item name) is the unique identifier for that DB record. It is the foreign key used to link two entities together (e.g. ItemChannelLink, Group membership, Metadata, etc.).
Note that Items are particularly tricky because that one line in a .items file can generate:
each of which are stored and represented separately from the Item itself internal to OH itself. There is a lot of book keeping involved. Every time this has come up as an issue (and it’s come up many times) the maintainers decide it’s way too much work for too little benefit.
Of course, if someone decides differently and volunteers to implement something…