Not necessarily. My Item names are pretty long. The biggest thing you want to do is come up with a naming convention and stick to it. For example, here is my naming convention:
// Naming Conventions:
// - Groups all start with a lower case g
// - Items are all capitalized camel case
// - 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' Conroller
// 'D' Door
// 'I' Input
// 'L' Light
// 'V' Value
// 'W' Window
I’m the first to admit this is not a very good naming scheme. It was my first attempt and I’ve not gone back to think about a better approach. But the key is to come up with something that will help you as your HA grows.
I recommend using proper indentation. For example:
if(BasementMotionSwitch.state == ON) {
if(BasementLights2.state == 0) {
sendCommand ...
}
}
Proper indentation will help you avoid scope errors because you can just look and see what you intended your scope to be rather than needing to count curly brackets.
The only thing I can see that would save you a handful of lines of code would be to put BasementLights2, BasementLights5, BasementBackRoom, and BasementMotionSwitch in the same group you can then issue the OFF commands and ON commands using something like
gBasementLights.members.forEach[s | s.sendCommand(OFF)]
For the ON you can still do a one liner but you need to be a little tricker:
gBasementLights.members.forEach[s | if(s instanceof DimmerItem) s.sendCommand(60) else s.sendCommand(ON)]
You can have Items be members of multiple groups as well so if you wanted to create one group that just included the Dimmers for your Lights On rule and everything for your override rules you can.
I like this approach because as your HA system grows or your configuration changes all you have to do is add and remove items from membership in your various groups and you never have to touch your rules. It also makes for terser and easier to read rules code.
One final bit of advice. Where ever possible I recommend calling the sendCommand and postUpdate methods on the Items rather than using the actions like you do above. The Item’s methods are necessarily smarter about converting the data you pass to it into something the Item can understand than the generic action methods which have to work for all Item types. You will save some headaches in the future if you follow this advice.
