YAGSA - Yet Another Group Structure Approach

Very interesting post, and I must say, a well though through concept!

As many others, I guess, I have spent some time myself on coming up with a naming convention, but in my case only for items so far. Next on my list was groups, but I think I will pick-and-choose from this thread, :slight_smile:

The naming convention that I am using for items across my system - and that have not broken down so far - is as follows:

[<Where>_][<What>_]<Type><Property>[_<Attribute>]

Where:
    Living room, outside, etc.

What:
    Door, lamp, etc.

Type:
    a   - actuator (connected to a binding); both postUpdate and sendCommand are relevant.
    s   - sensor (connected to a binding); only postUpdate is relevant.
    t   - timer (connected to 'expire'-binding); is this needed/meaningful?
    v   - virtual (not connected to a binding; only modified by rules or UI); both postUpdate and sendCommand are relevant.

Property:
    Temperature, humidity, power, etc.    

Attribute:
    Last update, last change, etc.

Where, what, property and attribute are all "upper camel case" (ex. ThisIsAnExample). 

The “attribute” part is basically the same as described here: Design Pattern: Associated Items

Here are some examples:

LivingRoom_sTemperature
LivingRoom_Light_aDimmer
LivingRoom_TV_aPower

==

When it comes to groups, what I have considered so far is that I want to be able to describe my system in “three models”:

  1. Device-centric (i.e. things. This is mostly for debugging/maintenance)
  2. Location-centric (i.e. floors, rooms, garden, etc.)
  3. Function-centric (i.e. heating, lighting, etc.)

This matches very well what the original post describes.

2 Likes