Professional Documents
Culture Documents
Switch On IoT Connected Lighting - Element14
Switch On IoT Connected Lighting - Element14
Switch On IoT Connected Lighting - Element14
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.
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.
Single point of failure (lost smart phone?) Flexible Connectivity (multi protocol)
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.
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.
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.
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 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.
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.