IoT for Beginners: From MQTT to Device Management, Platforms, and Edge Computing

The Internet of Things (IoT) integrates connected devices, networks, and software to collect, process, and utilize data from the physical world. A typical data flow involves devices sending information to a network protocol, which then passes through platform processing and storage before being analyzed by applications or rules. Commands are sent back to devices, which must report the results.

This guide explains MQTT, IoT platform components, device management, and edge computing using a warehouse temperature-and-humidity sensor as an example. FastBee documentation uses this product to demonstrate these concepts, with specific capabilities indicated by edition.

Key point: MQTT moves publish/subscribe messages; an IoT platform organizes device identity, data models, rules, and applications. Edge computing may be needed for local responses, intermittent connectivity, or on-site data processing, despite additional deployment and operational requirements.

Let's say there's a temperature-and-humidity sensor in a warehouse. This sensor periodically takes measurements and connects to a messaging service via Wi-Fi or cellular service. The platform checks the device's identity, interprets the message using a data model, stores the information, and checks alarm rules. A dashboard displays trends; if the temperature becomes too high, the system notifies an operator.

Simplified data flow: sensor → network/gateway → message ingestion → device and data services → rules and storage → dashboard or business app. Control flows in the opposite direction as well: an authorized user or application requests an action. The platform sends this request to the appropriate device, and the device reports the outcome.

Deployment may combine or split these responsibilities across different services.

MQTT, a lightweight publish/subscribe messaging protocol, allows devices to publish messages to topics and applications or services to subscribe to topics of interest. A message broker routes messages based on subscriptions, and publishers and subscribers don't need to know each other directly, making this pattern useful for exchanging messages between devices and applications.

A sensor might publish to a topic like warehouse/zone-a/sensor-07/telemetry. A monitoring service subscribes to this topic and receives readings. Topics serve as routing addresses, not identity credentials, so devices still need authentication and narrowly-scoped permissions.

QoS (Quality of Service) in MQTT defines message delivery at the protocol layer. QoS 0 is at most once and may lose messages; QoS 1 is at least once and can produce duplicates; QoS 2 delivers a message exactly once within the MQTT flow. QoS 2 does not guarantee that a device action ran exactly once or succeeded. A "open valve" command still needs an application-level confirmation, and systems should use idempotent handling for duplicate business requests.

These definitions follow the OASIS MQTT 5.0 standard; always verify behavior against the specific protocol version and components in use.

Plain language: publish sends a message to a topic. Agree on topic names and payload format. Subscribe asks to receive messages matching a topic filter. Keep scope narrow and permissions controlled. Broker is the communications hub, receiving and forwarding publish/subscribe messages. QoS defines message delivery levels, balancing data importance and network cost. Handling duplicates and business acknowledgments is crucial.

FastBee's open-source MQTT Broker supports QoS 0 and QoS 1. Do not assume support for QoS 2 without checking the broker documentation for the target release. For an example of device reporting and command usage, see FastBee MQTT Access.

An IoT platform consists of more than just an MQTT service. It connects device ingestion, a device registry, data processing, rules, storage, permissions, and application interfaces. Each part has specific responsibilities: sensor example protocols handle connections, authentication, and message routing; device and product registries record identity, ownership, status, and capability definitions; rules and application services transform data, evaluate conditions, and trigger notifications or actions; data storage stores device configurations, business records, and historical data; consoles and APIs provide operators and business systems with ways to view or act on platform data.

FastBee's open-source architecture includes access, business, service, data, and presentation layers, with details on device reporting and command-dispatch flows. This is one platform implementation example, not a required architecture for every IoT project.

Device management in a platform goes beyond simply indicating a device is "online." It includes maintaining connections, authenticating devices, and receiving or routing messages. The platform must also manage a device registry, record device identities, statuses, and capabilities; provide rules and application services; store data; and offer consoles and APIs for operators and business systems.