Internet of Things background management system based on MQTT protocol and data processing method thereof

Abstract

The invention relates to an Internet of Things background management system based on an MQTT protocol and a data processing method. The Internet of Things background management system comprises a device end, an MQTT access and routing module, a data processing and normalizing module, a front-end application UI and a real-time state and instruction issuing module. The equipment end issues data through the MQTT and receives a control instruction; the MQTT access and routing module is responsible for receiving and transmitting messages; the data processing and normal form module dynamically analyzes and cleans the heterogeneous original data and converts the heterogeneous original data into normal form data in a uniform format by using a data analysis template engine; when the device state changes, the real-time state and instruction issuing module actively pushes update to the front-end application UI, encapsulates a user operation instruction into an MQTT message and issues the MQTT message to the target device, so that efficient access, data standardization and millisecond-level state synchronization of massive devices are realized, the real-time performance, the expansibility and the control reliability are remarkably improved, and the user experience is improved. The problems of monitoring blind areas and control failure caused by protocol fragmentation and state delay of a traditional platform are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, specifically to an IoT backend management system and its data processing method based on the MQTT protocol. Background Technology

[0002] With the rapid popularization of the Internet of Things (IoT), various smart terminals (such as sensors, controllers, edge gateways, etc.) are widely deployed in industrial, energy, municipal and home scenarios, and there is an urgent need for an efficient and reliable back-end management system to realize device access, status monitoring and data application.

[0003] Currently, most mainstream solutions in the industry use a request-response model based on the HTTP / HTTPS protocol for device communication. Devices periodically send status data to the server, or the server periodically polls the device to obtain information.

[0004] However, this mode suffers from several drawbacks: frequent polling requests result in excessive network traffic and server computational overhead; state updates rely on polling intervals, leading to poor real-time performance. Especially in low-power wide-area networks (LPWANs) or unstable mobile network scenarios, this communication method is highly susceptible to connection interruptions or data loss, severely impacting system reliability.

[0005] Meanwhile, with the increasing diversity of connected devices, the data formats reported by these devices are highly heterogeneous (such as JSON, binary streams, and custom protocols). Traditional backend systems typically require hard-coded data parsing logic to be developed separately for each type of device. When a new device type is added or the protocol is upgraded, the backend service code must be modified, resulting in poor system scalability, long development cycles, and high maintenance costs.

[0006] At the data analysis level, existing systems mostly use preset templates for reporting, and users cannot independently select data sources, define aggregation dimensions (such as statistics by region, device type, or time window), set calculation rules, or switch visualization formats.

[0007] Furthermore, access control typically employs a coarse-grained control model at the "role-menu" or "user-page" level, which cannot provide fine-grained authorization for specific devices, data points (such as temperature, on / off status), or operations (such as viewing, controlling, and exporting). This makes it difficult to meet the needs of business scenarios in complex organizational structures such as multi-tenancy and cross-departmental collaboration.

[0008] In summary, existing technologies are insufficient to simultaneously meet the comprehensive requirements of high concurrency, high real-time performance, high flexibility, and high security. Summary of the Invention

[0009] This invention provides an IoT backend management system based on the MQTT protocol, which enables unified management of IoT devices with high concurrency, high real-time performance, high scalability, and high security.

[0010] The present invention also provides a data processing method for an IoT backend management system based on the MQTT protocol as described above.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] An IoT backend management system based on the MQTT protocol includes:

[0013] On the device side, it is used to publish data reporting messages and receive control commands via the MQTT protocol;

[0014] The MQTT access and routing module is used to receive the data reporting messages and send control commands to the corresponding devices.

[0015] The data processing and normalization module is used to parse, clean, and convert the raw data in the data reporting message into normalized data in a unified format. The data processing and normalization module includes a data parsing template engine, which is used to dynamically parse the data formats of different device types according to a preset data parsing template.

[0016] The front-end application UI is used to provide users with a device monitoring interface and receive user operation commands;

[0017] The real-time status and command delivery module is used to automatically push status updates to the connected front-end application UI when the device status changes, and to receive user operation commands from the front-end application UI, encapsulate the user operation commands into MQTT control messages, and send them to the target device via the MQTT access and routing module.

[0018] The real-time status and instruction issuance module includes a high-speed cache module, which stores the latest standardized status data using the device's unique identifier as the key.

[0019] Furthermore, it also includes a multi-dimensional permission control module for verifying permissions of access requests from the front-end application UI.

[0020] The multi-dimensional permission control module intercepts all access requests from the front-end application UI through the API gateway, performs triple verification on each request, and the triple includes user identity, target resource identifier and operation type, and decides whether to authorize based on the pre-configured permission policy.

[0021] Furthermore, it also includes a templated report generation module, which responds to report requests from the front-end application UI, reads normalized data from the database, and generates visual reports based on preset report templates.

[0022] The templated report generation module dynamically generates SQL query statements based on the data source identifier, filtering conditions, aggregation rules, and time dimension in the report template. After execution, the result data is obtained and rendered into a visual report in combination with chart display format.

[0023] The modular report generation module includes a report template engine for receiving structured report templates;

[0024] The report template is submitted by the user through the front-end application UI, or reported by the device to the MQTT access and routing module via the MQTT protocol, and then stored in the database through the data processing and normalization module.

[0025] A data processing method for an IoT backend management system, including data processing and real-time interaction steps;

[0026] Step S11: Establish a persistent connection with the IoT device based on the MQTT protocol through the MQTT access and routing module, and subscribe to the device's instruction Topic;

[0027] Step S12: The MQTT access and routing module receives the data reporting message published by the device, the message containing the device identifier and the original data;

[0028] Step S13: Forward the data reporting message to the data processing and normalization module;

[0029] Step S14: The data processing and normalization module parses and cleans the raw data according to the preset data parsing template, and converts it into normalized data in a unified format;

[0030] Step S15: The real-time status and instruction delivery module receives the standardized data, stores it in the cache with the device identifier as the key, and pushes the status change to the connected front-end application UI through the persistent communication channel when the data is updated.

[0031] Step S16: Receive user operation instructions from the front-end application UI, and encapsulate the instructions into MQTT control messages by the real-time status and instruction delivery module;

[0032] Step S17: The MQTT control message is published to the corresponding device's instruction Topic through the MQTT access and routing module to complete remote control.

[0033] The data processing method of the IoT back-end management system also includes a multi-dimensional permission control step based on a triplet model;

[0034] Step S21: Receive access requests from the front-end application UI through the API gateway;

[0035] Step S22: The multi-dimensional permission control module intercepts the access request and extracts the user identity, target resource identifier and operation type from it to form a permission verification triplet;

[0036] Step S23: Query the pre-configured permission policy library to determine whether the triplet matches the authorization rule;

[0037] Step S24: If a match is found, the request is allowed to proceed to the subsequent business module for processing; if no match is found, a permission denial response is returned.

[0038] The target resource identifier includes at least one of the following: device identifier, data point identifier, report template identifier, or system function interface identifier.

[0039] The data processing method of the IoT back-end management system also includes a dynamic report generation step based on a structured template;

[0040] Step S31: Receive a structured report template. The report template is submitted by the user through the front-end application UI or reported by the device through the MQTT protocol. After being received by the MQTT access and routing module, it is transmitted to the data processing and normalization module.

[0041] Step S32: Store the report template in the database;

[0042] Step S33: Respond to the report request from the front-end application UI and load the corresponding report template from the database;

[0043] Step S34: Dynamically generate SQL query statements based on the data source identifier, filtering conditions, and aggregation rules defined in the report template;

[0044] Step S35: Execute the SQL query statement to obtain a normalized data result set;

[0045] Step S36: Based on the time dimension and chart display format in the report template, aggregate and calculate the result set and render it into a visual report;

[0046] Step S37: Return the visualization report to the front-end application UI for display.

[0047] Compared with the prior art, the present invention has the following advantages:

[0048] 1. By constructing an IoT backend management system based on the MQTT protocol, including data processing and standardization modules as well as real-time status and command issuance modules, unified access and standardized processing of heterogeneous device data have been achieved. It also supports millisecond-level real-time push of device status and reliable issuance of remote control commands, significantly improving the system's access capability for massive numbers of devices, data consistency, and human-machine interaction response speed. This solves the monitoring blind spots and control failures caused by protocol fragmentation and status synchronization delays in traditional IoT platforms.

[0049] 2. By introducing a multi-dimensional permission control module based on the "user identity-target resource-operation type" triplet model and deeply integrating it with the API gateway, fine-grained dynamic authorization of front-end access requests is realized. It not only supports flexible permission configuration by device, function, and role, but also effectively prevents unauthorized access and illegal operations, greatly improving the security and compliance of the system. It is especially suitable for industrial IoT scenarios with multi-tenant and multi-department collaborative management.

[0050] 3. By setting up a templated report generation module and its report template engine, users or devices can define report templates in a structured manner, including data sources, filtering conditions, aggregation rules, and time series dimensions. The system can then dynamically generate and execute SQL queries based on these templates, automatically rendering them into diverse visual charts. Personalized data analysis and report customization can be achieved without developer intervention, greatly reducing the operational threshold and improving data insight efficiency and business decision response speed. Attached Figure Description

[0051] Figure 1 This is an overall framework diagram of an IoT backend management system based on the MQTT protocol;

[0052] Figure 2 This is a data reporting flowchart for an IoT backend management system based on the MQTT protocol;

[0053] Figure 3 It is a flowchart illustrating the data processing and real-time interaction steps;

[0054] Figure 4 This is a flowchart illustrating the steps of multidimensional access control based on the triplet model;

[0055] Figure 5 This is a flowchart illustrating the steps involved in generating dynamic reports based on structured templates. Detailed Implementation

[0056] The following examples further illustrate the features and other related characteristics of the present invention in detail, to facilitate understanding by those skilled in the art:

[0057] It should be noted that the terms “front,” “back,” “left,” “right,” “up,” and “down” used in the following description refer to the directions in the attached diagrams, while the terms “bottom surface,” “top surface,” “inner,” and “outer” refer to the directions toward or away from the geometric center of a specific component, respectively.

[0058] Furthermore, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0059] To facilitate understanding of the technical solutions of this invention by those skilled in the art, the key technical terms and implementation mechanisms involved are described in detail below.

[0060] MQTT Protocol: MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol based on a publish / subscribe model, designed for low-bandwidth, high-latency, or unstable network environments, and suitable for resource-constrained IoT devices. Its core mechanisms include persistent TCP connections between the client and server, heartbeat keep-alive, and three Quality of Service (QoS) levels (0 / 1 / 2), effectively ensuring reliable message delivery and timeliness.

[0061] Distinguishing between MQTT Broker and MQTT Access and Routing Module: In this invention, MQTT Broker refers to a general-purpose message middleware (such as EMQX, Mosquitto, etc.) that conforms to the MQTT protocol standard. Its function is limited to message reception, routing, and distribution, and it belongs to well-known infrastructure. The MQTT Access and Routing Module, on the other hand, is a core component of the backend system of this invention. It is responsible for actively establishing MQTT connections with devices, subscribing to specified topics, receiving messages reported by devices, and forwarding messages to subsequent processing modules (such as data processing and normalization modules) according to preset rules. It also undertakes the task of encapsulating and issuing control commands. In other words, MQTT Broker only serves as the underlying support for the communication channel, while the MQTT Access and Routing Module carries the business logic and system integration capabilities of this invention.

[0062] Topic Rules: A Topic is a hierarchical string structure in the MQTT protocol used to identify message topics (e.g., / device / {deviceId} / status). This system uses preset Topic naming rules to achieve automatic message routing and device identification. For example, when a device reports data, it uses a Topic with a fixed format. The MQTT access and routing module can extract metadata based on the unique device identifier (e.g., {deviceId}) in the Topic and accurately distribute the message to the corresponding data processing flow, thereby achieving efficient access and management of massive numbers of devices.

[0063] WebSocket technology: To achieve "zero-refresh" real-time awareness of device status by the front-end user interface (UI), this system uses the WebSocket protocol to establish a full-duplex connection between the browser and the backend. When the device status is updated in the background, the real-time status and command delivery module actively pushes JSON-formatted status change messages to subscribed front-end pages through this connection, avoiding the latency and server load caused by traditional HTTP polling.

[0064] Caching and Key-Value Storage: To improve device status query performance, this system introduces a caching mechanism. Specifically, a memory-based key-value storage system (Redis in one embodiment) is used, with the device's unique identifier (such as device ID) as the key and the latest normalized status data (such as operating status, temperature, task progress, etc.) as the value. This design allows the current status of any device to be read within microseconds, greatly optimizing the response efficiency of high-frequency access scenarios such as monitoring dashboards and alarm judgments.

[0065] Although the MQTT protocol, as mentioned above, has been widely used in IoT device communication scenarios due to its lightweight, low bandwidth consumption, and publish / subscribe mechanism compared to HTTP / HTTPS protocols, and has alleviated the problems of poor real-time performance and high server load caused by traditional HTTP polling to a certain extent, existing MQTT-based backend management systems still face the following problems in practical applications.

[0066] First, most MQTT-based systems essentially treat it as a "data pipeline"—devices send messages, the system receives them as is, and subsequent processing relies on hard-coded code. For example, devices from different manufacturers report data in a wide variety of formats; some use JSON, while others use custom binary protocols. Existing systems often need to write separate parsing logic for each type of device. Adding a new device type requires code modification and redeployment, resulting in high development and maintenance costs and significant scaling difficulties.

[0067] Furthermore, MQTT itself doesn't care about the "current state of the device." Although devices continuously send status messages, without an efficient caching mechanism in the backend, it's difficult to quickly obtain the latest state of a device. Many systems still rely on the frontend to periodically check or build their own WebSocket push system, which is not only complex to implement but also prone to errors, failing to achieve truly real-time, automatic state synchronization.

[0068] Furthermore, report templates are usually hardcoded in advance, making it impossible to flexibly combine data sources, statistical dimensions, or chart types according to user needs. Access control also mostly remains at a coarse-grained level of "who can view which page," failing to reach a level of precision such as "user A can only view the temperature data of device X and cannot issue control commands."

[0069] Finally, the devices can only passively report data within the system; they cannot actively tell the system "which data points I can provide" or "which report formats I support." As a result, the system lacks adaptability, many configurations still require manual intervention, and its level of intelligence is limited.

[0070] In response, this invention proposes an optimized solution, please refer to the following: Figure 1 and Figure 2 This invention discloses an IoT backend management system based on the MQTT protocol, designed to address the comprehensive challenges brought about by the explosive growth in the number of IoT devices, including high-concurrency access, heterogeneous data processing, real-time status synchronization, flexible data analysis, and refined access control. The overall system architecture includes a device-side module, an MQTT access and routing module, a data processing and standardization module, a front-end application UI, and a real-time status and command issuance module. In some embodiments, it also includes a multi-dimensional access control module and a templated report generation module. These modules work collaboratively to form an end-to-end closed-loop management capability.

[0071] Specifically, during the system initialization phase, various IoT devices (such as industrial sensors, smart meters, and edge gateways) act as device-side components. They establish persistent TCP-based connections with the backend via the MQTT protocol and subscribe to dedicated command topics (e.g., / cmd / {deviceId}) according to preset rules. Simultaneously, they publish messages containing raw operating status or sensor data to standardized data reporting topics (e.g., / data / {deviceId}). Due to its small header, support for QoS (Quality of Service) levels, and heartbeat keep-alive mechanism, the MQTT protocol is particularly suitable for scenarios with unstable networks or low power consumption, effectively ensuring the stable online presence of massive numbers of devices and reliable message delivery.

[0072] The MQTT access and routing module serves as the unified entry point for communication between the system and devices. It is responsible for receiving all data reporting messages from the device and automatically identifying the message source based on the unique device identifier in the Topic.

[0073] Upon receiving the raw message, the data processing and normalization module immediately initiates the processing flow. This module has a built-in data parsing template engine that can dynamically load the corresponding parsing template based on the device type. For example, for devices from vendor A, the template defines that the temperature field is located at the payload.env.temp path in the JSON; while for the binary protocol from vendor B, data points with the same semantics are extracted through bit offset and byte order rules. After parsing, cleaning, and unit normalization, all heterogeneous data is converted into normalized data with a unified structure (such as standard key-value pairs: {"device_id": "D1001", "temperature":25.3, "status": "running"}) and written to the time-series database. This mechanism completely eliminates the constraints of hard-coding parsing logic for each type of device in traditional systems, significantly shortening the new device access cycle and improving system scalability.

[0074] Meanwhile, the real-time status and command issuance module continuously monitors the standardized data stream. Once a device's status is updated, this module immediately stores the latest data in a high-speed cache module using the device's unique identifier as the key. In a preferred embodiment, this module uses a Redis in-memory database for efficient key-value storage, allowing the current status of any device to be queried within microseconds. More importantly, this module maintains a persistent connection with the front-end application UI of the opened monitoring page via WebSocket. When cached data changes, it proactively pushes status update messages in JSON format, achieving "zero-refresh" dynamic updates for components such as dashboards and numerical cards, greatly improving user experience and monitoring real-time performance.

[0075] Furthermore, when a user initiates a control operation through the front-end application UI, the MQTT access and routing module is also responsible for accurately publishing the encapsulated MQTT control message to the command Topic of the target device, ensuring that the command is accurately delivered.

[0076] To ensure system security in complex business scenarios, this embodiment further integrates a multi-dimensional access control module. Deployed after the API gateway, this module intercepts all requests originating from the front-end application UI. For each request, the system extracts the user identity, target resource identifier (which can be refined to specific devices, data points such as "temperature," report templates, or function menus), and operation type (such as view, control, export), forming a triple, and then matches and verifies it against a pre-configured access control policy library. Only when the combination of these three elements is authorized is the request allowed to proceed to subsequent business modules. This model supports advanced scenarios such as multi-tenant isolation and inter-departmental data access control, achieving atomic-level security management.

[0077] In some implementations, the system also includes a templated report generation module, granting users a high degree of autonomy in data analysis. This module is equipped with a report template engine that can receive structured report templates. Templates can be configured by users through a front-end application UI in a common office software-style interface (selecting data sources, setting time ranges, defining aggregation rules such as summation / average / peak, and specifying chart types), or they can be actively reported by devices with self-describing capabilities via the MQTT protocol. Templates reported by such devices are received by the MQTT access and routing module, parsed by the data processing and normalization module, and stored in the database. During report generation, the system dynamically constructs SQL statements based on the template content, executes queries to obtain normalized data, and then renders it into a visual chart in a specified format. The entire process requires no developer intervention, enabling flexible report customization.

[0078] In this way, the inherent advantages of the MQTT protocol in high-concurrency, low-latency communication are fully utilized. A complete capability system covering data processing, status management, access control, and intelligent analysis is built upon it, comprehensively addressing the core pain points of traditional IoT back-end systems in terms of scalability, real-time performance, flexibility, and security.

[0079] The following is a detailed description of the data processing method of the IoT backend management system based on the MQTT protocol described in the application.

[0080] Please refer to Figure 3 The present invention discloses a data processing method for an IoT backend management system, comprising data processing and real-time interaction steps. Specifically, it includes:

[0081] Step S11: Establish a persistent connection with the IoT device based on the MQTT protocol through the MQTT access and routing module, and subscribe to the device's instruction Topic;

[0082] Step S12: The MQTT access and routing module receives the data reporting message published by the device, the message containing the device identifier and the original data;

[0083] Step S13: Forward the data reporting message to the data processing and normalization module;

[0084] Step S14: The data processing and normalization module parses and cleans the raw data according to the preset data parsing template, and converts it into normalized data in a unified format;

[0085] Step S15: The real-time status and instruction delivery module receives the standardized data, stores it in the cache with the device identifier as the key, and pushes the status change to the connected front-end application UI through the persistent communication channel when the data is updated.

[0086] Step S16: Receive user operation instructions from the front-end application UI, and encapsulate the instructions into MQTT control messages by the real-time status and instruction delivery module;

[0087] Step S17: The MQTT control message is published to the corresponding device's instruction Topic through the MQTT access and routing module to complete remote control.

[0088] Thus, by constructing an IoT backend management system based on the MQTT protocol, including data processing and standardization modules as well as real-time status and command issuance modules, unified access and standardized processing of heterogeneous device data are achieved. It also supports millisecond-level real-time push of device status and reliable issuance of remote control commands, significantly improving the system's access capability for massive numbers of devices, data consistency, and human-machine interaction response speed. This solves the monitoring blind spots and control failures caused by protocol fragmentation and status synchronization delays in traditional IoT platforms.

[0089] Further, please refer to Figure 4 The data processing method of the IoT backend management system further includes a multi-dimensional access control step based on a triplet model. Specifically, it includes:

[0090] Step S21: Receive access requests from the front-end application UI through the API gateway;

[0091] Step S22: The multi-dimensional permission control module intercepts the access request and extracts the user identity, target resource identifier and operation type from it to form a permission verification triplet;

[0092] Step S23: Query the pre-configured permission policy library to determine whether the triplet matches the authorization rule;

[0093] Step S24: If a match is found, the request is allowed to proceed to the subsequent business module for processing; if no match is found, a permission denial response is returned.

[0094] The target resource identifier includes at least one of the following: device identifier, data point identifier, report template identifier, or system function interface identifier.

[0095] Thus, by introducing a multi-dimensional permission control module based on the "user identity-target resource-operation type" triplet model and deeply integrating it with the API gateway, fine-grained dynamic authorization of front-end access requests is achieved. This not only supports flexible permission configuration by device, function, and role, but also effectively prevents unauthorized access and illegal operations, greatly improving the security and compliance of the system. It is especially suitable for industrial IoT scenarios with multi-tenant and multi-department collaborative management.

[0096] Further, please refer to Figure 5 The data processing method of the IoT backend management system further includes a dynamic report generation step based on a structured template. Specifically, it includes:

[0097] Step S31: Receive a structured report template. The report template is submitted by the user through the front-end application UI or reported by the device through the MQTT protocol. After being received by the MQTT access and routing module, it is transmitted to the data processing and normalization module.

[0098] Step S32: Store the report template in the database;

[0099] Step S33: Respond to the report request from the front-end application UI and load the corresponding report template from the database;

[0100] Step S34: Dynamically generate SQL query statements based on the data source identifier, filtering conditions, and aggregation rules defined in the report template;

[0101] Step S35: Execute the SQL query statement to obtain a normalized data result set;

[0102] Step S36: Based on the time dimension and chart display format in the report template, aggregate and calculate the result set and render it into a visual report;

[0103] Step S37: Return the visualization report to the front-end application UI for display.

[0104] In this way, by setting up a templated report generation module and its report template engine, users or devices can define report templates in a structured manner, including data sources, filtering conditions, aggregation rules, and time series dimensions. The system can then dynamically generate and execute SQL queries based on these templates, automatically rendering them into diverse visual charts. Personalized data analysis and report customization can be achieved without developer intervention, greatly reducing the operational threshold and improving data insight efficiency and business decision response speed.

[0105] As described above, this invention protects an IoT backend management system and its data processing method based on the MQTT protocol. All technical solutions that are the same as or similar to this invention should be considered to fall within the protection scope of this invention.

Claims

1. An Internet of Things background management system based on the MQTT protocol, characterized in that, Comprise: Device end, for publishing data reporting messages and receiving control instructions through MQTT protocol; MQTT access and routing module, for receiving the data reporting messages, and issuing control instructions to the corresponding device end; Data processing and canonicalization module, for parsing and cleaning the original data in the data reporting messages and converting them into canonicalized data in a unified format, the data processing and canonicalization module comprising a data parsing template engine for dynamically parsing data formats of different device types according to a preset data parsing template; Front-end application UI, for providing a device monitoring interface to users and receiving user operation instructions; Real-time state and instruction issuing module, for automatically pushing state updates to connected front-end application UIs when device states change, and for receiving user operation instructions from the front-end application UIs, encapsulating the user operation instructions into MQTT control messages, and issuing them to target device ends via the MQTT access and routing module. 2.The Internet of Things background management system based on the MQTT protocol of claim 1, wherein, The real-time state and instruction issuing module comprises a cache module for storing the latest canonicalized state data with device unique identifiers as keys. 3.The Internet of Things background management system based on the MQTT protocol of claim 1, wherein, Further comprising a multi-dimensional permission control module for checking the permissions of access requests from the front-end application UIs.

4. The Internet of Things background management system based on the MQTT protocol of claim 3, wherein, The multi-dimensional permission control module intercepts all access requests from the front-end application UIs through an API gateway, checks each request in a triple manner, and decides whether to authorize according to a preconfigured permission policy. Further comprising a templated report generation module for reading canonicalized data from a database and generating visual reports according to a preset report template in response to report requests from the front-end application UIs.

5. The Internet of Things background management system based on the MQTT protocol of claim 1, wherein, The templated report generation module dynamically generates SQL query statements according to data source identifiers, filtering conditions, aggregation rules, and time dimensions in the report template, executes the statements to obtain result data, and renders the data into visual reports in combination with chart display forms.

6. The Internet of Things background management system based on the MQTT protocol of claim 5, wherein, The modular report generation module comprises a report template engine for receiving structured report templates; 7.The Internet of Things background management system based on MQTT protocol of claim 5, wherein, The report templates are submitted by users through the front-end application UIs, or are reported by device ends to the MQTT access and routing module through MQTT protocol, and are stored into the database via the data processing and canonicalization module. Comprise data processing and real-time interaction steps; 8. A data processing method of an Internet of Things background management system, characterized by, Step S11: Establish a persistent connection based on MQTT protocol between the MQTT access and routing module and Internet of Things devices, and subscribe to the instruction Topic of the devices; Step S12: The MQTT access and routing module receives data reporting messages published by the devices, the messages containing device identifiers and original data; Step S13: Forward the data reporting messages to the data processing and canonicalization module; Step S14: The data processing and canonicalization module parses and cleans the original data according to a preset data parsing template, and converts them into canonicalized data in a unified format; ​ Step S15: The real-time state and instruction issuing module receives the normalized data, stores it in the cache with the device identification as the key, and pushes the state changes to the connected front-end application UI through the persistent communication channel when the data is updated; Step S16: Receive user operation instructions from the front-end application UI, and encapsulate the instructions into MQTT control messages by the real-time state and instruction issuing module; Step S17: Publish the MQTT control messages to the corresponding device's instruction Topic through the MQTT access and routing module, and complete remote control. 9.The data processing method of an Internet of Things background management system according to claim 8, wherein, It also includes a multi-dimensional permission control step based on a triple model; Step S21: Receive access requests from the front-end application UI through the API gateway; Step S22: The multi-dimensional permission control module intercepts the access request and extracts the user identity, target resource identification and operation type from it to form a permission verification triple; Step S23: Query the pre-configured permission policy library to determine whether the triple matches the authorization rules; Step S24: If it matches, release the request to the subsequent business module for processing; if it does not match, return a permission denial response; Wherein, the target resource identification includes at least one of device identification, data point identification, report template identification or system function interface identification. 10.The data processing method of an Internet of Things background management system according to claim 9, wherein, It also includes a dynamic report generation step based on a structured template; Step S31: Receive the structured report template, which is submitted by the user through the front-end application UI or reported by the device side through the MQTT protocol, and then transmitted to the data processing and normalization module after being received by the MQTT access and routing module; Step S32: Store the report template in the database; Step S33: In response to the report request of the front-end application UI, load the corresponding report template from the database; Step S34: Dynamically generate SQL query statements according to the data source identification, filtering conditions and aggregation rules defined in the report template; Step S35: Execute the SQL query statement to obtain the normalized data result set; Step S36: According to the time dimension and chart display form in the report template, aggregate and calculate the result set and render it into a visual report; Step S37: Return the visual report to the front-end application UI for display.

Images