DEV Community: Fastbee

ESP32/ESP8266 MQTT Tutorial: Docker Deployment and Remote Device Control

Fastbee — Wed, 28 Oct 2026 03:19:13 +0000

A reproducible IoT development walkthrough: run FastBee Open Source Edition with Docker, configure an MQTT product and Thing Model, then publish telemetry and receive remote commands on an ESP32 or ESP8266.

Short answer: Deploy FastBee Open Source Edition, create and publish an MQTT product with the properties your device will report, then connect the board using its product ID, device number, user ID, and MQTT credentials. Use FastBee-Arduino’s documented firmware path for supported ESP32 boards; an ESP8266 needs a custom MQTT client that follows FastBee’s documented topics and payload format.

For: Developers who know basic networking and Arduino development and are setting up an IoT platform for the first time.
Outcome: Move from Wi-Fi connectivity to a complete loop: the platform sees device data, sends a command, and receives the device’s reported state.
Board support: Official FastBee-Arduino zero-code firmware targets the ESP32 family. An ESP8266 can follow the MQTT protocol below with firmware you write and maintain; do not flash the ESP32 firmware onto an ESP8266.

What you will build

A FastBee Open Source Edition test environment deployed with Docker Compose.
An MQTT product with a temperature property and a writable switch property.
An ESP32 or ESP8266 device that comes online, reports properties, and completes a remote-control round trip.

Sensor/relay ↔ ESP32 or ESP8266 ↔ MQTT broker ↔ FastBee platform ↔ Web console

1. Prerequisites

A server or local VM. FastBee’s current Docker guide lists a minimum of 2 CPU cores and 4 GB RAM; this is a documented deployment minimum, not production capacity planning.
Docker 20.10+ and Docker Compose 2.0+.
An ESP32 development board. An ESP8266 is also suitable for the custom MQTT firmware path.
A data-capable USB cable and Wi-Fi. Optional: a temperature sensor, low-voltage LED, or isolated relay module.
A browser and, optionally, MQTTX to validate the broker and topics before debugging firmware.

The host, board, and browser must be able to reach one another. In this guide, SERVER_IP is the FastBee host address. Replace PRODUCT_ID, DEVICE_NUM, and other placeholders with values from your own console. On the device, use a reachable server IP or hostname: localhost refers to the device itself.

2. Deploy FastBee with Docker

FastBee Open Source Edition includes a built-in MQTT Broker, so a first test does not require a separate EMQX deployment. FastBee’s current Docker guide lists Docker 20.10+, Docker Compose 2.0+, and a minimum of 2 CPU cores and 4 GB RAM. Treat those values as the documented deployment minimum; production sizing depends on workload and should be measured for the target deployment.

Run the official installer on a Linux host and select the open-source edition when prompted:

sudo wget -c https://hub.fastbee.cn/resource/install.sh && bash ./install.sh

Check that the containers are running:

docker ps

Open http://SERVER_IP:80 in a browser. The documented initial credentials are admin / admin123; change the password after the first login. For a test setup, expose only the Web and MQTT TCP 1883 ports to the networks that need them. Do not expose internal database or Redis services directly to the public Internet.

Official guide: FastBee Docker deployment

3. Create an MQTT product and device

In the console, create an MQTT product and add these Thing Model properties:

Identifier	Type	Access	Purpose
`temperature`	Numeric	Read-only	Show sensor readings
`switch`	Boolean/switch	Read and write	Receive a command and report the actual switch state

Save and publish the product, then create a device. Record the product ID from the product details (not the product number), device number, MQTT username and password, and the current user ID. Also record the device authorization code if it is enabled for the product.

For a test connection, use:

Host: mqtt://SERVER_IP
Port: 1883
Protocol: MQTT 3.1.1
Client ID: S&DEVICE_NUM&PRODUCT_ID&USER_ID
Username: MQTT username
Password: MQTT password

If device authorization is enabled, use MQTT_PASSWORD&AUTH_CODE as the password. For production, follow the official encrypted-authentication instructions and never commit real credentials to a public repository.

4. Validate the data path with MQTTX

Use MQTTX first to separate broker and topic issues from firmware and wiring issues. Create a connection with the parameters above, then subscribe to the platform-to-device topic:

/{PRODUCT_ID}/{DEVICE_NUM}/function/get

Publish this device information payload:

{
  "rssi": -48,
  "firmwareVersion": 1.0,
  "status": 3,
  "userId": USER_ID
}

Next publish properties to:

/{PRODUCT_ID}/{DEVICE_NUM}/property/post

[
  {"id":"temperature","value":"23.6","remark":"bench test"},
  {"id":"switch","value":"0","remark":"relay off"}
]

Confirm that the device is online and both values appear in its detail page. Each id must exactly match a Thing Model identifier. Values are strings; Boolean values use "0" or "1". After connecting, publish /info/post first, followed by properties or events.

5. Connect an ESP32 or ESP8266

Option A: FastBee-Arduino on ESP32

For the fastest device-side start, follow the official quick-start guide to select a merged firmware for a supported ESP32 board and flash it with the online tool. Match the firmware to the board’s Flash and PSRAM configuration, then configure Wi-Fi, peripherals, and network settings.

Set the platform address to an IP or hostname reachable from the board. Enter the device identity and MQTT credentials configured for the product. On a local network, the broker is typically SERVER_IP:1883. Configure the temperature sensor and switch output, map them to temperature and switch, and check the device’s online state and property updates in the console.

Official steps: FastBee-Arduino quick start · Hardware and environment

Option B: A custom MQTT client on ESP8266

An ESP8266 can connect as a standard MQTT device, but you must implement and maintain its Arduino firmware adapter. Connect to Wi-Fi and the MQTT 3.1.1 broker with the credentials above, publish device information and properties, and subscribe to /function/get. FastBee-Arduino’s official zero-code firmware is not ESP8266 firmware.

The firmware logic should look like this. Replace mqttPublish, mqttSubscribe, JSON parsing, and GPIO operations with the APIs from your chosen MQTT library:

Connect to Wi-Fi
Connect to MQTT with clientId = "S&" + DEVICE_NUM + "&" + PRODUCT_ID + "&" + USER_ID
Subscribe to /{PRODUCT_ID}/{DEVICE_NUM}/function/get
Publish /{PRODUCT_ID}/{DEVICE_NUM}/info/post

Loop:
  Read temperature
  Publish /{PRODUCT_ID}/{DEVICE_NUM}/property/post
    [{"id":"temperature","value":"23.6","remark":"sample"},
     {"id":"switch","value":"0","remark":"actual state"}]
  On function/get, parse the id and value
  If id is switch: update the output using safe hardware logic, then read actual state
  Publish the actual switch state to property/post

For ESP8266, check GPIO levels, boot-strapping pins, power, and relay-module compatibility. Do not copy pin numbers from a different board. See the official MQTT access guide for the protocol format and topic list.

6. Send a remote command from the platform

In the console’s device detail or control view, set the switch property. The platform publishes a payload like this to the device subscription:

Topic: /{PRODUCT_ID}/{DEVICE_NUM}/function/get

[{"id":"switch","value":"1","remark":"platform command"}]

The firmware should parse the identifier and value, drive the output, then report the actual state on /property/post:

[{"id":"switch","value":"1","remark":"output confirmed"}]

Do not report the requested value as the device state without verifying execution. If the GPIO write fails, the relay does not move, or the read-back state differs, report the real result so it can be diagnosed. Test with an isolated low-voltage circuit; never connect a development board directly to mains. Relay modules can use different active levels, so confirm the module documentation and default-off behavior before powering it.

7. Acceptance checks and troubleshooting

Device is offline: Check that Docker containers are running, TCP 1883 is reachable, and the device is not using localhost as the server address.
Authentication fails: Verify the device number, product ID, and user ID in clientId; append the authorization code if the product requires it.
Online but no data: Publish the product, check the exact product ID and device number in the topic, send /info/post first, and confirm the property IDs and JSON array format.
Command is not received: The device must be online and subscribed to /{PRODUCT_ID}/{DEVICE_NUM}/function/get. Check the console command log and the MQTT subscription.
Console says on, hardware stays off: Make the property writable, confirm the firmware handles that identifier, check GPIO and module active level, and report the state after execution.

The minimum successful round trip is: the device appears online, temperature updates, the platform sends switch=1, the device changes its output, and the device reports the actual switch state.

Frequently asked questions

Can I use FastBee-Arduino zero-code firmware on an ESP8266?

No. FastBee-Arduino’s documented zero-code firmware targets supported ESP32 boards. An ESP8266 can use FastBee’s MQTT protocol with a custom firmware client that implements the documented authentication, topics, and payloads.

Does FastBee Open Source include an MQTT broker?

Yes. FastBee’s official Open Source Edition documentation says it includes a Netty-based MQTT Broker. The MQTT guide documents TCP port 1883 and MQTT 3.1.1 for TCP connections.

What does a successful ESP32-to-FastBee test verify?

Verify that the device appears online, reports a Thing Model property, receives a platform command, performs the hardware action, and reports the resulting state. Message delivery alone does not prove that the hardware action succeeded.

What server resources does the FastBee Docker guide specify?

The current official Docker guide lists Docker 20.10+, Docker Compose 2.0+, and a minimum of 2 CPU cores and 4 GB RAM. These are documented deployment prerequisites, not a production capacity guarantee.

Official references

Review the license before deployment or redistribution. FastBee’s official authorization page identifies AGPL-3.0 for the open-source edition and describes its usage boundaries.

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

Fastbee — Tue, 27 Oct 2026 03:54:28 +0000

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

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.

A Smart Building IoT Platform Is More Than a Dashboard

Fastbee — Fri, 23 Oct 2026 09:32:52 +0000

A building dashboard can look finished while the operations workflow behind it is still broken.

HVAC controllers, meters, pumps, environmental sensors, cameras, and access-control devices often come from different vendors and use different protocols. The real integration work is making their data consistent, routing alarms to the right people, and confirming that a remote command actually changed something in the field.

This post uses a multi-zone office building as a reference scenario, not as a claim about an undisclosed customer deployment. The goal is to show how to evaluate the complete device-to-operations path.

Figure: Device telemetry informs operations; acknowledged commands close the loop.

Start with one operational loop

Imagine a pilot that includes:

Water level and pump state in a plant room
Temperature and humidity sensors in shared areas
Selected electrical measurements from distribution panels
A low-risk controllable circuit, such as a fan or lighting relay

The first acceptance criterion should not be “the device is online.” It should be a complete loop:

field device or gateway
        ↓
protocol adapter and device identity
        ↓
product + device + data model
        ↓
rules, alarms, notifications, and dashboards
        ↓
operator action or command
        ↓
device execution and reported result

An online indicator proves only that a connection or heartbeat is working. It does not prove that a property was parsed correctly, that its unit is meaningful, or that a command reached the hardware.

Model signals as operational data

A small building pilot can use a table like this to define acceptance criteria:

Field signal	Platform model	What to verify
High water level and pump state	Level property, running state, fault event	Threshold alarm, duty-team notification, and recovery record
Room temperature and humidity	Temperature, humidity, sample time	Trends by floor and an alert for sustained threshold violations
Meter or power monitor	Voltage, current, power	Data is associated with the right area and can be queried consistently
Fan or lighting relay	Writable property or function	Authorized command, physical action, and device-reported state

For each device type, compare the source payload with the platform value. Check identity mapping, units, timestamps, duplicate messages, reconnect behavior, and malformed input. Protocol support on a feature page is only a starting point; interoperability needs to be checked with the actual firmware, gateway, and payload.

FastBee’s commercial device-access catalog lists MQTT, Modbus RTU/TCP, HTTP, TCP, CoAP, JT808, video, and gateway/sub-device paths. Use it as a documentation entry point, then validate the specific device combination in a PoC.

Alarms are workflows, not thresholds

A threshold is only the trigger. A useful alarm workflow also needs an owner, notification channel, silence or deduplication policy, recovery condition, and an auditable record of what happened.

For example, a pump-room high-water event might be tested in this sequence:

Send a value above the configured threshold.
Confirm that the rule matches the correct device and property.
Verify that an alarm record is created.
Check that the intended on-call contact receives the notification.
Send a normal value and confirm the recovery behavior.
Review logs to see whether repeated messages caused duplicate notifications.

FastBee’s alarm configuration guide documents alarm and notification configuration. The exact workflow and channels should still be verified against the edition and deployment being evaluated.

Remote control needs an acknowledgement path

A console button changing state is not proof that a field device acted. A complete control test should verify:

The user has permission to issue the command.
The platform publishes to the correct device route.
The device firmware receives and parses the command.
The physical output changes.
The device reports the resulting state.
The operation is visible in logs.

Start with low-risk equipment. For life-safety systems or equipment governed by building controls, follow the site’s existing safety and authorization procedures; a general IoT platform should not bypass them.

Why hardware manufacturers build their own platforms

A sensor, controller, or gateway manufacturer may want its own platform to provide device inventory, remote configuration, firmware updates, customer organizations, alarms, and after-sales workflows.

That does not automatically mean every infrastructure component must be built from scratch. A manufacturer can retain its device protocol and customer application while evaluating a general IoT platform for product models, fleet management, permissions, rules, and dashboards. Before integrating, assign ownership for:

Device identity and credential rotation
Source of truth for device state
Tenant or customer data isolation
Command timeouts, retries, and acknowledgement
Existing mobile app and service-desk integration

FastBee publishes a System ArchitectureTreat documentation as a compatibility hypothesis; test it with production-like hardware and messages before committing to an integration.

Private deployment is an operations commitment

A private installation may be required by network boundaries, data governance, or site-specific integration. It also makes the project team responsible for more than starting containers:

Port exposure and TLS certificates
Persistent database and upload storage
Backup and restore drills
Upgrade and rollback procedures
Log collection and health monitoring
Capacity planning and incident ownership

For a deployment PoC, restart services, restore a backup, reconnect a device, trigger an alarm, and repeat a control action. Confirm that data and operational records survive the steps that matter to the customer.

FastBee’s deployment and operations architecture guide outlines common components and launch checks. The documentation center provides the broader, version-specific platform material. Confirm which edition and support scope apply; do not infer production topology or capacity from a demo installation.

What public case material can prove

FastBee’s Smart Agriculture showcase illustrates how device management, thing models, scene automation, visualization, video, and traceability can be combined in an industry application.

The public page does not provide a verifiable customer identity, fleet size, operating period, or benchmark results. It is a capability example, not evidence that a smart-building deployment has been validated at a particular scale. The office-building scenario in this post is also illustrative.

For an actual deployment assessment, define a PoC with the target devices, protocols, message rates, alarms, private-network constraints, and acceptance criteria. Record the platform version, hardware, test duration, resource use, failures, and recovery behavior.

A practical PoC checklist

Connect one representative device per protocol.
Verify identity, telemetry mapping, units, and timestamps.
Test disconnect and reconnect behavior.
Trigger an alarm, send a notification, and confirm recovery.
Send a remote command and verify physical execution plus reported state.
Restart services and rehearse backup restoration.
Record device count, message rate, properties per message, query patterns, resource use, and failure rate.

The useful question is not “How many features does the platform list?” It is “Can this team operate the device, alarm, and command workflows in its own environment?”

References: FastBee website · English documentation home · Architecture overview