Switch On
IoT Connected Lighting

You want to control your lights wirelessly. How do you know what technology to use? In this article Silicon Labs will provide insight into user and design considerations with home connected lighting. Trends in wireless technologies, protocols, and home connected lighting ecosystem are highlighted. We’ll look at specific design challenges with wireless lighting connectivity and how developers are addressing the growing demand with the latest technology.

Home Lighting Market

The home lighting industry is facing disruptive technology transforming from incandescent to LED lighting. The LED lighting market is a $30 billion industry driven by government regulation to lower energy usage that’s accelerating the growth. The price of LED bulbs has declined from $25 in 2014 to under $2. Smart LED lighting combines energy conservation with the connectivity benefits of convenience, intelligence, and analytics. The market solutions for connected lighting must meet user’s simplicity, reliability and security expectations. Research firm IHS Technology forecasts 11M+ smart wireless LED bulbs shipments globally in 2018. The growth projection is 50M+ beyond 2020 globally.

Connected lighting and home automation presents challenges to early adopters and innovative entrepreneurs. Market makers must design simple, flexible, reliable lighting control solutions that feature security, future proof updates, and an ecosystem with device interoperability. The chart below lists user’s concerns with the deployment of connected lighting solutions and the challenges confronted by designers.

Designers want to know which wireless protocols are best suited for wireless connected lighting. Lighting networks require a reliable, single network that delivers instantaneous control and command response. Several different wireless technologies, shown in Figure 1, are available in this market. Wi-Fi, Bluetooth, ZigBee, and Thread for mesh networking, and proprietary sub-GHz protocols, each address different needs. Mesh networks provide a communications backbone that allows a wide variety of connected wireless devices, such as Smart LED lights, switches, thermostats and sensors, to interoperate as a “smart” system.

Figure 1. Wireless Protocols

Wi-Fi connectivity is ideal for high data rate products and services in the connected home, and for providing connectivity to the Internet cloud via home gateways. However, Wi-Fi is not suited for lighting networks due to Wi-Fi’s large protocol stack, memory and processor power requirements, and its star network topology.

Bluetooth enabled devices in a connected home provides direct connectivity to smartphone applications providing device control without the power consumption of Wi-Fi. However, Bluetooth/BLE has a limited network device count, lacks scalability and the benefits of a mesh network.

ZigBee networking technology is a local mesh network based on the 802.15.4 standard that is scalable to hundreds of devices. The ZigBee cluster library defines features of smart lights and home automation devices that provide control of Smart light of dimming, RGB color, and color temperature. The ZigBee advantage of mesh networking is ideal. However, direct smartphone control isn’t supported. The ZigBee gateway router serves as a bridge to connect ZigBee devices to a Wi-Fi/Ethernet IP-based LAN network enabling Internet control and cloud connectivity.

Thread is an emerging mesh network technology that provides IPv6 networking protocol built on open standards for low-power 802.15.4 mesh networks that can securely connect hundreds of devices to each other and directly to the Internet Cloud. Thread 1.1 is emerging so only a small number of thread-based devices are available. Thread devices are able to run the ZigBee application layer which provides interoperability with the available ZigBee home control devices. “A key strength of the ZigBee Alliance's technologies is our application layer — the only mature, widely deployed, interoperable and open IoT application language” said Tobin Richardson, President and CEO of the ZigBee Alliance.

Finally, Proprietary protocols are used in closed ecosystems. Multi-band radios may be used to provide sub-GHz bands instead of 2.4GHz, which can provide a longer range and improve propagation in homes.

Ecosystem Considerations

Wireless technology selection for a lighting control design is influenced by the lighting use case, the system integration task, and the ecosystem. Designers must consider the type of ecosystem supporting the wireless technology. An ecosystem is a network of interconnecting and interacting parts. In a business, for example, the success of Apple’s ecosystem depends on hardware and software integration.

Designers will select the type of wireless ecosystem to deploy. In ZigBee home automation networks, there are three main types of ecosystems: Proprietary or closed, open system, or hybrid.

First, on one side is the proprietary, or closed ecosystem. These ecosystems exist because they have non-standard implementation from special requirements. You see this type of closed ecosystems typically in lighting or commercial and industrial applications.

Second, on the opposing side, you will find completely open ecosystems. If you comply with the standard, for example ZigBee HA 1.2, then you can get on the network. The gateway will let your device join the network, but it may or may not recognize all the features or attributes of your device.

Finally, the majority of the ecosystems are in between or a hybrid. These ecosystems can accept other standards compliant devices. However, in order to fully utilize the features and functions on the devices, each device will need to be approved by the ecosystem. This may be referred to as “white listing” the devices.

Multi-protocol Types - Lighting Applications

The evolution of embedded wireless SoCs with multi-protocol stacks is becoming a differentiator to provide product upgradeability, better user experience, and enhanced use cases for connected lighting designs and home automation. A multi-protocol user case for Bluetooth/BLE is for commissioning a device to join a network, which may be running both ZigBee or Thread and Bluetooth at the same time.

Programmed Multi-Protocol. The most basic multi-protocol support entails a chipset being programmed by the manufacturer at the production stage with a software stack that can run any one of a number of wireless protocols: Bluetooth Smart or ZigBee or Thread or some proprietary protocol.

Switched Multi-Protocol. The next progression of any multi-protocol platform is the ability to change which wireless protocol is supported by bootloading a new firmware image while the device is deployed in the field. This requires some fundamental building blocks to be in place, but opens up al lot of opportunity for future proofing existing products. The following future proofing example depicts a light bulb manufacturer that supplies Bluetooth enabled light bulbs to consumers that want to directly control their lights from their smartphone via a supplied app. However, sometime in the future that consumer may purchase a home automation system that uses ZigBee or Thread or some proprietary protocol and may wish to add the light bulb into that ecosystem. In Figure 1, the smartphone uses a BLE connection to the wireless lightbulb to commission the device on the ZigBee or Thread network. The user operates the smartphone app to get the device joined onto the network, set up a pairing with other appropriate devices in the network, then switches over to ZigBee or Thread mesh network stack used by the lighting control network. Figure 3 shows the initial load of the Bluetooth stack for commissioning, the bootloader execution 10 -15 seconds to load the mesh stack, and the protocol switch to Zig-Bee or Thread.

Figure 2. Switched Protocol – BLE commissioning on mesh network

Figure 3. Switched Protocol – BLE commissioning time requirements

Dynamic Multi-Protocol. Any multi-protocol solution must address the possibility of running multiple wireless protocols together on one chip, using some time slicing mechanism to share the radio between protocols. This opens up even more use cases, especially when combining Bluetooth Smart with other wireless protocols. The simplest of these use cases involves the periodic use of Bluetooth Beacons from a device that normally operates on ZigBee, Thread or some other wireless protocol. In Figure 4, a retail store is equipped with a ZigBee-controlled lighting system, the ZigBee enabled lighting fixtures could also be made to transmit a Bluetooth beacon periodically. Lighting in a store is an ideal way of determining location as lights tend to be spaced evenly and throughout the area but also transmit information to devices based on those locations.

Figure 4. Dynamic Multi-Protocol – BLE Beaconing in ZigBee lighting network

Figure 4. Shows a dynamic multi-protocol lighting example of this at work. The Bluetooth beacons are used to enable proximity-aware applications alongside a mesh network, in this retail lighting network.

An example of this at work, Figure 5, lighting fixtures transmit Bluetooth beacons to enable proximity-aware applications alongside a mesh network, in this retail lighting network. If a retail store is equipped with a ZigBee-controlled lighting system, the ZigBee-enabled lighting fixtures could also be made to transmit a Bluetooth beacon periodically.

Figure 5. Dynamic Protocol – BLE commissioning on mesh network

A Bluetooth beacon is used to advertise the device’s presence and services. By using received signal strength (RSSI) measurements on periodic received packets, it is possible for a mobile device to determine how close it is to any given beacon and whether it is moving closer to it or further away. Monitoring multiple beacons can provide quite an accurate understanding of where the mobile device is in the store. In this retail environment example, Bluetooth beacons can be used to deliver coupons and tailored offerings relevant to where you are in the store. The store would provide shoppers with a smartphone app, and by monitoring the beacons emanating from lighting fixtures located around the store, the app can provide location-specific information and create an interactive user experience based on nearby products and services.

Figure 6 shows multi-protocol timing requirements to enable this use case. A ZigBee Router always has its radio in receive mode when not transmitting, which allows other devices in the network to always send packets to it, or route through it. Because of the low duty cycle for ZigBee traffic and the retry mechanisms in the ZigBee networking stack, it is possible for the ZigBee Router to switch its radio to some other frequency/protocol for short periods without dropping any messages at an application level.

Figure 6. Dynamic Multi-Protocol – BLE Beacon and Zigbee time slicing requirements

Typically beacons are quite short packets, usually up to 30 bytes, although it differs slightly between different ecosystems like Apple iBeacon, Google Eddystone and Radius Networks’ AltBeacon. The radio only needs about 1ms to transmit the beacon and the interval between beacons is typically no shorter than 100ms, which is what Apple specifies, thus providing a duty cycle of just 1%, and ensuring that the radio can devote at least 99% of its time to the main wireless protocol. In some environments, the beacon interval can be much longer, perhaps seconds. The critical mission is managing the transition from ZigBee to Bluetooth beacon in this application.

IoT Cloud Connectivity

The Internet of Things is comprised of a variety of wireless technologies and standards each offering unique connected lighting solutions. How do all of these hardware and software elements communicate to each other?

Here’s a connected lighting application scenario. A connected lighting application in a smart home uses a connected light operating a 2.4 GHz radio, the stack is Bluetooth Smart 4.1, and the application is custom. A motion sensor, used to automatically turn on the light when someone enters the room, uses a radio operating on a different 2.4 GHz modulation scheme; operating IP-based Thread protocol stack for mesh networking; and the application is open. A rapidly emerging trend to ensure device-to-device interoperability in the smart home is the use for multi-protocol system-on-chip (SoC) devices capable of “speaking” multiple wireless “languages” protocols.

The system-on-chip implementation is the critical device to support wireless standards, ensuring interoperability among connected devices supporting these standards. The SoC device must have adequate flash memory to be able to store multiple protocol stacks in firmware and to enable dynamic switching among the protocols as devices join the network. Equally important is the application layer software that connects the end user to the hardware. Leading SoC vendors are offering comprehensive hardware, protocol stacks, and software development tools to support the design of multi-protocol devices. This unified hardware and software approach to multiprotocol connectivity will ensure seamless interoperability of wireless lighting devices and sensors.

• Silicon Labs is a supplier of smart, connected, energy-friendly 8 & 32-bit MCUs, wireless transceivers, wireless SoCs, and smart sensors.
• Our 32-bit EFR32 Gecko MCU portfolio includes nearly 250 products with ARM cores ranging from Cortex-M0+ to Cortex-M4, and integrated flash memory from 4KB to 1MB, supporting a broad spectrum of energy-sensitive, battery-powered applications.
• Our wireless portfolio includes IC products (from sub-GHz transceivers and transmitters to 2.4 GHz ARM-based ZigBee SoCs), software stacks and development tools.
• Silicon Labs’ MGM111 Mighty Gecko Module is a pre-certified module with a Mighty Gecko wireless SoC that can save months of design and development effort featuring a 2.4 GHz radio with support for wireless mesh networking using the ZigBee or Thread protocols.
• Silicon Labs also offers smart environmental sensors (relative humidity and temperature) and optical sensors (IR, ambient light and ultraviolet index) that can be integrated into smart home and other IoT designs.
• With this breadth of MCU, wireless, sensor and software solutions, we are able to address a wide array of smart home application requirements.

Where to get more Info :

Silicon Labs’ wireless offerings:

• www.silabs.com/wireless

Silicon Labs connected lighting:

• Connected Lighting
• Lighting Whitepaper

EFR32™ Mighty Gecko Mesh Networking Wireless SoCs for ZigBee® and Thread

Silicon Labs’ Mighty Gecko family of SoCs is ideal for designing energy-friendly wireless connected IoT devices. Part of the Wireless Gecko portfolio, the Mighty Gecko is the superset part and supports 2.4 GHz and Sub-GHz protocols, including zigbee, Thread, BLE, and Silicon Labs Connect stack for 2.4 GHz, as well as Sub-GHz for proprietary protocols and the Connect stack.

MGM111 Mighty Gecko Module

Silicon Labs’ MGM111 Mighty Gecko Module is a pre-certified module with a Mighty Gecko wireless SoC that saves months of design and development effort. The MGM111 is based on the EFR32 Mighty Gecko SoC, a highly integrated, energy efficient device that includes an ARM Cortex-M4 with DSP extensions and an FPU, and a 2.4 GHz radio with support for wireless mesh networking using the ZigBee or Thread protocols for low-power wireless applications in the lighting, connected home, building automation.

Silicon Labs (NASDAQ: SLAB)

is a leading provider of silicon, software and solutions for the Internet of Things, Internet infrastructure, industrial automation, consumer and automotive markets. We solve the electronics industry’s toughest problems, providing customers with significant advantages in performance, energy savings, connectivity and design simplicity. Backed by our world-class engineering teams with unsurpassed software and mixed-signal design expertise, Silicon Labs empowers developers with the tools and technologies they need to advance quickly and easily from initial idea to final product.