Items file structure

I have found a lot of (old) posts and questions related to this subject, but no answer. I wonder if I missed something, because it seems so obvious.

Within ‘things’ files we are able to group channels within a thing and allow for some form of hierarchical addressing, e.g.:

Bridge mqtt:broker:mosquitto {
    Thing topic 4ch_switch  {
        Channels: 
            Type switch : power12v    [ stateTopic="stat/sonoff//4ch/POWER1"] 
            Type switch : power220v  [ stateTopic="stat/sonoff/4ch/POWER2" ]              
    }  
}
// just an illustrative example, might not be syntactically correct. 

Where a channel is addressed in the items file as:

Switch mySwitch { channel = "mqtt:topic:mosquitto:4ch_switch:power12vl"  }

Which seems logical and follows an hierarchical addressing scheme. (although imho it would be cleaner if the bridge “mqtt:broker:mosquitto” would also have a symbolical name and ‘topic’ would become after the bridge name)

However, with item naming I always find myself creating a kind of chaos with long names and underscores e.g.

Switch groundFloor_rear_garden_lamp1 { channel = "... "}
Switch groundFloor_rear_garden_lamp2 { channel = "... "}
Switch groundFloor_rear_garden_lamp3 { channel = "... "}

Is it possible somehow (or considered) to follow a more hierarchical approach here, something like:

groundFloor_rear_garden {
   Switch lamp1 { channel = "... "}
   Switch lamp1 { channel = "... "}
   Switch lamp1 { channel = "... "}
 }

It improves readability and makes it also easier to maintain.

What you are probably looking for is the Group concept. Creating the groups as you suggested is not possible since an item might be a member of several groups, for example a lamp might be a member of a room group and of the global group of all.lamps.

Beware of relying on old posts, the syntax for linking an item changed from openHAB1 to openHAB2 and no one stated the version when there was only version 1.

And they are dropping the digit again in OH3 naming. :frowning:

The formally naming of the files and folders is NOT the same as the naming in the forum!

Thanks for your reply.
I am aware of the groups property (and use it as well) , however I was more referring to the textual structure of the file.

Group is still part of the item line:
Switch groundFloor_rear_garden_lamp1 (gLights) { channel = "… "}

By adding all those properties a defintion for an item becomes long, where the majority of information is repeated for similar items.

Using your example the item name would not be unique (the upper level name [ground_floor_rear_garden] be needed as well. Try to call on such an item from as rule.
And I would assume your items lamp1, lamp1… should be named lamp1,lamp2…

However, as this is an open source project anybody can create a code change and post it as a pull request on github.

I think what your are asking is this

My thing file

Bridge mqtt:broker:myMQTTBroker [ host ="192.168.1.148", clientID ="myMQTTClient" ]
{
 
    Thing topic fan1 "Dining FAN" [ availabilityTopic="IFANdining/tele/LWT", payloadAvailable="Online", payloadNotAvailable="Offline"] {
    Channels:
        Type switch : Power1   "Dining Light "  [ stateTopic = "IFANdining/stat/POWER", commandTopic = "IFANdining/cmnd/POWER", on="ON", off="OFF" ]
        Type dimmer : fanspeed "Fan Speed"      [ stateTopic = "IFANdining/stat/FANSPEED", transformationPattern = "JSONPATH:$.FanSpeed", commandTopic ="IFANdining/cmnd/FANSPEED", 0="OFF", 1="LOW", 2="MED", 3="HIGH", 2=100  ]
      }
    
    Thing topic fan2 "Anabel FAN" [ availabilityTopic ="AIFAN/tele/LWT", payloadAvailable ="Online", payloadNotAvailable ="Offline"] {
    Channels:
        Type switch : Power1   "Anabel Light "  [ stateTopic ="AIFAN/stat/POWER", commandTopic ="AIFAN/cmnd/POWER", on="ON", off="OFF" ]
        Type dimmer : fanspeed "Anabel Fan"     [ stateTopic ="AIFAN/stat/FANSPEED", transformationPattern ="JSONPATH:$.FanSpeed", commandTopic ="AIFAN/cmnd/FANSPEED", 0="OFF", 1="LOW", 2="MED", 3="HIGH", 2=100  ]
      }

    Thing topic Kettle "Kettle in Kitchen" @ "Kitchen" [ availabilityTopic ="tele/kettle/LWT", payloadAvailable ="Online", payloadNotAvailable ="Offline"] {
    Channels:
        Type switch : PowerSwitch  [ stateTopic ="stat/kettle/POWER", commandTopic ="cmnd/kettle/POWER", on="ON", off="OFF"]
        Type string : WarmMode [ commandTopic ="cmnd/kettle/TuyaSend4"]
        Type number : temperature "Temperature [%.0f °C]" [ stateTopic ="tele/kettle/TUYARECEIVED", transformationPattern ="REGEX:(.*DpId\":5.*)∩JSONPATH:$.TuyaReceived.DpIdData∩JS:HEXtoDEC.js"  ]
      }
// More things here 
}

If you want to add things to different files hover use the same broker connection you can do that too

Thing mqtt:topic:myMQTTBroker:Absorbar "Absorbar" (mqtt:broker:myMQTTBroker) @ "Kitchen"{
Channels:
      Type switch : Power "Power" [ commandTopic="broadlink/absorbar/power", stateTopic="broadlink/absorbar/power", on="ON", off="OFF" ]
      Type switch : Light "Light" [ commandTopic="broadlink/absorbar/light", stateTopic="broadlink/absorbar/light", on="ON", off="OFF"  ]
      Type string : Move  "FAN Move" [ commandTopic="broadlink/absorbar/move" ]
      Type switch : switch "Lights" [ commandTopic="zigbee2mqtt/living_room_lights/set", stateTopic="zigbee2mqtt/living_room_lights", transformationPattern="JSONPATH:$.state", formatBeforePublish="{\"state\":\"%s\"}", on="ON", off="OFF" ]
      Type dimmer : dimmer "Dimmer" [ commandTopic="zigbee2mqtt/living_room_lights/set", stateTopic="zigbee2mqtt/living_room_lights", transformationPattern="JSONPATH:$.brightness", formatBeforePublish="{\"brightness\":%s}",  min=0, max=255, step=1 ]
      Type switch : secondswitch "Test 2Lights" [ commandTopic="zigbee2mqtt/living_room_lights/set", stateTopic="zigbee2mqtt/living_room_lights", transformationPattern="JSONPATH:$.state", formatBeforePublish="{\"state\":\"%s\"}", 1="ON", 0="OFF" ] 

  }

^ You can see how you can group two different technologies into one topic

It seems my point is not completely clear :slight_smile:

Currently the items file (simplified) looks like this:

Switch groundFloor_RearGarden_Terrace_lamp1    { channel: .... }
Switch groundFloor_RearGarden_Terrace_lamp2    { channel: .... }
Switch groundFloor_RearGarden_Terrace_lamp3    { channel: .... }	
Switch groundFloor_RearGarden_Terrace_heater   { channel: .... }

Switch firstFloor_Bedroom_CeilingLamp    	   { channel: .... }
Switch firstFloor_Bedroom_WallLamp   		   { channel: .... }
Switch firstFloor_Bedroom_BedLamp    		   { channel: .... }

It contains a lot of repeated information, which does not improve readability and maintainability.
it gets more cluttered if you include groups and labels.

I prefer something like this (which is similar how the “things file” can be structured)

groundFloor_RearGarden_Terrace {
    lamp1    { channel: .... }
    lamp2    { channel: .... }
    lamp3    { channel: .... }
    lamp4    { channel: .... }
}


firstFloor_Bedroom {
    CeilingLamp    	   { channel: .... }
    WallLamp   		   { channel: .... }
    BedLamp    		   { channel: .... }
}

There is no way to do that with Items. It’s a flat structure.

They must each have unique names. So even using Groups , you could not have groupa:lightx and groupb:lightx “compound references” as different Items.

If it is all about

you do know that an items file can have comments and you do know that you can have separated items files.

I use comments in the configuration files and I use multiple items files to group items.

But that does not remove the fact that if Items are named by location (I expect that most people add assemble the item name from the locantion where the item is, but I might be wrong), the location is repeated for each item.

In my last example, when using it in rules it would then be: firstFloor_Bedroom:CeilingLamp

I was just wondering if something was possible, since for “things” it works like this.

If you mean by ‘something was possible’ if it’s currently possible than the answer is no.

If you mean by ‘something was possible’ if it’s something that could be implemented that the answer is yes if someone would implement it.

I meant “currently possible” :slight_smile: