Items are where you get to model your home automation. In this case the names for 1, 2, and 3 make sense. These Channels represent the state of the room itself.
What does the Battery Channel represent? The battery on the Xiaomi. So I’d use a name like LivingRoom_Sensor_Battery. The Item represents the state of the Xiaomi device itself, the sensor, so name the Item as such. If you have more than one sensor device in the room, come up with some other way to give them a unique name.
That’s one way to do it too.
The key is the names need to make sense to you. They should be meaningful and represent the purpose of the device. Including location in the name is one way to help make the Item name unique.
Having gone through a number of Item naming schemes my best advice is to not be overly prescriptive in your approach. Sometimes it makes sense to use a special case (e.g. by adding Sensor only to the one Item instead of adding a new category to all the Items). The only real requirement for Item names is that they are all unique.
Whatever scheme you come up with, it should be intuitive. If you have to refer to some table to remember how to name an Item, it’s a bad scheme (a weakness of my first two naming schemes).
Even with a well thought out naming scheme, it is important to consider Group usage and structuring as well, particularly if you intend on using HABot which heavily relies upon Group membership and tags.
Just to provide another example of my current naming scheme.
- If it’s a Group, use a plural name, e.g Lights
- If it’s a sensor, value, or otherwise “input” to OH, start the name with ‘v’
- If it’s an actuator (i.e. sending a command to it causing something to happen) the name starts with
- I use
_ instead of camel case (see Kim’s examples for camel case) because it’s easier to parse out parts of the Item name in Rules, see Design Pattern: Associated Items
That’s it. Those are the only hard and fast Rules, and even those are not super strictly followed (e.g. I still have a bunch of Groups that start with
I organize my Items by function because I also organize my Rules by function. So all the lighting Items go in one file, all the HVAC in another file, and so on. Similar Items are more likely to be co-located making copy/paste/edit easier and it is easier to find the Items used by a given set of Rules easier. The Items the Rules in my lights.rules file are in the lights.items file.
The overall naming scheme I use for Items (beyond the Rules above) can vary from function to function. For example, my weather.items file has names like: vWeather_Temp, vIsCloudy, vTimeOfDay but my climate.items file has names like: vMainfloor_Temp, vMBR_Humidity and my admin.items file has names like: vSonoff_3157_Online, vNetwork_medusa, vCalibre_Online.
It’s kind of a mix of standards and styles for Item naming. I do make a point to be consistent within a group of closely related Items (e.g. machine’s online status are all vNetwork_[hostname] while a service is v[Service Name]_Online) but not necessarily across all Items within the same file.
I find it easier to use names that make sense to me in a specific and narrow context rather than enforcing some global set of naming rules. And because most of my Rules are triggered by
Member of SomeGroup, beyond defining the Item and putting them on the sitemap which happens once, I don’t really care what the names of my Items are. They don’t really matter. What does matter are their label, Group membership, and increasingly their tags and metadata.