There have been many posts (you should search and read some, it is good to see what everyone comes up with) and there is a discussion on an open issue (I think it is still open) to add a naming convention recommendation to the docs themselves. At a high level the advice is:
-
Use meaningful names for the data or functionality the Item represents. Items are the functional view of your Home Automation so the names should reflect what that Item represents functionally, not what device it happens to be linked to.
-
There is debate on this but some people, myself included, use some sort of convention to distinguish between different types of Items. For example, I start my actuators with “a” (e.g. aGarageDoorOpener1 to open/close the garage door), by values with a “v” (e.g. vGarageDoorOpener1 to represent the open/closed state of the door), and “g” for Groups (e.g. gGarageDoorOpeners). The consensus on the open issue was that Groups should be plural rather than prepending the “g”.
-
If you plan to use Design Pattern: Associated Items (I highly recommend it) be sure to name Items that are closely related in such a way that you can construct the name of one Item given the name of the other Item with some simply String manipulation. (e.g. vGarageDoorOpener1 and vGarageDoorOpener1_Timer (Expire based timer Item) so I can send the on command to the Timer from a rule using
sendCommand(triggeringItem.name+"_Timer", ON)from a Rule that lets me write generic Rules). -
Be prepared to change your convention. Over time you will find that what works for you may not be what works for others and as you grow you will come up with alternatives. My recommendation would be not to over define your naming convention. Let it be pretty loose to start and over time you will find whether or not you need to add more structure.
Finally, I’ll recommend structuring your files (you will want to use more than one file) based on function rather than location. For example, I have a lights.items, lights.rules, lights.things set of files where all the lighting stuff goes rather than a kitchen.items, et al.
Inclusion works just fine in PaperUI. Configuration of devices also works in PaperUI. I don’t think PaperUI supports exclusion yet. But most people recommend Habmin for administering zwave because it provides more information, has more capability, and it is written by the same author as the zwave binding itself.
But Markus’ point is key. To a large extent, an opensource project is strictly an additive process. Capabilities like Habmin rarely if ever get removed. And while not all areas of Habmin are at the same maturity or up to date (e.g. the Rules creator in Habmin still generates OH 1.x rules) I don’t think there is much of anything that PaperUI can do that Habmin cannot do. Lots of people prefer Habmin to PaperUI.
And I’ll also point out that this is a good thing. If OH tried to be more exclusive we would never have received HABPanel, VSCode, and any number of bindings.
@job, it occurred to me last night that you could edit the location of autodiscovered Things in the JSONDB directly. I’m not certain of the exact format but it looks like it is a first level entry under the Thing ID.
"zigbee:coordinator_ember:a38f078d": {
"class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
"value": {
"label": "Zigbee Coordinator",
...
},
"location": "Office"
}
},