Matcher de topics
Matcher de topics
Vérifiez les filtres wildcard avant de livrer.
Vérifiez si un nom de topic MQTT correspond à un filtre avec les règles wildcard + et # avant de livrer du code.
Validez les wildcards MQTT avant firmware, ACLs ou dashboards.
Wildcard rules
MQTT wildcards are simple, but easy to misuse.
`+` matches one topic level and `#` matches multiple levels only when it is the final level. Topic names cannot contain wildcards. These rules matter for subscriptions, broker ACLs, retained message reads, and alert routing.
- `factory/+/temperature` matches exactly one middle level
- `factory/#` matches every descendant under factory
- `factory/#/temperature` is invalid
- Filters that do not start with `$` do not match `$SYS` topics
Use cases
Validate filters before they become permissions.
A topic filter is often copied into device firmware, dashboards, stream processors, and access-control rules. A small wildcard mistake can expose too much data or hide critical telemetry.
- Design tenant-safe topic trees
- Test dashboard subscriptions
- Review broker ACL topic filters
- Confirm rule engine inputs before deployment
Naming hygiene
Good topic design makes testing easier.
Prefer predictable topic levels such as tenant, product, device, signal, and event type. Avoid packing multiple meanings into one level when a topic hierarchy would make filters safer.
- Keep topic levels stable
- Avoid device identifiers that contain slashes
- Reserve `$SYS` for broker/system metrics
- Document retained topics separately from event topics