I’m still getting my openHAB setup organized and I’m starting to add more devices, sensors, and rules. Everything works individually, but I’m finding it harder to keep things organized as the setup grows.How do you experienced users normally structure your Items, Things, Groups, and rules? I’d rather set things up properly now than have to reorganize everything later.
Hi @tornado
welcome.
i am not sure if you have had the chance to read through the tutorial on the semantic model. Its a great starting point because using the semantic model has benefits that are exposed in locations like group all lights in the living look or each bedroom.
Its worth a first read and then when you start to create locations and add the “Items” (you need) again, and then you will be able to use the tabs “Locations” “Equipment”, “Properties” at the bottom of the overview screen. Once you get work on this you will start to get a feeling for your next steps for groups etc.
Here is a reference
hope this helps.
Ther is no “best” way. Everyone has their preferences. And it depends largely on what you mean by “organize”. Are you using files? The UI? both? DSL or YAML? What problems are you hoping to solve or avoid through this organization?
As @BrettLHolmes points out, the Semantic model is one excellent way to organize your Items in the UI. And it comes with benefits like autopopulating the Overview tab and now the AI integrations use it too.
But if you are talking about how you should Group Items in separate files the Semantic model is kind of irrelevant to that.
So how are you configuring OH and what do you hope to avoid or solve through the organization?
Here’s how I am planning on re-organising mine:
- Use YAML file config - prefer file-based config
- One main file to define the Locations semantic model
- One file for each room. Each file contains Things and their related Items
- Things naming (MQTT) roomname-thingname, e.g.
livingroom-window,livingroom-light1,livingroom-light2, etc. - Item naming: “RoomName_What_Property,” e.g.
LivingRoom_Light1_Power,LivingRoom1_Window_State,BedRoom1_Light_Color, etc. - Use semantic tags
- Use YAML Composer
That’s interesting: For things I planned the opposite way:
I keep similar things (e.g. lights) together in one file, organized by device model. This way, identical devices are grouped consecutively, making bulk changes (adding channels, adding things) easier.
So: Yes, probably a question of taste…
Using YAML Composer, that can be easily done across many files. You just keep the device definition in one file, and include them everywhere.
So when you want to change the device definition you only need to change that one definition that lives in one small file, and still keep the more logical room-by-room grouping.
But yes it’s a matter of taste and workflow.
I find it easier to think of a room and what are all the devices in that room.
That sounds interesting—I’ll have to try it out. Thanks for the tip!
Thanks everyone for the ideas. I can see why both approaches make sense, but I think organizing things by room would be easier for me to manage as the setup grows. The YAML Composer idea is also something I hadn’t really considered, so I’ll definitely look into that. I guess the best setup is the one that makes it easiest to find and update things later.
The setup that scales best is a semantic model with location-based Groups mirroring your home, floors then rooms, then tag Items by point type. Keep Things in files or all via UI, don’t mix, consistency matters more than which. Name Items with a clear scheme like Room_Device_Function. For rules, split by function into separate files rather than one giant file. Doing this now saves a painful reorg later, good instinct to ask early.
I might add that you are not limited to just one organization. There are limitations on how many of what kind of tagged Items can be a member of a semantically tagged Group. But that doesn’t prevent the same Items from belonging to other Groups. So you could have a semantic model but also a functional model (e.g. all lighting in one set of Groups.)
I’ll also mention that generally only about 80% of all your Items have any business in the semantic model. The main purpose of the semantic model is to create how your home automation appears to its users. You will have a bunch fo status Items such that only you as the administrator and perhaps some rules will care about. Those Items do not belong in the semantic model generally, or at least they should bee hidden (i.e. visibility set to only admin users).
Thats a really good question to ask in the beginning of an installation. I my case, I had some main trigger for thinking out „naming convention“ .
- Installation was growing up with new bindings.
- With new version over the time, the new function e.g. semantic model came in.
- Because I consequently start and use until now a text based configuration, I had the question how too organize the settings with files.
- Some minor questions…
Keep in mind, i start 12 years ago only with the LCN binding. It’s a bus system for all this electrical stuff in a house like KNX.
As @jimtng and @rlkoshak mention, you should combine all these different approaches.
In opposition of @jimtng , I don’t use a file per room (location). I use a file per binding. Normally one items, one things and one sitemap file. For files and mappings, sometimes more.
I have two extra item files, one for groups and one for items, which not belongs to a binding directly.
Furthermore I use consequently groups and since I updated to 4.x, I use the semantic model too.
Especially for rules I am going more and more into a differentiation.
- only dataloging → stored in the mariaDB
- notifications
- activities / actions for different types of automation…
This is helpful in my opinion, for testing in case of update / upgrades.
As more as complex your installation became, you are not keen about having trouble after an update, because of a rule does not work as expected furthermore.
In 2025 I wrote a script which help me to rename items in the whole installation. This process must rename an item in the config folder as well as in the persistances (I use mariaDB) and the „uicomponents_*.json“ files of your installation as well.
At the end, it a continuous improvement process 
I am not finish with all 
Perhaps, check my GitHub - rayb67/openhab-textual-config: Some of my openhab configurations based on a textual setup. · GitHub configuration files. Maybe this will give you an idea how to handle your question.
One thing to note is for some time persistence has supported aliases. So you could rename your item, set an alias for the new name and not have to charge the database itself.
I’ll also note, with the yaml format you can mix Items, Things, Rules, and UI Widgets/pages all in the same file, opening up new ways to organize your config.
The persistence alias approach makes a lot of sense. I was mainly concerned about breaking references when reorganizing or renaming items, so knowing there’s a way to handle that without directly modifying the database is reassuring. I’ll definitely look into this.