Naming convention

[thissiac (Chris)]

Hello to all OH beginners …

as a beginner I managed to put an OH2 on Raspi and integrate Homematic and Zigbee components.

After the first weeks of testing with wild naming conventions, like /firstfloor/kitchen/window or /bathroom/light, etc… I made many mistakes because I got confused with the different naming conventions. As far as I know, many names may not be the same.

*.items
O0_Outdoor_Temperature

*.things
netatmo_020000135bf6_sensor01_temperature

Let’s take an example.

In my living room I use an OSRAM+ plug with a lamp connected. What is the name?

livingroom_light
livingroom_lamp
livingroom_power
livingroom_power_plug

I have three windows with contacts in the kitchen.

kitchen_window_01_contact
kitchen_window01_contact
kitchen_window_contact01

There is a Netatmo sensor for temperature, humidity, etc. in the garden.

garden_temperature
garden_humidity
garden_sensor_temp
garden_sensor01_hum
garden_sensor01_temp
garden_sensor01_hum

Two light buttons with two channels.

kitchen_switch01_01
kitchen_switch01_02
kitchen_switch02_01
kitchen_switch02_01

Of course I know anyone can do it the way you like it.

I’m trying to find a name standard that will simplify further administration. I would be interested to know how you do it. Unfortunately I can’t find anything about it in the forum.

It becomes more difficult if MQTT is added. Then the right path has to be defined.

/kitchen/switch01/01/cmd
/kitchen/switch01_01/cmd
/kitchen/switch/01_01/cmd

/garden/temperature/
/garden/sensor/temperature
/garden/sensor/humidity

It all sounds strange, but as long as I don’t find a proper naming convention, I’m going to get problems again and again in the future. At the moment I don’t want to talk about trying to integrate HOMIE.

I would be grateful for any support.

[luckymallari (Lucky)]

Each will have their own convention. For me, it’s basically:

categoryTypeLocationNameFunction

Contact alarmPanelContactReady      	"panel ready: [%d]" (gAlarmPanel)      		{alarmdecoder="KPM:00#contact,bit=17"}
Contact alarmPanelContactBacklight    	"panel backlight: [%d]" (gAlarmPanel)    	{alarmdecoder="KPM:00#contact,bit=14"}
Contact alarmPanelContactProgramming  	"panel programming: [%d]" (gAlarmPanel)   	{alarmdecoder="KPM:00#contact,bit=13"}
Contact alarmPanelContactBypass     	"panel bypassed: [%d]" (gAlarmPanel)       	{alarmdecoder="KPM:00#contact,bit=9"}
Contact alarmPanelContactPower      	"panel on AC: [%d]" (gAlarmPanel)      		{alarmdecoder="KPM:00#contact,bit=8"}
Contact alarmPanelContactChime      	"panel chime: [%d]" (gAlarmPanel)      		{alarmdecoder="KPM:00#contact,bit=7"}
Contact alarmPanelContactAlarmOccured 	"panel alarm occurred: [%d]" (gAlarmPanel)  	{alarmdecoder="KPM:00#contact,bit=6"}
Contact alarmPanelContactAlarm      	"panel alarm sounding: [%d]" (gAlarmPanel)  	{alarmdecoder="KPM:00#contact,bit=5"}
Contact alarmPanelContactBatteryLow   	"panel battery low: [%d]" (gAlarmPanel)     	{alarmdecoder="KPM:00#contact,bit=4"}
Contact alarmPanelContactDelay      	"panel delay off: [%d]" (gAlarmPanel)      	{alarmdecoder="KPM:00#contact,bit=3"}
Contact alarmPanelContactFire       	"panel fire: [%d]" (gAlarmPanel)       		{alarmdecoder="KPM:00#contact,bit=2"}
Contact alarmPanelContactZoneIssue    	"panel zone issue: [%d]" (gAlarmPanel)    	{alarmdecoder="KPM:00#contact,bit=1"}
Contact alarmPanelContactAway       	"panel away: [%d]" (gAlarmStatus)       		{alarmdecoder="KPM:00#contact,bit=16"}
Contact alarmPanelContactHome       	"panel home: [%d]" (gAlarmStatus)       		{alarmdecoder="KPM:00#contact,bit=15"}
Contact alarmPanelContactArmedStay    	"panel armed stay: [%d]" (gAlarmStatus)    	{alarmdecoder="KPM:00#contact,bit=0"}

Number arduinoSensor_kitchen_gas	"Kitchen Gas Sensor" (gArduinoSensors) 
Switch arduino_garage_siren {expire="10m,command=OFF"}

Contact alarmContactZone10FrontDoor "Front Door" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllDoors,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0215137#contact,bitmask=0x20"}
Contact alarmContactZone11GarageDoorInside "Garage Door Inside" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllDoors,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0059750#contact,bitmask=0x20"}
Contact alarmContactZone12SideGarageDoor "Side Garage Door" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllDoors,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0045487#contact,bitmask=0x20"}
Contact alarmContactZone13MotionFamilyRoom "Motion Family Room" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllMotion) {alarmdecoder="RFX:0095809#contact,bitmask=0x80"}
Contact alarmContactZone14LivingWindow1 "Living Window 1" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0702437#contact,bitmask=0x20"}
Contact alarmContactZone15LivingWindow2 "Living Window 2" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0905475#contact,bitmask=0x20"}
Contact alarmContactZone16DiningRoomWindow "Dining Room Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0052015#contact,bitmask=0x20"}
Contact alarmContactZone17KitchenWindow "Kitchen Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0154901#contact,bitmask=0x20"}
Contact alarmContactZone18KitchenSlidingDoor "Kitchen Sliding Door" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllDoors,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0693198#contact,bitmask=0x20"}
Contact alarmContactZone19FamilyRoomWindowOne "Family Room Window One" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0775213#contact,bitmask=0x20"}
Contact alarmContactZone20FamilyRoomWindowTwo "Family Room Window Two" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0491945#contact,bitmask=0x20"}
Contact alarmContactZone21OfficeWindow "Office Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0915779#contact,bitmask=0x20"}
Contact alarmContactZone22BathroomWindow "Bathroom Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0280634#contact,bitmask=0x20"}
Contact alarmContactZone23GarageDoorDriveway "Garage Door Driveway" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllDoors,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0954588#contact,bitmask=0x10"}
Contact alarmContactZone24MotionDetectorOffice "Motion Detector Office" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsDownstairs,gAlarmAllMotion) {alarmdecoder="RFX:0097360#contact,bitmask=0x80"}

Contact alarmContactZone25LoftWindow "Loft Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0284772#contact,bitmask=0x20"}
Contact alarmContactZone26MasterBedroomWindow1 "Master Bedroom Window 1" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0344031#contact,bitmask=0x20"}
Contact alarmContactZone27MasterBedroomWindow2 "Master Bedroom Window 2" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0421163#contact,bitmask=0x20"}
Contact alarmContactZone28MasterBathroomWindow1 "Master Bathroom Window 1" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0233610#contact,bitmask=0x20"}
Contact alarmContactZone29MasterBathroomWindow2 "Master Bathroom Window 2" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0808517#contact,bitmask=0x20"}
Contact alarmContactZone30KyleRoomWindow "Kyle Room Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0312638#contact,bitmask=0x20"}
Contact alarmContactZone31GuestWindow1 "Guest Window 1" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0848448#contact,bitmask=0x20"}
Contact alarmContactZone32GuestWindow2 "Guest Window 2" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0744818#contact,bitmask=0x20"}
Contact alarmContactZone33GuestWindow3 "Guest Window 3" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0278503#contact,bitmask=0x20"}
Contact alarmContactZone34KoyoRoomWindow "Koyo Room Window " (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0507933#contact,bitmask=0x20"}
Contact alarmContactZone35MasterBathroomWindow3 "Master Bathroom Window 3" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:1030079#contact,bitmask=0x20"}
Contact alarmContactZone36UpstairsBathroomWindow "Upstairs Bathroom Window" (gAlarmContacts,gAlarmAllSensors,gAlarmAllSensorsUpstairs,gAlarmAllWindows,gAlarmAllDoorsAndWindows) {alarmdecoder="RFX:0855529#contact,bitmask=0x20"}
Contact alarmContactZone37UpstairsMotion "Upstairs Motion" (gAlarmContacts,gAlarmAllSensors,gAlarmAllMotion,gAlarmAllSensorsUpstairs) {alarmdecoder="RFX:0638432#contact,bitmask=0x80"}

Switch zwave_switch_kitchen "Kitchen Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesIndoor, gGoodNightGroup) ["Lighting"]  { channel="zwave:device:16892085d79:node4:switch_binary" }
Dimmer zwave_switch_dining "Dining Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesIndoor, gGoodNightGroup) ["Lighting"] { channel="zwave:device:16892085d79:node5:switch_dimmer" } 
Dimmer zwave_switch_living "Living Room Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesIndoor, gGoodNightGroup) ["Lighting"] { channel="zwave:device:16892085d79:node6:switch_dimmer" } 
Switch zwave_switch_frontdoor "Front Door Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesOutdoor) ["Lighting"] { channel="zwave:device:16892085d79:node7:switch_binary" }
Dimmer zwave_switch_backyard "Backyard Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesOutdoor, gGoodNightGroup) ["Lighting"]   { channel="zwave:device:16892085d79:node11:switch_dimmer" }
Switch zwave_switch_by_security "Security Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesOutdoor) ["Lighting"] { expire="30s,command=OFF", channel="zwave:device:16892085d79:node12:switch_binary" }
Dimmer zwave_switch_xmaslights "Christmas Light Switch" <light> (gZwaveSwitches, gZwaveAll, gZwaveSwitchesOutdoor, gGoodNightGroup) ["Lighting"]   { channel="zwave:device:16892085d79:node13:switch_dimmer" }

You get the idea… Didn’t wanna fill the page with my things/items lol

So just looking at an item name, I know exactly what it does, and where it is located. And of course with 200+ items, it’s nice to have a folder search for a string. Notepad++ works wonders. VS Code does too

[HomeAutomation]

I use something similar but I confuse the syntax highlighting/coloring feature of VSC.

My idea is to start every item with his type to have an overview in my rule how to use it.

String stText for Strings
Number nuValue for Numbers
Group gnuAllItems for groups with number items
...

But it looks like the first lower character confuses VSC and does not color the item in the right way. If I use a upper case as first character it is working.

This leads me to the question:
What is the implemented syntax coloring trigger of items, things, groups, … in VSC OH extention?
It looks like rule language code words like Item, switch, case, are working right.

[thissiac (Chris)]

Hi Lucky,

this is also a good approach.

[vzorglub (Vincent Regaud)]

I use a location/function based convention:
Room_Device_Function

Number LivingRoom_Thermostat_TargetTemp
Switch LivingRoom_WallSwitch_Left
Contact LivingRoom_Window_TopLeft

My groups are plurals:

Group Temperatures
Group:Contact  Windows
Group:Contact LivingRoom_Windows

This approach allows this:

Design Pattern: Associated Items

Please see Design Pattern: What is a Design Pattern and How Do I Use Them for how to read and use DPs. Problem Statement Often one will have a number of separate Items which are all related to each other in some way. For example, one might have a Contact on a door and a DateTime to represent when the last time the door was opened. This is easy enough to keep track of if there are only one or two such Items, but if one has a lot of similar Items or is using a lot of generically coded rules where…

and

Design Pattern: Working with Groups in Rules

Please see Design Pattern: What is a Design Pattern and How Do I Use Them for how to read and use DPs. Problem Statement Often one finds a number of Rules that are very similar and that all work on similar Items resulting in a lot of duplicated code. One way to solve this problem is through the use of Groups. Concept [image] This DP is not a standard DP in that it provides a single concrete template to follow to solve a specific problem. Instead this DP is more of a grand exploration of some …

And results in nice short code.
I have ONE rule for ALL my windows for alarm example
Or this in my heating rules:

rule "Generic Windows Changed"
when
    Member of HeatingWindows changed or
    Member of Radiators changed
then
    if (previousState == NULL) return;
    val String room = triggeringItem.name.split("_").get(0)
    val GroupItem window = Windows.members.filter[ i | i.name.contains(room) ].head as GroupItem
    val SwitchItem radiator = Radiators.members.filter [ i | i.name.contains(room) ].head as SwitchItem
    if (radiator.state == ON) {
        if (window.state == OPEN) {
            sendCommand(room + "_RadiatorValve", "OFF")
            postUpdate(room + "_Thermostat_Mode", "off")
        }
    }
    if (radiator.state == OFF) {
        if (window.state == CLOSED) {
            val offset = House_HeatingOffset.getStateAs(QuantityType).doubleValue
            val target = (Targets.members.filter[ i | i.name.contains(room) ].head.state as QuantityType<Number>).doubleValue
            val ambient = (AmbientTemps.members.filter[ i | i.name.contains(room) ].head.state as QuantityType<Number>).doubleValue
            if (ambient <= (target - (offset / 2))) {
                sendCommand(room + "_RadiatorValve", "ON")
                postUpdate(room + "_Thermostat_Mode", "heat")
            }
        }
    }
end

If a window in a room is opened and the radiator is on then turn it off and vice versa.
Let’s say that the window SmallBedroom_Window changed to OPEN and the
radiator SmallBedroom_RadiatorValve is ON
The rule goes like this:

room = "SmallBedroom" (String)
window = SmallBedroom_Windows (Group Item Contact)
radiator = SmallBedroom_RadiatorValve (Item)
radiator.state is ON
window.state is OPEN
sendCommand "OFF" to "SmallBedroom_RadiatorValve"
sendCommand "off" to "SmallBedroom_ThermostatMode"

If I closed the window and the radiator is off then the rule checks if the room needs heating and opens the valve if needed

ONE rule for ALL the rooms. That can only work if you have a consistent approach to naming your items.
And using _ to separate the Room_Device_Function allows the extraction of the Room or Device from triggeringItem.name to be reused to call other related items.

Does it make sense?

[HomeAutomation]

Yes, this does make sence. I use the same logic and the same seperator

Any hint about this question?
What is the implemented syntax coloring trigger of items, things, groups, … in VSC OH extention?

You use upper first characters and I think you do not run into this problem. But I, in my early OH days, followed the examples in the docs and they start mostly with a lover first character for group naming. I follow this for my items too. Maybe this was a not so good idea. Now most of the items in the docs have a first upper character. Lot of work for me to change it

[vzorglub (Vincent Regaud)]

@HomeAutomation

Lot of work for me to change it

VSC can help you with that and change all instances at once.
You will have problems with persistence though…

[HomeAutomation]

@vzorglub

You will have problems with persistence though…

This is what i mentioned with lot of work All my historical sql-datas will be gone then.

[vzorglub (Vincent Regaud)]

@HomeAutomation

All my historical sql-datas will be gone then

Unless you edit the reference table in sql by hand

[rlkoshak (Rich Koshak)]

@thissiac

Unfortunately I can’t find anything about it in the forum.

There is a posting like this at least once a year. Search results for 'naming convention' - openHAB Community

The funny thing is every time it comes up I’ve changed my convention. And it almost always gets simpler and less rigorous.

@thissiac

It becomes more difficult if MQTT is added. Then the right path has to be defined.

Avoid the leading / in your topic names. That is no longer considered proper use. I forget why. I think it has something to do with messing up subscriptions to wild card topics or something like that. Of course, there are some older firmwares that still use the leading / in topic names. But if you have control over the topics, remove the leading /.

---

OK, here is my two cents. Don’t worry about it too much. You can change your conventions as many times as you want. Sure it is a bit of work to do it but you don’t have to “get it right” immediately. What makes sense for you probably won’t become apparent until you have spent a good deal of time building up your home automation system.

I myself started with a really complicated and thorough naming convention with little leading characters and locations embedded in the name of such. I had to put a chart at the top of one of my .items files and had to keep referring to it to remember the proper convention. It was causing my more work. Any convention you choose should save work.

Also, don’t worry too much about normalizing the Item names with any of the names, topics, or whatever used by the device. The Item is supposed to represent what that device means in your home automation. The fact that this lamp is using zwave and it’s node12 and that one is using Tasmota and uses MQTT topic cmnd/sonoff-4079/POWER is irrelevant. What matters is the first one controls the porch light and the second one controls the light over the sink (for example).

And now, for my convention.

1. Organization

I organize all my Items and Rules by function. All the lighting goes in lights.items, all the hvac and temp/humidity sensors goes in climate.items, and so on.

2. Naming

• Actuators start with “a”.
• Sensors or just data Items start with a “v” for value
• Groups are plural with no leading character, unless the Group’s purpose is to provide a way to control lots of Items (start with a) or aggregate the value of a lot of sensors (start with a v).
• Associated Items, like Vincent described, use the same name as the “main” Item with “_” appended.

That’s it. That’s my complete naming convention.

So, for example, all the Items that are used to control and manage one of my garage doors are:

• Group:Switch aGarageOpeners - Group that stores the action Items for both garage openers.
• Switch aGarageOpener1 - causes the opener to open or close, this is a Proxy Item so I can do stuff before the command is sent to the device
• Switch aGarageOpener1_Cmd - Item is actually connected to the opener, this could be replaced with the MQTT Action
• Contact vGarageOpener1 - sensor that indicates whether the door is open or closed
• Switch vGarageOpener1_Timer - Expire binding timer used to send me an alert when the door has been open for too long
• DateTime vGarageOpener1_LastUpdate - time when the door was last opened

One could argue that the Timer would more appropriately be named aGarageOpener1_Timer but I decided to treat all timers as values. Inconsistent? Perhaps, but it makes sense to me and I’m the only one I have to please (with the naming convention anyway).

I chose this set of Items specifically because it shows why I’ve kept around the a/v prefix. I need some sort of convention to distinguish between the actuator and the sensor. I use a prefix because the associated Items names are defined by suffixes. And it doesn’t get any shorter than a single letter.

That’s it. It is a pretty loose and flexible standard. There is a lot of gray area (see the Timer Item) but that’s OK. It really isn’t super important to be consistent as it is to be intuitive to you. Unlike in most software development activities, you are the sole developer of your home automation so you don’t have to be as rigorous in standards such as these. Using something that makes sense to you is the most important thing. If you are consistently inconsistent then it’s not big deal because it will still be intuitive for you.

One nice thing about this convention is that it lets you establish little mini conventions where it makes sense. For example, with lighting it is pretty useful and important to know where the light is, so include the location in the name for lighting. But the location of a house wide system like central air HVAC doesn’t really even make sense. So why force yourself to include it?

As I mentioned, I find no benefit and actually find it to complicate matters to include the binding, technology, or any other reference to what the device physically is in the Item name. Those are all concerns for Things. Items are used to model you home automation. The fact that it uses zwave is irrelevant. You just need to know it’s a Switch and conceptually what that Switch is controlling. So, to show the difference, I would name a couple of Lucky’s Items as

• vAlarmBatteryLow instead of alarmPanelContactBatteryLow
• vKitchen_Gas instead of arduinoSensor_kitchen_gas
• aKitchen_LightSwich instead of zwave_switch_kitchen, if I didn’t have other light actuators in the kitchen I’d just use aKitchen_Light.

I list these just to show the difference. Lucky’s approach to naming is as valid as mine. Your convention needs to make sense to you.

---

@HomeAutomation

But it looks like the first lower character confuses VSC and does not color the item in the right way. If I use a upper case as first character it is working.

The accepted convention is that Item all start with a capital and use camel case. Many do not follow that convention. I don’t either.

@HomeAutomation

What is the implemented syntax coloring trigger of items, things, groups, … in VSC OH extention?

It’s implemented by the Language Server Protocol service built into OH. VSCode connects to a running OH to have it check the code as you type.

The fact that VSCode doesn’t highlight the Item names really isn’t that big of a deal all things considered. I wouldn’t change your naming convention to make VSCode happy in this instance.

[thissiac (Chris)]

Hi Rich … this approach is completely new for me. Using v/a is very interesting.

You are the first using numbers like 1 or 2 or … . In most examples they use only one item, like contacts or power plugs. In some bigger rooms I have 8-10 power switches or 3-4 lamps. This is why I was wondering never seen number in naming conventions.

And I also changed my naming convention many times

But know I have to find the right one who fits best to my home.

[rlkoshak (Rich Koshak)]

@thissiac

You are the first using numbers like 1 or 2 or … . In most examples they use only one item, like contacts or power plugs. In some bigger rooms I have 8-10 power switches or 3-4 lamps. This is why I was wondering never seen number in naming conventions.

For most people and in most cases, something that tells you more about the location of the device is usually preferable. In my garage door case there are only two. So I could have done something like aGarageOpenerWest and aGarageOpenerEast, but, like I said over and over again above, 1 and 2 was more intuitive to me so that is what I chose.

If numbering your Items makes more sense to you then use that. But for something like lights something indicating the location might be a little more intuitive in the long run.

[luckymallari (Lucky)]

Yup. I agree with @rlkoshak, use a convention that makes sense to you. “Standardized” naming conventions, I guess, were created in the past when you have to work with different programmers/teams and the IDE’s back then were not that smart. Do you guys remember the szVariable days?

[rlkoshak (Rich Koshak)]

I remember when variables could be more than six characters long. Lovely lovely Fortran.

[jvank (Jasper)]

Hi all,

I’ve recently been busy getting more comfortable using the more advanced features of OpenHAB (eg. rules). I thought this would be a good time to perfect my naming convention. For physical switches I strictly follow the below scheme. My virtual switches (spotify binding, gpstracker etc.) don’t really follow a strict naming scheme like my physical ones.

All devices follow this scheme:

OpenHAB Naming Scheme
    - All groups start with 'g' (eg. gClimate)
    - All items follow the 'XX_XX_Name' notation
        - First letter pair signify part of the house
            'GF'  -   Ground Floor
            'FF'  -   First Floor
            'OS'  -   Outside
        - Second letter pair signify location
            'LR'  -   Livingroom
            'BY'  -   Backyard
       - For example:
            'GF_LR_Temperature' (ground floor, livingroom, temperature sensor)
    - Virtual switches follow the 'Binding_Name_Attribute' notation
        - eg. 'Spotify_Home_Volume' (Spotify binding, home account, volume)
        - 'SME_Delivery_Actual' (Smart meter electricity, current delivery)
        - 'SME_Delivery_Actual_W' (Smart meter electricity, current delivery in W)

[Kevin71246 (Kevin b)]

@rlkoshak

t and actually find it to complicate matters to include the binding, technology, or any other reference to what

Rich - I’ve been seeing your name/posts come up quite a bit (I just started using OpenHAB a week ago so I’m TOTALLY new). You sound reputable and like you know what you’re doing so I’m doing my best to do EXACTLY what you do

Reading your post here, I’m not sure if you’re differentiating between Items & Things, and Rules, etc - Mind elaborating so I can duplicate what you do? Eg, how would you name these Things, corresponding items, and Rules, etc? (And what exactly will be more important to keep this convention/used often & need to reference?) I first found out how important Items naming is, when I tried setting up a persistence config for InfluxDB. The automatic “Simple Mode” names are impossible to type into SSH. And am thinking this is just the beginning to make my life miserable if I don’t fix them now. I guess I have to delete all the automatic ones created by PaperUI and re-add them manually.

Few examples we could use:

• Familyroom Light switch
• Familyroom Light Light level Item
• Lutron IP Access Point (smart hub that controls light switches)
• Server_Ping (ping host “server” to see its up)
  – Online, Latency, Last Seen Items
• Server_80 (TCP ping server port 80 to see website is up)
• FamilyRoom Multisensor
  – Temperature, Humidity, Motion Alarm Items
• ZWaveSerialController
• Exec shell command
  – Input, Output, Running Items

I think I’m going to have to use MQTT since I plan to have 3 instances of OpenHAB in 3 remote locations (I saw your comment about that). Also, I’m a little confused because a light switch can be both an actuator and report back a value (light level), so how does that play into your scheme?

Thank you so much & for all you have contributed!

[rlkoshak (Rich Koshak)]

@Kevin71246

you’re differentiating between Items & Things, and Rules

This thread and my posts are strictly about Items.

@Kevin71246

I guess I have to delete all the automatic ones created by PaperUI and re-add them manually.

Yep. I hate simple mode.

I don’t have a convention for Things. I usually try to use something that tells me what it is. But you never actually use a Thing’s name so it’s just for display purposes and to make it easier to find. You use the Thing ID which you can’t change.

Same goes for Rules. In Rules DSL, the babe just needs to be unique. I like to make it descriptive, but beyond that it doesn’t really matter. For Scripted Automation, the name is a little more important as you can use the name from a rule to enable/disable that rule. But still, the same applies, user something unique and descriptive.

Is only Items that I have a convention for and the main goal for the convention is you should never have to look at a table it do a lot of mental algebra to figure it what an Item represents. You should be able to figure out the Item’s name just by looking at the device or figure out the device by the Item’s name.

So I have few rules for item naming.

1. Start with “v” to denote a read only value, e.g. temperature reading
2. Start with an “a” to denote an actuator, e.g a light switch
3. Groups are plural

Beyond that, context drives the name. Stuff like how the Item is used in rules, associated items design pattern and the like.

Don’t be complicated. Don’t be overly prescriptive. And don’t worry about it too much. The scheme needs to work for you, no one else.

• Familyroom Light switch: aFamilyRoom_Mantil_Lamp, you may have more than one light in that room
• Familyroom Light Light level Item: vFamilyRoom_Light
• Lutron IP Access Point: you don’t say what this item does. If it’s just the online status I’d call it vLutron_Status

And so on.

@Kevin71246

Also, I’m a little confused because a light switch can be both an actuator and report back a value (light level),

It’d be different Items then. One for the switch and another for the light level. An item can only represent one value or one thing to actuate. A thermostat may have half a dozen items or more.