With the advance of IoT and connected lighting, BEATRICE WITZGALL notes key areas of expertise that must be brought to bear in product development and projects, including a look at the changing supply chain.
Last fall, I spoke at the 2016 IES Annual Conference about the Internet of Things (IoT) and smart lighting. Several attendees asked me what a hardware manufacturer needs to do to turn wireless. It is a valid question, as I've found there is confusion in the ecosystem regarding which responsibilities each stakeholder has, which in turn is stalling development and market traction.
Working for the past four years in the smart lighting industry, and having talked to several dozen manufacturers about integrations, I've outlined here how I view the responsibilities of all those involved in the development and supply chain for smart lighting.
Hardware manufacturers
Many hardware manufacturers are wondering how they can enable their light fixtures to become wirelessly connected and controlled. It's a different expertise and know-how set and many don't know how to approach that. The wireless chip, whether it is ZigBee or Bluetooth, is basically nothing more than a radio component that needs to be integrated inside the fixture or onto the LED board, driver, or power supply. It's the manufacturer's choice and strategic decision if they want to go either with ZigBee or Bluetooth technology. Both have pros and cons.
The next step is then to determine the radio chip manufacturer the lighting company wants to work with. Typically, pricing and support are the key considerations. One important aspect of the radio module is the firmware that runs on it. It's a piece of software, which defines the functionalities, a set of commands, or endpoints enabling the control of your light fixture. These commands can be then shared in the form of an API (application programming interface) with software manufacturers to integrate them into control software. Without an API, it will be hard for any hardware manufacturer to join the open architecture community and the larger ecosystem of software opportunities.
FIG. 1. The lighting supply chain has changed with the advance of smart lighting and IoT applications. Software developers, electronics engineers, and lighting manufacturers must collaborate and consider all facets of the end-user product together.
The API defines what kind of hardware control you have (on/off, dimming, color spectrum, tunable white, color changing such as RGB or multi-channel) as well as how to discover and commission your lights. Additional advanced API features offer scene creation, light grouping, multi-room use, and scheduling. A good example is Philips Hue, which opened up a huge ecosystem for third-party software apps to control this lighting hardware, thereby offering a range of different functionalities. My recommendation is to bring firmware development in-house as it allows you to keep control over all the components of your hardware.
The choice of protocol is a strategic decision and it depends on your speed to market and resources. ZigBee is a well-established and widely adopted protocol that already has hundreds of thousands of deployments. For ZigBee chips, NXP is a good starting point. Bluetooth is a novel protocol that in the long term will allow more functionalities through beacon integration. I suggest joining the Bluetooth Special Interest Group (SIG) as a member to have access to their resources and the recently published Bluetooth mesh standard from October 2016. Some hardware manufacturers offer both, or offer it as a flexible setup: They have a slot in their fixture into which they can plug the radio module when specified. It's a similar setup to phones or cameras that operate with a memory card, and it offers a flexible upgrade option.
FIG. 2. In newer residential smart lighting setups that are designed to simplify the experience for consumers, controls are connected via gateway to communicate wirelessly with Wi-Fi enabled smart lamps (top), rather than requiring the additional wired hardware of a "traditional" complex installation. Interoperable products must be designed in collaboration across the lighting supply chain to enable simplified setup.
There are some companies in the market that offer a Bluetooth chip integration kit to manufacturers, which simplifies the on-boarding process and fast-tracks the go-to-market strategy. While these are important considerations, those types of companies require that you sign up for their software solution based on an ongoing software-as-a-service (SaaS) model. Typically, their software is not open and competitive with other software solution providers, and the hardware manufacturers lock themselves into a proprietary system that doesn't allow flexibility or open architecture. Also, the offered software interfaces are not as well developed and tailored to specific customer needs and applications. You will depend on that software vendor for its services and ecosystem.
My recommendation is for manufacturers to take on the ownership of that additional component in-house and then offer an open API to selected software providers the same way Philips Hue has done with its wireless lamps. This will ensure an open landscape, larger market reach, and more flexibility, offering a more feature-rich environment.
In summary, the hardware manufacturer has several decisions to make:
• Which wireless protocol should we use? ZigBee or Bluetooth or both?
• Do we develop the wireless radio chip component in-house and offer access or an API for an open architecture, or do we integrate with a third party and become locked into their proprietary software?
Software developers
Lighting control software is replacing all the heavy hardware cabinets and hardware controllers. Easy over-the-air updates allow for new features and upgrades. The software is the controller - the part that used to be composed of tons of hardware racks in an IT closet and required lots of wiring. We now have the mobile apps and a whole web platform to manage and control the lighting with all its features, from light scenes to grouping and scheduling to status reports, user interfaces, and integrations. For example, LumiFi provides the software that controls the fixture and covers all the software aspects.
Software providers shouldn't also necessarily provide hardware. They are two distinct skillsets and require different expertise and processes. Lighting control software is really starting from the moment the hardware manufacturer has integrated the ZigBee or Bluetooth radio chip inside its driver/dimming module and provides us with an API so the software can have access to the hardware.
To develop the software ecosystem the same way Apple has done with the iTunes store for the iPhone, or the way Google has done with the Google Play store for Android, hardware manufacturers need to offer an open APK architecture. An APK (Android Application Package) is a specific command set that can be shared to execute the control of one's lights. Various software providers can then develop solutions that are catered to specific verticals. Ultimately, an office will have different needs, features, requirements, and streamlined processes, and a different user interface than a hospitality project or a residence.
Installers
The installer's role is to deploy the systems and offer continued support to the end users. Installers require training on the wireless technologies. They need to understand how these wireless controls must be integrated into an existing building network and how the systems need to be commissioned. For example, a ZigBee-based installation requires an understanding of where the gateway needs to be placed and how IP (Internet Protocol) addresses need to be assigned within firewall network environments.
I believe that the responsibilities need to be clearly defined between the different parties so we can successfully grow the smart lighting ecosystem, and that an open and informed dialogue will nurture and expand this ecosystem.
BEATRICE WITZGALL is CEO of LumiFi (lumifi.com).
