Consumer Placeholder Reference
Every substitution token available in consumer queries, topics, and payloads — including epoch variants and the timezone semantics that trip people.
The complete token list is generated. This article explains how placeholders behave and which to reach for. For every token the engine accepts — 104 of them across 10 contexts, read from the source — see Consumer Placeholder Token Reference. The four payload consumers now share one engine, so that list applies to MQTT, Kafka, Event Hub and Kinesis alike.
Consumer configuration — SQL statements, MQTT topics, payload templates, endpoint bodies — is written as templates, and Infohub substitutes per value at send time. The tokens have never been listed in one place; several are documented only in old release notes. This is the list, with the semantics that matter.
The value tokens#
Substituted once per measure value being sent:
| Token | Substitutes |
|---|---|
[MeasureValue] |
The value itself |
[MeasureValueQuality] |
Its quality code |
[MeasureName] |
The measure's name |
[MeasureID] |
The measure's ID (local to this instance — see identity note below) |
[TimeSchemeName] |
The calendar the value belongs to |
[PeriodStart] / [PeriodEnd] |
The period boundaries |
[Version] |
Payload version marker (custom MQTT topic/payload — added in 7.2.0; see the note below) |
[Version] resolves on measure-value publishing only. In 7.2.0 the event-scheme, attribute and raw-tag MQTT publish paths still emit the literal text [Version]. Use it only in the topic and payload of measure-value publishing.
The time tokens, precisely#
Timestamps are where integrations go quietly wrong, so the semantics deserve exactness:
| Token family | Format | Zone |
|---|---|---|
[PeriodStart] / [PeriodEnd] |
Date-time string | See the warning below |
[MeasureValueDateTimeUtc] |
Date-time string | UTC, explicitly |
| Epoch variants | Unix epoch number | UTC by definition |
Epoch placeholders exist for consumers whose targets want Unix time (they entered the product in the 7.1.2 era and were documented only in those release notes). When a target rejects a date string or plots values decades off, the epoch variant — and whether it is seconds or milliseconds — is the first thing to check. Confirm the unit against one known value rather than assuming.
The local-time trap. Tokens without an explicit Utc suffix substitute a local time — and "local" here has historically meant the server's operating-system time zone, not the Infohub instance's configured TimeZoneID. On a server whose OS zone differs from the instance's zone, [periodstart] shifts by the difference.
Two defences: prefer the explicit-UTC tokens wherever the destination can take UTC; and where the destination requires local time, verify one substituted value end-to-end on a server whose OS zone differs from the instance zone — that is the configuration that exposes the trap. (A fix aligning these tokens to the instance TimeZoneID is in progress; until you have verified your build's behaviour, treat non-UTC tokens as suspect.)
Event context tokens#
Where a consumer sends event-contextualised values:
| Token | Substitutes |
|---|---|
[Attribute] |
The attribute's name |
[AttributeValue] |
The attribute's value |
[Preferred] |
Whether this is the preferred value (true/false) — used to gate SQL upserts |
The [Preferred] gate matters in SQL consumers: Infohub can send multiple versions of a value, and a statement that does not distinguish preferred from superseded rows accumulates contradictions. See SQL and Snowflake Consumers.
Model attribute tokens#
[ModelAttribute("Name")] substitutes the attribute resolved for the measure being sent — the same token as on the retrieval side, and the mechanism that lets one consumer configuration serve a templated fleet:
[ModelAttribute("Enterprise")]/[ModelAttribute("Site")]/[ModelAttribute("Area")]/[MeasureName]
Three rules from hard experience:
- Every attribute in the template must resolve for every measure sent. An unresolved token does not error — it produces a literal
[ModelAttribute("…")]in the topic or SQL, which lands in a topic nobody subscribes to or a WHERE clause nothing matches. The classic symptom is some measures publishing and others silently not. - Case-sensitivity: as of 7.2.0 the MQTT consumer resolves attribute names case-insensitively (older versions were case-sensitive — a token that failed only because of case will begin resolving after upgrade, and the topic will move).
- Attribute values substitute as stored — a value with a
/in it will split an MQTT topic level. Constrain attribute values that feed topics.
Where each token class is valid#
| Consumer | Value/time tokens | Event tokens | ModelAttribute | [Version] |
|---|---|---|---|---|
| SQL family (queries) | ✓ | ✓ | ✓ | — |
| MQTT / Sparkplug custom topic & payload | ✓ | ✓ | ✓ | ✓ |
| Endpoint (body text) | ✓ | ✓ | ✓ | — |
| Event Hub / Kafka / Kinesis payloads | ✓ | ✓ | ✓ | — |
(The 7.2.0 release fixed Event Hub's previously unreachable Unix-time placeholders.)
Identity, one more time#
[MeasureID] is stable but local — meaningless at the destination and different on every Infohub instance. [MeasureName] is readable but changes on rename. Whichever you key the destination on, write the choice into the integration contract, because "is the key the name or the ID" is the question nobody can answer a year later. See What a Data Consumer Is.
Verifying substitution#
Before deploying any consumer template:
- Attach one measure.
- Send one value; capture what actually arrived (the SQL row, the MQTT message via a generic client, the HTTP body at the endpoint).
- Check every token substituted — no literal
[...]residue. - Check the timestamp: right zone, right unit, one known value compared end-to-end.
- Then scale up.
Token residue and timezone offsets are invisible in Infohub's own logs — the consumer reports success because sending succeeded. Only the destination shows the truth.