New lighting systems today rely on LED luminaires and networked lighting control systems (NLCS). With both efficient lighting and control sequences that curtail lighting energy use at opportune moments, lighting energy use goes down precipitously. This combination of low energy use and increasingly complex controls makes manually monitoring lighting control systems labor intensive with limited payback. If only there were a way to automate this approach. Something that could automatically detected faults and provide diagnostics. Maybe put in some visuals. Allow you to compare dissimilar control platforms…

Enter SkySpark

SkySpark is a data analytics platform that connects with the Internet of Things to automatically gather and analyze complex building data and identifies key events called “sparks” which are the ‘things that matter’. This makes it well suited to automating tedious tasks that wouldn’t make sense for review manually and lowers the cost of on-going commissioning (OCx) for NLCS projects. In this post, I’ll outline how to approach a Skyspark integration with lighting controls and key things to keep in mind as you execute your integration.

Integrating NLCS Data Into SkySpark

Getting The Data

The first hurdle is getting the data out of your NLCS platform and into your SkySpark instance. Depending on your control platform, you could have a number of paths to get access to your data. The most common connectors for control systems are usually BACnet or the manufacturer API. BACnet is a technical standard developed by ASHRAE that provides a consistent framework for different control systems/manufacturers to exchange data in a parseable format. That doesn’t mean that everyone shares the same data in the same way, but at least they’re all communicating in the same fashion.

An API, or Application Programming Interface, allows software systems to interact in a set of predefined ways. APIs are very flexible, which is fantastic; but they’re also very flexible, which is terrible. Yeah, you heard that right. APIs tend to be somewhat poorly documented (who likes writing documentation?) and irregularly updated. When you rely on an API integration, you’d better plan on some extra time to parse the API documentation and troubleshoot poorly documented idiosyncrasies. And account for some extra time in the future doing the same thing when the manufacturer suddenly updates their platform.

Yet another option is to integrate directly with the control system database – bypassing BACnet or the manufacturer’s API. This option requires at least read-access to the database, but can vastly reduce network traffic and keep your control system unhindered by the SkySpark instance.

Lastly, some control platforms rely on a common framework that is used widely in the control community. Niagara based lighting control systems (like the Acuity nLight system) have native connectors that are configured for easy integration between the control platform and SkySpark. If your system supports this type of integration, this may be the most robust option available to you.

 To date, I’ve focused on BACnet, given its reliability, predictability, and robust documentation.

Regardless of what approach you pick for getting the data, make sure you get a copy of the system’s integration guide. Each vendor has a different approach for selecting what to report via their connections and just exactly what that data means. For example, Encelium’s platform reports the dimming command as a 0 to 100 variable, where zero is the minimum dimming threshold (also called “low end trim”) and 100 is defined as the maximum programmed output (also called the “task tuned output or “top/high end trim”).

Document Your Sequences of Operations by Zone & Circuit

Lighting control zones are configured (rather than programmed) any number of ways – usually defined by the manufacturer and hardware combination in a given zone. Most methods of integrating NLCS data into Skyspark don’t describe the lighting control sequence of operations (SOO) in a zone or on a circuit. It can be difficult to tell whether a zone is dimming because of a daylight sensor, a user touched the dimmer, or a time-of-day scene kicked in. Until lighting control systems start reporting why changes are occurring a lighting system (e.g. “light level setpoint raised at wall station”, “vacancy sensor shut off lights”, etc.), via their integration connections, it’ll be on the SkySpark integrator to interpret the signals.

To get around this hurdle, we need to evaluate the lighting control sequence of operations. Ideally, we’d comb through the NLCS interface and document the control features by each zone. In doing so, we could develop an implementation-specific understanding of how the control system operates. For example, when an occupancy sensor puts a zone into the vacant state, does the lighting turn off (as we’d expect in a private office) or does it dim the lighting to 40% power (as required by Title 24 in corridors). If we don’t have access to the programming interface, we can use the as-built SOO, but we’re one step further removed from the “true” programming of the control system. If the as-builts are also not available, we can attempt to decern the programming from the trend data directly, but the risk of drawing false conclusions increases.

In the NLCS control integrations I’ve managed, it wasn’t always clear when occupants were manipulating the system versus an automated process. To help separate user changes and control changes, I suggest consulting the manufacturer’s integration guide or the programming literature to identify the lighting control order of operations. For example, we generally understand that if an occupancy sensor turns off the lights, the daylighting signal would be immaterial. Similarly, if the user dimmed the lights down to 20%, a daylighting controller set to dim lights to 40% won’t affect the lights in this zone, since the current operating state (20%) is below the minimum threshold (40%). We want to understand when control sequences are in effect so that we can program SkySpark’s sparks to evaluate periods when the associated SOO is active.

Tagging Your Data

SkySpark uses Project Haystack tagging. While the tagging nomenclature is robust for HVAC systems, the list of predefined tags for lighting systems is fairly minimal. Here are some good tags to consider during your deployment:

• Lighting Control Manufacturer or Platform: The lack of lighting control standardization rears its head again. A tag that specifies the manufacturer allows you to write scripts that interpret the data stream according to the manufacturer’s integration guide. For example, dimming commands reported by Encelium’s BACnet connector will differ from the reported value from Wattstopper DLM or Lutron Quantum. This is particularly handy when you’re dealing with campus-based customers without a sole-sourced lighting control vendor (you can learn more about that in this blog post.)
• Interior & Exterior: Lighting systems outside of buildings naturally behave differently than those inside buildings. An interior/exterior marker tags allows you to quickly filter different lighting zones to easily exclude them from your rules.
• Sequence of Operations Tags: Once you know the SOO used in a given zone, you’ll want to create a tagging scheme that includes sufficient marker tags to that zone or switch gang with an SOO specific tag. A zone may have multiple SOO tags, at least one for every control strategy and often more than one, depending on specific device/zone configurability. A list of some common tagging details follows below
  • Occupancy/Vacancy Sensor Configuration/Response
    • occupancy
    • occAutoOn or occPartialOn or occManualOn
    • occAutoOff or occPartialOff or occManualOff
  • Daylighting Sensor/Control Response
    • daylight
    • openLoop or closedLoop or hybridLoop
    • illuminance or luminance
    • primary or secondary or skylit
  • Scheduling Behavior
    • afterHoursAutoOff or afterHoursDim or afterHoursOn
    • astronomic or timeOfDay
  • Window Shade Behavior
    • orientation
    • autoControl
  • Demand Response Behavior
    • tier1Response
    • tier2Response
    • tier3Response
    • drDim or drOff or drDwell

With the appropriate tags in place, a spark that looks for faults related to that specific SOO can be written and applied to zones with that behavior, helping minimize false alarms. ANSI Standard 137.6-2021 (published in April of 2021) is not of any practical value, being too vague to be directly applicable without additional interpretation/definitions; therefore, you’re going to be on your own.

• Tag Those Setpoints: Unlike HVAC control systems, which typically have a trend reporting the setpoints associated with some controlled value (e.g. supply air temperature and supply air temperature setpoint), most lighting control systems do not report a setpoint trend. To get around this limitation, we’ll need to program a tag that captures the key setpoints. Review your SOOs and identify any setpoints required to execute the SOO – light levels, dwells, calendar or time of day inputs, sheds, etc. Each of these numeric values will need to be retrieved inside SkySpark to compare against behavior of the zone.

Structuring The Data

When structuring the data inside of the Builder App, it’s important to consider how the lighting system interacts with the related control system platforms in the space. Ultimately, the best approach we identified was to create a structure down for each physical room, where occupancy sensors were associated with the room and lighting zones (either by switched zones, dimming zones, task zones, or daylighting zones). This approach allows the lighting zones to read the parent room’s occupancy sensor status (via an equipRef or zoneRef), while also allowing zone HVAC terminal units (VAV boxes or single zone package units) access to the aggregate occupancy sensor status.

Onward to Spark, KPI, and Dashboard Development

Once you’ve developed imported, tagged, and structured your data, you’re ready to roll with Spark, KPI, and Dashboard development. In a subsequent post, we’ll discuss a couple common sparks and how to develop meaningful lighting dashboards. If you’re interested in integrating SkySpark with any of your building systems, contact us anytime.