These docs are for v2.0. Click to read the latest docs for v3.3.

Best Practices

This page describes some tricks in order to integrate your device with our Platform in an efficient way.

Sending data only when the value changes

An easy way to optimize the battery of your devices is to only send the value when it changes. For example, if you have a device that reads the temperature from the sensor every 100ms, instead of sending it 10 times per second, send it only when changes. Doing so will preserve battery life and reduce energy consumption.

To get the current temperature from a subscriber you should first get the last recent value and then subscribe. As the publisher device is only sending the value when it changes, you know that the reading of the latest value is the current value.

Choosing the product's resources/keys

Choosing the right resources for a product is a challenging task. Basically you need to consider the interoperability and the optimization of the device resources (battery, memory, network).

Interoperability

In the future you may be interested to make your things compatible with 3rd party apps. To make the life of your future third party app developers easy, the resources of the things should be as intuitive as possible. For this we have a list of recommendations and in the future we will publish a list of known resources and their meanings.

  • Only alphanumeric characters and ".", "-", "_" symbols are admitted for the resource name "key".
  • Do not put capital letters in the resource names.
  • Separate-the-resource-names-like-this
  • Use the International System of Units when possible.

Optimizing device resources

When you don't need interoperability or you are creating a new resource, it may be a good idea to merge some resources into a single resource. For example, if the device has three resources called acceleration-x, acceleration-y, acceleration-z, merging the three into a single resource called acceleration as a complex object (JSON) with three keys x, y, z is a good idea.

A good rule of thumb is knowing if the resources will be accessed (read) at the same time. In the example above, resources x, y and z will almost certainly be accessed at the same time.

Why keepAlive is necessary?

HTTP and CoAP subscribe/observe have an optional parameter called keepAlive. Every X time the server will send a message (an empty object {} in JSON). Where X is the keepAlive value in ms. When subscribing you need to configure the keepAlive time to prevent the router from removing the entry from the PAT table if the thing is not receiving messages.