First of all, let's discuss the available communication protocols and the supported message formats.
Connhex supports many communication protocols typically used in IoT applications:
- CoAP (RFC7252)
- LoRa (note that this requires an external LoRa server)
Connhex requires all messages to be structured according to one of three formats:
- SenML (RFC 8428) standard
- Connhex JSON
- Generic JSON
If you're creating a new application, we suggest choosing either the SenML or the Connhex JSON format.
The main reason is their standardization: having a standard message format allows us to perform optimizations and provide additional features. In practice, this translates to faster data retrieval after it has been saved to a database and out-of-the-box availability of data visualization and analysis. In the following sections, we have listed some pros and cons to each format - read those for some guidelines and help in choosing one or another.
If you want to leverage Connhex to communicate with existing devices currently on the field, the simplest solution may be to keep using the existing message format. Connhex handles generic JSON messages and can be easily extended to support custom formats (for example, proprietary binary or text-based formats in scenarios where reducing data transfer is a priority).
SenML is a format for representing simple sensor measurements and device parameters. Its purpose is to describe sensory information (temperature readings, pressure measurements, geo-localization, etc.) in a unique way.
What SenML tries to solve is the problem of interoperability: the IoT world is still in a divergent phase, where most of the systems are pretty much closed and everyone has its own data format and standard. Among all the different IoT "languages", SenML wants to be the one that everybody can understand.
Moreover, deep diving into the technical part, SenML can be used to efficiently interchange batches as well as the time series of sensor and actuator data. For example, it supports multiple measurements to be batched into a single HTTP or CoAP request allowing the server side to efficiently support a large number of devices.
If you're interested in the SenML format, check out our specification page where you can find examples and more details about the standard.
If you need to send in a single message complex structures, SenML is not ideal. As stated before, it has been conceived to efficiently represent sensor measurements: if your use case is different, your best bet is Connhex JSON.
For further details, make sure to read the Connhex JSON page, where we have outlined its main characteristics and differences with respect to SenML.
Using a generic JSON format will inevitably lead to the loss of database-related optimizations that Connhex applies when standard formats are used. In cases that need to handle lots of data and devices (tens of thousands or more), this could make user-facing applications feel slow. This is why we suggest using a generic JSON format only in case of existing devices, whose message format cannot be updated.
Need higher performances?
If you can't change the message format used by your devices and feel like user facing apps are hitting a performance limit, we offer specific customization services to tailor Connhex to your use case.
Just drop us an email at email@example.com and we'll be glad to help you.
Many devices don't use a flavour of JSON to communicate: think for example of custom binary formats to reduce data transfer rates, or legacy text-based formats. Connhex can handle all of these cases by integrating format adapters: these are translation layers that are straightforward to integrate, thanks to Connhex's expandability.
By the way, this is exactly how we handle situations in which the same Connhex instance needs to gather data from devices that communicate with different message formats.
For additional information, just get in touch at firstname.lastname@example.org: we can develop an adapter for your specific use case, or provide guidance on how to do it yourself.
Now that we have covered the basics, let's see here how you can publish messages to the Connhex infrastructure using some of the available communication protocols.