使用MQTT传输传感器数据，咨询Broker中Topic Rewrite功能的用途

Awesome question—Topic Rewrite is one of those MQTT broker features that might seem niche at first, but it solves tons of practical pain points when dealing with sensor data. Let me walk you through its key real-world uses:

• Fix Legacy Device Compatibility
  If you’re working with older sensors or devices that have hardcoded topic paths you can’t modify (without reflashing firmware, which is costly and time-consuming), Topic Rewrite saves the day. For example, a sensor stuck sending data to /old/sensor/temp can be automatically mapped to your system’s standardized topic like /factory/floor3/sensor/temperature. No firmware changes needed!

• Simplify Clunky Topic Hierarchies
  Some devices spit out overly verbose topics (think /company/east-coast/building-2/floor-5/room-12/sensor/humidity). Rewrite lets you trim these down to something more manageable, like /east-coast/f5/r12/humidity, making subscriptions easier to manage and reducing unnecessary payload overhead.

• Enforce Data Isolation & Access Control
  If you’re managing multi-tenant environments (like serving multiple clients with their own sensor fleets), Rewrite can automatically inject tenant identifiers into topics. For example, a client’s sensor sending to /sensor/data can be rewritten to /tenant-abc/sensor/data, ensuring their data stays isolated from other tenants. This pairs perfectly with ACLs to lock down access to specific topic paths.

• Normalize Data from Heterogeneous Devices
  Different sensor manufacturers often use their own topic formats. A temperature sensor from Brand X might send to /brand-x/temp, while Brand Y uses /temp/brand-y. Topic Rewrite lets you standardize all these into a consistent structure like /sensors/brand-x/temperature and /sensors/brand-y/temperature, making it easier to ingest and process data in your backend systems.

• Dynamic Routing Based on Context
  Advanced brokers let you rewrite topics using metadata from the MQTT message or client (like client ID, QoS level, or even message payload fields). For example, a sensor with the client ID sensor-floor2 sending to /data can be automatically routed to /floor-2/sensor/data, organizing your data streams without any device-side changes.

Here’s a quick example of what a rewrite rule might look like (using a common broker syntax):

rewrite_rule {
  source_topic = "/legacy/sensor/+"
  dest_topic = "/standard/floor3/sensor/$1"
  action = "replace"
}

In this case, $1 captures the wildcard part of the source topic (e.g., temp from /legacy/sensor/temp), inserting it into the destination topic.

内容的提问来源于stack exchange，提问作者Manigandan Seetharaman