Getting Started Cameras & Video Detection & Recording Automation & Events Actions Integration & Connectivity Network & Discovery AI & Remote Control MQTT Modbus ZeroMQ System & Administration Use Cases Troubleshooting About & Legal
Home / Documentation / MQTT Topic Listener
Knowledge base

MQTT Topic Listener

MQTTTopicListenerTask subscribes to MQTT topics through a configured MQTT connector and fires Banalytics events when messages arrive. Use it when external IoT devices, industrial gateways, cloud services, or automation hubs should drive Banalytics rules.

Turn incoming MQTT messages into Banalytics events

The task subscribes to a topic filter on an MQTT connector. Each received message becomes an MQTTTopicMessageEvent containing topic, payload, QoS, retained flag, and payload type metadata.

SUB

Subscribe

The task uses an MQTT v3 or v5 connector to subscribe to one topic filter.

EVT

Fire events

Every matching message can trigger Event Manager rules inside Banalytics.

PAY

Payload handling

Payloads can be delivered as UTF-8 text for easier rule processing.

Adding an MQTT topic listener

01

Select the connector

Choose an MQTT v3 or v5 connector that is connected to the broker where the topics are published.

02

Choose a topic filter

Start narrow whenever possible, for example site/line1/+/state or building/floor1/sensor/temperature.

03

Set QoS

Use QoS 1 for most state-change topics, QoS 0 for high-frequency telemetry, and QoS 2 only when duplicate processing is more dangerous than protocol overhead.

04

Decide payload mode

Keep stringPayload=true for JSON, plain text, numeric values, and home-automation style topics.

Design filters that keep events manageable

#

Diagnostics

Use # only during commissioning or troubleshooting when you need to observe all reachable broker traffic.

+

Subsystem filter

Use one-level wildcards such as site/line1/+/state to capture a family of related devices.

ONE

Single signal

Use exact topics for critical automations where the Event Manager rule should be easy to reason about.

Broad filters multiply work: MQTT wildcards can create a large number of Banalytics events on busy brokers. Prefer narrow filters for production rules.

QoS, retained messages, and event timing

QoS 0
Best for high-frequency telemetry where old values are not important.
QoS 1
Good default for state changes where at-least-once delivery is acceptable.
QoS 2
Use when duplicate processing is riskier than the additional protocol overhead.
Retained
A listener may receive retained broker state immediately after subscription. Use the event's retained flag to distinguish it.

Configuration parameters

ParameterRequiredDescriptionDefault
MQTT Connector
YesReference to an MQTT connector. It can be MQTTV3Connector or MQTTV5Connector.None
Topic Filter
YesMQTT topic filter pattern. Supports MQTT wildcards: + for one level and # for multiple levels.#
QoS
YesRequested subscription quality of service: 0, 1, or 2.1
String message
YesConverts the received payload to a UTF-8 string before event delivery.true

MQTTTopicMessageEvent fields

FieldTypeDescriptionUse
topic
StringMQTT topic on which the message was received.Route rules by source
stringPayload
booleanShows whether payload is represented as a String.Branch processing
payload
ObjectMessage payload. Usually a String when string payload mode is enabled.Rule conditions
qos
intQoS level of the received message.Diagnostics
retained
booleanWhether the message was delivered from broker retention.Ignore stale commands

Operational notes

RUN

Connector must be running

The listener can subscribe only when the selected connector is running and connected.

RST

Restart on configuration changes

Changing connector, topic filter, QoS, or payload mode requires restarting the task.

DISC

Disconnected connector

Message delivery pauses while the connector is disconnected and resumes according to connector and task restart behavior.

Related MQTT pages

Related tasks and pages