Collectors and data formats
MQTT collector
basic settings the collector settings are used to connect to the mqtt broker mqtturl description the connection url for the mqtt broker required yes example tcp\ //localhost 1883 clientcertificate description use a client certificate required no default false options false | true username description username required no password description password required no topics description comma separated list of topics to subscribe to (wildcards are allowed) required yes qos description qos with which to subscribe required yes default 1 options 0 | 1 | 2 keepalivesecs description the keep alive period in seconds, before which the client sends a ping to the mqtt broker (default is 30 seconds) on no response received, the connection is closed required no default 30 persistentsession description if the session is persistent, the broker will store the session information and deliver messages to the client when it reconnects so the broker is responsible for caching the messages until the collector is active again required no default true configuration this guide provides comprehensive instructions for setting up and configuring the mqtt collector for factry historian it includes installation steps, connection setup, and best practices for secure and reliable data transmission collector installation to install the mqtt collector, follow the steps outlined in the collector installation guide connecting the mqtt collector to a broker to connect the mqtt collector to your broker, ensure the following configurations are properly set up authentication provide the username and password required for broker authentication secure communication (tls) use a ca certificate to validate the broker’s identity for mutual tls, include the client certificate and private key while tls is optional, it is highly recommended for secure environments to ensure encrypted communication and prevent unauthorized access quality of service (qos) mqtt supports three levels of quality of service (qos), each offering different guarantees for message delivery level description guarantee use case qos 0 at most once no guarantee of delivery non critical data qos 1 at least once message delivered at least once (may duplicate) recommended for most industrial use qos 2 exactly once message delivered exactly once critical data, higher overhead recommendation use qos 1 or qos 2 to ensure reliable delivery of measurement data topics mqtt topics are used to route messages the collector subscribes to specific topics to receive data topics act as filters — the collector only processes messages from subscribed topics measurement configurations can only extract data from these subscribed topics wildcards in topics mqtt supports wildcards for flexible topic subscriptions single level wildcard + matches exactly one level of a topic example factory/+/temperature matches factory/machine1/temperature factory/machine2/temperature multi level wildcard # matches multiple levels (including zero) and must be the last character in the topic example factory/# matches factory/machine1 factory/machine1/temperature factory/machine2/status/online for more information and best practices, refer to mqtt topics best practices – hivemq mqtt messages there are multiple types of messages that can be processed via mqtt {{json}} messages see json settings docid\ wzx5o0po00yfahzxqixzw sparkplug b messages see sparkplug b settings docid\ ey5tgfrnf4egfqzembzxo