How do you prefix your Groups/Items? Or how I do it

Hi,

after I saw the last live stream about the new openhab 3 main ui and the extensive usage of semantic tagging, I was motivated enough to restructure my whole item hierarchy to be prepared for the migration from openhab 2.

At the beginning I was following the unofficial group naming convention where I added the prefix “g” to every group. But in my setup I’m using >400 items and now also >400 groups. So I extended the naming convention and I want to share the simple idea behind.

Groups, outside the semantic model, are still prefixed with a “g”
Location groups are prefixed with a “l”
Equipment groups are prefixed with a “e”
Property items are prefixed with a “p”

that’s all. It helps me a lot to keep the overview about the semantic type of hundreds of items/group names.

2 Likes

Just to play devil’s advocate, what problem does this solve? In your rules do you need to know the difference between a location group and an equipment group? Are the location groups not already apparent based on their names without the letter signifier? And if not, isn’t it apparent by the tags? The same for equipment.

If it solves a problem for you so much the better. But as someone who used to have a similar naming convention for Items and Things, after years of maintaining it I’ve found that they serve almost no practical purpose. Pretty much all of the information conveyed by the letter prefixes is already apparent based on what I already understand about the Items (i.e. my mental model) and by using meaningful names for what the Item represents.

And if you move to creating and managing your Items through the UI the Item names become even less relevant. It’s the labels that the Items are listed by and sorted by and such.

However, there is one naming convention I would strongly recommend users adopt. When you have Point Items that are a member of an Equipment Group, prefix the Item with the name of the Equipment Group followed by a “_” and then what that Item represents. There are a number of reasons why this is a good idea:

  • that’s how the Items are named by default when you create them from a Thing
  • in custom widgets that, for example, use a bunch of Items from a single equipment (e.g. a single widget that includes the Image, player, app, artist and media title for a Chromecast), you can set a single property they the name of the equipment Group and reuse that widget for more than one Chromecast
  • in your rules you can construct the names of related Items on the same equipment through a simple split on the name of the triggering Item

And if you plan on doing much with your Items on the UI, it is even more important now to use meaningful and unique labels for your Items than the name because the label is what’s used primarily in search and sorting.

one additional use case is to make it easier for a system wide fulltext search for a specific group.

e.g. if i have a location lGF_Livingroom and a equipment eGF_Livingroom_Lamp and a point pGF_Livingroom_Lamp_Powered, it is now much easier to do a system wide (rules, habpanel config, scripts which uses rest endpoints etc) file search/replace for the usage of the location. Before, all equipments and points matches too. I know, i could to a “complex” regex based search with the possibility of mistakes. Now a simple text search is enough.

another reason ist that it is way easier, to get the purpose of a group name, if you scroll through a lot of configuration files, because you must not read the full name anymore.

by the way, for me, the usage of the ui is not an option, because i deploy my whole setup fully automated with ansible. So i have to stay with configuration files. https://github.com/HolgerHees/smartserver

I too deploy my whole setup using Ansible. Configuration files are not required to do so using Ansible. Ansible Revisited

Everything that you do through the UI gets saves as JSON text. Or if you want to, you can create tasks to push stuff using OH’s REST API, but that would be a lot of work. Just deploy the text created by interacting with OH through the UI. In my case I configuration control my OH config (and in OH 3 I’m 100% UI based) and my Ansible checks it out. But that is because I’m lazy and I don’t need more than that. You could of course write tasks to deploy each binding installation and create the Things, Items and Rules as separate tasks or roles if you wanted.

I’m not saying that you should do it this way too. But I don’t want others to think that it can’t be done this way too.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.