IoT for Beginners: MQTT, Platform and Edge
IoT Basics · MQTT · Edge Computing | FastBee Tech Team | Originally published: October 26, 2026 | Content reviewed: October 27, 2026
The Internet of Things (IoT) is a system made up of connected devices, communication networks, and software services that collect, transmit, and process real-world data, then present status or trigger control based on it. The typical data path is "device sensing → protocol transport → platform parsing and storage → application display or rule processing"; control commands travel the reverse path, and the device still has to report the execution result. This article uses a warehouse temperature and humidity sensor to explain the respective responsibilities of MQTT, platform architecture, device management, and edge computing, and cites FastBee's official documentation as an example to mark specific product capabilities and version boundaries.
The bottom line first: MQTT handles publish/subscribe message delivery; an IoT platform also has to organize device identity, data models, rules, and applications; edge computing is added only when on-site response, offline operation, or local processing is a clear requirement. FastBee's open-source official documentation lists a built-in MQTT broker, products/devices/thing models, and scene linkage; OTA firmware upgrade is listed as a commercial-version feature. Platform features change across versions, so check the documentation for your target version before deployment.
How Does a Single Data Point Flow Through an IoT System?
Suppose there is a temperature and humidity sensor in a warehouse. It reads temperature and humidity at intervals and connects to a message service over Wi-Fi or a cellular network; the platform confirms which device the message came from, parses the data by the model, stores it, and checks alert rules; a management page shows the trend, and when the temperature is too high it notifies the operator on duty.
The simplified path is: sensor → network/gateway → message access → device and data services → rules and storage → dashboard or business application. The control direction is the reverse: the user issues a command, the platform checks permissions and sends the command to the target device, and the device reports the result after execution. A real project can combine these responsibilities in a single service, or split them across several services.
What Is MQTT?
MQTT is a lightweight publish/subscribe messaging protocol. Devices publish messages to a topic, and applications or services subscribe to the topics they care about; a message broker forwards messages according to the subscriptions. Publishers and subscribers do not need to know about each other directly, which makes it well suited to devices and applications exchanging messages through an intermediate service.
Understanding Topics with Temperature and Humidity Data
A sensor can publish data to a topic such as warehouse/zone-a/sensor-07/telemetry. Once a monitoring service subscribes to that topic, it receives the readings. A topic is a message routing address, not an identity credential; devices still need separate authentication, and the range of topics they can publish to and subscribe to should be restricted.
What Does QoS Mean?
MQTT QoS describes the delivery level for protocol messages between a single sender and receiver: QoS 0 delivers at most once and may lose messages; QoS 1 delivers at least once and may duplicate; QoS 2 delivers exactly once within the MQTT protocol delivery flow. QoS 2 does not mean a business action is executed exactly once, nor does it prove the device has completed the action; for example, after an "open valve" message is delivered successfully, the device should still report its execution status, and the business side should design idempotency and result confirmation. This definition follows Section 4.3 of the OASIS MQTT 5.0 standard; a specific implementation still needs its protocol version and client/server behavior checked.
| Concept | A simple way to think about it | What to remember as a beginner |
|---|---|---|
| Publish | Send a message to a topic. | Agree on the topic and payload format first. |
| Subscribe | Declare that you want to receive messages matching a topic. | Narrow the subscription scope and control permissions. |
| Broker | The intermediate service that receives and forwards publish/subscribe messages. | It is the communication hub, and does not necessarily include device management and business rules. |
| QoS | The delivery level at the protocol layer. | Choose it by data importance and network cost, and handle duplication and acknowledgement at the application layer. |
| QoS level | Standard definition | What to watch out for |
|---|---|---|
| 0 | At most once; no acknowledgement, and messages may be lost. | Suitable for scenarios that can tolerate occasional data loss. |
| 1 | At least once; messages may be duplicated. | The application needs to recognize duplicate messages or use idempotent handling. |
| 2 | Exactly once within the MQTT protocol delivery flow. | It only constrains protocol message delivery; it does not mean the business effect happens only once. |
You can read the FastBee MQTT access example to learn how devices report data and how the platform delivers data down through topics.
What Parts Make Up an IoT Platform?
An IoT platform is more than an MQTT service. A typical platform organizes connectivity access, a device catalog, data processing, rules, storage, permissions, and application interfaces.
| Part | Main responsibility | Temperature and humidity example |
|---|---|---|
| Protocol access | Maintain connections, authenticate devices, and receive and forward messages. | Handle the sensor's MQTT connection and telemetry messages. |
| Device and product catalog | Record device identity, ownership, status, and capability definitions. | Identify which warehouse and model sensor-07 belongs to. |
| Rules and application services | Transform data, evaluate conditions, and trigger notifications or linkage. | Generate an alert when the temperature stays above the threshold. |
| Data storage | Store device configuration, business information, and historical observations. | Query the temperature and humidity trend of the past week. |
| Management UI and API | Let operators or business systems view and act. | View online status, curves, and alert records. |
FastBee's architecture overview describes the access, business, service, data, and presentation layers, and shows the paths for device reporting and platform command delivery. This is an implementation example from one specific platform; different projects choose different components based on their devices, scale, and team.
How Does a Platform Manage Devices?
"Device online" is only part of device management. The platform also has to know who the device is, which product or customer it belongs to, what data it reports, which operations it is allowed to perform, and whether it has been working normally recently.
- Identity and authentication: assign each device a unique identity and credentials, support credential rotation, and restrict access by least privilege.
- Products and thing models: define the properties, events, and callable functions that devices of the same model can report as a shared model, so applications do not have to understand the fields of each device individually.
- Status and logs: record connection status, last report time, error information, and key operations, and distinguish network failures from data format issues.
- Lifecycle: handle registration, configuration, firmware upgrade, deactivation, and credential revocation; batch operations should have authorization and auditing.
FastBee's official open-source documentation lists modules such as product management, device management, and thing models. Version boundaries need special attention: the official open-source overview lists OTA firmware upgrade under commercial-version feature comparison; therefore the "firmware upgrade" mentioned in this article is a general IoT device lifecycle concept and does not mean that FastBee's open-source version includes OTA. Please consult the official feature overview and the product management documentation for your target version. Do not commit example accounts, device credentials, or unencrypted production keys to a code repository.
What Problem Does Edge Computing Solve?
Edge computing puts part of the processing on a gateway or on-site server close to the devices, rather than sending all data to a remote platform first. It fits situations where the network is unstable, response time requirements are short, on-site data volume is large, or limited local logic still has to run during a network outage.
For example, a gateway can convert Modbus data into a unified format, cache data during a brief outage, or upload only per-minute aggregate values. A central platform is still the better fit for cross-site device management, long-term storage, unified permissions, reporting, and global rules. Edge and center need to work together, so you have to design cache limits, backfill strategy, rule versions, time synchronization, and remote update responsibilities.
| Reason to put it on the edge side | What to design in advance |
|---|---|
| Collection or local logic must still run during an outage. | Cache capacity, data expiry, and the backfill order after connectivity is restored. |
| The site needs a fast response. | Safety interlocks must not rely only on the remote network; define the local failure state. |
| Multiple protocols or a large data volume need on-site conversion/filtering. | Adapter versions, resource limits, data drop policy, and failure logs. |
Edge computing does not automatically make a system safer or more reliable; it adds nodes that have to be deployed, updated, and monitored. Add an edge layer only when on-site latency, connectivity conditions, or data cost genuinely require it.
How Can a Beginner Build a First Project?
- Pick one simple device and one measurement, such as temperature; define the unit, sampling frequency, and reasonable range.
- Publish test messages with an MQTT client or a development board, and check the topic, authentication, and payload format.
- Define the product/device and properties on the platform, and map the messages to readable fields.
- Add a threshold rule and verify alert generation, clearing, and operation records.
- Disconnect and reconnect the network, and observe reconnection, caching, and duplicate message handling. Once the basic path works, consider batch device management or edge nodes.
Remember this main line: MQTT solves how messages are exchanged; an IoT platform organizes devices, data, and business rules; device management handles identity, status, and lifecycle; edge computing puts the necessary processing on site. Get one observable, recoverable data loop working first, then expand the system.
FAQ
Can MQTT QoS 2 guarantee that a device command is executed only once?
No. QoS 2 constrains the message delivery flow at the MQTT protocol layer, and does not guarantee that a device business action is executed only once or executed successfully. The device side should report the execution result; for business requests that may arrive more than once, handle them with a command ID, status check, or idempotent logic.
Does FastBee's open-source version support OTA firmware upgrade?
The official comparison of FastBee's open-source and commercial features lists OTA firmware upgrade as a commercial-version capability. The open-source product management documentation states that the open-source version can record firmware versions; versions and features may change, so check the official documentation for your target version before deployment, and do not equate recording a version with an OTA upgrade.
Does having an MQTT broker mean you have an IoT platform?
No. A broker provides publish/subscribe message forwarding; a device catalog, identity and permissions, thing models, historical data, alerts, and an operations UI usually require other platform capabilities.
Does every IoT device have to use MQTT?
No. Choose the protocol based on device capability, network conditions, interaction model, and existing systems; MQTT is one common option, not the only answer.
Does a small project need edge computing?
If devices can connect directly and stably, the data volume is not large, and offline local response is not needed, connecting directly to the platform is usually easier to maintain. Confirm the on-site requirements before adding edge nodes.
Official Resources
- FastBee open-source documentation
- MQTT access example
- Architecture overview
- Product management and firmware version notes
- FastBee English open-source documentation
- OASIS MQTT 5.0 standard, Section 4.3 QoS
The temperature and humidity warehouse in this article is an illustrative scenario used to explain concepts, not a measured project or customer case. No performance, scale, or effect data has been added. For specific protocol behavior, refer to the protocol version and components you use; for FastBee capabilities, refer to the official documentation for your target version.