MQTT does not have registers or point indexes - it routes messages by topic, a slash-delimited string that both names a piece of data and organizes it. Choose those strings well and a field's assets fall into a clean namespace; choose them badly and it becomes an unsearchable mess. This guide explains how MQTT topics form a hierarchy, how the single-level plus and multi-level hash wildcards let one subscription capture a whole area, and how a sensible topic namespace maps a field's assets for a cloud SCADA broker.
MQTT Topic Hierarchy and Wildcards in one line: An MQTT topic is a UTF-8 string split into levels by forward slashes, such as site/wellpad/separator/pressure, and the levels form a hierarchy that organizes data much like folders organize files. Publishers send messages to a specific topic and subscribers ask for topics, but subscribers can also use wildcards: a plus matches exactly one level and a hash matches all remaining levels. Together the hierarchy and wildcards let a subscriber grab a single point or a whole branch of a field's assets with one subscription.
A topic is just a string, but the forward slash gives it structure. A topic like northfield/pad7/separator2/pressure reads left to right from the broadest scope to the most specific value: the field, then a pad within it, then a separator on that pad, then the specific measurement. Each slash-separated segment is a topic level, and the ordering is a design choice - a good design puts the most general grouping first so related data shares a common prefix. There is no fixed schema imposed by MQTT; the meaning lives entirely in the convention the designer adopts.
The broker does not need topics to be declared in advance. A publisher simply publishes to a topic and, if the message calls for it, the topic effectively comes into existence; subscribers ask for topics they want. This flexibility is powerful but double-edged, because nothing stops one integrator from writing pad7/sep2/press and another from writing NorthField/Pad-7/Separator2/Pressure for closely related data. Consistency is a discipline the team imposes, not something the protocol enforces, which is why a documented topic-naming convention is one of the most valuable artifacts in an MQTT deployment.
Because the hierarchy is arbitrary text, it can and should mirror how a field is physically organized. A namespace that follows enterprise, site, area, line, and device levels - a pattern many industrial MQTT designs adopt - makes the topic tree a readable map of the plant. When the topic string itself encodes where a value comes from, an engineer can look at a message's topic and know exactly which asset produced it, without a separate lookup table. That legibility is the whole payoff of thinking carefully about the hierarchy up front.
Wildcards are only used when subscribing, never when publishing - a publisher always names one exact topic. The single-level wildcard, written as a plus sign, matches exactly one topic level in the position where it appears. A subscription to northfield/+/separator2/pressure matches that pressure on every pad in the north field - pad1, pad7, pad12 - because the plus stands in for any single value at the pad level, while the levels around it must still match exactly. It is the tool for saying give me this same point across all siblings at one level.
The multi-level wildcard, written as a hash, matches every remaining level and must appear at the end of a subscription. A subscription to northfield/pad7/# captures everything published anywhere beneath pad7 - every separator, every measurement, every status - in a single subscription. Where the plus is surgical, matching one level, the hash is a broad net that scoops up an entire branch of the tree regardless of how deep it goes. Subscribing to just # would capture every topic on the broker, which is occasionally useful for diagnostics but usually far too much.
Combining the two gives precise control. A subscription like northfield/+/+/pressure gathers the pressure from every separator on every pad in the north field, matching two arbitrary levels while pinning the field and the measurement. A monitoring client can therefore subscribe once to a whole area of interest rather than enumerating hundreds of individual topics, and it automatically picks up new assets that publish under the matched pattern without any subscription change - a new pad that starts publishing northfield/pad13/... is captured the moment it appears if the subscription used a wildcard at the pad level.
For a cloud SCADA such as Merobix consuming data over MQTT, the topic namespace is effectively the addressing scheme for the entire field, so designing it deliberately is foundational. A hierarchy that runs from field to pad to equipment to measurement lets the platform organize incoming data along the same structure operators think in, and lets it subscribe efficiently. Rather than one subscription per point, the platform can subscribe to a wildcard pattern per area and receive everything beneath it, which keeps the connection simple even as the field grows.
Wildcards make the mapping resilient to change. When a field expands, new devices that publish under an existing branch are picked up automatically by a wildcard subscription, so the platform sees a new well or separator as soon as it starts reporting, without someone editing the subscription list. This is a natural fit for how oil and gas fields evolve - pads are added, equipment is swapped - and a wildcard-based subscription means the ingest side keeps pace without constant reconfiguration, provided publishers follow the agreed naming convention.
The flip side is that a sloppy namespace undermines all of this. If topic strings are inconsistent, a wildcard pattern that should catch every separator's pressure will silently miss the ones named differently, and those points quietly go unmonitored. This is why the topic convention deserves to be documented and enforced as carefully as a point map on a polled protocol. When Merobix ingests MQTT data, a clean, consistent hierarchy is what turns a stream of messages into a structured, browsable model of the field - and what lets a handful of wildcard subscriptions stand in for thousands of individual points.
The plus is a single-level wildcard that matches exactly one topic level in its position, so northfield/+/pressure matches one level between those segments. The hash is a multi-level wildcard that matches all remaining levels and must come last, so northfield/pad7/# matches everything beneath pad7. Plus is surgical for one level; hash is a broad net for an entire branch.
No. Wildcards are only valid in subscriptions. A publisher must always send to one exact, fully specified topic with no plus or hash. The wildcards exist so that subscribers can match many topics with a single subscription, but every published message names a single concrete topic.
No. MQTT topics are not declared in advance; a publisher simply publishes to a topic and subscribers request the topics they want. This flexibility means nothing enforces a naming standard, so consistency depends on a documented convention the team follows. Without that discipline, related data can end up under mismatched topic strings that wildcard subscriptions will miss.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.