MQTT for Shelly and Sonoff: From Devices to Business Workflows

28 September 2026 | Neuronidis Manos | Blog

MQTT for Shelly and Sonoff provides a lightweight messaging layer between smart devices, an MQTT broker, and business software. The broker receives device data and distributes it to dashboards, databases, alerts, automated actions, ERP processes, and operational tools. The real value is not switching a relay remotely. It is turning device events into information and controlled business workflows.

The short answer: MQTT connects devices to workflows

Shelly and Sonoff devices can publish readings or status updates and receive commands through MQTT. A temperature reading, power measurement, access event, or relay state becomes a message that other systems can consume without connecting directly to every device.

This separation matters. Devices do not need to know whether a message feeds a dashboard, sends an alert, updates a maintenance record, or starts an automated process. Each application subscribes to the messages it needs. That makes MQTT useful for IoT business automation, especially when a company has many devices or several systems need the same data.

How Shelly and Sonoff devices publish and receive MQTT messages

MQTT uses a publish-subscribe model. A device publishes a message to a topic. An MQTT broker receives it and passes it to subscribed applications. A dashboard, storage service, automation engine, or custom application can subscribe without creating a separate direct connection to the device.

For example, a Shelly device might publish a power reading to a topic such as:

site/warehouse/line-2/shelly-07/telemetry/power

A Sonoff device could publish its relay state to:

site/office/entrance/sonoff-03/state/relay

These topic names are examples, not universal requirements. Device models, firmware, configuration options, and integration methods differ. The important point is to establish a consistent structure that identifies the site, area, device, data type, and message purpose. A command topic should not be confused with a measurement topic.

The message itself contains a payload, often in a simple format such as JSON. It may include a value, unit, timestamp, device identifier, or status. MQTT also supports retained messages. The broker stores the latest message for a topic and delivers it to a new subscriber. This is useful for current state, but it can expose stale information if applications do not check timestamps.

Quality of Service, or QoS, controls delivery guarantees. Lower levels reduce overhead but may not confirm delivery. Higher levels provide stronger delivery behaviour at the cost of additional traffic and processing. The right setting depends on the message. A frequent temperature reading and a safety-related command do not necessarily need the same treatment.

What should the MQTT architecture contain?

A production MQTT architecture usually includes devices, a broker, authentication, topic rules, client applications, storage, dashboards, and alerting. The broker coordinates messages, but it should not be treated as the long-term database or the only place where business rules live.

A practical setup often contains these layers:

• Devices: Shelly and Sonoff units publish telemetry and receive commands through their configured MQTT connection.
• MQTT broker: The broker accepts client connections, checks permissions, and routes messages to subscribers.
• Authentication and access control: Each device or application should have controlled credentials and access to only the topics it needs.
• Topic convention: Topics should remain predictable as more buildings, rooms, devices, and measurements are added.
• Ingestion service: A service can validate, transform, enrich, and route incoming payloads before storage or further processing.
• Storage: Time-series data may suit measurement history, while a relational database can hold assets, users, work orders, permissions, and business records.
• Applications: Dashboards, notification services, automation engines, and ERP connectors consume the processed data.

Local control and business-facing data flows should be considered separately. A local rule might turn on a fan when a sensor reaches a threshold. A business workflow might also require a record in an asset system, a notification to a responsible person, an approval check, and an audit entry. Putting all of that inside the broker or a device rule makes the system difficult to test and change.

For larger installations, a building-control design may need to connect otherwise closed systems with operational software. The IoT and smart automation approach explains why this wider connection matters beyond isolated device control.

From device messages to dashboards, alerts, and automated actions

MQTT data becomes useful when another system gives it context. A message containing 21.8 is not enough on its own. The application needs to know whether this is temperature, where the sensor is installed, when the reading was taken, and what range is acceptable.

A common flow looks like this:

1. A Shelly or Sonoff device publishes a reading or state change.
2. The broker delivers the message to an ingestion service.
3. The service validates the payload and adds context such as the asset or location.
4. The data is stored for history and reporting.
5. A dashboard presents the current state and trends.
6. An alert or workflow engine decides whether further action is needed.

Possible outcomes include an alert when temperature remains outside an acceptable range, a report on unusual power consumption, a notification when an access point changes state, or a scheduled command that controls equipment during defined hours. Historical data can help a facilities team compare consumption, investigate an incident, or plan maintenance.

There is a meaningful difference between a direct rule and a business workflow. A direct rule might be: “If temperature exceeds a threshold, publish a command.” A workflow may need to check whether the sensor is trusted, whether the equipment is already running, whether a person has permission to approve the action, and whether the result must be recorded in an ERP system.

That second type of requirement needs logging, validation, retries, and clear ownership. It may also need a human notification rather than immediate device control. Intelligent automation is useful here because it connects the event to the wider process instead of treating every message as an isolated trigger. See the intelligent automation service overview for the wider systems perspective.

When a direct connection is enough, and when custom middleware is better

A ready-made integration is often the right choice for a small, well-defined use case. If one device sends data to a dashboard, or a simple broker rule controls a relay, adding a custom application may create unnecessary cost and maintenance.

Direct connections and broker rules are less suitable when data must cross several systems or follow business rules. Warning signs include:

• Multiple device types use different payload formats.
• Several sites or departments need different permissions.
• Messages must be converted before entering an ERP, CRM, or database.
• Commands need retries, confirmation, scheduling, or approval.
• The business needs an audit trail showing who changed what and when.
• Device ownership, tenant separation, or user roles matter.
• Offline devices must be reconciled when they reconnect.
• Operational data must be exposed through a controlled application interface.

In these cases, custom MQTT middleware can sit between the broker and business software. It can validate payloads, normalise device data, apply permissions, manage retries, publish events to other systems, and record failures for review.

REST APIs and webhooks can also be part of the design. MQTT is well suited to event delivery, while an API may be better for querying records, updating a business object, or requesting a controlled action. The distinction is useful. An API integration strategy can help define which system owns each piece of data.

A custom layer is not automatically better. It is justified when the cost of inconsistent data, manual work, weak permissions, or failed synchronisation is greater than the cost of designing and maintaining the application. A custom web application can provide the user interface and workflow controls when a dashboard alone is not enough.

Security and reliability details that are easy to postpone

MQTT security starts with encrypted connections, unique credentials, and carefully limited permissions. Use TLS where appropriate, avoid shared passwords across devices, and restrict each client to the topics it must publish or read. Network segmentation can reduce the damage if one device or credential is compromised.

Credentials and certificates should not be hard-coded into source code or copied into uncontrolled documents. Client IDs should be unique so reconnecting devices do not accidentally replace one another. Brokers and applications also need monitoring for failed authentication, unusual message volume, repeated reconnects, and unexpected topic activity. The small-business security guidance on reducing avoidable security exposure applies to connected device environments as well.

Reliability needs equal attention. Devices go offline. Networks fail. Messages can arrive more than once, arrive late, or remain retained after the underlying state has changed. Applications should use timestamps, detect stale readings, and make important actions idempotent. In practice, repeating the same valid command should not create an unsafe result.

For important workflows, record command status and confirmation rather than assuming that publication means execution. Define what happens after a timeout, how reconnection is handled, and who is notified when a device remains unavailable. These decisions are less exciting than choosing a dashboard, but they determine whether the system can be trusted during a real incident.

A practical decision path for an MQTT business project

Start with the operational outcome, not the device brand. Define what the business needs to observe, decide, or change. Then inventory devices and data, design the topic structure, select the broker and storage model, and test disconnections, duplicates, stale values, and failed commands.

Only then decide whether a ready-made connector, broker rule, API integration, or custom middleware fits the job. Before connecting MQTT to an ERP or important workflow, design the data ownership and recovery rules first. The database design guide is a useful reference for deciding what belongs in historical measurements, operational records, and business entities.