Item Naming

Yet another topic on naming.

I have a Xiaomi temperature, humidity, pressure sensor. A single device (Thing) has the following channels -> items that I’m monitoring:

  • Temperature
  • Humidity
  • Pressure
  • Battery level

I am a bit confused as to how I should name my items that correspond to that one Thing.

Currently I have:

  1. LivingRoom_Temperature
  2. LivingRoom_Humidity
  3. LivingRoom_Pressure
  4. LivingRoom_Battery?? This is where I got stuck. What if I have another device (Thing), say, LivingRoom_Door (open or close sensor), and it will have its own battery level to monitor.

My guess is I should add another part e.g. LivingRoom_Climate_Temperature, hence LivingRoom_Climate_Battery vs LivingRoom_Contact_Sensor, LivingRoom_Contact_Battery ?

Is there a better name than Climate and Contact ?

There is no standard or even just recommendation on Naming.
Now unfortunately this means everybody has to come up with his own scheme - you have to have the feeling that it makes sense, is extensible etc.
What you wrote makes sense. Search the forum to see what others use but don’t expect anyone to tell you a precise scheme to follow.

I’m looking for suggestions / ideas

From my point of view a very common naming scheme is the following:

<Location>_<Thing>_<Channel>

Groundfloor-Livingroom_Multisensor_Temperature

This can be enriched and/or modified in many ways. The location can be shortened: Livingroom is LR, Bedroom is BR, …

There are some interesting discussions about group usage and structure that may give you some hints. One advice may help try not to deveolp your nanig scheme on the fly. User some time, think a little bigger and write your structure down.

Unfortunately you will see that this is a never ending story.

1 Like

First I use something to identify which room the device is located in.
Second I use something to identify the function/thing of the device.
Third If the room got more than one device having the same thing, such as battery, I use something to identify the device as well.

So devices placed in a bedroom:
BedroomTemperature
BedroomHumidity
BedroomPressure

If I had two Xiaomi battery devices in my bedroom I would use [Room][Devicexx][Function] like:
BedroomXiaomi01Battery
BedroomXiaomi02Battery

The labels of the items will help by containing more specific where exactly the device is placed if needed. Whats important is not to use the same item naming more than one.
I dont use PaperUI for items. I use manual created items files. It gives me a lot better overview, even though I have several items files, which basicly is splitted into devices. Ie… all my zwave devices are located in the same zwave.items file. All my IHC devices are located in a ihc.items, and all my Zigbee devices are located in a zigbee.items etc…
Since my IHC devices are covering the whole house (cause its my main system) and contains several things, I have inserted sections into the items file telling me which room the items belong to. I didn´t actually had to do this, as I already got the room covered in the item naming. But it give me a fast overview to scroll/search to the section I need to find fast:

//Stort Bad
Group g_Stortbad_TSTAT			"Stort Bad Thermostat" 																[ "Thermostat" ]
Number stort_bad_Temperature		"Stort Bad Temperatur [%.1f °C]" 						<cu_heating> 	(g_Stortbad_TSTAT,Temperatur,gTvaer,gSugeTemp) 	[ "CurrentTemperature" ]	{ihc="7986196"}
Number stort_bad_Tempsetpunkt 		"Stort Bad Temperature setpunkt [%.1f °C]" 					<temperature>	(g_Stortbad_TSTAT)				[ "TargetTemperature" ]		{ihc="7989780"}
Switch telestat1_stort_bad		"Stort Bad Telestat [%s]"							<cu_switch> 	(g_Stortbad_TSTAT,gTelestat) 							{ihc="6144859"}
DateTime telestat1_stort_badStamp	"StortBad Telestat ON [%1$tH:%1$tM:%1$tS %1$td.%1$tm.%1$tY]"			<time>		(gTelestatStamp)
Number stort_bad_fugt 			"Stort Bad Fugtighed [%.0f %%]" 						<Humidity> 	(g_Stortbad_TSTAT,Fugtighed,gHumidityBathRoom) 	[ "CurrentHumidity" ] 		{ihc="13699623"}
Number stortBadSensorFejl		"Stort Bad Sensor fejl [MAP(nilan_on_off.map):%s]"				<error>		(gSensorfejl)									{ihc="<7996682"}
Number stortBadVentilMotion		"Stort Bad Ventil motionering [MAP(nilan_on_off.map):%s]"			<cu_switch>	(gVentilMotion)									{ihc="<7989522"}
DateTime stortBadVentilMotionStamp	"Stort Bad Ventil motionering [%1$tH:%1$tM:%1$tS %1$td.%1$tm.%1$tY]"			<time>		(gMotionStamp)
DateTime stortBadSensorFejlStamp	"Stort Bad Sensor fejl [%1$tH:%1$tM:%1$tS %1$td.%1$tm.%1$tY]"			<error>		(gSensorfejlStamp)
Switch stort_badDimmerStatus 		"Stort Bad Dimmer status" 							<light> 							 				{ihc="5540626"}
Switch stort_badDimmerLys 		"Halogenlys i StortBad [%s]" 							<WallSwitch> 							[ "Lighting" ] 			{ihc="<5537553,>[ON:20314:100],>[OFF:20314:100]"}
Switch stort_bad_NV 			"Nilan styring [%s]" 								<WallSwitch> 							[ "Switchable" ] 		{ihc="<14474513,>[ON:20570:100],>[OFF:20570:100]"}


//Sove vaerelse
Group g_sove_TSTAT 			"Soveværelse Thermostat" 															[ "Thermostat" ]
Number sove_Temperature 		"Soveværelse Temperatur [%.1f °C]" 						<cu_heating> 	(g_sove_TSTAT,Temperatur,gTvaer) 		[ "CurrentTemperature" ]	{ihc="8227092"}
Number sove_Tempsetpunkt		"Soveværelse Temperature setpunkt  [%.1f °C]" 					<temperature> 	(g_sove_TSTAT)					[ "TargetTemperature" ]	 	{ihc="8230676"}
Switch telestat2_sove			"Soveværelse Telestat [%s]"							<cu_switch>	(g_sove_TSTAT,gTelestat) 			 				{ihc="6147419"}
DateTime telestat2_soveStamp		"Sovevær Telestat ON [%1$tH:%1$tM:%1$tS %1$td.%1$tm.%1$tY]"			<time>		(gTelestatStamp)
Number soveSensorFejl			"Soveværelse Sensor fejl [MAP(nilan_on_off.map):%s]"				<error>		(gSensorfejl)									{ihc="<8230418"}
Number soveVentilMotion			"Soveværelse Ventil motionering [MAP(nilan_on_off.map):%s]"			<cu_switch>	(gVentilMotion)									{ihc="<8237578"}
DateTime soveVentilMotionStamp		"Soveværelse Ventil motionering [%1$tH:%1$tM:%1$tS %1$td.%1$tm.%1$tY]"		<time>		(gMotionStamp)
DateTime soveSensorFejlStamp		"Soveværelse Sensor fejl [%1$tH:%1$tM:%1$tS %1$td.%1$tm.%1$tY]"			<error>		(gSensorfejlStamp)
Switch sove_doer_OEV 			"Soveværelse Lampeudtag [%s]" 							<WallSwitch> 						 					{ihc="<110353,>[ON:22618:100],>[OFF:22618:100]"}
Switch sove_doer_OEH 			"Soveværelse Halogenlys [%s]" 							<WallSwitch> 						 		 			{ihc="<16369681,>[ON:22874:100],>[OFF:22874:100]"}
Switch sove_halogenlys 			"Soveværelse Dimmer status" 							<light> 						 		 			{ihc="13711133"}
Dimmer sove_halogenlys_niv 		"Soveværelse Dimmer niveau [%.1f %%]" 						<light>								["Lighting"] 		 	{ihc="13710941"}
Switch sove_lampeudtaglys 		"Soveværelse 80mm Lampeudtag" 							<light> 									 		{ihc="111890"}

(small note, this is a very small snip of my ihc.items file covering our master bathroom and master bedroom, (we´ve got 13 rooms in our house including garage)).
As you might notice there is a breaking in my naming principal with the telestats, which actually starts with [function] and the [room]. Thats because all the telestats are not located in each room, but insted underneeth our boiler in our garage because we´re having floorheating). But they still belong to the room thermostat. I used to have these telestats in their own items file, but in the past few months I have change it, so most devices are placed main from their interface/communication, and second for their function.

I do have other items files as well which is named from their function, Ie, I got an item file called ProxySwitches.items which is a file having all my proxyswitch items, even though they´re used in specific rooms or functions in specific rooms. Simular I´ve got a file named Velux.items which contains all my Velux eletric windows, even though they are located in different rooms.

Hope it might give you some ideas.

Whats most important is, that you do what you feel suits you best. Keep it clear and simple for you to understand, then you can easily find what you need very fast and limit the chances of loosing track using the same item name twice.

I think you meant channel here instead of thing.
In OH
device == Thing
battery, for instance, == Channel of the Thing.

Yes I did… Sorry :smiley:

1 Like

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 a
  • 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 g)

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.

1 Like

Adding to what the others have said, my only advice is that longer, descriptive names are better than brief names. When you edit a rule weeks/months/years later, you want to be able to look at the items and know what they are without having to think too hard.

Especially as you age and your memory fades … :wink:

2 Likes

Huh! Memory, whats that?

:smiley:

2 Likes

I forget. :rofl:

2 Likes

So many people, so many preferences :slight_smile:

Just make sure that whatever naming scheme you use, you can easily apply the Design Pattern: Associated Items (I know Rich mentioned this as well, but I think this cannot be stressed enough).

1 Like