Simon Buddle discusses how using KNX to control units for block-wide BMS controls is not only achievable but financially advantageous, and argues why fan coil unit manufacturers should build KNX devices directly into their units.
The work morning begins at 7am; grab a coffee, check the inbox whilst sitting on the ‘outbox’, and during these fresh late winter mornings turn the car heaters on before venturing outside. Now that is a step forward. No scraping of ice from windscreens, seat nicely warm before you arrive, and cabin temperature approaching something like an acceptable level. Getting the AC (Air-Conditioning) on is something we can all do via our KNX controls of course, so for us, remote control of temperature is nothing new.
HVAC acronyms
AC is only one of many acronyms we hear bandied about as part of any smart home installation. We have MVHR, FCU, AHU, HRU, HIU, CIU… the list goes on. But what are they and why do we need to know about them? They provide either heat, fresh air or cooling into the home.
The MVHR (Mechanical Ventilation and Heat Recovery) unit is a direct replacement for the traditional 4” fan that would typically have been installed in a bathroom or kitchen. It is designed to run 24/7 in ‘trickle’ mode, exchanging a small volume of stale air in the home for fresh air pulled in from outside. During this process, the unit cleverly extracts heat from the stale air and passes it to the fresh air. In addition to trickle mode, it also has a boost function. This should be triggered when the bathroom is in use – just like an old 4” fan – or when someone is cooking. KNX can easily achieve this by either connecting to the lights in the bathroom and/or using a humidity threshold sensor to trigger the boost function.
An AHU (Air Handling Unit) does a similar job, but without the heat recovery. An HRU (Heat Recovery Unit) is fundamentally doing the same job as the MVHR.
FCU vs AC
In simple terms, an AC system generates its own cooling or heating whereas an FCU (Fan Coil Unit) is supplied with cold or hot water from another system, typically a block-wide system. The hot or cold water comes via the HIU (Heat Interface Unit) or CIU (Cooling Interface Unit) – more on them later.
For AC, KNX control is straightforward insofar as all we need to do is establish the make and model and choose from a myriad of pre-configured KNX interfaces. Zennio and Intesis both have a strong selection of options.
The FCU however, is a bit of an outlier. You will often find communications to the FCU are done via BACnet or a similar protocol. KNX-to-BACnet communications are robust, and there are many options to achieve the desired outcome.
Three simple elements to control heating or cooling in a room
There is, however, a school of thought that suggests we should be using KNX devices directly in the FCU. The basic control of an FCU is achieved by three primary elements: one hot water valve, one cold water valve, and a fan. If I open the cold valve allowing water to pass through the FCU’s cold coil (of pipe) and then blow air across that pipework, the air will be cooled when it is blown into the room. Close the cold valve and open the hot and the opposite is true.
These three simple elements are all that is required to provide the heating or cooling for the room. If you add to this temperature and fault monitoring, you absolutely have everything you need to control and monitor the unit. Most fan coils use a proportional 0-10V signal to drive the hot/cold valves, and again, typically, the fan is simply operated using a 0-10V signal as the speed control. Gira, Jung, Zennio, and ABB all have products suitable for this role.
Manufacturers – build KNX devices directly into your units!
And here’s the pertinent point from my perspective; the FCU manufacturer needs controls of some sort to operate the unit, so why not use KNX devices built directly into the FCU? That way we have total system control without jumping between communication protocols and necessarily creating demarcation lines between systems, which then require multiple engineers playing battleships in order to solve any functionality problems that may arise. This makes perfect sense to me, technically, financially, and even for maintenance.
Why else is KNX the right solution?
As mentioned earlier, the FCU does not generate heat/cooling – it arrives from a block-wide plant room. This is where the aforementioned HIU/CIU comes in. Across the block, hot and cold water are permanently available. If the apartment requires heat, it needs to give a signal to the HIU to run the pump and valve to allow hot water into the property. This is simply done by use of a volt-free contact within the HIU.
If I have 10 FCUs across the building, I’ll also need to have a simple OR gate bit of logic to say that if any one of the FCUs is demanding heat, then trigger the HIU to operate. Everything I’ve described is achievable in a simple, robust, and repeatable way using KNX devices. Indeed, I would go so far as to say it is a cheaper solution than jumping between protocols and proprietary solutions.
Conclusion
Using KNX to control units that may typically have formed part of the block-wide BMS (Building Management System) controls is not only achievable but financially advantageous, both at the time of purchase and as part of ongoing maintenance. For us, the important point is to introduce the idea at design concept planning stage and provide the M&E team with the confidence that, not only will we achieve a successful outcome, but that it will continue to perform way into the future. M&E consultants have a habit of staying with what they know, so if we can convince them to choose KNX, it may just become ‘what they know’ and that is good for everyone.
Simon Buddle CEng MIET, is a consultant for Future Ready Homes, a specialist in BMS and ELV services system design.
