MQTT connections
MQTT is part of the program. You need no plugin for it.
The connection
Section titled “The connection”| Field | Meaning |
|---|---|
| Broker address | mqtt:// plain, mqtts:// encrypted. Give the port when it is not 1883. Example: mqtt://10.0.0.5:1883 |
| User | leave empty when the broker needs no login |
| Password | stored encrypted |
| Client id | leave empty for a derived one |
About the client id: two connections must never share one. The broker then keeps kicking one of them off in turn, and it looks like an unstable network.
TrakState holds no durable subscriptions on the broker. After a restart it resubscribes from the configuration; the truth lives here, not in a broker-side queue. A reconnect is attempted every five seconds.
The tag
Section titled “The tag”| Field | Meaning |
|---|---|
| Topic | + matches one level, # the rest. Example: line1/+/cycle |
| Payload | The whole payload is the value or JSON, value at a path |
| JSON path | JSON only. Levels separated by a slash, for example data/temperature |
A tag is called something like Press1.PartCount and listens on a topic. If an incoming
message has no such JSON path, the tag is reported bad. The last value is not left
standing — an old figure that looks current is worse than a visible gap.
When you save the tag, its fields are checked against what the connector expects: an empty topic, a field the connector does not know, or a value it cannot take is listed under the fields as a warning. The tag is saved anyway — a warning means it will most likely never receive a value until the field is corrected. The same holds for a tag whose connector is no longer installed: it can still be saved, its fields just cannot be checked.
Writing out
Section titled “Writing out”MQTT can write. A tag whose direction is Writes to the machine or Both, for example
Press1.Setpoint_bar, publishes its value onto the topic.
Two rules go with that:
- The topic has to be exact. A topic containing
+or#cannot be published to. - There is a receipt. The message is published at QoS 1, and the write counts as successful only once the broker has acknowledged it. If the connection is not up, or the acknowledgement takes longer than five seconds, TrakState reports a failure rather than a success. A setpoint that vanishes silently is not a display glitch in a plant.
Before sending, the interface asks once more and names the value, the tag, the connection and the topic.
When the broker is gone
Section titled “When the broker is gone”If a connection drops, only that connection’s tags are marked bad. A hall that is down does not make the other hall’s numbers look suspect.