Networking Lighting Controls

Oct 9, 2019

By Steve Mesh

What is a “network”? One definition of “network” (from the Merriam-Webster app on my iPhone) is… “an interconnected or interrelated chain, group, or system.”

What kinds of components exist in a networked lighting control (NLC) system? That can vary from system to system. Are there basic elements that must be present in order to know that you have a bonafide actual lighting control system? There sure are. Here are six.

Luminaires — there must be some way of controlling the luminaires themselves. If you have no way of controlling the luminaires, then what you have is decidedly not a lighting control system! Typically, luminaires are switched on/off and dimmed up/down by on-board “controllers”. In some cases, the controllers are centralized and do not reside in every single luminaire.

Some NLC systems offer higher-amperage controllers that can be used to control an entire group (or “zone”) of luminaires. One example might be round LED downlights in a corridor. You might only want those to turn on/off or dim up/down altogether, not individually. If you’re absolutely certain of that, then using a higher-amperage controller upstream of each fixture might make perfect sense. Otherwise, having fixture-integrated controllers for maximum flexibility may be preferable.

Some systems may only have controllers that are located at the very center of the system – meaning possibly in the electrical closet or IT room. In that case, the “zoning” is purely based on the physical wiring from those centralized controllers to the luminaires. Those systems are on the DLC Qualified Products List for exactly that reason. Systems that meet the DLC criteria for their QPL must have the ability to be individually addressable. That can only happen when an NLC offers controllers that can be embedded into every fixture.

Switches — this is a misnomer. Get in the habit of thinking of these as “manual override devices.” Why? Because in an NLC, the behaviour of luminaires is probably going to be pre-programmed. In an NLC, if something looks like a switch and smells like a switch, it’s probably a “manual override device.” What you’re really doing is temporarily overriding the pre-programmed behaviour, for a certain period of time. In some energy codes, you are only allowed to override the pre-programmed behaviour for up to two hours before the behaviour reverts to the automatic settings.

Almost all installations of NLCs make use of full-range dimming capability. Remember that almost all LED luminaires sold today come with integral dimming drivers, often using the 0-10V protocol for the dimming signal. So that “switch” (um … I mean “manual override device”) usually allows occupants to dim lights up and down as well as switch them on and off.

Occupancy sensors — every NLC system allows you to use occupancy sensors to automatically turn lights on or off, or to dim them up or down – depending on how you program the software. The actual occupancy sensor itself may make use of PIR technology, but it may also use ultrasonic, or both. Or any number of other methods of detecting occupancy or vacancy. Some examples are acoustic, microwave, video, etc.

But there also must be some way of connecting this device to the network, just like the switches (er … I mean “manual override devices).

Photosensors — lighting control systems also have to have some way of detecting the amount of natural light entering a space (or the amount of natural light outdoors in the case of control systems for exterior lighting). Just as with occupancy sensors, the actual sensor technology is essentially the same as it’s been for a while – a photodiode that actually changes the amount of light energy into electricity to send a signal to the system. Just as with occupancy sensors, there must be a way to connect these to the system as well.

You can actually buy a system with only those components. But wait – there’s more! Most NLC systems have a few other components that are required (or at least strongly suggested), such as:

Server – the “server” is merely a computer that is the central brain for the system. If you do not have a central server, then there must be some way of doing simple programming – such as pressing buttons or setting microswitches on the on-board controllers, switches or sensors to do things like assign zones, set behaviours, etc. However, there may be many things you can’t do if the system doesn’t have an actual central server. For example, if there’s no central server, there may be no way to interface with the system – such as to create an external dashboard, or to store energy use history, or even to easily rezone or reprogram the system (not to mention doing things like ADR ). A central server usually allows you to do any and all of these things, and more.

Gateways — in an NLC system, a gateway is a device that allows you to rout multiple “things” back to the central server. These “things” could be either:

• luminaires themselves. For example, in a wireless control system, the wireless gateway is usually what the luminaires communicate with. Then the gateway must somehow be connected to a central server. In some cases, especially with newer “simplified” systems, these are actually combined into one small unit.
• loops of wired networks. For example, in a wired control system, luminaires are usually on a loop of wire connecting back to a gateway. Then, similarly to the wireless system, that gateway is then connected to the central server. In these kinds of gateways, multiple “loops” may be used. These “loops” are not the things that determine “zoning”. Remember that it’s merely a way to connect all luminaires (and/or peripheral devices) back to a central location (the server). Keep in mind that some systems still use the DALI protocol (Digital Addressable Lighting Interface). A DALI “universe” has a limit of 64 “nodes” per universe (loop). Therefore, most spaces will automatically require multiple loops to control all of the luminaires and peripheral devices.

Other things:

Some systems allow you to incorporate thermostats to control the HVAC system. The set points might change based on time of day, occupancy, etc. Some systems provide visibility to the HVAC system and/or the resulting energy savings right in the lighting control system’s dashboard.

Many energy codes currently require you to control at least 50% of the receptacles in many spaces. So lots more systems are offering “plug-load control.” Some wireless systems even offer duplex receptacles where one of the receptacles can actually be controlled by the NLC itself. So for example, it may shut off power to that receptacle when vacancy is detected by the occupancy sensor.

A specific NLC system may in fact require (or at least offer) additional components. That may include things like network bridges, which can essentially be thought of as repeaters to extend the reach of the network, or to allow you to connect other devices (such as a building management system) to the NLC.

There are lots of different kinds and capacities of luminaire controllers, occupancy sensors, photosensors, and manual override devices. But more importantly, every system has its own software/interface. It is super critical for you to develop some understanding of what this software looks like and how it functions, and what capabilities it provides (and doesn’t!) — as much as it’s important for you to understand the hardware itself, and how the pieces all work together.

Lastly, remember that in order to communicate two (or more) components in any system must have a common language. Imagine what would happen at the United Nations if a group of people from different countries were trying to communicate. They might all have different primary languages. So they might either decide to all speak in English, or they might employ translators to translate back into their mother tongues. Each component in an NLC may use different languages (“protocols”) to communicate with the other components in the system. For example, it’s common for systems to use a proprietary protocol to communicate between the central server and a gateway. But in a wireless system, it’s common for the gateway to speak to the luminaires, sensors and switches (er… I mean “manual override devices”) using an open protocol such as Zigbee. Usually, this doesn’t matter very much to the specifier or end user. But it might. So if it does, then it behooves you to learn a bit more about different protocols, or at least to ask very well educated salespeople to explain it.

Armed with this basic understanding of what is in an NLC and how the components communicate with each other, you should be able to go out and try your hand at specifying one now. Good luck!

Published with the permission of Lighting Control Association.

Steven Mesh is an award-winning lighting designer who has designed lighting and control systems for a variety of project types (commercial, museums, schools, residential, restaurants, retail, historic, healthcare, etc.). As an educator, he has taught classes and given presentations about lighting and controls across North America and internationally. One of his is developing lighting and lighting controls courses that rely on hands-on and/or interactive content. He has been a repeat speaker at LightFair for many years.

Image source: Cree Canada