MEC 030 - MQTT Subscription Scope and Hardcoded Notification Handling
**Problem Summary**
The current MQTT subscription and message handling logic are too restrictive and partially hardcoded.
---
**Details**
1. **Subscription Scope (etsi-mec-sandbox/go-packages/meep-vis-traffic-mgr/mqtt.go file)**
```go
token = broker_mqtt.client.Subscribe(tm.topic+"/+", 0, nil) // qos:0
```
- The `+` wildcard matches only **one sub-level** under `tm.topic`.
- Effectively, only **two-level topics** are captured (e.g., `v2x/cam`, `v2x/denm`).
- Any deeper hierarchy (e.g., `v2x/cam/eu`) or single (e.g., `v2x`) is ignored.
- It is unclear if this was intentional or if the subscription should instead cover all sublevels using `tm.topic+"/#"` or single.
---
2. **Hardcoded Notification Handling (etsi-mec-sandbox/go-packages/meep-vis-traffic-mgr/mqtt.go file)**
```go
if msg.Topic() == "3gpp/v2x/obu/vam" { // FIXME: Need to manage how to extract message type & message version
_v2x_notify(msg.Payload(), 16, 2, "ETSI", nil, nil)
}
```
- The topic and notification parameters are **hardcoded** (message type = `16`, version = `2`, org = `"ETSI"`).
- This prevents support for **multiple V2X message types** (e.g., CAM, DENM, MAPEM, SPATEM).
---
**Proposed Resolution**
- **Subscription Logic**
- Clarify whether `tm.topic+"/+"` is intentional.
- **Notification Handling**
- Dynamically parse the **topic** (and/or payload) to determine message type, version, and standard organization.
- Avoid hardcoded values so multiple message types can be handled.
issue