Files
cariflex/tools/EVerest-main/lib/everest/framework/docs/MQTTCommunication.md
Eric F d398a6ced2 Add extracted tools: CitrineOS, OpenOCPP, ShapeShifter
- CitrineOS core extracted (CSMS OCPP 2.0.1)
- OpenOCPP extracted (firmware OCPP 1.6J/2.0.1)
- ShapeShifter library installed (pip install -e)
- ShapeShifter specification extracted
- EVerest extracted

TODO updated with progress
2026-06-08 00:38:27 -04:00

3.3 KiB

EVerest Framework MQTT Topic Structure

This document describes the MQTT topic structure used by the EVerest framework for communication between modules.

Topic Prefix Structure

The EVerest framework uses a configurable MQTT prefixes for topics. This allows multiple instances of EVerest to run at the same time using the same broker. The default prefix is everest.

1. Variables (Vars)

The following structure applies for variable topics:

Topic Structure

{everest_prefix}modules/{module_id}/impl/{impl_id}/var/{var_name}

Message Payload Structure

The payload contains the actual variable data in the data field.

{
  "data": <variable_value>
}

2. Commands (Cmds)

The following structure applies for command topics. Modules that provide (implement) the command subscribe to the command topic, while modules that call the command publish to it. Each command call generates a unique UUID as the call ID. The origin field identifies the calling module. Command handlers process the request and publish responses to a separate response topic.

Topic Structure

{everest_prefix}modules/{module_id}/impl/{impl_id}/cmd/{cmd_name}

Message Payload Structure

{
  "id": "<unique_call_id>",
  "args": {
    "arg1": "value1",
    "arg2": "value2"
  },
  "origin": "<calling_module_id>"
}

3. Command Responses

The following structure applies for command response topics. These are used to send back results or errors from command handlers to the calling module. Response topics include the calling module ID for proper routing. The call ID matches the original command request.

Topic Structure

{everest_prefix}modules/{module_id}/impl/{impl_id}/cmd/{cmd_name}/response/{calling_module_id}

Message Payload Structure

Successful Response

{
  "name": "<cmd_name>",
  "type": "result",
  "data": {
    "id": "<matching_call_id>",
    "retval": <return_value>,
    "origin": "<responding_module_id>"
  }
}

Error Response

{
  "name": "<cmd_name>",
  "type": "result",
  "data": {
    "id": "<matching_call_id>",
    "error": {
      "event": "<error_type>",
      "msg": "<error_message>"
    },
    "origin": "<responding_module_id>"
  }
}

Error Types

Command responses can contain the following error events:

  • MessageParsingFailed: JSON parsing error
  • SchemaValidationFailed: Schema validation error
  • HandlerException: Exception in command handler
  • Timeout: Command execution timeout
  • Shutdown: System shutdown
  • NotReady: Module not ready

4. Errors

The following structure applies for error topics. Errors are raised by modules and can be subscribed to by other modules. Each error has a unique UUID and includes information about the originating module, implementation, EVSE, and connector if applicable.

Topic Structure

{everest_prefix}modules/{module_id}/impl/{impl_id}/error/{error_type}

Message Payload Structure

{
  "type": "<error_namespace>/<error_name>",
  "message": "<error_description>",
  "severity": "<error_severity>",
  "origin": {
    "module_id": "<originating_module>",
    "implementation_id": "<originating_impl>",
    "evse": <evse_number>,
    "connector": <connector_number>
  },
  "state": "<error_state>",
  "timestamp": "<iso_timestamp>",
  "uuid": "<unique_error_id>"
}