Architecture Overview

The FastBee open-source edition uses a layered architecture with clear responsibilities per layer, making it easy to extend and maintain. This page explains the system layers, core modules, and typical data flows; see the corresponding chapters for installation, deployment, and platform operations.

1. System Layers

Layer	Purpose	Components
Access	Protocol adaptation & connection	MQTT Broker (Netty), SIP Server
Business	Core IoT logic	Product/Device/ThingModel/Scene/Rule
Service	Common capabilities	Auth, cache, messaging
Data	Persistence & storage	MySQL, Redis, TDengine (optional)
Presentation	User interfaces	Vue Web, UniApp Mobile

The access layer implements the MQTT Broker on Netty; devices connect via TCP 1883 or WebSocket 8083, and video devices connect through the SIP Server using the GB/T 28181 national standard. The business layer, built on Spring Boot, hosts the core domains of products, devices, thing models, scene linkage, and rule scripts. The data layer uses MySQL + Redis by default, with TDengine, IoTDB, or InfluxDB as optional time-series storage. The presentation layer consists of the Vue web console and the UniApp mobile app (WeChat Mini Program / Android / iOS / H5). See Technology Stack for the full selection.

2. Core Modules

• Device Access: The built-in MQTT Broker supports MQTT 3.1.1, QoS 0/1, retained messages, and last-will messages, with Product ID + device key authentication—no need to deploy EMQX separately.
• Product / Device / Thing Model: Create products and define thing models (properties, services, events); manage device registration, grouping, real-time status, and remote control. See Product Management, Device Management, and Thing Model.
• Scene Linkage and Rule Scripts: Scene Linkage configures inter-device automation visually; Rule Scripts use Groovy syntax to process device-reported and platform-issued data, forwarding it in a format that matches device interactions.
• Video Monitoring: Supports the GB/T 28181 national standard; the SIP Server connects to the ZLMediaKit media server, providing live streaming and PTZ control (live streaming only in the open-source edition). See Video Monitoring.
• Access Control: RuoYi-based fine-grained management of users, roles, departments, positions, and operation logs.

3. Core Flows

3.1. Device Data Reporting

Device → MQTT Broker → Message Routing → Rule Script (optional) → Business Processing

3.2. Platform Command Dispatch

User/API → Business Layer → MQTT Broker → Device

3.3. Video Monitoring

Camera → SIP Server → ZLMediaKit → Web Playback

4. Deployment Architecture

4.1. Single-node Deployment (Recommended)

All services run on the same server, suitable for small and medium scale (≤ 1000 devices). Use Docker Compose one-click deployment as described in the installation chapter.

4.2. Distributed Deployment

• Web and API separated onto different servers
• Database deployed independently
• Suitable for medium scale (1000-5000 devices)

5. Edition Capability Boundaries

The open-source edition covers core capabilities: MQTT access, product/device/thing-model management, scene linkage, rule scripts, video monitoring (live streaming only), and access control. The following capabilities are available only in the commercial edition: CoAP/HTTP/TCP protocol access, visual dashboards, Web SCADA, AI knowledge base, data bridging, work orders, IoT SIM card management, alert center, multi-tenancy, OAuth SSO, and OTA firmware updates—see the Commercial Edition Docs. For cluster deployment, load balancing, and large-scale benchmarking, see the Cluster Edition Docs. The full feature comparison is in the version comparison table on the Open-Source IoT Platform page.