Ok - well I have completed this task and it was a bit of a mission - took me about a week of evening coding to change all the names, after a couple of ideas/attempts at a naming convention. Then I stupidly decided
<location>-<type>-<name> was a clever way to name my items, forgetting that the item openHAB parser treats
- as a separator.
So after renaming everything and double checking all my changes, I deployed them to my live server only to see everything go t!ts up!! I couldn’t face starting again so did a global search+replace for
_. Unfortunately this screwed up a load of icon names, host names and many labels. So let that be a warning to all, don’t use
- in your item names!!
Anyway - long story short it is all done. Here is the naming convention I decided upon;
<area> is one of
GF (ground floor),
FF (first floor),
OU (outside), or
VT (virtual). And
<name> is optional if the type adequately describes it. Also, the
VT items often don’t have a
<room> for things like presence items etc.
So some examples;
GF_Kitchen_CoffeeMachine - coffee machine in the kitchen
FF_Ensuite_PIR - motion sensor in the ensuite
GF_Living_Light_Dining - living room dining table light
GF_Garage_Temp - temperature sensor in the garage
VT_Presence_Ben_Owntracks - virtual switch which is updated by Owntracks for presence detection
VT_Online_FreeNAS - virtual switch indicating if my NAS is online (via the networkhealth binding)
I also decided on name groups
GP_Presence_Ben which I have a number of virtual items belonging to, if any are ON then my presence group is ON.
I have already been able to streamline some of my rules, in particular sensor threshold warning rules, to build more human-readable messages since I can deconstruct the sensor name from the item name.
I also created a couple of groups for persistence, i.e.
GP_Persist_InfluxDB. So any item I want to be persisted to my timeseries DB (i.e. InfluxDB) I just add to that group. Anything I want stored and restored on startup I add to the MapDB group.
I also created a couple of groups for storing config and state,
GP_State. These belong to the MapDB group. This means I can simply add an item to the
GP_Config group and it will be auto-persisted and restored by MapDB. If I decided to use a different persistence engine for this I can change one group config and all child items will be automatically updated to use the new engine. Thought this was quite a good idea!
The immediate benefits haven’t really been worth the amount of time and effort but I am hopeful that over time as I streamline more of my rules etc this naming scheme will make life a lot easier.
BTW - I lost all my historical data in InfluxDB (my persistence engine) since all the names changed! Wasn’t too bad as I took the opportunity to upgrade from v8 -> v11 which was long overdue.