IoT Basics · MQTT · Edge Computing | FastBee Technical Team | Published October 26, 2026 · Reviewed October 27, 2026
The Internet of Things (IoT) is a system of connected devices, networks, and software that collects and processes data from the physical world so people or applications can monitor conditions and trigger actions. A typical data path is device → network protocol → platform processing and storage → application or rule; commands travel back to devices, which should report the result. This guide uses a warehouse temperature-and-humidity sensor to explain MQTT, IoT platform components, device management, and edge computing. FastBee documentation provides a product example, with edition-specific capabilities called out separately.
Key takeaway: MQTT moves publish/subscribe messages; an IoT platform also organizes device identity, data models, rules, and applications. Add edge computing when local response, intermittent connectivity, or on-site data processing justifies the extra deployment and operations work. FastBee’s current open-source documentation lists an embedded MQTT broker and product/device/thing-model management; OTA firmware updates are a commercial-edition capability.
How does data move through an IoT system?
Imagine a temperature-and-humidity sensor in a warehouse. At intervals, it takes a reading and connects over Wi-Fi or cellular service to a messaging service. The platform verifies which device sent the message, interprets it using a data model, stores it, and checks alarm rules. A dashboard shows the trend; if the temperature gets too high, the system notifies an operator.
A simplified path is: sensor → network/gateway → message ingestion → device and data services → rules and storage → dashboard or business app. Control flows the other way: an authorized user or application requests an action, the platform sends it to the right device, and the device reports what happened. A real deployment may combine these responsibilities in one service or split them across services.
What is MQTT?
MQTT is a lightweight publish/subscribe messaging protocol. A device publishes a message to a topic; an application or service subscribes to topics it cares about. A message broker routes messages according to those subscriptions. Publishers and subscribers do not need to know each other directly, which makes the pattern useful for exchanging messages between devices and applications.
Understanding a topic with sensor data
A sensor might publish to warehouse/zone-a/sensor-07/telemetry. A monitoring service subscribes to that topic and receives readings. A topic is a routing address, not an identity credential. Devices still need authentication, and their publish and subscribe permissions should be scoped narrowly.
What does QoS mean?
MQTT QoS describes message delivery between a sender and receiver at the protocol layer: QoS 0 is at most once and can lose a message; QoS 1 is at least once and can produce duplicates; QoS 2 delivers a protocol message exactly once within the MQTT delivery flow. QoS 2 does not guarantee that a device action ran exactly once or succeeded. A delivered “open valve” command still needs an application-level result, and systems should use command identifiers or idempotent handling where duplicate business requests matter. These definitions follow section 4.3 of the OASIS MQTT 5.0 standard; verify behavior against the protocol version and components in use.
| Concept | Plain-language meaning | Remember |
|---|---|---|
| Publish | Send a message to a topic. | Agree on topic names and payload format. |
| Subscribe | Ask to receive messages matching a topic filter. | Keep the scope narrow and permission-controlled. |
| Broker | The service that receives and forwards publish/subscribe messages. | It is a communications hub; it may not provide device management or business rules. |
| QoS | A protocol-level delivery level. | Choose for data importance and network cost; handle duplicates and business acknowledgments in the application too. |
| QoS level | MQTT delivery meaning | Practical limit |
|---|---|---|
| 0 | At most once; no acknowledgment, and loss is possible. | Use when occasional message loss is acceptable. |
| 1 | At least once; duplicates are possible. | Make application processing duplicate-aware or idempotent. |
| 2 | Exactly once within the MQTT protocol delivery flow. | Does not guarantee exactly-once business execution. |
FastBee-specific note: the official open-source MQTT Broker documentation lists support for QoS 0 and QoS 1. Do not assume that FastBee’s broker supports QoS 2; check the broker documentation for the target release. For a device-reporting and command example, see FastBee MQTT Access.
What makes up an IoT platform?
An IoT platform is more than an MQTT service. A common platform connects device ingestion, a device registry, data processing, rules, storage, permissions, and application interfaces.
| Part | Responsibility | Sensor example |
|---|---|---|
| Protocol ingestion | Maintain connections, authenticate devices, and receive or route messages. | Handle the sensor’s MQTT connection and telemetry. |
| Device and product registry | Record 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 actions. | Create an alarm when temperature stays above a threshold. |
| Data storage | Store device configuration, business records, and historical observations. | Query the last week of temperature and humidity readings. |
| Console and APIs | Let operators and business systems view or act on platform data. | Inspect online status, charts, and alarm history. |
FastBee’s open-source architecture overview describes access, business, service, data, and presentation layers and documents device reporting and command-dispatch flows. This is an example of one platform implementation, not a required architecture for every IoT project.
How does a platform manage devices?
“Online” is only one part of device management. A platform also needs to know who a device is, which product or customer it belongs to, what data it reports, which actions it may perform, and whether it is operating normally.
- Identity and authentication: Give each device a unique identity and credential, support credential rotation, and enforce least-privilege access.
- Products and thing models: Describe the properties, events, and callable functions shared by a device model, so applications do not need to interpret every device’s fields separately.
- Status and logs: Track connection state, last report time, errors, and important actions to distinguish a network outage from a payload-format problem.
- Lifecycle: Handle registration, configuration, firmware-version records or updates, retirement, and credential revocation. Firmware recording and OTA delivery are different capabilities; bulk operations need authorization and an audit trail.
FastBee’s official documentation lists product management, device management, and thing models in the open-source edition. Its product-management documentation says the open-source edition records firmware versions, while OTA upgrades are supported by the commercial edition. Check the target release before deployment. Do not publish example accounts, device credentials, or unencrypted production secrets in a source repository.
What problems does edge computing solve?
Edge computing places some processing on a gateway or local server near devices instead of sending every operation to a remote platform first. It can help when networks are unreliable, response time matters, local data volumes are high, or limited local logic must continue during an outage.
For example, a gateway can convert Modbus readings into a common message format, buffer data during a temporary disconnection, or upload one-minute summaries instead of every raw sample. A central platform remains useful for cross-site device management, long-term storage, shared permissions, reporting, and global rules. Edge and central systems work together, so define local buffer limits, replay behavior, rule versions, time synchronization, and remote-update ownership.
| Why process at the edge? | What to design first |
|---|---|
| Collection or local logic must continue during an outage. | Buffer capacity, data expiry, and replay order after reconnection. |
| The site needs a fast response. | Do not make safety interlocks depend only on a remote network; define local failure behavior. |
| Many protocols or large data volumes require local conversion or filtering. | Adapter versions, resource limits, dropped-data behavior, and diagnostic logs. |
Edge computing does not automatically make a system safer or more reliable. It adds nodes that must be deployed, updated, and monitored. Add an edge layer when site latency, connectivity, or data cost calls for it.
How can a beginner build a first project?
- Choose one simple device and one measurement, such as temperature. Define its unit, sampling interval, and sensible range.
- Use an MQTT client or development board to publish a test message. Check the topic, authentication, and payload format.
- Define the product/device and property in a platform, then map the message to a readable field.
- Add one threshold rule and verify how an alarm starts, clears, and appears in operation history.
- Disconnect and reconnect the network. Observe reconnection, buffering, and duplicate handling before adding fleet management or edge nodes.
Keep this mental model: MQTT moves messages; an IoT platform organizes devices, data, and business rules; device management handles identity, status, and lifecycle; edge computing moves necessary processing closer to the site. First make one data loop observable and recoverable, then expand it.
Frequently asked questions
Does MQTT QoS 2 guarantee that a device command runs only once?
No. QoS 2 governs protocol-level message delivery, not whether a device executes a business action once or successfully. Devices should report execution results; applications can use command IDs, state checks, and idempotent handlers to manage retries or duplicate requests.
Does FastBee Open Source support OTA firmware updates?
FastBee’s current official edition comparison and product documentation list OTA firmware updates as a commercial-edition capability. The open-source edition can record firmware versions; version records are not the same as delivering an OTA update. Verify the documentation for the release you plan to use.
Is an MQTT broker the same as an IoT platform?
No. A broker routes publish/subscribe messages. A device registry, identity and permissions, thing models, historical data, alarms, and operations console typically require additional platform capabilities.
Does every IoT device need MQTT?
No. Choose a protocol based on device capability, network conditions, interaction pattern, and existing systems. MQTT is a common option, not the only one.
Does a small project need edge computing?
If devices can connect reliably, data volume is modest, and local outage response is unnecessary, a direct platform connection is often simpler to operate. Add edge nodes only when site needs justify them.
Official references
- FastBee open-source documentation
- MQTT Access
- MQTT Broker capabilities
- Architecture overview
- Product Management and firmware version records
- FastBee Chinese open-source documentation
- OASIS MQTT 5.0 standard, section 4.3
The warehouse sensor is an illustrative scenario, not a measured deployment or customer case. This article adds no performance or scale measurements. Check the MQTT version and component documentation for protocol behavior, and verify FastBee capabilities against the target edition and release.
Top comments (0)