Environment, Energy Consumption, and Linkage Reference Solution
Page Guide
1. Solution Overview
Office buildings, campuses, and commercial complexes commonly face three types of problems: subsystems such as HVAC, lighting, and water supply and drainage each run independently, with data scattered in their own controllers; energy consumption can only be tallied after the fact from monthly meter readings, making it impossible to locate high-consumption areas; and device start/stop relies on manual patrols, so environmental comfort and energy-saving goals are hard to reconcile.
This solution centers on the FastBee IoT platform. Environmental sensors, smart meters, air-conditioning units, fresh-air systems, lighting, access control, and other devices in the building are connected uniformly through edge gateways; device data is standardized through thing models; scene linkage and alarm notification are then driven by the rule engine; and everything is finally presented centrally on monitoring dashboards and the mobile app. The solution supports on-premises deployment, so building data never leaves the local network.
The platform capability positioning is consistent with the published complete smart agriculture case: gateway access, thing models, scene linkage, alarms, dashboards, mobile app, and video monitoring (GB28181) are all general platform capabilities, and the building solution organizes industry-specific device models and linkage policies on top of them.
2. System Architecture
The solution is organized into four layers:
- Device Layer: Environmental sensors such as temperature and humidity, CO₂, and PM2.5; smart electricity and water meters for sub-metering; and terminal devices such as air-conditioning units, fresh-air units, lighting circuits, access control, and cameras.
- Access Layer: Edge gateways are deployed in the building's low-voltage equipment rooms. Downward they collect field device data over Modbus and TCP/UDP, and upward they communicate with the platform over MQTT or WebSocket. When the network is interrupted, the gateway caches data locally and automatically backfills it after recovery.
- Platform Layer: The FastBee core platform, responsible for device management, thing model parsing, scene linkage rule execution, alarm distribution, and historical data storage and statistics.
- Application Layer: Monitoring dashboards, the web management console, the mobile app, and report output, providing operations staff with a unified monitoring and operation entry.
3. Core Features
3.1. Environmental and Energy Data Collection
Collection points are established by floor, room, or circuit. Environmental sensors report temperature, humidity, and air quality at minute-level intervals, and smart meters collect electricity data by circuit. The platform unifies raw reports into thing model properties, and historical data can be queried retroactively, providing the data foundation for energy analysis and linkage judgment.
3.2. Remote Control
Deliver control commands to devices such as air conditioning, fresh air, and lighting from the web console or the mobile app. Both single-device point control and grouped batch control are supported, and scheduled tasks can be configured for devices — for example, turning on fresh air early on workday mornings and automatically turning off public-area lighting after work.
3.3. Alarm Notification
Configure alarm rules for scenarios such as temperature out of range, CO₂ concentration exceeding limits, device offline, and abnormal electricity usage. When triggered, notifications are pushed through the configured channels, and alarm records are retained on the platform, making it easy to track handling through to closure.
3.4. Monitoring Dashboard
Build monitoring dashboards by building and floor dimensions, presenting environmental parameters, energy trends, device online status, and alarm dynamics in real time — suitable for deployment in the building control room or the operations duty area.
3.5. Mobile App and Reports
Operations staff can check device status, receive alarms, and perform remote operations anytime from the mobile app. The platform performs statistical analysis on reported properties and generates energy and environmental reports, supporting monthly operations reviews.
4. Device Access
4.1. Gateways and Protocols
Field devices in buildings are mostly on wired buses. Downward, the gateway supports Modbus, TCP, UDP, and other protocols to collect data from air-conditioning controllers, meters, and sensors; upward, it communicates with the platform over MQTT and WebSocket. The gateway supports visual programming, enabling protocol conversion and local logic at the edge to reduce uplink data volume. For a general comparison of protocol options, see Comparing Common IoT Communication Protocols.
4.2. Thing Model
Each type of building device is abstracted into a thing model with three categories: device properties (such as room temperature, setpoint temperature, and cumulative electricity), device methods (such as power on/off, mode switching, and temperature adjustment), and device events (such as fault codes and offline). Once thing models are unified, devices of the same type from different brands and protocols present a consistent data structure on the platform, so upper-layer applications do not need to care about field protocol differences.
4.3. Scene Linkage
Scene linkage is driven by the rule engine. Typical policies include:
- When CO₂ concentration exceeds the limit, the fresh-air units of the corresponding area are turned on automatically, and turned off with a delay after levels return to normal;
- When room temperature deviates from the set range, air conditioning is adjusted in coordination, combined with scheduled tasks to avoid idling at night;
- When public-area lighting is detected as on during non-working hours, a reminder is pushed or the lighting is turned off automatically;
- When power consumption spikes beyond the limit, an alarm is triggered to help troubleshoot abnormal loads.
For the orchestration approach and trade-offs of linkage rules, see Rule Engine and Scene Linkage.
5. Deployment and Implementation
5.1. Implementation Steps
- Site survey: Inventory the existing subsystems and device list, confirm the communication interface and protocol of each device, and plan gateway installation locations and network cabling.
- Platform deployment: Deploy an on-premises FastBee instance on a local building server, and complete network and storage initialization.
- Device modeling: Create products and thing models by device type, and configure authentication methods and data parsing rules.
- Access and debugging: Connect gateways and devices layer by layer, verifying the round trip of property reporting and control commands.
- Linkage and alarm configuration: Configure scene linkage rules and alarm thresholds according to operations policy, validate on a small scale first, then roll out.
- Dashboards and permissions: Build monitoring dashboards, and assign accounts and device permissions by role (property management, operations and maintenance, administration).
5.2. Relationship with Existing Systems
The solution does not require replacing existing building automation devices. The gateway connects through bypass collection and supplementary control, retaining the original local control loops as a fallback. The trade-off thinking involved with existing systems is similar to the retrofit experience recorded in Retrofitting an Old Parking Lot with IoT.
6. FAQ
The building already has air conditioners and meters from different brands. Can they be connected in a unified way?
Yes. Devices from different brands are collected by the edge gateway according to their respective protocols and unified into thing model properties and methods on the platform side. The dashboards, linkage, and reports above all work against standardized data and do not depend on specific brands. When adding devices of the same type later, simply reuse the product models already created.
Must building data go to the cloud?
No. The solution supports on-premises deployment; the platform can run entirely on local servers in the building or campus, and data never leaves the intranet. External channels are used only for on-demand scenarios such as outbound alarm notifications.
Does device linkage fail when the network is disconnected?
The gateway caches reported data locally during network interruptions and automatically backfills it after recovery. Safety-related fallback control is recommended to remain on the field controller side; platform linkage is positioned for operational optimization and centralized management, not as the sole safety path.
How should we roll out from a pilot to the whole building?
It is recommended to first select one floor or one power distribution circuit as a pilot, and replicate by area after the access, linkage, and alarm closed loop is running. Device models and linkage rules can be reused on the platform side; the main rollout work is on-site construction and debugging. For the hands-on deployment walkthrough, see Verified Projects or Demo Cases.