KNX Naming and Numbering Conventions

Device Identifier Strings

In various different places within the Home Automation systems it’s necessary to have a short but unique identifier for each Device (lamp, blind etc.). KNX by itself doesn’t necessarily need this since it has other tools for organisation of Devices but other supporting systems definitely benefit from a structured identification scheme – and it’s very helpful if the same names are used across multiple systems.

There are various schemes recommended by different people but they all seem to boil down to a composite string made up of 3 elements:

  • An identifier for the Room
  • An identifier for the “Trade” – i.e. the type of device (lighting, heating, blind etc.)
  • An identifier for the Device (within a Room and a Trade)

The device identifier always tends to be placed last but some people put the Room first and others put the Trade first. On a large project you can see how putting the Trade first would make sense – so the lighting team can filter based on their prefix – but on a small project where one person / team is programming all the trades I recommend putting the Room first.

Room Identifiers

Different guidelines reference different schemes for Room Identifiers, some based on a letter for the Floor and a number for the Room (e.g. G.03 for the 3rd room on the Ground Floor) and some with just a number (e.g. 17 for “the 17th room”).

My preference is to use a 2-character Room code, for example:

  • B2 is Bedroom 2
  • E3 is the En-suite bathroom to Bedroom 3
  • LR is the Living Room
  • FL is the First-floor Landing
  • OS is Outside

Device Type Identifiers

The KNX guidelines propose a series of 1 and 2 character codes for device types – e.g. L for Light, W for Window, SH for Shutter, LD for Light (Dimmable). I prefer to always have 2 characters, so the overall identifier is always the same number of characters, but to keep the first character indicating the Trade, so I use:

  • HS for Heating (Switchable)
  • LD for Light (Dimmable)
  • LS for Light (Switchable)
  • ST for Sensor (Temperature)
  • WA for Window Actuator
  • WB for Window Blind

Device Numbers

Device numbers are easy – just a fixed-length number (with leading zeros) to identify the first, second, third etc. devices of a particular type in a particular room.

That results in composite strings such as the following:

  • DR_LD_02 – the 2nd dimmable light in the Dining Room
  • SL_WA_01 – the 1st window actuator on the Second-floor Landing

 

KNX Group Addresses

With the KNX system, Group Addresses are used to link together the various functions on various devices – for example so that a PIR sensor will turn on a light when it’s activated. Each device needs multiple Group Addresses, and the quantity required depends on the  nature of the device – for example:

  • A simple switched light needs 2 Group Addresses
    • One to Set the On/Off status
    • One to Query the On/Off status
  • A dimmable light needs at least 5 Group Addresses
    • One to Set the On/Off status
    • One to Query the On/Off status
    • One to Dim Brighter or Darker
    • One to Set a specific dimming Value
    • One to Query a specific dimming Value
    • (Optionally) One or more to report bulb failure status, if the driver supports that

It is pretty much essential to follow some sort of convention to keep track of which Group Addresses relate to which functions on which devices, and various people recommend different addressing conventions.

It’s common to adopt the “three level” Group Address hierarchy, in which the three levels consist of:

  1. Up to 31 “Main Groups”
  2. Up to 7 “Middle Groups” within each Main Group
  3. Up to 255 “Group Addresses” within each Middle Group

The limited number of Middle Groups means those are best suited to separating out the different types of Devices – Lights, Blinds, Heating, Windows etc. Assuming there are fewer than 31 rooms, using a separate Main Group for each Room can work well. Alternatively, many people advocate using the Main Groups to separate out different Floors – so we’ll do that.

No matter how the higher levels are structured, you always end up with several Lights or Blinds etc. needing Group Addresses within one Middle Group, and the best way to handle that is to batch them in groups of 5 or (preferably) 10 so that 11, 21, 31, 41 etc. relate to the same Function on different Devices.

In other words:

  • The first Light (on a Floor) gets assigned a block of Group Addresses starting with 001
  • The second Light gets assigned a block of Group Addresses starting with 011
  • The third Light gets assigned a block of Group Addresses starting with 021 – and so on

Another consideration is how to sequence the different Functions within a set of Group Addresses. There doesn’t seem to be any standard. What works well for me – because I (used to) use openHAB – is to order the Functions so that the entries in the KNX binding field in the openHAB “items” file are in sequential order:

  • For dimmable lights, that order is:
    1. Set Status (On or Off)
    2. Get Status (On or Off)
    3. Dimming
    4. Set Value (Percentage Dimmed)
    5. Get Value (Percentage Dimmed)
  • For blinds (treated as Roller Shutters), that order is:
    • Set Status (Open or Closed)
    • Get Status (Open or Closed)
    • Stop
    • Set Value (Percentage Closed)
    • Get Value (Percentage Closed)

(That ordering is dictated by the order of “acceptedCommandTypes” in the DimmerItem and RollerShutterItem source files)

References

 

CC BY-SA 4.0 KNX Naming and Numbering Conventions by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.