Energy management system real-time data interaction method
By introducing the message middleware MQ and the STOMP protocol into the energy management system, the problem of poor data acquisition timeliness in traditional systems is solved, enabling real-time data display from multiple clients and simplifying system connections, thereby improving data interaction efficiency and reliability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- TIANJIN KEYVIA ELECTRIC CO LTD
- Filing Date
- 2022-09-30
- Publication Date
- 2026-05-19
AI Technical Summary
Traditional energy management systems lack real-time data monitoring capabilities in the urban rail transit industry, resulting in poor data acquisition timeliness. Existing B/S architectures are unable to meet the needs of real-time data interaction.
Deploy message queue (MQ) in the existing energy management system. MQ sends data acquisition tasks from the monitoring module to the front-end machine and forwards them to the monitoring module. The STOMP protocol is used to realize real-time data display for multiple clients. SessionStorage and localStorage are used to store data, simplifying system connections and improving data interaction efficiency.
It enables real-time data display across multiple clients, reduces system connection complexity, improves data interaction efficiency, ensures data real-time performance and reliability, and simplifies business processing across different modules.
Smart Images

Figure CN115562888B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of energy management systems, and in particular relates to a real-time data interaction method for energy management systems. Background Technology
[0002] The rapid development of energy management systems in the urban rail transit industry has expanded the traditional function of reading electricity data from subway substation meters to include real-time monitoring of subway station equipment. Traditional energy management systems are based on a B / S architecture and generally only need to query historical energy data for subway stations and the entire line. In terms of the real-time performance of data acquisition, they are relatively poor compared to C / S architecture. Summary of the Invention
[0003] In view of this, the present invention aims to propose a real-time data interaction method for energy management systems, which adds a real-time data interaction method to the existing energy management system architecture to improve the data monitoring function of the real-time monitoring part in the energy management system.
[0004] To achieve the above objectives, the technical solution of the present invention is implemented as follows:
[0005] A real-time data interaction method for an energy management system.
[0006] Deploy message middleware MQ on the energy management system. Message middleware MQ sends data acquisition tasks from the monitoring module in the energy management system to the acquisition module in the front-end machine of the energy management system.
[0007] The energy management system's front-end server sends the collected data to the message queue (MQ), which then forwards the corresponding collected data to the monitoring module in the energy management system.
[0008] The message queue (MQ) relays data acquisition tasks, displaying real-time web data interfaces for multiple energy management system monitoring modules across multiple clients.
[0009] Furthermore, this includes the following steps:
[0010] S1. Configure data types and data ID association information, device and line names and corresponding device ID association information on the energy management system web configuration interface, and save them to the database;
[0011] S2. The Web data monitoring interface program starts and loads the associated information from the database. At the same time, the Web client obtains all node information from the SVG file, including node name, node data type, and collection time period.
[0012] S3. The client collects task messages according to the specified JSON format based on all node information in the SVG file.
[0013] S4. The client uses stomp to connect to the message middleware MQ software. stomp is a simple text-oriented message protocol.
[0014] S5. The client sends a message to the message middleware MQ according to the following structure for each set of monitoring data tasks in step S2.
[0015] S6. The client sends a subscription message to the MQ message middleware. The MQ message middleware will receive the corresponding topic message and forward it to the corresponding terminal, which will then process the message.
[0016] S7. The data acquisition module of the energy management system server uses stomp to connect to MQ software. stomp is a simple text-oriented message protocol.
[0017] S8, the energy management system server-side data acquisition module subscribes to the " / topic / task" message to receive acquisition task messages sent by the client;
[0018] S9 and MQ message middleware automatically forward any topic message containing " / topic / task" to the data collection module on the energy management system server.
[0019] S10. The energy management system server-side data acquisition module parses each received " / topic / task" topic message, queries the energy management system database, associates the device ID with the field device address, and associates the data ID with the telemetry and telesignal register address of the field device. Then, according to the requirements, it processes the data packet frames of the device data tasks to be collected. Receiving a collection task will generate a corresponding data packet.
[0020] S11. When the data collection interval time is up, the data packets are sent to the terminal in a cyclical timer.
[0021] S12. The energy management system server-side data acquisition module receives the returned data message and parses the message.
[0022] S13. After parsing each message, the data acquisition module of the energy management system processes the data and sends a JSON string message in the format corresponding to the message to be sent as a reply to the acquisition task.
[0023] S14. The data acquisition module of the energy management system server sends a reply message to the MQ message middleware.
[0024] S15. Each time the MQ message middleware receives a topic message with " / topic / terminal ID", it forwards it to the corresponding client.
[0025] S16. The client receives JSON data returned by the server-side data collection module, which is forwarded by the MQ message middleware.
[0026] S17. Client parses JSON data;
[0027] S18. The real-time data monitoring interface of the energy management system changes the equipment operating status and displays data based on the acquired data.
[0028] S19. When switching monitoring stations on the client data monitoring interface, a message to cancel the collection task will be sent to the message middleware, and then the real-time data interaction process will be executed again according to the above steps.
[0029] The S20, client, and server-side acquisition modules all establish heartbeat connections with the MQ message middleware to monitor whether the link is normal. If it is abnormal, the connection is interrupted and reconnected. If multiple reconnections fail to restore the connection, an alarm message is displayed on the interface so that the work team can troubleshoot the fault in a timely manner.
[0030] Furthermore, in step S1, the data types monitored in the energy management system include: phase A voltage, phase B voltage, phase C voltage, phase A forward active power, phase B forward active power, phase C forward active power, total forward active power, phase A reverse active power, phase B reverse active power, phase C reverse active power, total reverse active power, phase A power factor, phase B power factor, phase C power factor, total power factor, frequency, equipment operating time, operating mode, forward active energy, forward reactive energy, reverse active energy, and reverse reactive energy.
[0031] The associated data IDs are as follows:
[0032] The data types and data IDs listed above, “1011,1012,1013,1021,1022,1023,1031,1032,1033,1034,1041,1042,1043,1044,1051,1052,1053,1054,1061,1071,2011,2021,2031,2041”, can be modified and added.
[0033] The device and line IDs are automatically generated from the file information created in the energy management system, and all of them are unique values.
[0034] Furthermore, in step S3, the different devices in the energy management system contain some of the same data types as well as unique data types. Each type of real-time monitoring data corresponds to a data ID, and multiple data IDs together form the attribute value set Attri.
[0035] The data collection task message content is generated according to the following three schemes:
[0036] 1) Create a separate data acquisition task for each device. The JSON format of the data acquisition task is: "Device ID & Attribute Set Attri & Data Acquisition Time Period time";
[0037] 2) Generate a collection task for devices with the same data ID, and then create a separate collection task for devices with unique data IDs. The JSON format of the collection task is: "Device ID set & Attribute set Attri & Collection time period time".
[0038] 3) Based on Scheme 2), further improve upon it by creating new data IDs from the new data ID set as a special collection task.
[0039] Furthermore, in step S5, the collection task message is sent to the MQ message middleware in the following format: the subject name of the MQ message is " / topic / task", and the information content is the collection task message generated in step S3.
[0040] Furthermore, in step S17, the parsed data is stored in the browser's sessionStorage and localStorage respectively;
[0041] in,
[0042] sessionStorage is responsible for saving the data that has just been parsed. It updates the data by overwriting the original data. If there is no matching data item, it creates a new data item for storage.
[0043] localStorage is responsible for storing the parsed historical data locally, which is then used by the web data monitoring interface program to display historical curves and bar charts;
[0044] Both sessionStorage and localStorage store data by storing JSON strings, and all maintenance involves converting the stored JSON strings into JSON objects for maintenance.
[0045] Both sessionStorage and localStorage store data in units of device ID;
[0046] The process by which the client parses the JSON data returned by the server-side data collection module for MQ message middleware forwarding is as follows:
[0047] 1) Obtain the device ID, data ID, value (val), and data collection time (time);
[0048] 2) Use sessionStorage.getItem(“device id”) to find the JSON string stored for the corresponding device;
[0049] 3) Convert the JSON string to a JSON object;
[0050] 4) Retrieve the stored Oval value from the JSON object in sessionStorage using the data id as the key;
[0051] 5) Replace Oval with the parsed value val;
[0052] 6) Convert the updated JSON object to a JSON string, and call sessionStorage.setItem("device id", "JSON string") to update it to local storage;
[0053] 7) Retrieve the JSON string stored for the device using the localStorage.getItem(“device id”) method;
[0054] 8) Convert the JSON string to a JSON object;
[0055] 9) Insert the data collection time (time) as the key and the data ID and value (val) as the value into a JSON object;
[0056] 10) Convert the JSON object to a JSON string;
[0057] 11) Call localStorage.setItem("Data collection time", "JSON string") to update the local storage, completing the entire real-time data interaction process.
[0058] An electronic device includes a processor and a memory communicatively connected to the processor and used to store processor-executable instructions, the processor being used to execute a real-time data interaction method for an energy management system.
[0059] A server includes at least one processor and a memory communicatively connected to the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to perform a real-time data interaction method for an energy management system.
[0060] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements a real-time data interaction method for an energy management system.
[0061] Compared with existing technologies, the real-time data interaction method for an energy management system described in this invention has the following advantages:
[0062] This invention discloses a real-time data interaction method for an energy management system. Based on an existing energy management system, it deploys a message queue (MQ) to send data acquisition tasks from the monitoring module to the acquisition module in the energy management system's front-end server. The front-end server sends the acquired data to the MQ, which then forwards the corresponding data to the monitoring module. By using the MQ to relay data acquisition tasks, multiple clients can display real-time web data from multiple different energy management system monitoring modules. Furthermore, using the MQ as a message broker avoids the need for separate connections between different monitoring modules and the acquisition module in the front-end server, reducing system connection complexity and decoupling the connections between the two modules. Each module can focus on its own business processing; in particular, the acquisition module does not need to know which module's acquisition task it is, treating all data acquisition tasks from different web monitoring modules as a single task, only needing to return the acquired data in the corresponding message format to the single connection—the MQ. Attached Figure Description
[0063] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:
[0064] Figure 1 This is a schematic diagram of the sessionStorage storage structure according to an embodiment of the present invention;
[0065] Figure 2 This is a schematic diagram of the localStorage storage structure described in an embodiment of the present invention;
[0066] Figure 3 This is a schematic diagram of the real-time data interaction process described in an embodiment of the present invention. Detailed Implementation
[0067] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.
[0068] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0069] 1. Configure data types and data ID association information, as well as device and line names and their corresponding device ID association information, on the energy management system's web configuration interface, and save this information to the database. This association information can be modified at any time according to actual on-site needs, including adding, modifying, and deleting association information. The main purpose of this association information is to convert the objects to be monitored into digital information, facilitating data interaction with the computer.
[0070] The data types monitored in the energy management system are divided into: A-phase voltage, B-phase voltage, C-phase voltage, A-phase voltage, B-phase voltage, C-phase voltage, A-phase forward active power, B-phase forward active power, C-phase forward active power, total forward active power, A-phase reverse active power, B-phase reverse active power, C-phase reverse active power, total reverse active power, A-phase power factor, B-phase power factor, C-phase power factor, total power factor, frequency, equipment operating time, operating mode, forward active energy, forward reactive energy, reverse active energy, and reverse reactive energy. The associated data IDs are: "1011,1012,1013,1021,1022,1023,1031,1032,1033,1034,1041,1042,1043,1044,1051,1052,1053,1054,1061,1071,2011,2021,2031,2041";
[0071] The data types and data IDs mentioned above can be modified and added at any time.
[0072] The device and line IDs are automatically generated from the file information created in the energy management system, and all of them are unique values.
[0073] 2. Start the Web data monitoring interface program, load the associated information from the database, and at the same time, the Web client obtains all node information from the SVG file, including node name, node data type, and collection time period.
[0074] 3. The client collects task messages according to the specified JSON format based on all node information in the SVG file.
[0075] The different devices in an energy management system contain some common data types as well as unique data types. For example, for escalator and elevator equipment, real-time monitoring data consists of voltage, current, power, power factor, frequency, equipment operating time, operating mode (power frequency, variable frequency), and electricity consumption. For lighting equipment, only voltage, current, power, power factor, frequency, and electricity consumption are included. Each type of real-time monitoring data corresponds to a data ID, and multiple data IDs together form the attribute value set Attri.
[0076] The data collection task message content is generated according to the following three schemes:
[0077] 1) Create a separate data acquisition task for each device. The JSON format of the data acquisition task is: "Device ID & Attribute Set Attri & Data Acquisition Time Period time".
[0078] 2) To increase data collection efficiency and timeliness, a single collection task is generated for devices with the same data ID across most devices, while a separate collection task is created for devices with unique data IDs. The JSON format of the collection task is: "Device ID set & Attribute set Attri & Collection time period time".
[0079] 3) Further improve upon Scheme 2) by creating new data IDs from a new set of data IDs, treating it as a special data acquisition task. Electricity meters account for over 80% of the energy management system in subway stations, and the data types of all meters are basically the same, providing feasibility for this scheme. This scheme provides a way to combine identical data ID sets from devices into new data IDs, reducing the length of transmission messages. For example, data types such as "A-phase voltage, B-phase voltage, C-phase voltage, A-phase voltage, B-phase voltage, C-phase voltage, A-phase forward active power, B-phase forward active power, C-phase forward active power, total forward active power, A-phase reverse active power, B-phase reverse active power, C-phase reverse active power, total reverse active power, A-phase power factor, B-phase power factor, C-phase power factor, total power factor, frequency" can be combined into a new data ID of 9011. Similarly, data types such as "forward active energy, forward reactive energy, reverse active energy, reverse reactive energy" can be combined into 9021. The simplified attribute set Attri contains only "9011, 9021". Then, configure the new data type and data ID association information on the energy management system's web configuration interface. The data acquisition task JSON format is: "Device ID set & Simplified attribute set Attri & Data acquisition time period time".
[0080] The choice of which of the three schemes to use in practice is configured on the web interface of the energy management system.
[0081] 4. The client uses stomp, or Simple (or Streaming) Text Oriented Messaging Protocol, to connect to the message queue (MQ) software.
[0082] 5. Following the steps in step 2, the client sends messages to the message queue (MQ) for each set of monitoring data tasks according to the following structure. The client sends the data collection task message to the MQ message queue in the following format.
[0083] The topic name of the message sent by the MQ is " / topic / task", and the message content is the collection task message generated in step 3.
[0084] 6. The client sends a subscription message to the MQ message middleware in the following format.
[0085] Topic Name: " / topic / terminal id"
[0086] The MQ message middleware will receive the message for the corresponding topic and forward it to the corresponding terminal, which will then process the message.
[0087] 7. The data acquisition module of the energy management system server uses STOMP (Simple (or Streaming) TextOriented Messaging Protocol) to connect to the MQ software.
[0088] 8. The energy management system server-side data acquisition module subscribes to the " / topic / task" message. This is primarily used to receive data acquisition task messages sent by clients.
[0089] 9. Whenever the MQ message middleware receives a topic message with " / topic / task", it will automatically forward it to the data collection module on the energy management system server.
[0090] 10. The data acquisition module on the energy management system server parses each received " / topic / task" topic message, queries the energy management system database, associates the device ID with the field device address, and associates the data ID with the telemetry and telesignal register address of the field device. Then, according to the requirements, it processes the data packet frames of the device data to be collected. Receiving a collection task will generate a corresponding data packet.
[0091] 11. When the data collection interval expires, the data packets will be sent to the terminal in a cyclical manner.
[0092] 12. The data acquisition module on the energy management system server receives the returned data message and parses the message.
[0093] 13. The energy management system server-side data acquisition module processes the data after parsing each message, such as adding ratios and coefficients, and then replies with a message in JSON format. Generally, the data uploaded by the terminal is processed data, i.e., secondary-side data, which needs to be converted to primary-side data to restore the original data.
[0094] 14. The data acquisition module on the energy management system server side sends a reply message to the MQ message middleware in the following format.
[0095] Subject Name: " / topic / Terminal ID", Message Content: "Object ID1&Data Type&Value"
[0096] 15. Each time the MQ message middleware receives a topic message with " / topic / terminal ID", it forwards it to the corresponding client.
[0097] 16. The client receives JSON data returned by the server-side data collection module, which is forwarded by the MQ message middleware.
[0098] 17. The client parses the JSON data. The parsed data is stored in the browser's sessionStorage and localStorage respectively. sessionStorage is responsible for saving the parsed data, updating the data by overwriting the original data; if no matching data item is found, a new data item is created and stored. localStorage is responsible for storing the parsed historical data locally, used by the web data monitoring interface program to display historical line charts and bar charts. Both sessionStorage and localStorage store data using JSON strings. All maintenance involves converting the stored JSON strings into JSON objects. The structure diagram of the JSON object stored in sessionStorage is shown below. Figure 1 As shown in the diagram. The structure of JSON objects stored in localStorage is as follows. Figure 2 As shown. Both store data in units of device ID. The process of the client parsing the JSON data returned by the server-side data collection module forwarded by the MQ message middleware is as follows:
[0099] 1) Obtain device ID, data ID, value (val), and data collection time (time).
[0100] 2) Use sessionStorage.getItem(“device id”) to find the JSON string stored for the corresponding device.
[0101] 3) Convert the JSON string to a JSON object
[0102] 4) Further, retrieve the stored Oval value from the JSON object in sessionStorage using the data id as the key.
[0103] 5) Replace Oval with the parsed value val.
[0104] 6) Convert the updated JSON object to a JSON string, and call sessionStorage.setItem("device id", "JSON string") to update it to local storage, such as... Figure 1 As shown.
[0105] 7) Use the localStorage.getItem(“device id”) method to get the JSON string stored for the device.
[0106] 8) Convert the JSON string to a JSON object
[0107] 9) Insert the data collection time (time) as the key, and the data ID and value (val) as the value into a JSON object.
[0108] 10) Convert a JSON object to a JSON string.
[0109] 11) Call localStorage.setItem("Data Collection Time", "JSON String") to update the local storage, such as... Figure 2 As shown, the entire real-time data interaction process is completed.
[0110] 18. The real-time data monitoring interface of the energy management system changes the equipment operating status and displays data based on the acquired data.
[0111] 19. When switching monitoring stations on the client-side data monitoring interface, a message to cancel the data collection task is sent to the message middleware. Then, the real-time data interaction process is executed again following the steps above.
[0112] The above describes the real-time data interaction process, and the specific workflow is as follows: Figure 3 As shown.
[0113] 20. Both the client and server-side acquisition modules establish heartbeat connections with the MQ message middleware to monitor whether the link is normal. If it is abnormal, the connection is interrupted and reconnected. If multiple reconnections fail to restore the connection, an alarm message is displayed on the interface so that the work team can troubleshoot the fault in a timely manner.
[0114] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0115] In the several embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the division of units described above is merely a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The aforementioned units may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention according to actual needs.
[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.
[0117] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A real-time data interaction method for an energy management system, characterized in that: Deploy a message middleware MQ on the energy management system. The message middleware MQ sends the data acquisition tasks in the monitoring module of the energy management system to the acquisition module in the front-end machine of the energy management system. The energy management system's front-end server sends the collected data to the message queue (MQ), which then forwards the corresponding collected data to the monitoring module in the energy management system. The message queue (MQ) relay data acquisition task displays real-time web data interfaces for multiple energy management system monitoring modules implemented on multiple clients; Specifically, the following steps are included: S1. Configure data types and data ID association information, device and line names and corresponding device ID association information on the energy management system web configuration interface, and save them to the database; S2. The Web data monitoring interface program starts and loads the associated information from the database. At the same time, the Web client obtains all node information from the SVG file, including node name, node data type, and collection time period. S3. The client collects task messages according to the specified JSON format based on all node information in the SVG file. S4. The client uses stomp to connect to the message middleware MQ software. stomp is a simple text-oriented message protocol. S5. The client sends a message to the message middleware MQ according to each set of monitoring data tasks in step S2. S6. The client sends a subscription message to the MQ message middleware. The MQ message middleware forwards the corresponding topic message to the corresponding terminal, and the terminal processes the message. S7. The data acquisition module of the energy management system server uses stomp to connect to MQ software. stomp is a simple text-oriented message protocol. S8, the energy management system server-side data acquisition module subscribes to the " / topic / task" message to receive data acquisition task messages sent by the client; S9 and MQ message middleware automatically forward any topic message containing " / topic / task" to the data collection module on the energy management system server. S10. The data acquisition module of the energy management system server parses the " / topic / task" topic message received each time. By querying the energy management system database, it associates the device ID with the address of the field device and the data ID with the telemetry and telesignal register address of the field device. Then, according to the requirements, it processes the data packet frame of the device data task to be collected. Receiving a collection task will generate a corresponding data packet. S11. When the data collection interval time is up, the data packets are sent to the terminal in a cyclical timer. S12. The energy management system server-side data acquisition module receives the returned data message and parses the message. S13. The energy management system server-side data acquisition module processes the data after parsing each message and sends a JSON string message in the format corresponding to the data acquisition task message. S14. The data acquisition module of the energy management system server sends a reply message to the MQ message middleware. S15. Each time the MQ message middleware receives a topic message with " / topic / terminal ID", it forwards it to the corresponding client. S16. The client receives JSON data returned by the server-side data collection module, which is forwarded by the MQ message middleware. S17. Client parses JSON data; S18. The real-time data monitoring interface of the energy management system changes the equipment operating status and displays data based on the acquired data. S19. When switching monitoring stations on the client data monitoring interface, a message to cancel the data collection task will be sent to the message middleware, and then the real-time data interaction process will be executed again according to the above steps. The S20, client, and server-side acquisition modules all establish heartbeat connections with the MQ message middleware to monitor whether the link is normal. If it is abnormal, the connection is interrupted and reconnected. If multiple reconnections fail to restore the connection, an alarm message is displayed on the interface so that the work team can troubleshoot the fault in a timely manner.
2. The real-time data interaction method for an energy management system according to claim 1, characterized in that: In step S1, the data types monitored in the energy management system include: phase A voltage, phase B voltage, phase C voltage, phase A forward active power, phase B forward active power, phase C forward active power, total forward active power, phase A reverse active power, phase B reverse active power, phase C reverse active power, total reverse active power, phase A power factor, phase B power factor, phase C power factor, total power factor, frequency, equipment operating time, operating mode, forward active energy, forward reactive energy, reverse active energy, and reverse reactive energy.
3. The real-time data interaction method for an energy management system according to claim 1, characterized in that: In step S3, the different devices of the energy management system contain some of the same data types as well as unique data types. Each type of real-time monitoring data corresponds to a data ID, and multiple data IDs together form the attribute value set Attri. The data collection task message content is generated according to the following three schemes: 1) Create a separate data acquisition task for each device. The JSON format of the data acquisition task is: "Device ID & Attribute Set Attri & Data Acquisition Time Period time"; 2) Generate a collection task for devices with the same data ID, and then create a separate collection task for devices with unique data IDs. The JSON format of the collection task is: "Device ID set & Attribute set Attri & Collection time period time". 3) Based on Scheme 2), further improve upon it by creating new data IDs from the new data ID set as a special collection task.
4. The real-time data interaction method for an energy management system according to claim 1, characterized in that: In step S5, the data collection task message is sent to the MQ message middleware in the following format: the subject name of the MQ message is " / topic / task", and the message content is the data collection task message generated in step S3.
5. The real-time data interaction method for an energy management system according to claim 1, characterized in that: In step S17, the parsed data is stored in the browser's sessionStorage and localStorage respectively; in, sessionStorage is responsible for saving the parsed data, updating the data by overwriting the original data, and creating a new data item for storage if there is no matching data item. localStorage is responsible for storing the parsed historical data locally, which is then used by the web data monitoring interface program to display historical curves and bar charts; Both sessionStorage and localStorage store data by storing JSON strings, and all maintenance involves converting the stored JSON strings into JSON objects for maintenance. Both sessionStorage and localStorage store data in units of device ID; The process by which the client parses the JSON data returned by the server-side data collection module for MQ message middleware forwarding is as follows: 1) Obtain the device ID, data ID, value (val), and data collection time (time); 2) Use sessionStorage.getItem("device id") to find the JSON string stored for the corresponding device; 3) Convert the JSON string to a JSON object; 4) Retrieve the stored Oval value from the JSON object in sessionStorage using the data id as the key; 5) Replace Oval with the parsed value val; 6) Convert the updated JSON object to a JSON string, and call sessionStorage.setItem("device id", "JSON string") to update it to local storage; 7) Retrieve the JSON string stored for the device using the localStorage.getItem("device id" method; 8) Convert the JSON string to a JSON object; 9) Insert the data collection time (time) as the key, and the data ID and value (val) as the value into a JSON object; 10) Convert a JSON object to a JSON string; 11) Call localStorage.setItem("Data collection time", "JSON string") to update the local storage, completing the entire real-time data interaction process.
6. An electronic device, comprising a processor and a memory communicatively connected to the processor and used for storing processor-executable instructions, characterized in that: The processor is used to execute the real-time data interaction method of an energy management system as described in any one of claims 1-5.
7. A server, characterized in that: The system includes at least one processor and a memory communicatively connected to the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to perform a real-time data interaction method for an energy management system as described in any one of claims 1-5.
8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it implements the real-time data interaction method of an energy management system as described in any one of claims 1-5.