Networked Lighting Controls FAQ
May 25, 2020
By Steve Mesh
Over the past decade, I have taught many classes on networked lighting control systems (NLCs). These classes often start with an academic presentation about a typical NLC’s components, features and benefits. Most of the classes I teach also incorporate hands-on training. In the past decade, I’ve used six different systems covering a wide range of NLC offerings – wired, wireless, DALI, 0-10V, large centralized systems, smaller systems, complex legacy systems, newer “simplified” systems, etc.
Although in theory many of these classes have been geared toward electrical contractors, a variety of people usually attend, including engineers, designers, owners and facilities managers. Remember that a major goal of these classes is to introduce new equipment, topologies, protocols, functionality and concepts to people who are used to hard-wired “unit” controls. Over the years, I’ve seen some recurring themes in terms of questions asked by attendees, such as the following.
1. “Power packs” vs. “controllers”?
Many electrical contractors are familiar with “power packs”. They contain a transformer and a relay. As such, they can provide power to, for example, one or more occupancy sensors. Then based on a signal from the occupancy sensor, they can close the relay to turn lights on. In classes, attendees see “controllers” as opposed to “power packs”. It’s true that a controller contains a relay, used for the same purpose of switching loads on and off. It’s also true that controllers provide low-voltage power — even if it’s just used to energize on-board LED indicator lights and circuitry.
But the big difference between power packs and controllers is that a controller is a device that is networked. These controllers control one or a series of luminaires. This is essentially how you turn a “dumb” luminaire into a “smart” luminaire, by linking it to the NLC through the controller. During the classes, it becomes evident that there must be some method of linking the controller to the system — either with wires, or wirelessly. If it’s a wired system, then the connection may be made using Ethernet cable, 18/2, or some other proprietary or non-proprietary cable.
2. Why are certain devices not connected to luminaires?
Many electrical contractors as well as specifiers (and others) have had lots of experience with wired unit controls, i.e., wallbox dimmers, timers, wallbox occupancy sensors, etc. These are devices that are cut into the line-voltage power distribution wires between the panel and the luminaire. The world of NLCs is quite different. Devices such as switches, dimmers, occupancy sensors, photosensors, touch screens and others are usually not directly connected to the luminaires themselves. These devices typically talk to the server (at least in a centralized system) and do things like issue commands (such as “turn lights on” or “dim lights down”) or provide information (such as the amount of light hitting a photosensor, or whether or not someone is in the space).
In some systems, it’s true that there is a more direct link between a device and a luminaire. For example, in most systems, signals from a wireless switch go directly to the luminaire. The information – for example about when someone hits the “on” or “off” portion of the switch – is also relayed to the system which typically records such events in its history. However, in the case of a break between these components and the gateway and/or server, the switch will continue to function normally. These types of interactions are very different than if you simply cut in a “unit” device such as a wallbox occupancy sensor on the physical switch leg of a zone of lights. So it takes time for some class attendees to adjust their thinking about this.
3. “Star” vs. “mesh” network topologies?
It seems to be a very popular assumption that wireless systems all use “self-healing mesh” network topologies. This is not true! There are systems that use “star” topologies instead. In a self-healing mesh network, any “node” can potentially talk to any other “node”. That doesn’t mean that everything always talks to everything else. That would be a fully connected mesh network. However, in a typical self-healing mesh network topology, connections can be made between components that essentially allow the network to connect back to a central server taking a variety of routes.
The benefit of this topology is that if one component is not operational for any reason, the network traffic can simply reroute itself around that defective component. Some systems, however, have adopted the use of a “star” topology. In these systems, signals from all devices (i.e., luminaire controllers, occupancy sensors, photosensors, switches, etc.) must reach the wireless gateway. In such systems, it’s important to note caveats about recommended maximum distances between components and the gateway, and also about things that attenuate the signal (such as interior partitions). Since there’s no possibility to jump to other nearby devices in the system, the signals from every single luminaire and device absolutely have to reach the gateways — no ifs, ands or buts about it. It should be noted that in some systems, there is an option to turn an individual node (such as a luminaire controller) into a “repeater”.
4. Why do you have to commission one luminaire at a time?
Guess what? You don’t! In a class environment with limited quantities of luminaires, I usually have attendees commission one luminaire at a time, as though that luminaire is representative of a group of fixtures in a particular zone (i.e., eight fixtures in a conference room). I typically do this to give attendees practice at entering different variables for different zones — for things like target light levels, occupancy sensor timeout delays, enabling vs. disabling photosensors, etc. I have to explain that you can discover and add more than one luminaire to a zone at the same time, but that with the limited quantity of luminaires in the class environment we’re not doing that. In some NLC systems, you can discover everything that is on the network and then assign components to zones. In other NLC systems, that process happens one zone at a time. The most important takeaway is for attendees to realize that you don’t have to commission literally one luminaire at a time. That would drive a commissioning agent crazy.
5. “Why do I need to read instruction sheets and look at wiring diagrams?”
Most installing contractors can wire typical “unit” control devices with their eyes closed. However, in every single class, at least one person wires a luminaire controller incorrectly. I tell attendees that the motto of the class is not … “smoke ‘em if you got ‘em”! When other people are stumped by what wire to connect with what, I suggest that they locate the wiring diagram! Additionally, I always check the wiring before attendees energize equipment in the class! Sometimes controllers, sensors, switches or other devices have a bunch of wires coming out of them – not all of which are clear to people who are used to wiring simple devices like “unit controls” cut into the line side of a branch circuit. Some devices have wires that need to be capped, if we’re not incorporating special functions that those devices can handle. Some devices can be wired in different ways, depending on whether or not you use them in conjunction with other devices. In addition to wiring the hardware correctly, I also expect attendees to commission the system according to my expectations.
How are those expectations communicated? On drawings and/or control schedules (showing what equipment is in what zone), as well as documentation showing how I want them to program variables for each zone. For example, in private offices, I expect attendees to program occupancy sensors to work as vacancy sensors (manual on/auto off). The moral of the story is that a networked lighting control system has a lot of parts and pieces – and it is absolutely essential that you approach the installation, commission and programming methodically. Even in the controlled environment of a classroom – with only six “zones” and luminaires – it quickly becomes apparent to attendees how critical it is to do things like name the zones, tag luminaires, etc. Regardless of an attendee’s level of experience, wiring … and commissioning … and programming … and reprogramming an NLC system is something that you absolutely must approach methodically.
6. “Why can’t I commission this wireless system by going onto the manufacturer’s website?”
One of the NLC systems I use in the classes is wireless but “closed”. What talks to what — and how — in a wireless system is a frequent source of confusion in these classes. Typically, wireless components such as luminaire controllers, wireless sensors and wireless switches communicate with a wireless gateway. Sometimes the gateway communicates with a separate server. In one system I use in hands-on classes, there is a very small server incorporated into the housing of the gateway. In either case, those connections are typically hard-wired. What’s missing? The user interface! Most systems need some way of using a computer, tablet or phone to commission and program them. In many systems, that connection uses WiFi. Effectively, the gateway (or gateway/server combination) is like a wireless router. However, in this scenario, the gateway doesn’t allow you to connect to the internet! It simply uses WiFi to allow your computer, tablet or phone to connect to the software that is resident on the server. This is often in the form of a webpage. To make matters worse, some systems have servers in the cloud! In those cases, an internet connection is in fact required (unless there’s some other form of connection such as a dedicated 3G device).
To date, I haven’t used such systems in a hands-on class. If for any reason I can’t get an internet connection in a class venue, then there would be no class. As such, I’ve only use systems with physical servers in the same room. As attendees work through the different types of connections between the various components, it becomes clear that different protocols may be used to make different wired and/or wireless connections in the same system, i.e., Zigbee vs. WiFi, DALI vs. 0-10V, etc. By the end of the class, attendees also understand that some systems are truly closed, even if you connect to them with your computer or phone wirelessly.
In the past decade, I have taught over 60 of these classes in different venues — at LightFair, Better Building by Design in Burlington, VT, and for many different electric utilities. Geographically, I’ve taught hands-on classes for NLCs from Boston to as far away as Honolulu (as part of a day-long class for the local IES section). Every time I teach a day-long class on NLCs, we go over things academically using PowerPoint. Then after lunch we break out the equipment and that’s where the fun starts. It is always very exciting to see people who have had no prior experience with these systems successfully wire, commission and program a system in a matter of 2-3 hours. It is very empowering for attendees, and enormously satisfying to see how easy it is to get these up and running. Typically, NLCs are not incredibly complex — certainly including the new crop of “simplified” systems. Regardless of a particular attendee’s job function or level of experience, they absolutely love having the opportunity to successfully make a system work even if they have no prior experience with this whatsoever.
This article was first published athttp://lightingcontrolsassociation.org/2020/02/14/steve-mesh-answers-networked-lighting-controls-faq/
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 eight years.
