Craig DiLouie, LC, CLCP recently had the opportunity to interview Szymon Slupik, President, CTO, Silvair about Bluetooth SIG’s new full-stack wireless lighting control standard, Bluetooth NLC for an upcoming article in ELECTRICAL CONTRACTOR. Transcript follows.
DiLouie: Please describe the new Bluetooth NLC standard and what it means for lighting control.
Slupik: Practically speaking Bluetooth NLC adds another standard specification layer on top of Bluetooth Mesh. It is called a device layer. The goal is to standardize device types / roles in a Networked Lighting Control (NLC) system. Initially there are 6 NLC device profiles: Occupancy Sensor, Ambient Light Sensor, Energy Monitor, Scene Selector, Dimming Control and Lightness Controller. This makes it much easier for hardware manufacturers to design their products, as they have precise recipes to follow. Bluetooth NLC also mandates many device features which had been optional before. So overall it means the devices claiming Bluetooth NLC compliance are more uniform and thus more interoperable.
DiLouie: What problems does it solve? How is it expected to affect adoption of networked lighting controls?
Slupik: The key problem that has been addressed with Bluetooth NLC is cross-vendor interoperability. From the Bluetooth specifications perspective, the rules are much tighter now, and there is a strong testing program associated with Bluetooth NLC. A typical NLC product must pass between 500 and 1000 qualification tests. Over the years since the launch of the original Bluetooth Mesh specifications in 2017, we have learned that this level of qualification testing is required to deliver cross-vendor interoperability.
Long term interoperability is the only viable approach in any industry. And that of course includes lighting controls.
DiLouie: Why is it so important for a wireless networked lighting control system to operate on the same protocol as a full-stack solution? What are the actual benefits of aligning all three layers to Bluetooth?
Slupik: The goal has always been to deliver a wireless NLC system that simply works. And works very reliably.
There are many aspects to that, such as security and performance, but also the user experience part. Bluetooth NLC covers all of them.
For example, a Bluetooth NLC device is fully discoverable. This means a smartphone app can interrogate the device (over Bluetooth) and figure out what it is: a sensor, a multi-sensor, does it have a fixture controller integrated, how many output control channels it has. Also performance aspects can be discovered, such as the size of a zone this device supports. This allows for complete automation of the commissioning process.
Bluetooth specifications also fully define the security of the system. Security is of course mandatory but it also covers the entire lifecycle of a device, from manufacturing, through commissioning, through operation, even up to the disposal (Bluetooth has means of preventing attacks through extracting security credentials from trashed devices (called trash can attacks).
In a full stack solution every layer knows what to expect from the other layer (e.g., on the performance front). Wireless communication is inherently lossy. So the Bluetooth communication layer takes that into account. There are special mechanisms to counteract radio packet loss and still achieve perfectly synchronized, low latency dimming action across large lighting zones. This would not be possible if a protocol designed for a wired system was ported to a wireless carrier.
So by defining and controlling all layers we are able to deliver the best wireless NLC standard: one that works very well, scales very well, is very reliable, and at the same time very easy to commission.
DiLouie: The Bluetooth NLC standard specifically features profiles for common devices in the device layer, which defines the role and responsibilities of devices in the control system. What is the significance of this? What devices are covered, and what do these profiles typically include?
Slupik: In the initial release there are 6 NLC device profiles:
- Occupancy Sensor NLC Profile 1.0
- Ambient Light Sensor NLC Profile 1.0
- Energy Monitor NLC Profile 1.0
- Dimming Control NLC Profile 1.0
- Basic Scene Selector NLC Profile 1.0
- Basic Lightness Controller NLC Profile 1.0
Together, they form a complete lighting control system, with commonly known functions like occupancy sensing, vacancy sensing, daylight harvesting, lighting scenes etc. There is also the popular energy monitoring feature. The initial architecture for that was published in 2020 in the Bluetooth whitepaper Building a Sensor-Driven Lighting Control System Based on Bluetooth Mesh. The whitepaper was not formally binding though, it was just the recommended architecture for Bluetooth Mesh – based NLC systems. Now with the launch of Bluetooth NLC, this has been elevated to the level of a formal specification, with its own testing / qualification program. So for example if a device, say, claims compliance with the Ambient Light Sensor NLC Profile, we know that it supports the calibration procedure and thus can be used to maintain constant lux level in a daylighting zone.
DiLouie: Looking at occupancy sensors as an example, what does the profile stipulate for these devices, and what does this provide for the specifier, installer, and ultimately the user? What is the potential for combining device roles in a single hardware device?
Slupik: It starts with simple things, such as that the device can be discovered and commissioned using a standard phone app. This sounds simple but is really important, as it gives specifiers freedom of choice. And the choice can be quite broad. You can use the professional Silvair app to commission this device to an already designed project. Or you can use a Nordic Semiconductor nRF Mesh app to experiment with the device. Basically any app that supports the Bluetooth NLC standard can be used. This is a real demonstration of the true cross-vendor interoperability. Pretty remarkable, as I don’t think we had had this on any other system ever before.
Then the NLC Profile mandates that the occupancy sensor can serve as a full mesh node, such that it can be a relay node (extending the radio range) and a proxy node (a communication endpoint for mobile phones).
And finally we know it supports one of the three occupancy detection methods (motion sensing, presence sensing, people counting).
The NLC profiles are designed with the intention to be combined in single hardware devices. A typical example here would be a multisensor combining occupancy and ambient light level sensing functions.
But practically, we see even more roles combined together. A Bluetooth NLC “sensor” with a DALI/D4i port (one of the most common designs) combines at least four NLC Profiles: occupancy sensing, ambient light sensing, lightness controller (acts as a DALI application controller, interacting with drivers attached to the DALI bus) and energy monitoring (aggregates energy data provided by the D4i drivers and forwards it over the mesh network).
On top of that, it is also common that such Bluetooth Mesh devices interact with popular energy harvesting wall switches like the EnOcean PTM-216B. These switches are not mesh network nodes, but because they use Bluetooth radios, their “telegrams” can be intercepted and forwarded to the mesh network as regular Bluetooth Mesh messages. If the combined NLC device offers such translation function (from EnOcean to Mesh), it would include the other two NLC profiles, namely the scene selector and the dimming control.
DiLouie: What are the benefits of Bluetooth NLC for lighting specifiers provisioning networked lighting control solutions for clients?
Slupik: Bluetooth NLC as a system offers a set of very clearly defined functionalities. So a specifier may just specify the Bluetooth NLC, without a need to require particular products from particular vendors. That gives them a lot of flexibility for customers to choose particular products based on form factors, prices, support options etc.
You can look at it through an example of the standardized line power wall receptacle. It is 100V/60Hz, precisely spaced prongs. Very simple yet very powerful. Unlimited flexibility through strict standardization.
DiLouie: What are the benefits for Bluetooth NLC for electrical contractors working on projects with networked lighting controls? What specific problems are solved?
Slupik: We have always wanted to make this system easy for contractors. I think there are two most important aspects of Bluetooth NLC. First, it is a standard, not a single system. So once you are familiar with the standard, you know how to deal with the products from many vendors, as fundamentally their behaviors and modes of operation are the same. Second, we wanted the system to fully interact with smartphone apps, which automate many commissioning tasks and have essentially become “the new screwdriver”: use the app to commission, use the app to configure, use the app to diagnose problems, use the app to test / control. All in your pocket.
But to achieve that simple vision we had to take care of precisely defining all the underlying technologies. Under the covers this is a complex system. But this complexity is hidden and enables very simple interactions as well as contributes to very high reliability.
DiLouie: For specifiers and electrical contractors, what would selecting and installing a system look like compared to other wireless lighting control solutions?
Slupik: So again – specifiers can focus on the control features supported by the Bluetooth NLC standard. Instead of diving deep into products’ datasheets, just knowing a product is compliant with Bluetooth NLC is sufficient to understand if it will do the job.
On the installation front, this really depends on which tool is used, as each may work differently or be suited to a different type of job.
For example, Silvair provides the Bluetooth NLC commissioning platform which allows almost everything to be done off-site, from the comfort of the office desk, including detailed configurations of lighting zones. Then the only thing to do on site is to map the actual fixtures and sensors to their zones on a floor plan. Everything else is automated with the help of the smartphone app, with the on-site tasks cut down to a minimum.
For projects which involve complex / dynamic architectural scenes there may be a different tool, which does a better job in designing such scenes. I believe that through strict standardization we will enable many creative tools for different types of jobs.
And the bottom line is – through standardizing all layers we have achieved a system which is fundamentally easy to commission. No manufacturer involvement is necessary (and in fact very often there will be multiple manufacturers). It is mostly plug-and-play.
DiLouie: If you could tell the entire electrical contracting community just one thing about Bluetooth NLC, what would it be?
Slupik: It is a wireless system that simply works. On all fronts.
DiLouie: Is there anything else you’d like to add about this topic?
Slupik: We have not mentioned the future plans. And as you see all the initial Bluetooth NLC specifications have “1.0” version number. This means the standard will be evolving. Also some specifications have the term “basic” in their names. That clearly suggests there will be more advanced variants. E.G., the Basic Lightness Controller NLC Profile covers dimmable lights but not color-tunable ones. So definitely you can expect more NLC profiles to come in future.
Last but not least we have been exploring the integration options with HVAC systems. This is the next lowest hanging fruit on the road to sustainability. The dense grid of lighting sensors can provide very useful information to HVAC systems to reduce energy consumption. We’re actively working on it.
