Topic Conventions

MQTT Topics Design

Topic Naming Conventions

  1. Base Topic Structure: Use a structured topic hierarchy. Example: device/{deviceId}/filter/{filterId}/{function}.

  2. Device and Filter Identifiers: Include unique identifiers for both the device and the filter in the topic to avoid conflicts and ensure targeted communication.

  3. Function Specificity: Tailor the last segment of the topic to the specific function or data type (e.g., cmd, status, data).

Topic Examples

  • Commands: device/123/filter/face-blur/cmd

  • Status Updates: device/123/filter/face-blur/status

  • Data Output: device/123/filter/face-blur/data

  • Metrics: device/123/filter/face-blur/metrics/fps

Data Flow Patterns

Sensor to Filter Communication

  • Topic: device/{deviceId}/sensor/{sensorId}/data

  • Purpose: Transmit sensor data to the filter.

  • QoS Level: 1 (ensure delivery but allow duplicates in case of network issues).

Filter Output

  • Topic: device/{deviceId}/filter/{filterId}/data

  • Purpose: Publish processed data from the filter.

  • QoS Level: 0 or 1, depending on the criticality of the data.

Control Messages

  • Topic: device/{deviceId}/filter/{filterId}/cmd

  • Purpose: Send cmd commands to start, stop, or configure filters.

  • QoS Level: 2 (ensure single delivery of critical cmd messages).

Status Updates

  • Topic: device/{deviceId}/filter/{filterId}/status

  • Purpose: Publish status updates from the filter (e.g., running, stopped, error).

  • QoS Level: 1 or 2, based on the importance of status updates.


  • Topic: device/{deviceId}/filter/{filterId}/metrics/{metric}

  • Purpose: Publish standardized performance data from the filter:

    • FPS

    • Latency: Min, Max, Mean, Std

    • Error Rate

Last updated