Device information interaction method, slave device gateway and master device

Abstract

The application belongs to the technical field of information interaction, and relates to a device information interaction method, a slave device gateway and a master device. The active transmission frame mechanism is realized through the slave device gateway, so that the slave device actively reports information to the master device when the state changes or the trigger condition is met. The master device can analyze and issue configuration instructions in real time to complete dynamic management of the slave device. The method supports centralized monitoring and configuration of the slave device in the parallel energy storage system, guarantees the consistency of device identification, address, group and state, realizes real-time, accurate and extensible management, does not interfere with the original Modbus master-slave communication process, and effectively solves the problems of poor expansibility, state update lag and communication conflict risk in the traditional one-master-one-slave mode.

Description

Technical Field

[0001] This application belongs to the field of information interaction technology, specifically relating to a device information interaction method, a slave device gateway, and a master device. Background Technology

[0002] The Modbus protocol, due to its simple structure and high openness, is widely used in automation and industrial control. Its typical communication mode is master-slave, where the master device initiates requests and the slave device responds passively. This master-slave communication mechanism was sufficient for early scenarios with a limited number of devices and simple system structures.

[0003] However, with the development of the Internet of Things and energy systems, the scale of equipment and the complexity of systems have increased significantly. A slave device system often consists of multiple slave devices. For example, an energy storage parallel system may simultaneously include inverters, battery modules, and control units. In this case, the master device not only needs to sense the overall status of the entire system, but also needs to obtain the operating information of each slave device in a timely manner.

[0004] In the process of developing this application, the inventors discovered at least the following problems in the prior art: First, the traditional master-slave mode lacks good scalability and is difficult to support the master device to uniformly manage and access multiple slave devices; Second, the existing communication mechanism relies on the master device to poll, and the slave devices cannot actively report data, resulting in untimely status updates; Third, if communication is directly extended, it is easy to interfere with the existing master-slave interaction process and increase the risk of communication conflicts. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a device information interaction method that enables slave devices to proactively report their own data without interfering with normal communication in a master-slave application scenario.

[0006] To address the aforementioned technical problems, one technical solution adopted in this application is as follows: a device information interaction method is provided, applied to a slave device gateway, which is communicatively connected to a master device and multiple slave devices. The method includes: receiving a first request message sent by a master device; returning a first response message corresponding to a first protocol version number in the first request message to the master device; and entering a device monitoring state; wherein the first response message is sent based on a preset active transmission frame; in the device monitoring state, acquiring first target information corresponding to a slave device; when the first target information meets a preset triggering condition, sending a second response message corresponding to the first target information to the master device based on the active transmission frame, so that the master device parses the second response message to obtain a first parsing result, and when a preset configuration condition is triggered, sending a second request message to the slave device gateway; in response to the received second request message, modifying the configuration information of the slave device corresponding to the second request message; acquiring second target information of the slave device corresponding to the second request message; when the second target information meets a preset triggering condition, sending a third response message corresponding to the second target information to the master device based on the active transmission frame, so that the master device parses the third response message.

[0007] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a device information interaction method applied to a master device, wherein the master device is communicatively connected to a slave device gateway, and the slave device gateway is also communicatively connected to multiple slave devices. The method includes: sending a first request message to the slave device gateway, causing the slave device gateway to return a first response message corresponding to a first protocol version number in the first request message to the master device; wherein the first response message is sent based on a preset active transmission frame; receiving a second response message sent by the slave device gateway, parsing the second response message to obtain a first parsing result, and sending a second request message to the master device when a preset configuration condition is triggered. The device gateway enables the slave device gateway to modify the configuration information of the slave device corresponding to the second request message in response to the received second request message; wherein the second response message is sent by the slave device gateway based on an active transmission frame when the first target information meets a preset trigger condition, and the first target information is obtained by the slave device gateway in the device monitoring state; and receives a third response message sent by the slave device gateway and parses the third response message; wherein the third response message is sent by the slave device gateway based on an active transmission frame when the second target information meets a preset trigger condition, and the second target information is obtained by the slave device gateway through communication interaction with the slave device corresponding to the second request message.

[0008] Unlike related technologies, this application provides a device information interaction method, a slave device gateway, and a master device. By setting an active transmission frame mechanism at the slave device gateway, active information reporting and real-time status monitoring from the slave device to the master device are achieved. Specifically, after the master device sends a first request message, the slave device gateway returns a corresponding first response message and enters device monitoring state, thereby continuously acquiring the first target information of the slave devices, including the identifier, address, group sequence number, and status of each slave device. When this information meets preset trigger conditions, the slave device gateway sends a second response message to the master device based on the active transmission frame, enabling the master device to promptly parse and obtain the first parsing result. If the parsing result meets preset configuration conditions, the master device can send a second request message, prompting the slave device gateway to modify the configuration information of the corresponding slave device. Subsequently, the slave device gateway continues to acquire the second target information and sends a third response message when the trigger conditions are met, enabling the master device to obtain the latest status of the slave devices after configuration. This method enables the master device to manage a parallel energy storage system containing multiple slave devices in real time, dynamically and accurately through an active reporting mechanism and message parsing logic. It effectively ensures the configuration consistency and operational stability of the parallel energy storage system without interfering with the original Modbus master-slave interaction process. Attached Figure Description

[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0010] Figure 1 This is a schematic diagram of the structure of a device information interaction system provided in an embodiment of this application;

[0011] Figure 2 This is a flowchart of a device information interaction method provided in an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of the slave device topology provided in an embodiment of this application;

[0013] Figure 4 This is a schematic diagram of the structure for slave device binding and management provided in an embodiment of this application;

[0014] Figure 5 This is a flowchart of a device information interaction method provided in another embodiment of this application;

[0015] Figure 6 This is an interactive schematic diagram of the device information interaction process provided in the embodiments of this application;

[0016] Figure 7This is a schematic diagram of the hardware structure of a slave device gateway that performs a device information interaction method according to an embodiment of this application;

[0017] Figure 8 This is a schematic diagram of the hardware structure of a master device that performs a device information interaction method according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application. It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, and all are within the protection scope of this application.

[0019] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more.

[0020] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application.

[0021] Under the existing Modbus master-slave communication framework, the "one master, one slave" interaction mode is still commonly used, that is, the master device actively initiates communication requests and the slave device passively responds. This mode is more effective when dealing with single device communication, but when there are multiple slave devices, the following shortcomings are exposed: (1) Poor scalability: The master device can usually only communicate with a single slave address, making it difficult to directly obtain detailed information of multiple slave devices within the parallel energy storage system, which cannot meet the management needs of the parallel energy storage system. (2) Lack of automatic discovery capability: The master device cannot automatically identify and configure the addresses and relationships of multiple slave devices, increasing the complexity of manual intervention and configuration. (3) Limitations of the passive response mechanism: In the existing mode, the slave device only responds with data when it receives a request from the master device. Once a slave device changes its state, the master device must poll to find out, which is delayed and cannot meet the timeliness and real-time requirements of the parallel energy storage system. (4) Communication conflict risk: If communication functions are extended or superimposed in a non-standard way, they are likely to interfere with the master-slave interaction logic of the standard Modbus protocol, resulting in communication abnormalities or data disorder, which will affect the stable operation of the parallel energy storage system.

[0022] To address the aforementioned issues, this application proposes a novel device information interaction concept for parallel energy storage systems. The core idea of ​​this concept is to introduce an active transmission frame mechanism while maintaining compatibility with the existing Modbus master-slave communication framework, achieving the following objectives:

[0023] (1) Unified reporting and management of information from multiple slave devices: By defining active transmission frames, the basic attributes of each slave device in the parallel energy storage system (such as slave address, serial number, device model, operating status, etc.) are encapsulated and transmitted to help the master device quickly establish a global understanding and tree-like logical relationship of the parallel energy storage system.

[0024] (2) Active reporting capability of slave device: With the help of active transmission frames, when a change is detected by the slave device, the change information is actively reported to the master device, thereby solving the problem of insufficient timeliness caused by the traditional polling method.

[0025] (3) Binding and management of slave devices: When the master device needs to manage the slave devices in the parallel energy storage system in groups, it can actively configure the addresses and distinguish the groups of the slave devices to better manage the parallel energy storage system.

[0026] (4) Parallelism and independence with standard protocols: This mechanism does not disrupt or interfere with the normal interaction of the Modbus standard protocol, but rather serves as an enhancement logic that exists in parallel with the standard protocol, ensuring that while maintaining system compatibility, it improves communication efficiency and real-time performance in one-to-many scenarios.

[0027] (5) Scalable protocol version design: By setting different protocol version numbers, it supports diverse functional expansions, such as system configuration, status reporting, remote upgrades, etc., providing flexible support for the continuous iteration and functional expansion of parallel energy storage systems.

[0028] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a device information interaction system provided in an embodiment of this application. For example... Figure 1 As shown, the equipment information interaction system 100 is applied to parallel energy storage scenarios. Its core objective is to achieve efficient and real-time data interaction and management between the master equipment and multiple slave devices within the parallel energy storage system. The system 100 includes a master equipment 10 and a parallel energy storage system 20. The master equipment 10 and the parallel energy storage system 20 establish a communication connection based on the Modbus protocol, thereby realizing the collection, status monitoring, and management of equipment operation information.

[0029] In terms of system architecture, the parallel energy storage system 20 consists of a slave device gateway 21 and multiple slave devices (22, 23, 24, ..., N). The slave device gateway 21 connects and interacts with each slave device through a standard communication interface, and serves as the IoT management hub for the entire parallel energy storage system. The master device 10 can indirectly obtain information about all slave devices within the parallel energy storage system 20 by communicating with the slave device gateway 21 via Modbus.

[0030] The master device 10 serves as the external control and management terminal for the equipment information interaction system 100. In practical applications, it is typically a user-end application (APP), but can also be expanded into a monitoring platform or energy management system. The master device 10 can receive system information and the status of each slave device reported by the slave device gateway 21, enabling remote monitoring and unified management of the entire parallel energy storage system 20. Through the master device 10, users can view the real-time operating status of each slave device and perform operations such as configuration adjustments, fault diagnosis, and the distribution of operating strategies.

[0031] The parallel energy storage system 20 is an integrated energy storage system formed by connecting multiple inverter systems and related supporting equipment in parallel, possessing energy storage and output capabilities. The parallel energy storage system 20 includes a slave device gateway 21 and multiple slave devices (22, 23, 24, ..., N). Slave devices 22-N can be inverter systems composed of inverters and multiple battery packs, or other accessory equipment (such as distribution boxes, smart sockets, DC-DC modules, etc.). The slave device gateway 21 is responsible for the unified management of all slave devices in the parallel energy storage system 20. Furthermore, the parallel energy storage system 20 communicates with the master device 10 through the slave device gateway 21, enabling the entire parallel energy storage system to be remotely monitored and intelligently managed.

[0032] The slave device gateway 21 is the core communication and management node in the parallel energy storage system 20, acting as the system's IoT management hub. The slave device gateway 21 is responsible for accessing and managing multiple slave devices in the parallel energy storage system 20, and uniformly encapsulates the slave device information before reporting it to the master device 10. It supports dynamic maintenance of device binding relationships: when a new slave device is accessed, removed, or its status changes, the slave device gateway 21 can promptly detect and synchronously update the system topology. Simultaneously, it also has a proactive reporting mechanism, enabling it to transmit change information to the master device 10 immediately upon the occurrence of critical events (such as slave device alarms or changes in battery pack quantity), thereby achieving real-time perception and response to the entire energy storage system.

[0033] Slave device 22-N is a specific operating unit in the parallel energy storage system 20, and can be an inverter system or an auxiliary device. When the slave device is an inverter system, it typically includes an inverter and multiple battery packs. The inverter is used to realize the AC / DC conversion of energy, and the battery packs are used for energy storage. When the slave device is an accessory device, such as a distribution box, smart socket, or DC-DC module, its structure includes a corresponding power management unit, sensors, and communication interfaces. In addition, slave device 22-N collects operating status, energy data, and alarm information through its internal sensing and control unit, and interacts with slave device gateway 21 through the communication interface. As the basic operating units of the parallel energy storage system, they jointly realize energy storage, parallel power output, and safe system operation. At the same time, they can provide binding information and real-time status to slave device gateway 21, ensuring the integrity and dynamic maintainability of the entire system topology.

[0034] Overall, the equipment information interaction system 100, through a hierarchical architecture of master device 10-slave device gateway 21-slave device 22-N, realizes unified management, proactive reporting and efficient communication of parallel energy storage systems, and has good scalability and real-time performance.

[0035] The implementation process of a device information interaction method provided in this application will be described below with reference to specific embodiments.

[0036] Example 1

[0037] Please see Figure 2 , Figure 2 This is a flowchart of a device information interaction method provided in an embodiment of this application. Figure 2 As shown, this method is applied to a slave device gateway 21, which is communicatively connected to a master device and multiple slave devices. The method includes steps S11-S16:

[0038] S11: Receive the first request message sent by the master device, return the first response message corresponding to the first protocol version number in the first request message to the master device, and enter the device monitoring state; wherein, the first response message is sent based on a preset active transmission frame.

[0039] The process includes receiving a first request message from the master device, returning a first response message corresponding to the first protocol version number in the first request message to the master device, and entering device monitoring state. This includes: obtaining third target information corresponding to the slave devices based on the first protocol version number in the first request message; the third target information includes the number of third devices and the third device identifier, third device status, third device address, and third group sequence number corresponding to each slave device; performing message format conversion on the number of third devices, third device identifier, third device status, third device address, and third group sequence number based on the active transmission frame to obtain a first response message; sending the first response message to the master device, and entering device monitoring state.

[0040] The master device obtains detailed information about each slave device in the entire parallel energy storage system from the device gateway, thereby constructing the logical topology of the parallel energy storage system and providing basic data support for subsequent proactive reporting, upgrade scheduling, and anomaly monitoring. The specific process is as follows:

[0041] The slave device gateway first receives the first request message sent by the master device. This message uses the request message format of writing a single holding register message (i.e., the request message format corresponding to function code 06H in the Modbus RTU instruction), where the register address is 0x0001 and the data value corresponds to the protocol version number to be activated (for example, when the first protocol version number is 1, it corresponds to obtaining slave device tree information and slave device details).

[0042] After receiving the first request message, the slave device gateway parses the message, including the function code, register address, and data value, and performs CRC or LRC checks to ensure message integrity and validity. If the requested protocol version is supported, the slave device gateway continues with subsequent processing; if the protocol version is not supported, the slave device gateway still returns a standard echo response to maintain compatibility with the Modbus master-slave communication protocol, but does not trigger the active reporting mechanism.

[0043] After completing the standard Modbus echo response, the device gateway begins to obtain the third target information, namely the total number of slave devices in the parallel energy storage system and detailed information of each slave device.

[0044] The number of third-party devices refers to the total number of slave devices in the parallel energy storage system. The third-party device identifier includes the slave device's serial number (SN) and model number, representing the device's unique factory code and device type code, used to uniquely identify each device. The status of the third-party devices includes online status, upgrade requirements, alarm or fault status, etc.

[0045] The third device address includes the Modbus single-device slave address, the parent device slave address, and the Modbus slave address summarizing information for devices of the same type. It can be understood that the Modbus single-device slave address represents the Modbus slave address sequence number of each device itself. The parent device slave address represents the slave address of the device at the next higher level for each slave device. This is mainly used when the parallel energy storage system architecture is complex (involving multi-level architectures), facilitating the master device to quickly obtain a logical framework similar to a "device tree diagram". It should be noted that, as... Figure 3 As shown, the slave topology of all slave devices in a parallel energy storage system can be obtained through the slave address of a single device and the slave address of its parent device. Figure 3 Taking Level 1 slave device 1 (0-1) as an example, the 0 in parentheses represents the slave address of the parent device (i.e., the slave device gateway), and the 1 in parentheses represents the Modbus single-device slave address of Level 1 slave device 1. The Modbus slave address for summarizing information on devices of the same type is used to provide summarized information on devices of the same type, such as the lowest version number of the device model and the total power of the device model. The third group sequence number is used to distinguish different slave device groups or binding relationships within the parallel energy storage system.

[0046] In practice, as shown in Table 1, the device gateway organizes the above information of each slave device according to a fixed register mapping order. For example, when the protocol version number is 1, the information of each slave device is sequentially filled into the register range from register 3 to register 10 (slave device 22), and multiple frames are sent using the device number offset, so that the master device can sequentially parse the logical structure of the entire parallel energy storage system.

[0047] Table 1 - Active Transmission Frames (First Protocol Version Number)

[0048]

[0049] After information collection is complete, the slave device gateway encapsulates the third target information into a first response message based on the active transmission frame format and sends it to the master device. This active transmission frame borrows the request message format for writing multiple holding register messages (i.e., the request message format corresponding to function code 10H in the Modbus RTU instruction). However, this frame is only sent by the slave device gateway to the master device to actively report its own information. It neither interferes with the standard Modbus master-slave response interaction nor follows the complete Modbus standard, but exists as a new protocol running parallel to the Modbus protocol. During the frame encapsulation process, the slave device gateway fills the register data area in a fixed order and calculates the CRC check value to ensure message integrity. If all the third target information cannot be sent in a single frame, the slave device gateway sends the frames in a split-frame manner according to the device number offset strategy until all slave device information has been reported.

[0050] After sending the first response message, the slave device gateway switches to device monitoring mode to perform real-time status monitoring of the managed slave devices, including online status, upgrade requests, alarm / fault status changes, and the addition of new devices or changes in device logical relationships. When the above changes are detected, the slave device gateway will report the updated information to the master device again based on the active transmission frame, ensuring that the master device always obtains the latest slave device status and topology. At the same time, when sending messages encapsulated in the active transmission frame, the slave device gateway will perform message validity verification and frame segmentation to prevent information loss or packet merging. In case of message abnormalities or unsupported protocol versions, it will prompt the master device with a standard echo response.

[0051] It should be noted that for messages corresponding to commonly used Modbus RTU commands (e.g., function codes 06H or 10H), unlike the request and response messages which are identical, the request and response messages for writing a single holding register (function code 06H) and writing multiple holding registers (function code 10H) have significant differences in format and length, as shown in Tables 2 and 3. It should also be noted that function code 10 shown in Tables 2 and 3 is a hexadecimal number, actually 0x10. It can be understood that function code 10 shown in Tables 2 and 3 is a simplified representation of 0x10. In this embodiment, 0x10 is replaced by 10H, where H represents Hexadecimal (hexadecimal), which will not be elaborated further below.

[0052] Table 2 - Request messages for writing multiple holding registers

[0053]

[0054] Table 3 - Response messages for writing multiple holding register messages

[0055]

[0056] Understandably, a request message for writing multiple holding registers (Master->Slave) is as follows: [SlaveAddress]

[10] [Start Address Hi] [Start Address Lo][Quantity Hi] [Quantity Lo][Byte Count] [Data Hi][Data Lo] ... [Data Hi][Data Lo] [CRC Lo][CRC Hi]. Here, Slave Address corresponds to the slave address in the table; 10 (0x10, also known as 10H) is the function code; Start Address Hi and Start Address Lo correspond to the high and low bytes of the register start address; Quantity Hi and Quantity Lo correspond to the high and low bytes of the register quantity; Byte Count corresponds to the number of bytes; Data Hi and Data Lo correspond to the high and low bytes of the data; CRC Lo and CRC Hi correspond to the low and high bytes of the CRC checksum. Understandably, the length of the request message can be flexibly adjusted according to the number of registers to be written.

[0057] The response message for writing multiple holding register messages (Slave->Master) is: [Slave Address]

[10] [Start Address Hi] [Start Address Lo][Quantity Hi] [Quantity Lo][CRC Lo] [CRC Hi]. Based on the message format, the response message length is fixed at 8 bytes. This means the response message only echoes the information from the request message regarding the "range to be written" (slave address, function code, starting address, number of registers), and does not include the actual data value written (the Byte Count and Data parts are omitted).

[0058] By comparison, it can be seen that the main reasons for choosing the request message format for writing multiple holding registers in the Modbus protocol as the active transmission frame in this embodiment are as follows. First, the request message format and response message format for writing multiple holding registers (function code 10H) have significant differences in length and content: the request message can flexibly adjust its length according to the number of registers to be written, while the response message is fixed at 8 bytes, only echoing the write range information and not containing the actual data value. This difference provides a natural message carrying capacity for slave devices to actively report information, allowing slave devices to flexibly transmit multi-register data using the request message format, while master devices can distinguish between ordinary Modbus interactions and active transmission frames by recognizing the message length or data structure, thereby achieving independent parsing and processing. Second, this message format is widely supported and easy to understand in the Modbus protocol, and its logical structure is stable with minimal changes. This allows for the introduction of an active reporting mechanism into the existing Modbus master-slave communication framework without modifying the original protocol stack, and enables rapid implementation of new functions, ensuring system compatibility and stability. Furthermore, by using the request message format for writing multiple holding registers, slave devices can proactively send their own information to the master device when there are changes in status, adjustments in the number of devices, or updates to critical attributes. This significantly improves the real-time performance and completeness of information exchange without affecting the original standard polling communication process between the master and slave devices. Therefore, using the "request message format for writing multiple holding registers" as the active transmission frame balances flexibility, compatibility, and maintainability, providing a highly efficient, scalable, and non-interfering active information reporting channel for parallel energy storage systems.

[0059] In step S11, by receiving the first request message sent by the master device and returning the corresponding first response message, the slave device gateway can provide the master device with complete information about the entire parallel energy storage system in the initial stage. This information includes the number of slave devices, the unique identifier of each device, the device status, the device address, and the group number, thus forming a clear logical topology of the devices. This process is based on active transmission frames, allowing slave devices to proactively report their own information to the master device without waiting for continuous polling from the master device. This significantly reduces the information acquisition delay and meets the high timeliness requirements of status monitoring in multi-device systems. Furthermore, the use of active transmission frames that borrow the request message format of writing multiple holding register messages allows this reporting mechanism to coexist smoothly without affecting existing Modbus master-slave communication, ensuring system compatibility and stability. Based on this, after the slave device gateway enters the device monitoring state, it can continuously track the status changes of each slave device and promptly trigger reporting when there are changes in the number of devices, updates to key attributes, or fault alarms. This ensures that the master device always has the latest system status, providing a reliable basis for subsequent device configuration management, upgrade operations, and fault handling.

[0060] S12: In the device monitoring state, acquire the first target information corresponding to the slave device.

[0061] In the device monitoring state, the slave device gateway continuously, reliably, and traceably collects the status data of each slave device within the parallel energy storage system. This ensures that any changes that meet preset trigger conditions are promptly triggered, leading to subsequent proactive reporting and management operations. The specific process is as follows:

[0062] First, the device gateway initializes upon entering device monitoring mode. Initialization includes: loading or creating a local device mapping table, which records the logical index, communication address (Modbus single-machine slave address), group sequence number, parent device address, device type / model sequence number, and the last successfully acquired device SN and status for each known slave device; initializing retry / timeout parameters, concurrent read / write limits, debouncing strategies, and frame / sequence number counters; and starting the device monitoring timer and event listener.

[0063] Secondly, the first target information is obtained from the device gateway through two main methods:

[0064] (1) Proactive Periodic / On-Demand Polling: In polling mode, the slave device gateway initiates a register read request for each slave device according to a preset polling strategy to obtain the required fields. To balance efficiency and real-time performance, the polling strategy typically includes: 1) One-time full data collection (initial or resynchronization): Upon first entering the device monitoring state or when inconsistencies in the device table are detected (such as adding a new device or address conflict), the slave device gateway performs a full data read for each slave device to obtain a complete set of device information (device SN, model number, single device slave address, parent slave address, same type summary address, device status bits, etc.). This read can read the corresponding fields through the local communication protocol defined by the device manufacturer. It should be noted that the communication protocol between the slave device gateway and the slave device is not limited to Modbus; it can also be CAN or WIFI, which is not limited here. For fields such as SN that span several registers, the slave device gateway parses the multi-register byte order combination into a string or value according to the register mapping rules. 2) Periodic Incremental Data Acquisition: After completing the initial full data acquisition, the device gateway reads key status registers (such as device status bits, online / offline indicators, alarm flags, upgrade request bits, etc.) from each slave device at short intervals (configurable, e.g., 1s, 5s, 10s, etc., depending on the application's timeliness requirements). Static fields (SN, model number, device address, etc.) are checked at longer intervals or through event triggering to reduce bus load. 3) Parallel and Concurrency Control: To improve throughput, the device gateway can initiate read requests to multiple slave devices in parallel, but must adhere to the access constraints of the underlying physical bus. Therefore, the device gateway uses a task pool or queue mechanism with concurrency limits for parallel reading to avoid bus conflicts and control response timeouts. Each read operation is configured with a timeout and retry strategy (e.g., 2 retries, each timeout period of 200–500 ms). Failures due to timeouts or consecutive retries will be handled according to degradation logic.

[0065] (2) Passive / Event-Driven Acquisition: In a slave device architecture that supports event reporting, when a slave device or its local control unit experiences a critical status change (e.g., alarm, module online / offline, group binding / unbinding, version change), it can proactively send the change information to the slave device gateway (e.g., via local CAN bus, vendor serial port, or local Ethernet). The slave device gateway immediately parses and updates upon receiving the event. Passive reception reduces polling latency and improves response speed to sudden events. For slave devices that cannot proactively report, the slave device gateway still relies on polling.

[0066] Regardless of whether the data originates from polling or events, the slave device gateway parses and maps the raw register / message data into a data structure for the first target information. This structure includes at least: First Device Count: The total number of currently registered and communicable slave devices (used for framing and offset calculation); First Device Identifier: The serial number (SN) and model number of each device (composed of several registers); First Device Status: A bit-encoded status field (bit0 online / offline; bit1 upgrade requirement; bit2 alarm; bit3 protection / fault; the remaining bits are reserved); First Device Address: Includes the Modbus slave address of a single device, the address of the parent device slave, and the Modbus slave address for summary information of devices of the same type; First Group Number: Group / binding identifier (0 indicates no binding).

[0067] Step S12 ensures that the slave device gateway can acquire and maintain the first target information with high reliability, high real-time performance, and controllability: namely, the total number of slave devices in the parallel energy storage system, the serial number and model of each slave device, real-time status bits, various addresses, and group sequence numbers, etc. When a preset trigger condition is detected, the slave device gateway will trigger the subsequent active reporting mechanism (S13) to ensure the master device's visibility into the status of the parallel energy storage system and the timeliness of its management.

[0068] S13: When the first target information meets the preset triggering conditions, a second response message corresponding to the first target information is sent to the master device based on the active transmission frame, so that the master device can parse the second response message, obtain the first parsing result, and send a second request message to the slave device gateway when the preset configuration conditions are triggered.

[0069] The first target information includes the first number of devices and the first device identifier, first device status, first device address, and first group sequence number corresponding to each slave device. When the first target information meets the preset triggering conditions, a second response message corresponding to the first target information is sent to the master device based on the active transmission frame, including: if the first target information meets at least one of the following conditions: the first number of devices is different from the third number of devices, the first device identifier is different from the third device identifier, the first device status is different from the third device status, the first device address is different from the third device address, and the first group sequence number is different from the third group sequence number, then an update reporting mechanism is triggered; when the update reporting mechanism is triggered, the first number of devices, the first device identifier, the first device status, the first device address, and the first group sequence number are converted into message formats based on the active transmission frame to obtain the second response message; and the second response message is sent to the master device.

[0070] When the first target information (hereinafter referred to as "real-time information") obtained by the device gateway under device monitoring status is compared with the previously reported third target information (hereinafter referred to as "historical information") and meets the preset triggering conditions, the device gateway sends the updated information corresponding to the real-time information to the master device based on the active transmission frame. The master device then parses the updated information and decides whether to issue a configuration command (second request message) to complete the management or configuration of the parallel energy storage system. The specific process is as follows:

[0071] (1) Triggering condition determination:

[0072] The real-time and historical information corresponding to the slave device are known from steps S11 and S12 above. The slave device gateway compares the real-time information with the historical information to determine whether the preset trigger conditions are met. The preset trigger conditions include at least one of the following situations: 1) The number of devices in the real-time information is inconsistent with the number of devices in the historical information (addition or removal of devices); 2) The device identifier (SN or model serial number) of a slave device changes (indicating device replacement or reset); 3) The device status of a slave device changes (e.g., online / offline, alarm bit or fault bit, upgrade request bit, etc. change); 4) The device address information of a slave device changes (e.g., single device slave address or parent device address changes, or similar aggregated address changes); 5) The group serial number of a slave device changes (binding / unbinding or group adjustment).

[0073] (2) Construct the second response message:

[0074] According to the reporting policy, the device gateway organizes the data to be reported into one or more data frames according to the register mapping rules of Protocol Version 1. Each frame is encapsulated in the format of an active transmission frame, specifically including:

[0075] Enter the protocol version number (e.g., 0x0001) in the first register (Reg1) of the data area;

[0076] Enter the device count offset for this frame in Reg2 (0 for the first frame, and the sum of the number of devices reported in the previous frame for subsequent frames).

[0077] Fill in the fixed fields of each slave device in sequence (e.g., Reg3: L8 single device slave address, H8 group number; Reg4: L8 parent device address, H8 group summary address; Reg5: device status bit; Reg6~Reg9: device SN; Reg10: device model number), convert the above register sequence into a byte stream (2 bytes per register, high byte first), and calculate Byte Count (number of registers × 2).

[0078] The request message format (active transmission frame) for writing multiple holding register messages in the Modbus protocol is encapsulated into a second response message: [Slave Address]

[10] [Start Address Hi] [Start Address Lo][Quantity Hi] [Quantity Lo][Byte Count] [Data...][CRC Lo] [CRC Hi]. The slave device gateway fills in its own address or broadcast address (e.g., 0x00) in the slave address field according to the deployment strategy to ensure that the master device can correctly receive and identify the frame. This frame is a "special transmission frame" sent unidirectionally from the slave device gateway to the master device. The master device can distinguish it from regular master-slave interactions and parse it separately based on the function code, byte count, and data structure.

[0079] If the required data cannot be contained in a single frame, the device gateway will divide the data into frames according to the device number offset rule and send them in sequence to ensure the integrity of the offset field and order in each frame.

[0080] (3) Transmission and bus scheduling:

[0081] Before transmission, the slave device gateway first performs bus status detection and courtesy: if the physical bus (e.g., RS-485) is occupied by the master device or there is a master device request / response, the slave device gateway waits for the bus to become idle and follows preset interval time and direction control rules to avoid conflicts. Subsequently, the slave device gateway sends the second response message to the master device in sequence and implements a retransmission strategy if necessary: ​​if a rejection or parsing anomaly is detected at the master device layer within a specified time, the slave device gateway can retransmit according to the retry count.

[0082] (4) Main device parsing and generation of the first parsing result:

[0083] Upon receiving the second response message, the master device identifies the frame as an active transmission frame (based on characteristics such as the function code appearing in the slave device direction, Byte Count, and data area structure). It then performs register-by-register parsing of the data area according to the protocol version, reconstructing or updating its internal device table to generate the first parsing result. This first parsing result should include: the number of received devices, the identifier, status, address, group information, and metadata such as frame sequence number / offset for subsequent decision-making.

[0084] (5) Determine whether the preset configuration conditions have been triggered and send a second request message:

[0085] The master device performs rule-based judgment on the first parsing result. If the first parsing result meets the preset configuration conditions, the master device sends a second request message to the slave device gateway to perform the configuration operation. The preset configuration conditions are set by the master device based on its own control strategy or user requests, and are not limited here.

[0086] The second request message constructed by the master device preferably adopts the Modbus write multiple holding registers request message format. After filling the target device's configuration items into the Data area according to the register mapping defined in Protocol Version 3 (for configuration), it is sent to the slave device gateway. After the master device sends the message, it can receive and verify the slave device gateway's standard response (echo start address and number of registers) according to the Modbus standard to confirm that the configuration write has been received by the slave device gateway and will be distributed to the target slave device by the slave device gateway.

[0087] In addition, during the sending of the second response message and the receiving of the second request message, the slave device gateway can record and handle abnormal situations: if the master device finds the frame incomplete or the verification fails during parsing, the master device can initiate a request to the slave device gateway to retransmit; if the slave device gateway experiences a single failure when issuing configuration to subordinate devices after receiving the configuration request, it should handle it according to the retry policy or rollback policy and report the processing result to the master device through subsequent active transmission frames to complete the closed-loop confirmation. The slave device gateway and the master device should record the transaction log and frame sequence number for each reporting / configuration interaction for subsequent auditing and troubleshooting.

[0088] Step S13, by setting preset trigger conditions and combining them with an active transmission frame mechanism, enables real-time perception and rapid reporting of changes in the status of slave devices, avoiding the latency and resource waste that may result from relying on the master device's polling method. When the number, identifier, status, address, or group sequence number of slave devices changes, the update reporting mechanism is automatically triggered. The changed information is converted into a message format and actively sent to the master device, enabling the master device to complete the parsing and generate the parsing result immediately. Based on this, the master device can not only keep abreast of the real-time operating status of the parallel energy storage system, but also send request messages to the slave device gateway when the parsing result meets the preset configuration conditions, thus forming a closed-loop processing flow of "change—reporting—parsing—response". This mechanism ensures that the transmission of status information in a dynamic operating environment is more efficient, timely, and accurate, significantly improving the real-time performance and reliability of the system, and enhancing the master device's unified management and flexible scheduling capabilities over the slave device cluster.

[0089] S14: In response to the received second request message, modify the configuration information of the slave device corresponding to the second request message.

[0090] When the slave device gateway is running in device monitoring mode, it responds to the second request message sent by the master device and executes the configuration processing flow. As shown in Table 4, the second request message (configuration message) adopts the standard message format of "write multiple holding registers message (function code 10H)". Its implementation flow is as follows:

[0091] Table 4 - Configuration Messages (Third Protocol Version Number)

[0092]

[0093] (1) Message reception and validity verification: The slave device gateway receives the second request message from the communication bus connected to the master device, parses out the slave address, function code, starting address, number of registers, number of bytes, and data field, and performs CRC check on the CRC field. If the CRC check fails, the function code is not 10H, or the starting address / number of registers does not match the preset range, the current configuration process is terminated directly, and no changes are made to the system configuration. When the check passes, the data field parsing stage begins. Optionally, the uniformly agreed entry address (including the broadcast address) in this embodiment is also accepted by the slave device gateway and participates in the parsing.

[0094] (2) Protocol Version and Frame Header Field Parsing: The device gateway first reads the frame header register from the data field, extracts the third protocol version number, and determines whether it is the protocol version used for device configuration within the system (e.g., conventionally "3"). When the third protocol version number is inconsistent with the preset, the device gateway does not perform configuration writing, but only gives an acknowledgment or ignores it (according to the implementation convention). When they are consistent, it continues to parse the "Device Quantity Offset" field in the frame header. The device quantity offset is used as a positioning identifier for multi-frame fragment configuration: the offset of the first frame is 0, and the offset of subsequent frames is the sum of the number of nodes transmitted in all previous frames, with a maximum supported number of nodes of 255. Based on this offset, the device gateway determines the positioning range of the device management record in the full set of device configurations within this frame to ensure the sequential consistency of multi-frame continuous configuration, etc.

[0095] (3) Device management record extraction and field interpretation: After parsing the frame header, the device gateway extracts several device management records from the data field in sequence according to the register mapping of protocol version 3. Each record includes at least: 1) Address / group composite word: the lower 8 bits (L8bit) are the "Modbus single device slave address" to be set, and the higher 8 bits (H8bit) are the "group number" to be set (0 indicates invalid or unbinding); 2) Device SN; 3) Device model simplified serial number.

[0096] For register addresses not used in version 3 of the protocol, the slave device gateway skips them or ignores them as null values; for cases with sparse address mapping, the slave device gateway slices the mapping table into continuous windows of "starting address + number of registers" and reconstructs the complete management record in the agreed order. Thus, the slave device gateway obtains the set of target configuration entries within this frame. }

[0097] (4) Target positioning and validity verification: For each management record The device gateway performs target matching based on the "device identifier," prioritizing the device serial number (SN) as the primary key and combining it with the simplified serial number of the device model for secondary verification to locate the unique slave device in the system. When no online or registered slave device can be matched, the record is not written and may be marked as "missed" for subsequent reporting. When multiple candidates are matched, the slave device gateway eliminates ambiguity according to a preset uniqueness strategy (e.g., using the SN as the unique key). Subsequently, the slave device gateway performs validity checks on the proposed "Modbus single device slave address" and "group sequence number": Slave address verification: Determines whether it falls within the allowed range and whether it conflicts with the addresses of other slave devices in the system; if there is a conflict, the record is not written. Group sequence number verification: Determines whether it falls within the allowed range; when the value is 0, it indicates unbinding, and the slave device gateway should remove the slave device from the original group. After the above verification, the slave device gateway forms an executable configuration action queue. }

[0098] (5) Configuration distribution and local mapping update: For queue { For each item in}, the device gateway executes the configuration in the order of "address first, then group": Address setting: The device gateway configures the address settings by communicating with the target device. The underlying communication link (such as RS-485 / Modbus RTU or internal bus) sends an address setting command to update its slave address to the address specified in the record; after this process is completed, the slave device gateway immediately sets the new address to the correct address. Perform a handshake or register read verification to ensure the address is valid. Group settings: Update from device gateway. The group attribute, when the group number is not equal to 0, will... Assign to the corresponding group; when the group number is 0, unbind the data. Deleted from the original group. Understandably, after group settings are configured, the group status of the slave device will be as follows: Figure 4As shown. Subsequently, the slave device gateway simultaneously updates its local "group-device" relationship table and "address-device" routing mapping table for subsequent forwarding and aggregation access by the slave device gateway (e.g., broadcasting OTA or parameter distribution to the same group). Legality and consistency maintenance: For changes in the superior / same type aggregated access address caused by address updates, the slave device gateway synchronously adjusts its internal index structure to ensure that subsequent aggregation queries based on "slave addresses of aggregated information for the same type of device" remain valid; for offline slave devices, the slave device gateway can optionally record them as "delayed effect," supplementing the configuration when the device comes back online. Persistence: Successful configuration results are written to non-volatile storage (e.g., Flash / EEPROM) and runtime cache to ensure that the configuration is not lost after a power outage and restart; if a new configuration is detected to be consistent with the current state, the slave device gateway can skip the actual write and only update the timestamp.

[0099] (6) Standard Response Message Return: After all executable configuration actions within this frame are completed, the slave device gateway returns a response message according to the response specification of the write multiple holding register message (function code 10H), at least echoing the starting address and the number of registers, and attaching a CRC check to indicate that the configuration write process of this frame has been correctly received and processed by the slave device gateway. For scenarios with a unified entry address, the slave device gateway also returns this response message as agreed. For records that were not executed due to verification failure or conflict, the slave device gateway does not carry detailed error codes in the response (error fields are not defined in protocol version 3), but will re-collect and report the latest information based on the active transmission frame in subsequent steps S15 / S16, so that the master device can know the final effective configuration status.

[0100] Step S14 involves directly modifying the configuration information of the corresponding slave device by responding to the second request message issued by the master device at the slave device gateway. This automates the management of group relationships, address allocation, and device identification information within the slave device system. Compared to the traditional method of relying on manual configuration one by one or single-point modification through fixed commands, this step, based on the protocol-formatted second request message, enables centralized modification and batch updates of multi-dimensional parameters, significantly improving the efficiency and consistency of the configuration process. Furthermore, due to the good scalability and maintainability of the adopted protocol, configuration fields can be flexibly added and adjusted according to different versions or business needs. This allows the system to quickly adapt and maintain efficient management capabilities in dynamic scenarios such as device expansion, group changes, or device unbinding. Through this process, the master device does not need to interact with each slave device individually; instead, it completes the configuration modification by issuing unified commands through the slave device gateway. This reduces communication overhead and synchronization difficulty, improves the overall system's controllability and stability in a parallel energy storage environment, and effectively ensures the reliability and flexibility of multi-device collaborative operation.

[0101] S15: Obtain the second target information of the slave device corresponding to the second request message.

[0102] S16: When the second target information meets the preset triggering conditions, a third response message corresponding to the second target information is sent to the master device based on the active transmission frame, so that the master device can parse the third response message.

[0103] The second target information includes the number of second devices and the second device identifier, second device status, second device address, and second group sequence number corresponding to each slave device. When the second target information meets the preset triggering conditions, a third response message corresponding to the second target information is sent to the master device based on the active transmission frame. This includes: if the second target information meets at least one of the following conditions: the number of first devices is different from the number of second devices, the first device identifier is different from the second device identifier, the first device status is different from the second device status, the first device address is different from the second device address, and the first group sequence number is different from the second group sequence number, then an update reporting mechanism is triggered; when the update reporting mechanism is triggered, the message format of the number of second devices, the second device identifier, the second device status, the second device address, and the second group sequence number is converted based on the active transmission frame to obtain the third response message; and the third response message is sent to the master device.

[0104] After modifying the configuration information of the slave device corresponding to the second request message in step S14, the slave device gateway enters the configuration confirmation stage. Based on communication with the slave device, it obtains the latest operating parameters of the slave device, including device identifier, device address, device status, and group sequence number, thereby generating the second target information. After obtaining the information, the slave device gateway compares and judges the second target information. If it finds that it matches the preset triggering conditions, such as a change in device status, successful adjustment of the device group, or reassignment of the device address, it determines that the configuration has taken effect and triggers the update reporting mechanism. Under the triggering mechanism, the slave device gateway encapsulates the second target information into a third response message based on an active transmission frame and immediately reports it to the master device so that the master device can parse and record it, thereby achieving real-time synchronization and feedback of the slave device configuration results.

[0105] It should be noted that the process of obtaining the second target information has been described in detail in step S12 above, and the implementation process of step S16 has been described in detail in step S13 above, so it will not be repeated here.

[0106] After modifying the configuration information of the slave device corresponding to the second request message, the slave device gateway further obtains and parses the latest operating parameters of the slave device, enabling timely generation of the second target information and ensuring consistency in configuration status between the master and slave devices. Based on conditional judgment of the second target information, when the triggering condition is met, the slave device gateway can proactively generate and report a third response message, allowing the master device to obtain the configuration results and device operating status without polling or additional commands. This proactive reporting mechanism not only improves the real-time performance and reliability of information interaction between the master and slave devices but also reduces the communication burden on the master device side, avoiding bandwidth consumption and response delays caused by frequent queries. Furthermore, the use of the same proactive transmission frame triggering mechanism after configuration and in monitoring scenarios maintains consistency and scalability of the protocol processing logic, facilitating subsequent system maintenance and functional upgrades, thereby significantly improving management efficiency and system adaptability in multi-slave device scenarios.

[0107] In some embodiments, the method further includes: obtaining fourth target information corresponding to the slave device and judging the fourth target information; if the fourth target information meets the preset upgrade conditions, then sending a fourth response message corresponding to the fourth target information to the master device based on the active transmission frame and the second protocol version number.

[0108] When the system is undergoing an upgrade, the device gateway reports upgrade information to the slave device according to the aforementioned reporting logic. It also periodically or on demand triggers the reading of the upgrade status of the target slave device and extracts the fourth target information based on a preset protocol frame structure. As shown in Table 5, when protocol version 2 is used, the fourth target information mainly includes the following key fields: Upgrade Status Identifier: L8bit is used to identify the upgrade execution status, representing no upgrade, upgrade in progress, upgrade successful, and upgrade failed; H8bit is used to record error codes during file transfer; Software Version Number: Composed of two register fields, the lower 16 bits and the higher 16 bits are concatenated to obtain the complete software version number; Device SN: Used to identify the unique identity of the device to support target verification and backtracking during the upgrade process; Device Model Number: Used to characterize the device type and its differentiated configurations.

[0109] Table 5 - Active Transmission Frames (Second Protocol Version Number)

[0110]

[0111] After obtaining the aforementioned fourth target information, the device gateway makes a logical judgment on it: if the device is detected to be online and has an upgrade requirement, or the current device software version number is inconsistent with the target version number, or the upgrade status is in a failed / abnormal state, then the fourth target information is considered to meet the preset upgrade conditions, and the upgrade reporting mechanism is triggered.

[0112] When the upgrade reporting mechanism is triggered, the device gateway performs message format conversion based on the active transmission frame, generating a fourth response message corresponding to the fourth target information. This message carries a second protocol version number in the frame header to clearly indicate that it corresponds to an upgrade service process; the message body contains upgrade-related information such as the upgrade status identifier, software version number, device serial number, and model number. Subsequently, the fourth response message is sent to the master device.

[0113] Upon receiving the fourth response message, the master device parses it and obtains the upgrade-related analysis results. This allows it to determine whether the device needs to initiate a remote upgrade task, whether to continue monitoring the upgrade progress, or to take appropriate fault tolerance and recovery strategies when error codes occur. Through this process, the system achieves real-time reporting and unified management of device upgrade status based on proactive transmission. This enables the master device to continuously monitor the latest status of slave devices throughout the upgrade cycle, thereby ensuring the effective execution and secure control of online upgrades.

[0114] In this embodiment, after obtaining the fourth target information from the device gateway, it can determine whether the device needs to perform an upgrade operation or whether the current upgrade status is abnormal based on preset upgrade conditions. By using a fourth response message based on an active transmission frame and carrying protocol version 2, the device gateway can actively send key information such as the upgrade status, software version number, device serial number, and model number of each slave device to the master device. After receiving the message, the master device can immediately parse the upgrade status and generate corresponding control policies, thereby realizing unified management, real-time monitoring, and anomaly handling of the online upgrade process of slave devices. On the one hand, it ensures that the master device can keep track of the latest status of each slave device at any time during the upgrade process, achieving timeliness and accuracy of upgrade decisions; on the other hand, through the active reporting mechanism and protocol version control, it achieves efficient and reliable centralized management of slave device upgrade information without affecting standard communication interaction, thereby improving the success rate, maintainability, and overall operational security of the system's online upgrade.

[0115] In some embodiments, the method further includes other customized private protocols (protocol versions 4, 5, etc.) based on the same reporting mechanism. The extensibility of this method lies in its provision of ample definable fields and extension points: a dedicated "version number" field is designed in the protocol header. This allows for the introduction of new, specific subsets of functionality (such as protocol version 3) while maintaining full compatibility with the mainline versions (such as protocol versions 1 and 2), without requiring a complete refactoring of the protocol stack.

[0116] Based on the above framework, the implementation of private protocols follows these principles:

[0117] (1) Version number identifier: In the "Version Number" field of the protocol header, a specific value range (such as 0x80 to 0xFF) is defined to identify the private protocol version, thereby distinguishing it from the backbone version and enabling multiple versions to coexist and be correctly routed.

[0118] (2) Modular addition and deletion of functions: The newly added private protocols can be used as functional module plug-ins of the backbone protocol version. According to the specific needs of the actual business scenario (such as periodic storage of historical data of device operation, unified reporting and storage of abnormal data, etc.), private protocol fields or message types can be added in the framework specification, or some unnecessary functions in the backbone protocol version can be selectively disabled to achieve the lightweighting of the protocol.

[0119] This application provides a device information interaction method. Through multi-level communication between the master device and the slave device gateway and its subordinate slave devices, it realizes real-time status monitoring, proactive information reporting, centralized management, and online upgrades of a parallel energy storage system. During implementation, the master device can obtain complete information about all slave devices within the slave device gateway, including the number of devices, identification number, status, slave address, and group number, providing a foundation for establishing the logical relationship and tree structure of devices within the system (protocol version-1). During device operation, it can monitor the status information of each slave device in real time. When the status changes or preset conditions are met, the slave device gateway sends a response message to the master device based on a proactive transmission frame, enabling the master device to immediately parse the device's operating status and trigger configuration or management operations (protocol version-3). After the master device issues configuration or management commands, the slave device gateway can quickly modify the slave device's slave address, group number, and other configuration information, and then re-determine whether the updated status meets the proactive reporting conditions, achieving continuous monitoring and dynamic... In addition to management, the system can also determine the online upgrade conditions of slave devices. When the conditions are met, the upgrade status information is transmitted to the master device via active transmission frames, thereby realizing centralized online upgrades and real-time status feedback for slave devices (protocol version-2). Simultaneously, based on the same reporting mechanism, other private protocol versions can be derived according to actual needs, adding private protocol fields and message types to increase corresponding device management functions. This allows for the flexible introduction of private protocol versions for specific scenarios while maintaining compatibility with the existing protocol framework. This design gives the protocol good scalability: on the one hand, the backbone protocol can operate stably without being affected by the addition of new functions; on the other hand, private protocols can add or remove modules as needed to quickly meet business requirements such as historical data storage and unified reporting of abnormal data. Thus, it ensures the coexistence of multiple versions and correct routing while avoiding the overall reconstruction of the protocol stack. Through the above process, this method achieves efficient information interaction, dynamic management, active reporting, and online upgrade functions for parallel energy storage systems without affecting standard Modbus communication, improving system security, reliability, and maintainability, while facilitating centralized monitoring and unified management of slave devices by the master device.

[0120] Example 2

[0121] Please see Figure 5 , Figure 5 This is a flowchart of a device information interaction method provided in another embodiment of this application. For example... Figure 5 As shown, this method is applied to master device 10, which is communicatively connected to slave device gateway 21. Slave device gateway 21 is also communicatively connected to multiple slave devices (22-N). The method includes steps S21-S23:

[0122] S21: Send a first request message to the slave device gateway, so that the slave device gateway returns a first response message corresponding to the first protocol version number in the first request message to the master device; wherein, the first response message is sent based on a preset active transmission frame.

[0123] On the master device side, a first request message is constructed and sent to the slave device gateway. This request message carries a first protocol version number, indicating that the master device wishes to obtain basic information about all slave devices within the slave device gateway. After sending this message, the slave device gateway will return a first response message to the master device based on preset active transmission frame logic. This first response message includes basic information such as the identifier, slave address, group sequence number, status information, and number of devices for each slave device. This facilitates the master device's overall understanding of the member structure and status of the slave device system and provides a data foundation for subsequent configuration and management. Through this step, the master device can establish a complete slave device information model, laying the foundation for dynamic monitoring and proactive interaction of the system.

[0124] S22: Receive the second response message sent by the slave device gateway, parse the second response message to obtain the first parsing result, and when the preset configuration condition is triggered, send the second request message to the slave device gateway so that the slave device gateway responds to the received second request message and modifies the configuration information of the slave device corresponding to the second request message; wherein, the second response message is sent by the slave device gateway based on the active transmission frame when the first target information meets the preset trigger condition, and the first target information is obtained by the slave device gateway in the device monitoring state.

[0125] The process includes receiving a second response message from the slave device gateway, parsing the second response message to obtain a first parsing result, and sending a second request message to the slave device gateway when a preset configuration condition is triggered. This includes: obtaining the first device identifier, first device address, and first group sequence number corresponding to each slave device based on the second response message; determining the first device address and first group sequence number; if the first device address and first group sequence number meet the preset configuration condition, converting the message format based on the third protocol version number, first device identifier, first device address, and first group sequence number to obtain a second request message; and sending the second request message to the slave device gateway. The preset configuration condition is set by the master device according to its own control policy or user request under actual circumstances, and is not limited here.

[0126] After sending the first request message and receiving the first response message, the master device continuously listens for the second response message sent by the slave device gateway. This second response message is based on a preset active transmission frame and is triggered by the slave device gateway when it detects changes in the slave device's system status, address, or group. The message includes: the first number of devices; the first device identifier (device SN, device model number) for each slave device; the first device address, including the Modbus single-device slave address, the parent device slave address, and the Modbus slave address for aggregated information of similar devices; the first device status information (node ​​online status, upgrade requirements, alarm or protection status); and the first group number.

[0127] The master device performs structured parsing of the second response message according to the preset parsing rules: identifies the frame header and protocol version number, confirms the message type; and extracts the first target information corresponding to each slave device, including the number of first devices, the first device identifier, the first device status, the first device address, and the first group sequence number.

[0128] When the master device is triggered according to its own control policy or the preset configuration conditions set by the user request, it generates a second request message: converts the message format of the first device identifier, first device address and group sequence number that need to be updated; constructs a second request message according to the third protocol version number, which is used to modify the configuration of the corresponding slave device of the slave device gateway; ensures that the message structure is complete and the address and group information are correct, and supports the slave device gateway to directly parse and execute the configuration modification.

[0129] The master device sends the generated second request message to the slave device gateway to complete the centralized configuration adjustment of the slave device system. This operation enables: dynamic management of slave device addresses and groups; and synchronous optimization of device status and configuration.

[0130] S23: Receive the third response message sent by the slave device gateway and parse the third response message; wherein, the third response message is sent by the slave device gateway based on the active transmission frame when the second target information meets the preset triggering conditions, and the second target information is obtained by the slave device gateway through communication interaction with the slave device corresponding to the second request message.

[0131] After sending the second request message and completing the configuration, the master device continues to receive the third response message sent by the slave device gateway. The third response message, based on an active transmission frame, is sent by the slave device gateway when the second target information meets preset trigger conditions. It reflects the latest status or configuration information of the slave device after receiving the second request message. The master device parses the third response message to confirm whether the slave device configuration has taken effect. It can also obtain the updated device status, group relationship, and address information, thereby achieving dynamic status tracking and closed-loop management of the slave device and ensuring real-time consistency and reliability of the system after configuration changes.

[0132] It should be noted that since the specific implementation processes of S21 and S23 above correspond to S11 and S16 in Embodiment 1, please refer to the description of the above embodiments for detailed implementation processes, which will not be repeated here.

[0133] In some embodiments, the method further includes: parsing the first response message to obtain a second parsing result, and sending a third request message to the slave device gateway when a preset configuration condition is triggered.

[0134] The master device receives the first response message sent by the slave device gateway. This message is sent based on a preset active transmission frame and contains basic information about the slave device system, including: the third device identifier (device SN, device model serial number) of each slave device; the third device address of each slave device (Modbus single device slave address, upper-level device slave address, Modbus slave address for summary information of devices of the same type); and the third group number of each slave device.

[0135] The master device parses the message according to the protocol format: verify the frame header and protocol version number, confirm the message type and version, and obtain the second parsing result, namely, extract the third device identifier, address and group sequence number of each slave device, and store them in the local device information table.

[0136] The master device evaluates the parsed second resolution result. If the second resolution result meets the preset configuration conditions, the master device sends a third request message to the slave device gateway to perform the configuration operation. It can be understood that the core judgment criterion is whether the preset configuration conditions set by the master device according to its own control policy or according to the user request have been triggered. The subsequent sending of the third request message will only be triggered when the preset configuration conditions are triggered.

[0137] When the configuration conditions are met, the master device: converts the message format of the third device identifier, the third device address, and the third group sequence number according to the third protocol version number, and generates a third request message; sends the third request message to the slave device gateway, so that the slave device gateway can perform configuration operations on the corresponding slave device (such as modifying the slave device address, group relationship, etc.).

[0138] This application provides a device information interaction method. By sending a first request message and receiving a first response message sent by a slave device gateway based on an active transmission frame, the master device can obtain basic information of the parallel energy storage system in real time, including the identifier, address, and group relationship of each slave device, thereby accurately grasping the number, status, and logical relationship of the slave devices. After parsing the first response message and obtaining the first parsing result, the master device can determine whether to send a second request message based on configuration conditions to quickly modify the slave device address, group, and other configuration information, thereby ensuring the configuration consistency and management efficiency of the entire slave device system. Subsequently, by receiving and parsing the third response message sent by the slave device gateway, the master device can grasp the latest status of the slave devices after configuration in real time, ensuring that in the parallel energy storage system, the master device can dynamically monitor, manage, and adjust the working status and configuration information of the slave devices. This method, through an active reporting mechanism and message parsing logic, achieves efficient, accurate, and reliable information interaction and system management between the master device and slave devices, not only improving the operational stability and maintainability of the parallel energy storage system, but also significantly enhancing the real-time performance and flexibility of inter-device collaborative work.

[0139] Example 3

[0140] The following describes the device information interaction process of a device information interaction method provided in this application embodiment, using a specific example.

[0141] Please see Figure 6 , Figure 6 This is an interactive schematic diagram of the device information interaction process provided in the embodiments of this application. For example... Figure 6 As shown, assume that the master device 10 in the parallel energy storage system needs to manage three slave devices (22, 23, and 24) under the slave device gateway 21. The master device 10 obtains the status of the slave devices in real time and performs configuration and upgrade operations as needed. The interaction process is as follows:

[0142] (1) Active query by the main equipment:

[0143] The master device 10 sends a first request message to the slave device gateway 21, specifying the protocol version number (e.g., protocol version 1, used for device tree relationship lookup). The first request message is sent using the request message format of a write single holding register message (function code 06H).

[0144] (2) Information returned from the device gateway and entry into monitoring status:

[0145] After receiving the first request message from the device gateway 21, the request is parsed according to the protocol version and a first response message is returned, which includes information such as the identifier, address, group number and status of each slave device under the device gateway (third target information), and the device monitoring state is entered.

[0146] (3) Triggered by device active reporting:

[0147] In device monitoring mode, if the status of a slave device changes, the slave device gateway 21 checks whether the active reporting trigger condition is met. If the trigger condition is met, the slave device gateway 21 sends a second response message to the master device 10 based on the active transmission frame format. The master device 10 parses the second response message to obtain the first parsing result, including which slave devices have changed status.

[0148] (4) The master device issues a configuration command:

[0149] When the preset configuration conditions are triggered (for example, when a user request is received to update the group sequence number or address of the slave device 22), the master device 10 generates a second request message (using protocol version 3 format) and sends it to the slave device gateway 21.

[0150] After receiving the information from device gateway 21, modify the configuration information of the corresponding slave device, such as adjusting the slave address or group relationship of slave device 22.

[0151] (5) Status check and reporting after configuration:

[0152] After completing the configuration from device gateway 21, obtain the configured second target information and determine whether the conditions for active reporting are met.

[0153] If the conditions are met, a third response message is sent to the master device 10 based on the active transmission frame to notify the master device that the configuration has taken effect.

[0154] In this example, when the slave device gateway 21 detects a status change or meets the trigger condition, it proactively reports information using a special transmission frame, reducing the polling pressure on the master device. Configuration and upgrade operations precisely manage the addresses, groups, and statuses of each slave device through different protocol version messages, achieving centralized management. The entire process is compatible with Modbus master-slave communication and does not interfere with existing master-slave interactions.

[0155] Example 4

[0156] This application embodiment also provides a slave device gateway 21, please refer to... Figure 7This diagram illustrates the hardware structure of a slave device gateway 21 capable of executing the methods described in the above embodiments. The slave device gateway 21 includes: at least one processor 210; and a memory 220 communicatively connected to the at least one processor 210. Figure 7 Taking a processor 210 as an example, the memory 220 stores instructions executable by the at least one processor 210. These instructions, when executed by the at least one processor 210, enable the at least one processor 210 to perform the device information interaction method described in the above embodiment. The processor 210 and the memory 220 can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0157] The memory 220, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the device information interaction method in the embodiments of this application. The processor 210 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 220, thereby implementing the device information interaction method described in the above embodiments.

[0158] Memory 220 may include a stored program area and a stored data area, wherein the stored program area may store the operating system and applications required for at least one function; the stored data area may store data created based on the use of the computing device, etc. Furthermore, memory 220 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 220 may optionally include memory remotely located relative to processor 210, and these remote memories may be connected to the computing device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0159] The one or more modules are stored in the memory 220, and when executed by the one or more processors 210, they perform the device information interaction method described in the above embodiments.

[0160] The above-described product can execute the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the methods. Technical details not described in detail in this embodiment can be found in the device information interaction method described in the embodiments of this application.

[0161] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions. These instructions are executed by one or more processors to enable the at least one processor to perform the device information interaction method described in the above embodiments. For example, the non-volatile computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0162] Example 5

[0163] This application also provides a main device 10, please refer to... Figure 8 The diagram illustrates the hardware structure of a master device 10 capable of executing the methods described in the above embodiments. The master device 10 includes: at least one processor 110; and a memory 120 communicatively connected to the at least one processor 110. Figure 8 Taking a processor 110 as an example, the memory 120 stores instructions executable by the at least one processor 110. These instructions, when executed by the at least one processor 110, enable the at least one processor 110 to perform the device information interaction method described in the above embodiment. The processor 110 and the memory 120 can be connected via a bus or other means. Figure 8 Taking the example of a connection between China and Israel via a bus.

[0164] The memory 120, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the device information interaction method in the embodiments of this application. The processor 110 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 120, thereby implementing the device information interaction method described in the above embodiments.

[0165] The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computing device. Furthermore, the memory 120 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the computing device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0166] The one or more modules are stored in the memory 120, and when executed by the one or more processors 110, they perform the device information interaction method described in the above embodiments.

[0167] The above-described product can execute the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the methods. Technical details not described in detail in this embodiment can be found in the device information interaction method described in the embodiments of this application.

[0168] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these 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 this application.

Claims

1. A device information interaction method applied to a slave device gateway, the slave device gateway being in communication connection with a master device and a plurality of slave devices respectively, characterized in that, The method comprises: receiving a first request message sent by the master device, returning a first response message corresponding to a first protocol version number in the first request message to the master device, and entering a device monitoring state; wherein the first response message is sent based on a preset active transmission frame; in the device monitoring state, obtaining first target information corresponding to the slave device; when the first target information meets a preset trigger condition, sending a second response message corresponding to the first target information to the master device based on the active transmission frame, so that the master device analyzes the second response message to obtain a first analysis result, and when a preset configuration condition is triggered, sending a second request message to the slave device gateway; in response to the received second request message, modifying the configuration information of the slave device corresponding to the second request message; obtaining second target information of the slave device corresponding to the second request message; when the second target information meets the preset trigger condition, sending a third response message corresponding to the second target information to the master device based on the active transmission frame, so that the master device analyzes the third response message.

2. The device information interaction method according to claim 1, characterized in that, The receiving of the first request message sent by the master device, the returning of the first response message corresponding to the first protocol version number in the first request message to the master device, and the entering of the device monitoring state comprise: According to the first protocol version number of the first request message, obtaining third target information corresponding to the slave device, the third target information comprising a third device quantity, a third device identification number corresponding to each of the slave devices, a third device state, a third device address, and a third group sequence number; based on the active transmission frame, performing message format conversion on the third device quantity, the third device identification number, the third device state, the third device address, and the third group sequence number to obtain the first response message; sending the first response message to the master device and entering the device monitoring state.

3. The device information interaction method according to claim 2, wherein The first target information comprises a first device quantity, a first device identification number corresponding to each of the slave devices, a first device state, a first device address, and a first group sequence number, When the first target information meets a preset trigger condition, the sending of a second response message corresponding to the first target information to the master device based on the active transmission frame comprises: if the first target information meets at least one of the following conditions: the first device quantity is different from the third device quantity, the first device identification number is different from the third device identification number, the first device state is different from the third device state, the first device address is different from the third device address, and the first group sequence number is different from the third group sequence number, then an update reporting mechanism is triggered; when the update reporting mechanism is triggered, performing the message format conversion on the first device quantity, the first device identification number, the first device state, the first device address, and the first group sequence number based on the active transmission frame to obtain the second response message; sending the second response message to the master device.

4. The device information interaction method according to claim 3, characterized in that, The second target information includes a second device quantity, a second device identification number corresponding to each of the slave devices, a second device state, a second device address, and a second group sequence number, The third response message corresponding to the second target information is sent to the master device based on the active transmission frame when the second target information meets the preset trigger condition, including: If the second target information meets at least one of the following conditions: the first device quantity is different from the second device quantity, the first device identification number is different from the second device identification number, the first device state is different from the second device state, the first device address is different from the second device address, and the first group sequence number is different from the second group sequence number, the update reporting mechanism is triggered; When the update reporting mechanism is triggered, the message format conversion is performed on the second device quantity, the second device identification number, the second device state, the second device address, and the second group sequence number based on the active transmission frame, and the third response message is obtained. The third response message is sent to the master device.

5. The device information interaction method according to claim 1, wherein The method further includes: obtaining fourth target information corresponding to the slave devices, and judging the fourth target information; If the fourth target information meets a preset upgrade condition, a fourth response message corresponding to the fourth target information is sent to the master device based on the active transmission frame and a second protocol version number.

6. A device information interaction method, applied to a master device, wherein the master device is communicatively connected to a slave device gateway, and the slave device gateway is also communicatively connected to multiple slave devices, characterized in that, The method includes: sending a first request message to the slave device gateway, so that the slave device gateway returns a first response message corresponding to a first protocol version number in the first request message to the master device; wherein the first response message is sent based on a preset active transmission frame; receiving a second response message sent by the slave device gateway, and analyzing the second response message to obtain a first analysis result, and sending a second request message to the slave device gateway when a preset configuration condition is triggered, so that the slave device gateway modifies the configuration information of the slave device corresponding to the second request message in response to receiving the second request message; wherein the second response message is sent by the slave device gateway based on the active transmission frame when first target information meets a preset trigger condition, and the first target information is obtained by the slave device gateway in a device monitoring state; receiving a third response message sent by the slave device gateway, and analyzing the third response message; wherein the third response message is sent by the slave device gateway based on the active transmission frame when second target information meets the preset trigger condition, and the second target information is obtained by the slave device gateway through communication interaction with the slave device corresponding to the second request message.

7. The device information interaction method according to claim 6, wherein The receiving of the second response message sent by the slave device gateway and the analysis of the second response message to obtain a first analysis result, and the sending of a second request message to the slave device gateway when a preset configuration condition is triggered, includes: According to the second response message, a first device identifier, a first device address and a first group sequence number corresponding to each of the slave devices are obtained; The first device address and the first group sequence number are judged; If the first device address and the first group sequence number satisfy the preset configuration condition, a message format conversion is performed according to a third protocol version number, the first device identifier, the first device address and the first group sequence number, so as to obtain the second request message; The second request message is sent to the slave device gateway.

8. The device information interaction method according to claim 6, wherein The method further comprises: The first response message is parsed to obtain a second parsing result, and when the preset configuration condition is triggered, a third request message is sent to the slave device gateway.

9. A from-device gateway, comprising: Comprise: At least one processor; And The memory is in communication connection with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method of any one of claims 1-5.

10. A host device, comprising: Comprise: At least one processor; And The memory is in communication connection with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method of any one of claims 6-8.

Images