It depends on why you want to do those things. What your end goal is will dictate the best approach.
For some ways to do separation:
-
Items, Rules, and Widgets can be assigned tags which can be searched on.
-
The Developer Sidebar (alt-shift-D or bring it up from the Developer Tools page) can search for and pin Things, Items, and Rules. So, for example, if you are working on your HVAC system you can pin all the relevant stuff to the sidebar and itâs all right there one click away.
-
Naming conventions can be used to group stuff together. When using âcreate equipment from Thingâ to create a bunch of Items all at once, the name of the Thing will be used for the default names of the Items.
Personally I use tags and when I want to see everything that is related, I search for the tag and the config page will only show the Items or Rules with the given tag. For Things there is already an option to group the Things by binding. If you need some other grouping, Iâve used tags on the Items linked to the Things. From the Item you can navigate from the Item to the Link and on to the Thing. Though mostly I use the Developer Sidebar and just pin the ones I need at that time.
I like this way of achieving separation because I donât have to decide ahead of time what I want the separation to be. I can create an adhoc grouping of anything relevant to what Iâm working on.
Firstly, I do not consider this to have anything to do with bulk editing. So perhaps there is a difference in definitions. Bulk edits to me is, for example, adding a tag to a bunch or related Items or creating a bunch of similar MQTT Things or something like that.
Anyway, for this rename case, this is a pet peeve of mine. There is no such thing as renaming an Item in the UI or text files. Every time you modify a .items file, all of the Items defined in that file are deleted from OH and then reloaded from scratch.
So to ârenameâ an Item in the UI you need to do the same thing. Delete the Item and recreate it. To delete you can delete the link and the Items linked to a Thingâs Channel from the Things page or the Link page. When the Item is deleted this way my understanding is that the metadata registry will clean itself up as well (I donât think managed Item metadata gets cleaned up at all for text based Items). You can choose to remove the link or not but you should.
From a bulk edit perspective, you can do this for all the Items linked to a Thing all at once using the options at the bottom of the Things Channels page.
Then you can use the âAdd Equipment to Modelâ or âAdd Points to Modelâ and you can recreate all those Items in one go with the new settings/names/etc. Whatâs nice about this is not only can you crate and configure all the Items for that Thing in one go, there are reasonable defaults for a lot of things and it will create the Equipment Group for you and let you select the Location.
But whether you are doing this in a text file or through the UI, renaming an Item should be done with great care. Not only will you potentially need to update rules and sitemaps and such but you will disconnect that Item from its persistence and itâs metadata. Renaming an Item should not be taken on lightly. I personally think itâs too easy to do so in .items files but not enough to harp on it. But it is a source of âleaksâ in openHAB because by design not everything gets cleaned up on the unload/reload.
After renaming the Item, you can close OH, open the JSONDB files in VSCode and do the find and replace just like you are used to, or you could do it though the API Explorer in some cases though I find that less easy to use.
Because of the disruption caused by ârenamingâ Items is so great, doing so should be done rarely and only under significant need.
Things are a little less easy to do but still not too bad to bulk edit and create a bunch of similar ones. The fastest way would be to generate one example Thing, query for it in the API Explorer, copy the JSON, edit it, and post it back to OH through the API Explorer. You can create dozens of similar MQTT Things in a few minutes that way. Less quick would be to use the Code tab YAML and copy/paste/edit.
There are not too many bindings that do not support automatic discovery of Things so the above only applies to those bindings that do not auto-discover (e.g. MQTT, KNX, modbux, etc.). Auto discover everything else.
Over all though, in my experience the number of times Iâve ever had to do a bulk edit in these ways are pretty limited. Usually itâs only when adding new devices to the home automation (or decomissioning them). The last time I renamed an Item was when I moved to OH 3 (the names of the Items donât really matter that much anymore compared to the labels of the Item). I use dynamic UI widgets (posted to the marketplace) for a lot of my devices that rely on Group membership and/or Item tags so there it doesnât matter what my Items are named, the widgets adjust dynamically.
One last piece of bulk edit. You likely have a bunch of Items that you want to look the same way in MainUI. So create the widget once under Developer Tools. Then you can apply that widget to each Item using the Itemâs metadata. Now, if you decide to make a change, you can modify that widget under Developer Tools and the change will be picked up by all the Items that are using it. Iâve posted a bunch of these types of widgets to the marketplace too.
Now for comments.
Things
I find using meaningful names and the location fields are more than sufficient when combined with the binding and the channels to determine what a Thing is for and what it represents.
Items
Here too, the Item name, label, type, link, Group membership, semantic tags and position in the semantic model, and additional tags make it clear what the Item represents and what itâs for. Were I to need more, Iâd probably use Item metadata to capture some notes.
For example:
Itâs pretty clear that Nateâ Christmas Tree controls the lights of a tree in the Family Room. Notice the Item name doesnât even appear in this tree (you can click on it and get the Item name easily enough though if you need it).
Rules
For UI created rules you have lots of places to add comments and additional information. Thereâs a name and description where you should explain what the rule does over all. Rules can have tags too.
Each rule can have one or more triggers, actions, and conditions. Each of these also have a name and a description. They are often filled in with a default that makes sense but you can modify them as needed.
If you have a Script Action or Script Condition, you can use inline comments per normal too in the script.
// No alarm scheduled
var type = (typeof(require) === "function") ? DateTimeType : DateTimeType.class;
if(time.class != type || time.getZonedDateTime().isBefore(ZDT.now())) {
logger.debug("No alarm scheduled for " + item);
if(this.timer !== null) {
logger.info('Cancelling alarm');
this.timer.cancel();
}
}
// create or schedule a timer to run at the configured time
else {
logger.info("Scheduling alarm at " + time + " for " + item);
if(this.timer !== null) {
logger.info("Rescheduling alarm for " + time);
this.timer.reschedule(time.getZonedDateTime());
}
else {
logger.info("Setting a new alarm for " + time);
var map = new java.util.HashMap();
map.put("triggeringItem", item)
this.timer = ScriptExecution.createTimer(time.getZonedDateTime(), callScriptGenerator(map, script));
}
}
The one place where comments are not really supported are widgets. I know there is an issue but itâs a hard problem since JSON, which is the underlying format, doesnât support comments. Itâs a known problem without a solution yet.