Device connectivity
Deep dive into Kamea IoT connectivity capabilities.
3 min
3 min
4 min
4 min
3 min
3 min
3 min
3 min
5 min
Kamea offers an open and extensible architecture for device connectivity. The platform comes with several default protocols and provides flexibility to easily add new ones to meet specific requirements.
Why device connectivity matters
- Device to cloud and cloud to device communication: Enables bidirectional communication, allowing not only the reception of data but also the ability to perform remote configuration without requiring the device to initiate the connection.
- Operational continuity: Ensures data can still be collected even during network outages through mechanisms like On-Behalf.
- Advanced device management: Allows monitoring of device connectivity status and applying remote configurations reliably.
Ingestion channels: HTTP, IoT Hub, MQTT
Kamea currently supports three main ingestion channels:
- HTTP
- Azure IoT Hub (based on MQTT)
- Native MQTT (vendor-neutral to avoid lock-in)
This flexibility makes it possible to connect devices across different infrastructures, whether public cloud (Azure, AWS) or on-premise.
Not all protocols are equal, and the choice directly impacts available features:
- HTTP is a unidirectional protocol. The device initiates communication by sending a request, retrieves the response, and then closes the connection. The server cannot push information spontaneously.
- MQTT and IoT Hub enable bidirectional communication with a persistent connection, allowing the server to send commands or notifications to the device in real time.
This distinction is critical for features like remote configuration. For example, changing the temperature of a connected radiator or adjusting a fan’s speed instantly requires a bidirectional protocol. With HTTP, such actions are limited; with MQTT, they are immediate.
If you require an additional connectivity protocol, Kamea can be easily extended to support it.
Data formats
Once the protocol is selected, the next step is defining the data format.
Kamea supports:
- JSON
- CSV
- Protobuf (with .proto file for structure)
These formats are handled through codecs, which decode the payload sent by the device. Each communication channel is paired with a codec to form what we call a channel. This configuration is highly flexible: a device type can use multiple channels simultaneously if needed, enabling communication tailored to specific use cases.
Just as for device connectivity protocols, Kamea can be easily extended to support new data formats.
On-behalf: managing offline scenarios
Connectivity is not always guaranteed, depending on device location or external conditions. What happens if a connected crane is in a rural area with no network coverage, yet you still need to report its status? Or what if your devices do not have connectivity capabilities ?
Kamea addresses this with the on-behalf feature, allowing an operator to collect data locally via a smartphone, tablet, or desktop application and push it to the cloud once network access is restored. This ensures operational continuity even during extended outages.
Device connectivity status
Monitoring device connectivity is a key aspect of device management:
- With IoT Hub and MQTT, Kamea can detect if the device is connected to the broker.
- With HTTP, since the connection is not persistent, Kamea uses a mechanism based on a maximum interval between two messages to determine if the device is active. By default, this interval is set to 30 seconds but can be customized to fit specific needs.
Provisioning
Provisioning ensures the device has everything it needs to communicate securely with the cloud. Kamea generates the necessary information for each channel and supports multiple authentication methods:
- For HTTP, a unique secret per device is transmitted with each request via HTTPS.
- For MQTT and IoT Hub, two options are available: a shared secret (login/password or symmetric key) or certificates, which can be self-signed or issued by a certification authority.
All protocols are used in their secure versions (HTTPS, MQTTS) with TLS, and each device has unique credentials. For certificates signed by an authority, a PKI is required on the client side.
Device connectivity is at the heart of IoT, and Kamea delivers a complete, flexible solution. You benefit from multi-protocol support, compatibility with various data formats, robust security and provisioning options, and advanced mechanisms to handle intermittent connectivity and monitor device status. Whatever your infrastructure or use case, Kamea adapts to ensure reliable and secure communication.

