Configurations & campaigns

Deep dive into Kamea IoT device management platform configurations and campaigns capabilities.

Configurations allow you to send parameters to your devices and, if necessary, retrieve the value applied by the device. This flexibility opens the door to many use cases, from simple device status reporting to firmware updates.

Why configurations matter

Desired & reported states

Each parameter sent is associated with a state:

Desired: the value you want to apply.
Reported: the value actually applied by the device.

This key-value logic is the foundation of the system.

Two concrete examples:

Connected radiator: set a target temperature without local intervention.
Firmware update: apply a specific software version and verify that it is properly installed.

Configurations types

Configurations keys are always text strings. Values can be:

Text
Number
Boolean
JSON object

This flexibility covers both simple and complex needs.

Unidirectional and bidirectional interfaces

The way your devices communicate with Kamea directly impacts how configurations are applied. There are two approaches:

1. Bidirectional interfaces

With a bidirectional interface (for example, MQTT), communication is event-driven:

When a configuration changes, the device is notified in real time via a message published on an MQTT topic.
If the device is disconnected at the time of the change, it will receive the latest configuration as soon as it reconnects to the MQTT broker.
This mechanism ensures that the device stays synchronized with the desired state without additional intervention.

This provides responsiveness and reliability. Devices are immediately informed of changes, which is ideal for environments where parameter consistency is critical (e.g., temperature, security, firmware).

2. Unidirectional interfaces

With a unidirectional interface (for example, HTTP), the logic is different:

The device initiates communication by polling the server.
There is no native mechanism to notify the device of a change because HTTP connections are stateless and established on demand.
To stay up to date, the device must send regular requests to retrieve the latest configurations.

Consequences:

More latency between the configuration change and its application.
Additional load on the device (polling).

Changing configurations via the Kamea API

When you want to modify a parameter on a device, you don’t need to know the details of underlying protocols like MQTT or HTTP. Kamea API handles all the complexity for you.

In practice :

You send a request to the API to define a new configuration, whether it’s a target temperature, a firmware version, or a business parameter.
Kamea then translates this request into instructions adapted to the device’s communication channel.
If the device uses a bidirectional interface, the configuration will be transmitted via MQTT with immediate notification.
If the interface is unidirectional, the update will be retrieved by the device during its next HTTP polling cycle.
Once the configuration is applied, Kamea allows you to check the reported state to confirm that the change has been successfully implemented.

This complete abstraction of protocols saves you from managing the complexity of MQTT brokers or HTTP endpoints.

Campaigns for mass configuration changes

In an industrial or B2B context, updating dozens, hundreds, or even thousands of devices simultaneously is essential. Managing these operations one by one would be time-consuming and risky. To meet this need, Kamea offers campaigns capabilities.

A campaign allows you to define a set of configurations to apply to a group of devices based on specific criteria, such as device type, location in a hierarchy, or other attributes. For example, you can target all devices of a certain model in a given area and apply a new firmware version or business parameters.

Creating a campaign goes beyond selecting the devices involved. It includes advanced options to control deployment:

you can schedule a start date,
decide whether execution will be automatic or manual,
and define batch segmentation.

This segmentation is essential to reduce risk: it allows you to update an initial batch of devices, verify that everything works correctly, and then proceed with the others.

Each batch can be spaced out over time, for example, one hour between two batches, to limit network load and ensure effective monitoring.

This flexibility meets real customer needs for secure deployments. Some prefer to start with a small panel before launching a massive update. Others opt for fully automated execution with defined intervals to avoid load peaks.

Once the campaign is launched, Kamea provides monitoring dashboards. You can view progress, check batch status, and verify which devices have applied the expected values. Detailed statistics allow you to quickly identify discrepancies and take corrective action. This level of control is essential to ensure reliable updates in production (cf section on Kamea IoT update management).

Configurations give you full remote control over critical parameters, ensuring consistency and reliability across every device. Campaigns take this further by enabling large-scale, planned, and controlled deployments, especially for over-the-air firmware updates.