Multi-Type Device Access and O&M Reference Solution
Page Guide
1. Solution Overview
Urban IoT sensing projects usually face three common problems: a wide mix of device types — street light control boxes, manhole cover sensors, environmental monitoring stations, river water-level gauges, and traffic cameras come from different vendors; inconsistent protocols — Modbus, MQTT, proprietary TCP protocols, and GB28181 video streams coexist; and widely scattered sites — devices are spread across city blocks, making manual inspection costly and fault discovery delayed.
This solution centers on the FastBee IoT platform and connects all types of urban devices to a single platform: edge gateways provide compatibility with mainstream communication protocols, the Thing Model abstracts devices from different vendors into unified properties, functions, and events, and Scene Linkage, alert notifications, and visualization dashboards support day-to-day O&M. The goal is to consolidate "scattered construction, each system fighting on its own" device management into "one platform for access, one map for O&M".
2. System Architecture
The solution adopts a four-layer architecture: from bottom to top, the device layer, access layer, platform layer, and application layer.
- Device layer: urban sensing devices such as street light controllers, manhole cover displacement sensors, air quality and noise sensors, water-level gauges, and cameras (IPC/NVR).
- Access layer: edge gateways perform protocol conversion and local logic processing; the uplink supports MQTT, Modbus, TCP/UDP, and WebSocket, while video is connected via the GB28181 national standard.
- Platform layer: the FastBee platform provides device management, Thing Model, Scene Linkage, data storage, and statistical analysis capabilities.
- Application layer: visualization dashboards, the alert center, the mobile O&M app, and report statistics, serving command centers and frontline operations staff.
3. Core Functions
3.1. Data Collection and Visualization Dashboard
The platform aggregates data reported by devices in each district by product category. The dashboard displays device distribution, online status, and alert hotspots by block, so the command center can grasp the operation of the citywide sensing network on a single screen.
3.2. Alerts and Notifications
Device offline events, out-of-range properties, and reported events can all trigger alerts, which are pushed by severity to the web side and the mobile app. For example, when a manhole cover displacement sensor reports an abnormal tilt angle, a pending alert is generated immediately and dispatched to the operations staff responsible for that district.
3.3. Remote Control and Scene Linkage
The platform supports delivering remote control commands to devices such as street lights and drainage pumps. Scene Linkage rules connect "sensing" directly to "handling" — for example, automatically starting the drainage pump when the water level exceeds the limit while pushing an alert at the same time — reducing the manual response steps.
3.4. Mobile O&M
The mobile app provides device status viewing, remote control, and alert handling capabilities, so operations staff can verify device information and confirm handling results on site without returning to the command center.
3.5. Report Statistics
Statistical analysis of reported device properties produces operation reports by region and device type, providing a data basis for facility maintenance planning and budget evaluation.
4. Device Access
4.1. Gateway and Protocol Access
Device communication is completed by the platform together with gateways. The gateway supports TCP, UDP, MQTT, WebSocket, Modbus, and other protocols, and supports visual programming for custom access logic. Proprietary protocols of existing devices can be adapted through gateway-side scripts without replacing hardware. Video surveillance devices are connected via the GB28181 national standard, with support for direction, zoom, streaming, and playback control.
4.2. Unified Thing Model Abstraction
The Thing Model abstracts a device into three kinds of definitions: properties carry telemetry data (water level, illuminance, tilt angle), functions carry remote control (switching lights, starting and stopping pumps), and events carry proactive reporting (displacement alerts, cabinet door opening). Devices of the same type from different vendors are attached to the same product Thing Model, so upper-layer applications do not need to care about underlying differences.
4.3. Scene Linkage Rules
Scene Linkage is configured in a "trigger condition → condition check → execution action" pattern. The trigger source can be a device event, a property threshold, or a scheduled plan, and the action can be device control, an alert notification, or a combination of both.
5. Deployment and Implementation
The platform supports private deployment and can be installed in the city management party's own server room or a government cloud environment, with data staying inside the intranet. Implementation is recommended in three steps:
- Pilot access: select one block and connect street lights and manhole covers first to verify gateway networking, Thing Model definitions, and the alert chain.
- Batch rollout: replicate the access template district by district, gradually bringing in environmental monitoring, water-level, and video devices while configuring Scene Linkage rules in parallel.
- O&M consolidation: establish a daily O&M process centered on the dashboard and the mobile app, with alert dispatching, handling confirmation, and report review all completed online.
Parking lots are a typical sub-scenario of urban IoT. Their retrofit experience (device selection, networking, and offline fallback) is described in Retrofitting an Old Parking Lot with IoT; for background on protocol selection, see Comparing Common IoT Communication Protocols and Applying Edge Computing in IoT Systems.
6. FAQ
In a smart city project, devices from different vendors use inconsistent protocols. Can they be connected uniformly?
Yes. The gateway supports mainstream protocols such as MQTT, Modbus, TCP, UDP, and WebSocket, and proprietary protocols can be adapted and converted through the gateway's visual programming. After access, all devices are abstracted uniformly with the Thing Model (properties/functions/events), so upper-layer applications face the same device semantics.
Can video devices also be connected to the same platform?
Yes. Video devices such as cameras and NVRs are connected to the platform via the GB28181 national standard, supporting PTZ direction control, zoom, streaming, and playback, and are operated within the same device management system as IoT devices.
When the on-site network is unstable, will device data be lost?
Edge gateways have local processing capability: during a network outage they can cache data locally and execute the configured linkage logic, then backfill reports after the network recovers. For critical scenarios (such as drainage and lighting), it is recommended to configure an offline fallback policy on the gateway side.
Must the platform be deployed on a public cloud?
No. The platform supports private deployment and can be installed in the city management party's own server room or a government cloud, with both device data and video streams staying in the intranet environment.