The e-magazine for KNX home & building control

Project Haystack: a Boon to Bringing Order to Group Address Naming Conventions?

Simon-BuddleBy Simon Buddle, Future Ready Homes.

So much of what we do as an industry requires absolute precision. From the choice of actuators for a specific function, to communication devices that control third-party products. Is it Modbus RTU or Modbus ASCII? Buy the wrong device and not only are you unable to communicate with the device but you’re also a few hundred quid out of pocket. Switch plates require focus and diligent documentation (with the customer) to ensure we order and install what has been requested. Is the colour right? Square edges or bevelled? Surface- or flush-mounted? Two buttons, four or eight? We are engineers and engineering is a trade based upon precision.

And yet when it comes to the ETS Group Address (GA) structures and their naming conventions, the neat and ordered world of the engineer inexplicably unravels into a near- chaotic free-for-all.

I have, over the years, seen quite a few different methods of creating the GA structure. The one taught during training is to assign each switch and actuator a unique ID. Then using the room name, use both of those IDs to create the GAs. That’s great in a classroom, but in practice, inputs and outputs often move around onsite due to any number of reasons.

Creating a Group Address using a unique switch or actuator ID combined with the room name.
Creating a Group Address using a unique switch or actuator ID combined with the room name.

Another method is to organise by function so that we have separate middle groups in, for example, lighting for switching and dimming functions. All well and good, but you can’t see an entire room lighting at one glance.

Group Addresses organised by function.
Group Addresses organised by function.

And then there are those programs that simply use the name of the Group Objects as they appear listed on the device.

Group Objects as they appear listed on the device.
Group Objects as they appear listed on the device.

Each individual or company will have a proven way to layout the Group Addresses. I know one company who used a Spanish KNX programmer, and despite all of their protestations, they couldn’t get him to write them in English. Now that he has moved on, they need a translator each time they go back to one of his old projects.

I use a structure that goes by discipline (lighting, heating, etc.) and then by house floor. My GAs are always the same from project to project, because I spent some time writing a small piece of Visual Basic code that enables me to simply write floor names, room names and circuit names into a couple of lists and the code auto-populates the Group Addresses from this data input. However, it is still different to the next person’s method.

Our programming world has many tendrils that require connections to Modbus (which has several versions; IP, RTU, ASCII), BACnet, C-Bus, XML, and LonWorks and each has its own unique language constructs and constraints.


Data is only useful if we know what its context is. For example, we can attach an oscilloscope to a data stream and read packet by packet the chain of zeros and ones and get the following bytes:


But that means nothing without context. It is in fact my first name converted from ASCII into binary.

The message here is simple: we live and work in a data-rich, multi-disciplinary, multi-protocol, interconnected world. Our own naming conventions play into the myriad of cracks that information might fall through. It is a wonder we manage to get anything to work at all never mind in a simple, seamless and integrated way.

Project Haystack

Project Haystack might be the solution we didn’t know we needed. To quote from its website, “Project Haystack is an open source initiative to streamline working with data from the Internet of Things. We standardise semantic data models and web services with the goal of making it easier to unlock value from the vast quantity of data being generated by the smart devices that permeate our homes, buildings, factories, and cities. Applications include automation, control, energy, HVAC, lighting, and other environmental systems.”

The essence of Project Haystack is a standardised method for naming and tagging data such that the data becomes self-describing.

To quote again from the website, “Haystack doesn’t prescribe any specific design on how entities are stored or managed, rather it defines how to tag those entities with specific name/value pairs. By using a library of standardised tags, we can build a taxonomy that allows semantic understanding across the industry. The end result: we can all save money on the labour-intensive task of mapping data from one proprietary system to another.” is an associate member, and I can see value in that.

Project Haystack founding/board and associate members.
Project Haystack founding/board and associate members.

The tagging structure creates an Entity out of a device, a row in a CSV file or a specific data point.

The following is an example of an Entity:

id: @weather.washington.humidity
dis: “Weather in Washing, DC – Humidity”
weatherRef: @weather.washington
kind: “Number”
unit: “%RH”

This Entity is transmitting the relative humidity from a known weather station in Washington. It carries all of the information we need; where the data comes from, what the data type is, what the sensor type is and how to read the value. In a sense, it is all of the different methods of naming or creating a Group Address structure rolled in to one. Someone has brought order to the chaos.


Will we see the Project Haystack data tagging system adopted for ETS programming? Even before that, will it become the ubiquitous solution for data transfer between smart devices? If both of those happened, it would be a fantastic boon for all concerned. However, for me, it has made me relook at what data is important and made me re-evaluate how I label it. It’s made me think in a more structured way about how I use my Group Addresses.

Simon Buddle CEng MIET, is a consultant for Future Ready Homes, a specialist in BMS and ELV services system design.

Share on facebook
Share on twitter
Share on linkedin


JUNG area / line coupler

JUNG area / line coupler
The JUNG area / line coupler connects two KNX lines while retaining electrical isolation. Across publicly accessible areas, such as corridors ...