During our years-long cooperation with Signify on the Philips MasterConnect system, we’ve built multiple mobile applications that bring this industry-leading smart lighting system to life.
The Philips MasterConnect app is the core tool for setting up and configuring smart lighting networks in commercial buildings. The app is straightforward and easy to use, but at the same time, it manages very complex hardware-software interactions.
The whole system, consisting of smart wireless switches, sensors, and luminaires from Signify’s MasterConnect line, is built on Bluetooth Low Energy (BLE) and Zigbee protocols. Since it utilizes technologies that come with phones we use every day, there’s no need to use any additional devices during installation, as was the case with older connected lighting systems.
While our case study of this project provides an overview of the system features, this blog post will give you a view of how things work under the hood. We will focus on how BLE and Zigbee enabled us to build this product and cover some of the app’s high-end features in more detail.
Bluetooth Low Energy & Zigbee making magic
The two wireless communication protocols that make the magic in the MasterConnect system happen are Bluetooth Low Energy (BLE) and Zigbee. The backbone of Internet of Things, they have been revolutionizing the way we interact with our devices for the past few years.
As its name suggests, BLE is a wireless communication technology created to be low-power and efficient. It is a version of the popular Bluetooth technology specifically designed for IoT devices. While Bluetooth Classic only supports point-to-point communication, BLE provides additional communication options such as broadcasting and meshing, enabling connectivity between devices in a network that supports this type of communication.
Similar to BLE, Zigbee is a wireless communication protocol specifically designed for low-power, low-data-rate applications. Zigbee efficiently transmits messages that are small in size, while its design allows devices to run on batteries for years, making this technology a great choice for systems that need to be installed in hard-to-reach locations or need to operate without frequent maintenance.
Both protocols have something in common – the ability to efficiently configure devices into large-scale networks that require zero maintenance. Since our system is fully scalable and adapts to buildings of various sizes, this was exactly what we needed to ensure network reliability in any scenario.
It might seem surprising that we’ve chosen two protocols so similar in nature. However, to support different types of communication taking place in the system, we needed both. Our smartphones have been supporting BLE pretty much since its release as part of the Bluetooth 4.0 standard, but they don’t support Zigbee, whose mesh networking is perfect for light connectivity.
The lighting industry paved the way to Zigbee standardization, with Signify as one of the key advocates. The MasterConnect system was one of the first ones to launch with the newly standardized protocol.
To work around this limitation for mobile, we modeled the system so that our apps communicate with devices using BLE, and then the devices communicate between themselves using Zigbee. That’s the high-level overview, but let’s roll up our sleeves and get a bit lower.
Achieving seamless hardware-software interaction
When setting up a lighting system, installers first need to physically install all of the devices in their respective places in a building. Once that’s done, they use the Philips MasterConnect app to configure the system. The app guides the installers through each phase of the setup – from creating projects and groups to discovering and commissioning lights, sensors, or switches into those projects.
Let’s go over some of those steps in a bit more detail.
All BLE devices need to follow something called the Generic Access Profile (GAP) guidelines, which dictate how they need to advertise data to other devices. This could be a blog post on its own (like our article on Bluetooth Beacons), but in short, the devices advertise information about them with a certain frequency. We could say that they yell something along the lines of “Hey, I’m here, my name is X. I am a light and I support Y features”. This allows us to filter out the devices that are a part of our system and present only them to the installers.
To make things even easier for the installers, we implemented an innovative solution to solve the problem of identifying specific devices in a room where there are hundreds of them. We decided to use torches (not the fire kind, the ones that produce light). Installers just need to point an everyday pocket torch at a light, and the onboard sensor will pick up the spike in the detected brightness. This will cause the device advertisement to change in a way that enables us to identify it and automatically start communicating with it.
Communicating with devices
Once we have discovered all the lights we need, we have to connect to each of them before we can make them a part of our network. We do this by following the Generic ATTribute Profile (GATT) guidelines, which specify how a device can support various features using services and characteristics.
Services are used to break up data into logical entities and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services with a unique numeric ID called a UUID.
Characteristics are the lowest-level concept in GATT transactions, and they encapsulate a single data point that can be either read from or written to.
In short, if you want to get some specific information from a device, you need to read the data from a characteristic that holds it. Alternatively, if you want to write some data to a device in order to tell it to do something, you need to write to a characteristic that is connected to that behavior.
Creating and configuring a network
Now that we know how to discover a device and how to communicate with it, we need to bring Zigbee into the picture. Zigbee enables us to arrange devices into groups, which allows us to use group addressing to communicate with multiple devices at the same time.
Since our phones don’t support Zigbee, we can’t send Zigbee messages directly to devices. That would be too easy. We’ve found a workaround by creating a Zigbee message on the app side that tells the device which group it will be a part of, and then send that message to the device over BLE. After receiving the message, the device firmware processes it and executes the appropriate actions.
After that, configuring devices is rather straightforward. First, the installer uses the intuitive app UI to configure how the devices should behave in the desired setup. The array of options is quite extensive here – from changing the brightness and color temperature to configuring occupancy sensing and matching the lighting with the human circadian rhythm. All the various properties are then converted into appropriate Zigbee messages that we send to a device using BLE.
Once a device receives those messages, it configures itself and relays the messages throughout the device network using Zigbee. This eliminates the need to be close to all the devices and provides significant time savings in large-scale setups.
The setup is complete, now off to the cloud
Once a system is configured, installers can back up all the necessary project data in the cloud, making it easy to share access between multiple installers. System maintenance can then also be transferred to the building manager or a person in a similar role, thus removing the need to hire installers for small maintenance work or system monitoring, e.g., reading the energy consumption report.
An additional benefit of backing up data in the cloud is that it can always serve as a safety net. In case something happens to the phone that configured the system, or there’s a need to revert to earlier settings, it’s easy to restore the original configuration.
Secure communication via Bluetooth
Philips MasterConnect systems are installed in public buildings, which means that security was a top priority for us.
Whenever two devices communicate over BLE, they usually exchange bytes of data that both of them know how to process. Let’s use a simple example of turning a light on.
To achieve this, the app needs to:
establish a connection to the light,
create a message containing the command bytes,
write those bytes to the appropriate characteristic (explained above).
The light needs to:
receive the message,
establish a connection to the light, convert it into something its firmware can process,
tell the hardware to turn on.
If you look at the list of steps, you might see a potential problem here that applies to any kind of unsecured traffic – it can be sniffed and captured by various third-party tools like Wireshark and used maliciously. We needed to find a way to shield the data we were sending between devices.
We came up with something similar to how Transport Layer Security (TLS) works with HTTPS traffic but applied to BLE – TLS over the BLE layer, one might call it.
To increase security, we added an additional part to the process of establishing connections between the app and the lights – Authenticated Key Exchange (AKE). It is a method used to establish secure communication between two parties that ensures only authorized parties can exchange keys and share messages.
AKE typically involves the use of a “shared secret” that is known only to the two parties involved in the communication. This shared secret is used to create a unique key that is then used to encrypt all following communication. The key is exchanged between the parties securely, ensuring that it is not intercepted or tampered with during the exchange.
After this authentication is done, the messages between the app and the devices are encrypted and, if needed, fragmented as well, to ensure they can be properly exchanged.
Doing this was no small feat, but making sure our systems can’t be tampered with makes it all worth it.
Daylight-utilizing and human-centric
Having covered the technical know-how, let’s move on to some elegant features. The system consists of more than just luminaires; we also have sensors and switches that integrate seamlessly. In case someone wants to push their setup to a higher level, there is also an option to add gateway support.
These functionalities enable us to increase the scope of features we bring to the market and make buildings more efficient – from cutting down the time and effort required to service the network and maximizing energy savings to creating a comfortable and adjustable environment for the people using the setups.
I’d like to highlight two of those features: daylight-utilizing and human-centric lighting. They work hand-in-hand to increase the occupants’ well-being.
Daylight-utilizing works in combination with sensors that detect the level of daylight in the room and adjust the lighting accordingly, reducing unnecessary costs. Growing up, we all probably had our parents telling us to turn off the lights because nobody needs them and we are just wasting electricity (and we probably stubbornly argued otherwise). Having LED luminaires that can be configured to emit less light, saving power and creating a pleasant mood using natural light, would have helped in such situations.
Human-centric lighting directly correlates with our human circadian rhythm. Think of it as an internal biological clock that regulates our sleep-wake cycle and other physiological processes to match the external environment, ensuring that we are alert during the day and sleepy at night. You might have guessed it, light is a key factor in regulating that behavior.
To help improve occupants’ well-being, tunable white luminaires from the Philips MasterConnect line can be configured to match the human circadian rhythm – they will emit blue light during the morning and change to warmer, less intense colors as the day passes.
Pretty cool, right?
The future is looking bright
If you thought that we would do a blog post on lighting systems without a single pun about light, you probably didn’t read that many of our blog posts.
We’ve shed some light on the inner workings of the Philips MasterConnect system – from the protocols used, hardware-software interaction, and security, all the way to benefits for people occupying the buildings and using the lights.
Philips MasterConnect is not a standard IoT system. It is the result of years of innovation on all sides – hardware, firmware, cloud, and mobile. And we’re just getting started. The future is looking bright.