Bench Talk

At a recent energy conference there was a great deal of discussion on how the commercial real estate market might leverage the current infatuation with smart devices, and buzz around the Internet of Things to help propel building automation technology into widespread adoption. It would seem that the technology maturity, price points, and market desire are finally beginning to intersect. In the final analysis many experts, including technologists, energy managers, engineers, and real estate professionals seemed to converge on the notion that lighting will be the key technology that will help other control technologies, such as HVAC, to finally gain greater adoption rates.

LED lighting technology specifically is of keen interest as a way to lower electrical utility bills while providing superior illumination quality. Coupled with the fact that LED lighting unit cost is dropping precipitously, there is now enough flexibility in the bill of materials cost to add wireless microcontrollers without upsetting the applecart of LED adoption.

These next, next-gen LEDs lights will help drive down the major cost that is often associated with adding automation to major relamping efforts, which is labor.  Adding automation to lighting is a historically time-intensive process of documenting where the fixtures are located, associating groups of fixtures into zones and creating lighting profiles. Moving forward with “smart” lighting that has wireless intelligence built directly into the bulb, lighting will be able to self-organize into zones thanks to coordinating mesh network technologies. This reduces the time needed to setup a lighting automation system from days to hours, depending on project scope. Additionally, ambient light detection sensors built directly into the bulb will allow the bulb itself to decide on when to dim and when to communicate its status to nearby bulbs to allow automatic setting of optimum lighting levels.

Of course, occupants may prefer to override the prescribed logic of the automated controls. Unsurprisingly, there was much consensus that smartphones and tablets are the preferred method of user interface to control automation systems. This leads to a particularly interesting insight regarding the preferred communications protocol that will eventually dominate automation products. The three leading contenders are Zigbee, Bluetooth, and 802.11 WiFi. However, only two are found in most modern smartphones and tablets, with Zigbee being the protocol left out. So while Zigbee might have some advantages over the other two protocols, the pervasiveness of the Bluetooth and WiFi will be a distinct advantage. Furthermore, if one considers the need for remote operation, then WiFi should trump Bluetooth as well.

While it is good to see convergence to standards on the lower end of the OSI Stack, specifically the physical through transport layers, the real challenge has been and still remains the higher layers closer to the user experience via an application. For automation to really become successful, we will have to break vendor lock and allow for systems made from different vendor components to interoperate more seamlessly. No one is going to want to fire up one app to control their lights and another app to change their thermostat settings. Interestingly, there is great discussion on this very topic and surprisingly a lot consensus on the solution.

Fundamentally, the solutions are not exactly hardware or even firmware in nature, as many embedded designers are probably used to dealing with. Rather, the solution that many are gathering around takes a lesson from the web developer’s playbook.  Enter the notion of Representational State Transfer (REST) Application Programmer Interfaces (APIs), which sound way more complicated than they actually are. In fact, you probably interact with dozens of websites everyday through sets of “RESTful APIs”.

The next time you get ready to submit a webform, take a look at the address bar and take a peek at the URI or Uniform Resource Identifier which shares a relationship to the more commonly known URL or Uniform Resource Locator. After the .com or .net top-level domain you might notice keywords such as GET, PUT, POST, or DELETE. These methods allow for the browser and the server to interact in more complex and useful ways than simply displaying a static webpage. They give the ability to request data, remotely change device settings, or interact with a database. Specifically following a REST architecture provides several key behaviors to a system including:

1.         High efficiency performance

2.         Scalability

3.         Simple and consistent software interfaces

4.         Ability to be modified as needed

5.         Portability and reusable code

These are five factors that traditional automation and control technologies have been lacking. What makes them interesting from the perspective of building automation is that while RESTful APIs typically allow for machines to interact with each other across the Internet, a connection to the cloud isn’t needed for them to work. An automation system could simply rely on a wireless router and local area network, sans connection to the cloud, and a RESTful architecture will still work. Furthermore, it is even possible to eliminate the router completely with a wireless embedded platform that has the computing horsepower if it’s configured as an access point (AP), thus allowing other devices to connect through it instead of a router.

With this in mind, it should be of little surprise that the big names in automation and control systems such as Modus and BACNet are working with more traditional I.T. focused firms to understand and integrate RESTful API architectures into their software, so that they can be much more scalable and interoperable. The ubiquity of WiFi in computers, smartphones, and tablets; the usefulness of RESTful API architecture, and the growing number of inexpensive embedded platforms with built-in WiFi means that I need to seriously learn higher level web programming if I want to continue to be employable as an embedded designer.