By Simon Buddle, Future Ready Homes.
Feedback takes many forms, from the HR (Human Resources) interview or personal appraisal (urgh – not my cup of tea), to the nostalgic car driver who loves the feedback they get from the road through the steering wheel of a old car. The feedback one gets, in this instance, is very real; the car wheels and the steering wheel are mechanically connected, so what happens on the road can be felt in the steering wheel. And one might venture to suggest that some drivers will adjust their driving on the basis of that feedback. Those drivers may not like what the future holds for us!
What is feedback?
There are many definitions of feedback, and I would like to draw on a few examples in order to emphasise a couple of points:
• Process in which the effect or output of an action is ‘returned’ (fed-back) to modify the next action.
• Feedback is essential to the working and survival of all regulatory mechanisms found throughout living and non-living nature.
• As a two-way flow, feedback is inherent to all interactions, whether human-to-human, human-to-machine, or machine-to-machine.
• In an organisational context, feedback is the information sent to an entity (individual or a group) about its prior behaviour so that the entity may adjust its current and future behaviour to achieve the desired result.
Feedback in control systems
In control systems, feedback is the return of a portion of the output of a process or system to the input, especially when used to maintain performance or to control a system or process.
The most common general-purpose controller using a control-loop feedback mechanism is a proportional-integral-derivative (PID) controller. As a rule of thumb, the terms of a PID controller are dependent on time: the proportional term depends on the present error; the integral term on the accumulation of past errors; and the derivative term is a prediction of future error, based on current rate of change.
In the KNX world, the PID controller helps us to modify the next action as it regulates and adjusts current and future behaviour. It is everywhere in our world, controlling lighting levels and temperatures – both actual and desired – using error messages from temperature sensors, the status of doors, gates, plant room equipment, and so on. I must know the temperature of the hot water in the tank in order to decide whether I need to turn the boiler back, and I need something to feedback that information into my system.
Temperature and comfort mode
Let’s get a little deeper in to this. Imagine we have a graphical user interface – it doesn’t matter whose – and on it we have the following controls and information:
• Set point up and down.
• Mode set – comfort, night, standby.
We will of course also need to display the actual room temperature.
As we know when we change modes, we affect our deadband (neutral zone where no action occurs in order to prevent oscillation between cooling and heating) settings. Typically, using relative set points, we might find a scenario such as this:
In Comfort Mode our base or reference setpoint might be 21oC. The other two modes will be referenced from this and may be -2 and -4 respectively. In Comfort Mode, the room will stay at 21oC. So far so good. However, let’s now change the mode to Standby. By doing this, our setpoint will change from 21oC to, say, 17oC. OK so that’s all fine, except that if we haven’t fed back the new set point to our screen, the client still thinks that it is set to 21oC. However, in the background the system is now working with a setpoint of 17oC. And what that means for the customer is that they will see the rooms actual temperature drop until it goes below seventeen before the heating will come back on. The system is doing what it should, but the customer will think that it’s broken because it isn’t turning the heating on to get the room to the displayed setpoint of 21o C.
Setpoints are tricky because there are so many options and they can be changed by timers, by user interfaces, by keypads and indeed by other overarching control systems. Therefore, knowing the real setpoint that the actual thermostat device is working to is an absolute must.
Remote monitoring and maintenance
There is little point offering remote monitoring if the information you can see in the diagnostics window is not real feedback. Take the simple example of turning on a dimming actuator. I can turn it on, send it to a percentage value or dim it up or down. All of these commands are being sent to the dimming actuator. However, what I want to know from the actuator is what it has done. And that may not be the same as what I told it to do. If I get a message or status back from the actuator that informs me that it has switched on, then I can be reasonably sure that my dimmer is working. That simple status message can help to diagnose the issue of the light not coming on remotely, and it is likely, in this instance, that the lamp has failed. I haven’t had a wasted journey to the customer’s house just to change a light bulb.
Conclusion
I’ve seen many systems that completely ignore feedback, and in many instances, people get away with it. Getting feedback working correctly between user interfaces and devices can be tricky, and a little bit of experimentation may be needed in order to get it working. But just because it isn’t easy doesn’t mean we shouldn’t do it.
If we provide our customers with information on their screens or keypads, it must be correct. If it isn’t, it’s not worth the time you wasted putting it there. Indeed, I’d say that no information is better than incorrect information. If this stuff were easy, everybody would be doing it. We do it because we know how to add value to the installation and give the customer a system that is great. As Einstein said, “The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.”
Simon Buddle is a consultant for Future Ready Homes, a specialist in BMS and ELV services system design.
