Switch On IoT Connected Lighting - Element14

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

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.

Connected Lighting - Issues


Too Pricy Cost

What if it doesn't work? Reliability

Too many competing standards Standards Interoperability

Single point of failure (lost smart phone?) Flexible Connectivity (multi protocol)

Can it be hacked? Security

How do I upgrade? Future proof (over-the-air updates)


Which lights offer smart phone control? Ecosystem

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.

You might also like