This article is based on another article that Ubidots contributed to the Sept/Oct 2015 Edition of the Microsolutions Magazine from Microchip.

The Internet of Things (IoT) is not only about millions of things talking to us; it is also—more importantly—about us being able to talk back to them. Let’s take retail analysis applications as an example. Suppose a retailer has a sensor that counts how many people enter and leave the store. This data is reported to the cloud, where a nice web interface helps the store analyze the shoppers’ behavior in real time, comparing store performance among multiple stores, or seeing how the visitor-to-customer rates change over time, especially when launching a marketing campaign.

This solution is, in fact, a growing IoT niche with several suppliers who are helping thousands of retailers optimize their sales performance (we actually once published an tutorial about building a People Counter using a Raspberry Pi and a PIR sensor).

Based on these metrics, imagine the possibilities if the system could automatically control devices inside the store. It could display contextual advertising based on the number of people walking in front of it, send promo codes to the shoppers’ phones depending on their gender and age, or maybe even play with the store lights to set a specific ambience. Being able to control devices would certainly enrich the IoT experience in retail and in almost every other market that has yet to be impacted by the IoT. Taking action based on that feedback loop will allow the IoT to realize its full potential.

From a technical perspective, communication from the cloud to the device has turned out to be more complex than the traditional communication from the device to the cloud. Why is that? The Internet was originally designed in a client-server model, where the client was always the initiator of the request. So far, this has allowed devices to initiate the communication whenever they need to push data to the cloud. But what happens if the server needs to push data to a client without the client first making a request? Web developers have come up with some techniques to overcome this challenge. Here are three options that we consider more “portable” to the embedded world.

The most basic way to solve this communication problem is called short polling—a method where the client periodically asks the server if there is new data available for it. This is the simplest solution to code, though it is not recommended if you need to notify a device in real time.

The next option is long polling. In this case, the client performs the request and the server won’t respond until it has something to send. This enables real-time push notifications from the cloud to devices, though it requires the device to leave the connection open for as long as it needs to listen to the server. Using this technique consumes more energy and also risks the loss of the connection. Consider the case where a device remotely controls the door of a truck. If a long poll request has been made, and then the truck goes into a tunnel, the mobile connection will drop. The device will then need additional logic to kill the hung connection and open a new one.

A third option is to use newer protocols like CoAp or MQTT, for example, which were designed to provide low latency, small packet sizes and stable communication over weak networks. These newer protocols provide a two-way communication channel, which in turn supports push notifications. This makes them good choices for IoT projects requiring the ability to control connected devices in real time. The only downside could be the lack of firmware libraries and examples for embedded devices, which are significantly more abundant for HTTP-based connections.

Choosing the right protocol will depend on your application and how often you will need to communicate with a device. In the sample project described below, short polling was chosen because the data needs to be updated only every minute and because handling the LED matrix while leaving an open socket would require more processing power.

In this example, we wanted to explore how to use the short polling method to push data from the Ubidots cloud to a chipKIT™ Uno32™ Development Board using a chipKIT Wi-Fi® Shield. Our example assumes that there is a people counter sending data to Ubidots, after which our chipKIT device will read the last value of the counter and display it in an LED matrix. Note that the memory and processing power of the chipKIT board allowed us to control the LED matrices while being able to poll the Ubidots cloud, as shown below:

We couldn’t have achieved this amount of processing with other Arduino® like boards. Read our “Pushing Data to a chipKIT Board with an LED Maxtix” article for more information on how this project was built. 

Ubidots is a cloud-based application development platform that not only adheres to the web standard (HTTP), but it is specifically designed for the IoT, providing a rich set of API functions that developers can understand.

In addition, we work closely with our users to deploy customer-specific API interfaces to suit their needs, from traditional TCP/UDP endpoints that talk binary data to more advanced protocols like MQTT or CoAP.

When developing projects for the IoT, embedded engineers expect a robust backend to store sensor data, the ability to perform tasks like computing math or statistical operations over that data, the ability to trigger alerts or web-hooks based on sensor readings and, of course, the ability to create user-friendly interfaces for their end customers. These are all services that Ubidots provides to help you capture, store and make sense of your sensing project.

This article was originally published in Ubidots' blog on October 14, 2015.