Best Practices

This page describes some tricks in order to integrate your thing with thethings.iO in an efficient way.

Choosing the protocol for your things

You can connect your things using any of the 3 protocols compatible with thethings.iO (HTTP, CoAP, MQTT). Each of them has its pros and cons.

HTTP

HTTP is over TCP and there are lots of libraries implementing it. If there isn't a language for your platform, it is very easy to implement as it is just writing characters on the TCP socket. However is the protocol that introduces more overhead.

CoAP

CoAP is over UDP, designed especially for IoT and introduces minimum overhead. While we don't support CoAP with DTLS yet, contact us if you need the feature.

MQTT

MQTT is over TCP and is best suited for long term subscriptions. MQTT is also lighter than HTTP, but it's not possible to reproduce all the features supported by the other protocols (like reads) with it.

ProtocolProsCons
HTTP
  • Lots of libraries
  • Energy consuming
CoAP
  • Light
  • IoT friendly
  • SSL not supported (yet)
MQTT
  • Best for pub/sub
  • IoT friendly
  • Reads not supported

Sending data only when the value changes

An easy way to optimise 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 optimisation 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 recomendations and in the future we will publish a list of known resources and their meanings.
  • Only alphanumeric characters and ".", "-", "_" simbols are admited 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.

Optimising 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 thumd 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.