Best PracticesThis page describes some tricks in order to integrate your thing with thethings.iO in an efficient way.
- Choosing the protocol
- Sending data only when the value changes
- Choosing the product's resources/keys
- Why keepAlive is necessary?
Choosing the protocol for your thingsYou 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.
HTTPHTTP 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.
CoAPCoAP 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.
MQTTMQTT 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.
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).
InteroperabilityIn 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.
- 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.