# MQTT Subscribe This function block listens to an MQTT topic and outputs incoming messages for use elsewhere in your scenario. It keeps track of whether a message is new so you can trigger actions only when fresh data arrives. ## đŸ“Ĩ Inputs * `Enable` Input socket — Enable or disable the subscription. When active, the block connects to the broker and listens for messages. ## 📤 Outputs * `Data` Output socket — Latest received message payload (text) from the subscribed topic. * `New Data` Output socket — Boolean output socket that becomes true for one run when a new message arrives. ## 🕹ī¸ Controls * `Broker Address` Hostname or IP of the MQTT broker to connect to. * `Port` Broker TCP port (commonly 1883 or 8883 for TLS). * `Topic` Topic string to subscribe to (supports exact topic matching). * `Client ID` Optional identifier for the MQTT client. * `Username` Optional username for broker authentication. * `Password` Optional password for broker authentication. * `Keep Alive` Interval used to maintain the broker connection. * `Use TLS` Toggle to enable TLS-secured connection (if supported by broker). * `Reconnect / Connect` Button or automatic logic in the UI to (re)establish connection when settings change. (how these controls appear in the UI may vary; provide valid connection parameters and enable the block to start receiving messages) ## đŸŽ¯ Features * Persistent subscription while `Enable` is true — messages are received in real time. * Provides both the raw `Data` and a one-run `New Data` flag so downstream blocks can respond only to new messages. * Automatically reconnects if connection parameters change. * Basic connection status and informational messages appear in the block UI to help diagnose connection events. ## ⚙ī¸ Running mechanism * When `Enable` is active, the block uses the configured connection settings to connect to the MQTT broker and subscribe to the chosen `Topic`. * Incoming messages are stored internally and exposed on the `Data` output. * The block sets `New Data` to true only for the run immediately after a new message arrives; on subsequent runs it resets to false until another message is received. * Changing connection settings causes the block to reconnect so the new parameters take effect. ## 📝 Usage instructions 1. Fill in connection parameters: `Broker Address`, `Port`, and `Topic` (add credentials if broker requires them). 2. Enable the block via the `Enable` input. 3. Use the `Data` output to pass received payloads to other blocks. Use the `New Data` output to trigger downstream processing only when a new message arrives. 4. If you change connection settings, allow a short moment for the block to reconnect. ## 💡 Tips and Tricks * To forward received messages to a server or service, connect `Data` to `REST API - Post`. * To re-publish or echo messages, combine this block with `MQTT Publish` or `MQTT Publish (TLS-Beta)`. * Use `Data to JSON` to structure multiple fields from incoming text before logging or exporting. * Save incoming messages for later review by connecting `Data` to `CSV Export` or to `SQL-DB Operations` (via `Data to JSON` or appropriate formatting). * Add a `Debug Input` block to quickly inspect message contents in the log window during development. * When dealing with changing formats, use `Replace None` or `Is None` blocks to handle missing or malformed messages gracefully. (hints above use only the function blocks available in the system) ## 🛠ī¸ Troubleshooting * No messages received: verify `Broker Address`, `Port` and `Topic` are correct and that the broker is reachable from the machine running the scenario. * Authentication errors: double-check `Username` and `Password` and whether your broker requires TLS. * Intermittent connection: check network/firewall settings and try enabling TLS or adjusting `Keep Alive`. * Messages arrive but are not forwarded: ensure downstream blocks are enabled and use the `New Data` flag if they should only run on new payloads. * If you change parameters, wait briefly after re-enabling for the block to reconnect before expecting messages. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.augelab.com/function-blocks/input-output/communication/mqtt-subscribe.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.