Guest post by Kevin Willmorth, Lumenique
In small- and medium-scale lighting application, wired controls remain the foundation for robust controls system architectures. However, the growth of wireless controls is expanding rapidly, and for good reason. The advantages of wireless controls include the ability to move controls and loads and re-assign control-to-load connections without involvement of wiring system remodeling. Wireless controls also separate loads from circuiting, eliminating issues of redundant circuiting to serve small loads (such as office and conference room lighting), and redundant controls to serve large area loads (such as warehouses and large retail spaces). The issue of load side voltage differences and low-voltage control losses and interference is also eliminated.
For designers and building operators, the capability to address controls without concern for hard-wire circuiting to and between fixtures opens doors to greater energy savings, enhanced lighting performance for occupants, lower costs of operation and greater system flexibility.
Realizing the advantages of a wireless controls system begins with selection of a uniform protocol under which all products (control and load side) are selected. For years, this has been a difficult problem to solve. The proliferation of proprietary manufacturer-specific systems, coupled with slow adoption of known protocols across a wide enough product range to allow a lighting system to be created without significant compromises, creates a serious problem connecting lighting products to controls without one compromising the other.
Developing a wireless strategy comes down to two choices. Select a proprietary protocol from a trusted source, or choose a more open-source protocol that supports greater freedom on product selection independent of any one manufacturers’ offering.
The tradeoff in the proprietary approach is limited product selection (to whatever the selected manufacturer offers or will support) in exchange for a simpler selection process and fewer potential compatibility issues. An open protocol delivers a broader range of products to choose from, including controls components, and greater versatility–but comes at the cost of more complex process of decision-making and exposure to potential compatibility issues. Proprietary protocols are subject to obsolescence and discontinuance without support. Open protocols are subject to evolving specifications and product-to-product conflicts that arise from the impossibility of testing every component available with every other product to ensure perfect operation.
In building automation, another factor will likely require consideration–connectivity to total building automation systems (BAS). In this, BACnet is a widely-applied network communication protocol, BACnet is widely used in HVAC, services, security and lighting application, including emerging Power Over Ethernet (POE) systems. For large wireless lighting application, there is a need to apply a protocol that can also connect to, or be monitored by a global BAS, most often using BACnet, directly or through accessory gateways.
A leading example of an open protocol that is compatible with a wide range of products and BAS networks is ZigBee. The ZigBee protocol operates under the IEEE 802.15.4 transport, at 900-928 MHz (home applications) or 2.4Ghz (commercial applications). ZigBee Alliance members offer products are compatible with one another, providing a wide range of lighting and building system control and load side products to choose from. Within these products are adapting gateway products that allow other protocols, like BACnet to connect through wireless communications. In fact, ZigBee is the only BACnet-approved wireless mesh network for commercial buildings and is used for lighting as well as other building system components. Further, adapters that allow connection of 0-10V dimming loads and EnOcean Alliance self-powered controls, making ZigBee the emerging star in the otherwise confusing and diverse wireless communications universe.
ZigBee gateways are also available to interface with PoE products and to connect to the IoT. ZigBee employs Advanced Encryption Security (AES) and CCB-CCM for network security, which differs from WiFi-based networks which use WEP, WPA and WPA2 protocols. ZigBee networks use a assemble and forget process that is very low in power consumption, frequently 25% of the power consumed by an equivalent WiFi network. Range of communications is typically 30 meters, but systems are available that can reach as far as 300 meters.
Products offered by ZigBee Alliance members include hardware and smart device control interfaces, sensors of every description, architectural luminaires, retrofit lamps, retrofit kits and interface relays for connection of building systems. Since ZigBee is a Local Area Network (LAN), devices are generally connected through a central hub. This hub receives control information and distributes it to controlled nodes. In comparison, Personal Area Networks (PAN), such as Bluetooth Low Energy (BLE) operate products directly from personal controls. When this is an advantage, the use of BLE can be connected to ZigBee networks to provide a single uniform overriding protocol.
While all of this is highly serviceable for small and mid-scale project applications such as homes, offices, clinics, mixed use lease space, etc., Zigbee is limited in applications where a great deal of control information is being communicated continuously, such as industrial environments or perhaps hospitals. When communications traffic is heavy and variable, ZigBee’s mesh network topology presents challenges in controlling latency (lag in response times to controls input) and bottle-necking (when the network is so busy talking to itself, it cannot respond to incoming controls input). This is where proprietary systems using WiFi networks, with overlays of BLE for PAN controls interfaces, may be a better choice. In large, complex, high traffic environments, WiFi and single source controls networks deliver more reliable service and less risk of conflicts. In highly complex systems, finding solutions with the fewest involved players is a strong strategy.
One caveat on open protocols. While all products identified as compliant with a protocol such as ZigBee, EnOcean, EMerge or BACnet should be compatible with one another, there are instances where manufacturers are “tuning” their products to suit unique needs that are not universally compatible. Due to proprietary tweaks in dialect within the overall protocol, there may be product functions unavailable when operated on a generic open network, only accessible when coupled to that manufacturers controller(s). This is against the intent of qualified open network alliances but does exist. When selecting products from different manufacturers to be used together, it is worth the effort to verify that there are no “special” features dependent on stepping outside the core protocol being applied. For best results, avoiding products that are not strictly in compliance with the core protocol will reduce potential issue of lost functionality.
For existing small and mid-scale systems, an open protocol like ZigBee is readily retrofitted using simple relay interfaces that can be applied at plug-in loads or added as modules to hard wired products, or attained by using enabled retrofit lamp products. These strategies provide the benefits of greater control fidelity (being able to divide loads in a space into more than what is hard wired in), with the added benefit of remote monitoring and control, along with increased control flexibility. Further, through the application of EnOcean Alliance/ZigBee-compatible self-powered controls adding automatic light and occupancy sensor response features is an easy plug-n-play operation. Finally, any protocol chosen should include capability of being connected to a BAS network (BACnet), now or in the future, to avoid potential future obsolescence.