MQTT API

This API is used by Enapter devices to communicate with the Enapter Cloud. It is based on MQTT protocol. The API allows to send telemetry and properties from the device to the cloud, receive commands from the cloud, and send command responses back to the cloud.

If you need to integrate your device with Enapter Cloud, you can use this API. Follow the Creating Standalone Device tutorial to learn more how to use this API.

Send telemetry

Publish telemetry message to the topic:

v1/from/<hardware_id>/<channel_id>/v1/telemetry

The message payload is a JSON object with timestamp and telemetry attributes:

{
  "timestamp": 1759212723,
  "temperature": 23.5,
  "pressure": 2.7
}

timestammpintegerrequired

The timestamp is in seconds since epoch.

<other keys>any

The other keys is telemetry attributes which should be described in the device blueprint.

Send properties

It works similar to telemetry. Publish properties message to the topic:

v1/from/<hardware_id>/<channel_id>/v1/properties

The message payload is a JSON object with timestamp` and properties attributes:

{
  "timestamp": 1759212723,
  "vendor": "Enapter",
  "fw_ver": "7.5.0"
}

timestammpintegerrequired

The timestamp is in seconds since epoch.

<other keys>any

The other keys is properties attributes should be described in the device blueprint.

Receive commands

Subscribe to the topic:

v1/to/<hardware_id>/<channel_id>/v1/command/requests

The message payload is a JSON object with request id, command name, and optional command arguments:

{
  "id": "123e4567-e89b-12d3-a456-426614174000",
  "name": "set_power",
  "arguments": {
    "power": 5000
  }
}

idstringrequired

The id is a unique identifier of the command request. Use it in the command response.

namestringrequired

The name is the command name. It should be described in the device blueprint.

argumentsobject

The arguments is a JSON object. Keys should be described in the device blueprint.

Send command responses

Publish command response message to the topic:

v1/from/<hardware_id>/<channel_id>/v1/command/responses

The message payload is a JSON object with request id, execution state, and optional payload result:

{
  "id": "123e4567-e89b-12d3-a456-426614174000",
  "state": "completed",
  "payload": {
    "new_power": 4700
  }
}

idstringrequired

The id should match the command request id.

statestringrequired

The state is the command execution state. Canb:

• completed when the command is successfully completed.
• error when the command execution failed.
• log to send intermediate log messages during command execution.

payloadobject

The payload is a JSON object. Keys should be described in the device blueprint.

Child devices

A single hardware device can expose more than one logical device to Enapter Cloud by declaring child devices. Each child appears in the cloud as a separate device attached to the parent, with its own properties, telemetry, logs, and commands.

To use this feature, the parent's blueprint must declare its children in the children section of manifest.yml. Each entry there names a child blueprint that the parent can instantiate.

Announce children

The set of children is announced by publishing a children property on the parent's properties topic:

v1/from/<hardware_id>/<parent_channel_id>/v1/properties

The payload contains a children JSON object keyed by an arbitrary per-child reference ID. Each entry must contain a type field — the reference name of one of the children declared in the parent's manifest:

{
  "timestamp": 1759212723,
  "children": {
    "inverter_a": { "type": "inverter" },
    "inverter_b": { "type": "inverter" }
  }
}

childrenobjectrequired

The full set of child devices currently exposed by the parent. Publishing this message replaces the previously announced set — children that are no longer listed are removed.

children.<child_id>.typestringrequired

The reference name of the child's blueprint as declared in the parent manifest's children section. Unknown types are rejected.

The children property is reserved — it can only be written via the parent device. Do not include other keys named children in your properties payloads.

Channel ID for children

Once announced, each child gets its own MQTT channel_id formed by joining the parent's channel ID and the child's reference ID with two dashes:

<parent_channel_id>--<child_id>

For example, for parent channel ucm-1 and child inverter_a the child's channel ID is ucm-1--inverter_a.

Use that channel ID in every per-child MQTT topic — telemetry, properties, command requests, and command responses — exactly as described in the sections above. The hardware_id stays the same as the parent's.

Examples

Send telemetry for inverter_a:

v1/from/<hardware_id>/<parent_channel_id>--inverter_a/v1/telemetry

Subscribe to commands for inverter_b:

v1/to/<hardware_id>/<parent_channel_id>--inverter_b/v1/command/requests