Who has got some clever ideas for item naming schemes?

Setup, Configuration and Use Items & Sitemaps
4

What an excellent question. This is something I’ve given a lot of thought to and I admit I’ve not come up with anything satisfying.

So here are what I consider when it comes to naming things:

  1. what sort of coding/naming standards seem to exist in the community, written or unwritten (e.g. look at examples)
  2. when I’m writing code or debugging logs, what information would I want to know that could be encoded in the name
  3. how do I want to organize my code and how can naming conventions contribute to that
  4. will I ever need to construct the name of an Item based on some other information (e.g. find a switch in a Group based on the name of a sensor that tripped)?

So I’ve come up with the following naming scheme:

  • I use first letter capitalized for Item names (1.) which helps distinguish them from vars and vals in Rules
  • I separate major parts of an Item name with an “_” (1., 4.) which makes it easy to strip out the common part of a name and add to it (e.g. when N_D_Front is opened, I can pull N_D_Front_Last_Opened out of the group gDoorSensorsTime with the line: gDoorSensorsTime.members.filter(dt|dt.name == door.name+"_Last_Opened").head
  • Group names all start with a lowercase ‘g’ (1., 2.)
  • I prepend Item names with some letters to indicate what the Item is for and what sort of object the Item represents (2., 3.):
// Naming Conventions:
//  - Groups all start with a lowercase g
//  - Takes the form of X_X_Name
//      - The first letter denotes the Item type:
//              None    Internal utility
//              'N'             Sensor
//              'S'             Switch
//              'T'             Trigger (switch without a state)
//              'W'             Weather
//      - The second letter denotes the object type
//              None    Internal utility
//              'C'             Controller
//              'D'             Door
//              'I'             Input
//              'L'             Light
//              'V'             Value
//              'W'             Window

For example, the Garage Door reed sensor is named N_D_GarageDoor1 while the relay that opens the door is named T_D_GarageDoor1.

Unfortunately I’ve not had the discipline to stick with these naming conventions throughout my system and I’ve not spent the time to refactor everything to follow it. I’ve actually found the prepended letters to be more of a pain than a benefit because I have to keep going back to the little comment I pasted above that I put in one of my .items file to remember what the letters stand for and thus far I’ve found them of limited use. If I keep this approach I may drop the letters for words or drop the concept entirely.

One last consideration is how I organize everything into files which is tangential to your question but relevant to your refactoring activity. I’ve seen two approaches. One approach is to organize your Items based on their location (e.g. firstFloor.items, basement.items, etc.) and the other approach is to organize by function (e.g. lighting.items, hvac.items, etc.). I’m a strong proponent of the latter approach.

When Items and particularly Rules are organized by function it increases your opportunities for merging rules, utilizing lambdas, and otherwise avoiding duplication of code. This is because while there is likely to be little in common in your rules for sensing your exterior doors on your first floor and the lights on the first floor, there is going to be a lot in common with controlling the lights on the first floor and in the basement.

The reason I bring this up is because the same reasoning can be applied to how one uses Groups. In my mind there are three reasons to use Groups.

  1. Grouping things for display on your sitemap, e.g. putting everything in one room in a Group and just putting the Group on your sitemap
  2. Grouping things for persistence, e.g. set up your .persist files using Groups and then just assign those Groups to Items to control how they are persisted
  3. Grouping things to help simplify Rules, e.g. triggering a Rule based on an update to one of its members, getting a reference to an Item by its name, checking the state of all the members of a Group.

I’ve actually abandoned 1. in my setup. When you put a Group on a sitemap you have no ability to customize how its members are displayed and I almost always want to customize them (e.g. change color, provide a mapping for switches, etc). 2. is something I just thought of and think I’m going to start looking into. 3. is exceptionally powerful and I cannot express in strong enough terms how doing this provides opportunities to simplify your code. Since I adopted this approach I’ve more than halved my lines of code and accomplish more. See this posting for how I use it in my lighting.

7 Likes