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.

Metrics

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

• Purpose: Publish standardized performance data from the filter:

  • FPS

  • Latency: Min, Max, Mean, Std

  • Error Rate