By 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.
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.
And then there are those programs that simply use the name of the 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
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
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.”
KNX.org is an associate member, and I can see value in that.
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
weatherPoint
point
humidity
sensor
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.
Conclusion
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.
