We talked about the technology perhaps we now need to focus on the language used in modern lighting controls solution. Don’t worry I’m not delving into that murky world of programming I leave that to people far more skilled in that area than me!
I believe that in the world of IoT multiple protocols will coexist within buildings in much the same way that we as individuals work within spaces and have to communicate daily. The challenge with technology is that we are not very good at communicating what we want. You only have to look how easily we can offend with the wrong inflection on a word within a mail or text; obvious to you but taken the wrong way by the recipient.
An example would be how we interpret dim the lighting. We have all used the phrase and what we are really saying is reduce the output of the lighting to a level I’m happy with. Now as we know from numerous studies age, sex and a knowledge of lighting can affect how we interpret a light level. It’s open to interpretation whereas a digital value to recall a preset is a precise command, there is no ambiguity, 56% is just that.
Digital commands are therefore more accurate than our interpretation of what we believe is the correct value. That doesn’t make the digital system any more accurate at interpreting our wishes, but it does allow a degree of consistency and in a world where we set values for what is the desired level of lighting for a task then we need some form of structure.
Lighting controls have been digital for many years with languages such as DSI and then DALI and numerous communications languages have been used by different companies to transmit and combine these device protocols.
Historically this worked, but lighting and technology has evolved and like the example I gave earlier if we are to dim or regulate any light source, we need to agree a platform on how we do this. I mentioned that in most smart buildings moving forward we will use multiple protocols and although this isn’t the ideal it’s the reality of how technology evolves.
The choice of protocol shouldn’t be something that limits the functionality, and this is only possible if there is a framework in place that supports these various protocols and allows each to work with the other.
After all the client isn’t an expert in connected systems and neither should they. What they want is something that works and doesn’t lock them in!
Obviously, IEC 62386 Part 101,102, 103 and 104 provide such a framework and using the Application gateway as a conduit to TCP/IP ensures data is centralised to local software or increasingly to the Cloud.
At a device level the commands are known, and we can ask questions and receive answers that can be understood by many different systems, so we have a common language. This works well in Lighting as we have hundreds if not thousands of intelligent devices in our buildings and looking for a limited number of commands ensures we have known responses to occupancy and daylight for example.
The more sophisticated the system and the higher the level of integration the greater the confusion becomes. I have touched on this before and protocols that are referred to as the IoT protocol are very interesting and may well become the technology of choice but is the market ready for them?
As an industry it amazes me that we are still specifying and installing dated systems that haven’t evolved from the platforms that they were originally built around. There have been a few tweaks, but these are patches to support what is often a dated approach.
In the world of DALI-2 we have only just agreed the standard for Wireless DALI which has been published and will be ratified this year with product available early in 2020. Agreeing these standards takes time and commitment from all of the major manufacturers involved in the lighting industry. The infrastructure must be solid and connectivity along with backwards compatibility assured. It’s evolution rather than revolution but with a solution that reflects the way systems function today and in the near future.
Moving to a non-lighting focused protocol may be a reality in the fullness of time but how do we manage these commands. How do we group, regulate and interrogate a device if we don’t have a common approach; a language we can all understand. These IoT protocols may be able to take the DALI data and push this to a hosted software or Cloud but management doesn’t end there.
Lighting Control can be complex but as an industry we have created a structure that provides a choice to the engineer and client that allows them to have the most up to date and flexible system they can. Removing dedicated lighting control functions away from this structure and making it part of a “free form” control philosophy may do more harm than good.
Imagine a sensor that can send data to a software suite where other non-lighting devices are connected. Making that sensor perform a function such as switch on or off is fairly straight forward providing the drivers within the luminaire are all working on the same protocol. Add in daylight dimming and hold override function and change the profiles throughout the day and the level of complexity escalates. Lighting management systems have handled this well for many years and within DALI-2 this has never been easier.
Wireless enabled sensor sends commands to software and in turn the luminaire subscribes to the software tool waiting for an input to trigger a command. All sounds straightforward but do we need to communicate over a Cloud or Software gateway to undertake that function if we can just say Luminaire go on and record that data. At a local level the control is simplified, however the same data can also be sent to the Cloud so it can switch on a Fan coil unit for example.
The functionality will be the same, but the latter is based on DALI whilst the former is based around an IoT protocol.
Don’t get me wrong I am all for smart devices but as we have struggled to agree the update of DALI to wireless how will the lighting industry adapt to other non-lighting focused protocols.
Obviously, this can and will be done but at what cost and what level of integration. There is a perfect opportunity for those less scrupulous to use smoke and mirrors as a way of misrepresenting new technology and we must guard against that.
The rise of the Master Systems Integrator (MSI) will see a wider use of new technologies which if handled well should improve the lit environment but we need to tread cautiously. Not because the technology isn’t there, it is in certain applications, but we do need to educate those specifying and installing the systems. How do you measure performance and agree acceptable levels of integration? How do you value controls, will the old metrics no longer be valid and will the service element of controls be taken as a given.
I wrote so much more on this topic and will add this to a follow up feature but for me, small steps are necessary to bring the industry up to speed and only then can we truly talk about integration. After all no one IoT project is the same and until we agree a holistic approach to the control interface, we will always be left with areas that can be interpreted differently.
Author: Stewart Langdown FSLL
Email: stewart.langdown@ zencontrol.co.uk
Mobile; +44(0)7774 821093