Intelligent device automatic networking method and system based on bus communication mode

Abstract

The application belongs to the technical field of Internet of Things communication and intelligent device networking, and relates to an automatic networking method of intelligent devices based on a bus communication mode. The method comprises the following steps: obtaining the device identifier and communication configuration parameters of the devices to be networked; establishing a multi-level tree network topology through step-by-step near field communication authentication, and connecting the intelligent sensor devices with the terminal communication devices by using a standard interface; scanning the devices after the network topology is established, and constructing a global device link table; based on the global device link table, searching the buffer through a polling reading mechanism in the data uploading stage, and performing path matching through a downlink routing forwarding mechanism in the data downlink stage; and sending data along the target transmission path and executing a control action. The application shields the differences among different sensor protocols by using a standardized communication interface and a unified protocol, realizes networking and precise addressing by using step-by-step near field communication authentication and a global device link table, and bridges the semantic gap between a large language model and intelligent devices by using a standardized JSON message.

Description

Technical Field

[0001] This invention relates to the field of communications, and in particular to a method and system for automatic networking of intelligent devices based on bus communication. Background Technology

[0002] In recent years, China's semiconductor technology has continued to mature and iterate, chip costs have been decreasing, and IoT and AI technologies have achieved leapfrog development. The intelligence level of various smart devices has also increased significantly, laying a solid foundation for the large-scale application of smart devices. However, current development work in the embedded systems and IoT fields still follows traditional models, with most products adopting an architecture of "single main controller + multiple sensors + communication module." This model has many limitations: on the one hand, the adaptation and debugging of different types of sensors and communication modules is extremely cumbersome, requiring developers to write separate low-level drivers and communication protocol parsing code for each device, greatly extending the product development cycle; on the other hand, the development process needs to consider multiple technical aspects such as low-level hardware adaptation and communication protocol debugging, resulting in a high development threshold and posing a significant obstacle to beginners' entry and learning.

[0003] In the current era of rapid development in artificial intelligence, large language models, with their powerful tool-calling capabilities, can easily connect to various software applications, effectively improving work and R&D efficiency. However, in terms of physical world interaction, such as connecting to and calling smart devices, many technical challenges remain. The core reason is that the market is currently flooded with a wide variety of sensors, with significant differences in communication protocols, electrical characteristics, and physical connection methods between different brands and models, lacking unified standards. For a large language model to connect to a particular sensor, it needs to be deeply adapted to its underlying hardware logic, proprietary communication protocols, and other core aspects. Without manual intervention for debugging, problems such as device connection failures, abnormal data transmission, and command execution deviations are highly likely to occur, severely restricting the collaborative application and deep integration of large language models and smart devices.

[0004] Furthermore, in large-scale intelligent device deployment scenarios, how to efficiently and securely construct network topology and achieve accurate data routing and device location is also a pressing problem to be solved. Traditional networking methods usually rely on manual configuration of network parameters or the use of disordered automatic addressing protocols. In tree-like topologies with a large number of devices and complex hierarchies, this can easily lead to topology chaos and make it difficult to achieve accurate addressing and location during data transmission. Once a low-level device fails or triggers an alarm, the management system struggles to quickly and accurately trace the physical location of the device in the complex network, severely impacting the system's operational efficiency and response speed. Summary of the Invention

[0005] This invention provides an automatic networking method for smart devices based on bus communication, which can solve the problems of inconsistent interfaces and protocols of traditional Internet of Things devices, difficulty in standardizing the connection between large language models and smart devices, and difficulty in addressing large-scale multi-level networks.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution: An automatic networking method for intelligent devices based on bus communication includes the following steps: S1. Obtain the device identification information and communication configuration parameters of the routing devices and terminal communication devices at all levels to be networked, and obtain the set of devices to be networked, wherein the device identification information includes a unique device identifier, and the communication configuration parameters include communication mode and communication handshake parameters; S2. Based on the device identification information and the communication configuration parameters, the set of devices to be networked is accessed through a step-by-step near-field communication authentication method to establish a multi-level tree network topology structure consisting of a primary main routing device, multiple sub-routing devices, and terminal communication devices. The terminal communication devices are connected to the smart sensor devices through a standard communication interface to achieve data interaction. S3. After the multi-level tree network topology is established, perform device scanning, record the hierarchical cascading paths between the smart sensor device, the terminal communication device and the routing devices at each level in sequence, and construct a global device link table containing all access devices; S4. Based on the global device link table, during the data upload phase, data is retrieved from the buffers of each level of device through a polling reading mechanism, and during the data downlink phase, path matching is performed through a downlink routing forwarding mechanism to perform routing addressing and status judgment on the data to be transmitted, so as to obtain the target transmission path and data status result. S5. Based on the target transmission path and the data status result, send the data to be transmitted along the target transmission path to the corresponding target device, and execute the corresponding control action according to the data status result to output the network communication result.

[0007] The basic principle and beneficial effects of this solution are as follows: This solution obtains the device identification information and communication configuration parameters of the device to be networked through steps S1 and S2, and connects the terminal communication device and the smart sensor device through a standard communication interface.

[0008] This solution introduces a standard communication interface between terminal communication devices and smart sensor devices, standardizing and regulating physical connections and electrical characteristics (e.g., using a unified 5-wire serial communication definition, and achieving plug-and-play identification through hardware low-level detection). Simultaneously, at the software protocol layer, a unified command frame format (such as big-endian mode and MODBUS CRC16 checksum) masks the differences in proprietary protocols between different sensor hardware. This mechanism completely eliminates the cumbersome process of writing low-level drivers and adapting interfaces separately for each sensor, a process common in traditional development models. Developers no longer need to concern themselves with the specific electrical characteristics and low-level register configurations of sensors; they only need to achieve data interaction through standard interfaces and unified protocols. This significantly lowers the technical threshold for embedded development and greatly shortens the development and debugging cycle of IoT systems.

[0009] In summary, this invention shields the differences in proprietary protocols among different sensor hardware through standardized communication interfaces and unified protocols. It achieves secure and convenient topology construction and accurate addressing through step-by-step near-field communication authentication and a global device link table. Furthermore, it bridges the semantic gap between large language models and intelligent devices in the physical world through standardized JSON messages. This solves the problems of inconsistent interfaces and protocols in traditional IoT devices, the difficulty in standardized interoperability between large language models and intelligent devices, and the difficulty in addressing large-scale multi-level networks.

[0010] Furthermore, in step S2, the topology access of the set of devices to be networked is performed through a step-by-step near-field communication authentication method, establishing a multi-level tree network topology structure consisting of a primary main routing device, multiple sub-routing devices, and terminal communication devices, including the following: Configure administrator and authorized personnel accounts on the primary router device and enter the corresponding near-field communication authorization identity information; using the operation terminal authenticated by the near-field communication authorization identity information, bring the secondary router device close to the near-field communication sensing area of ​​the primary router device, read the near-field communication tag built into the secondary router device to obtain its unique device identifier and communication configuration parameters, and complete the entry and binding of the secondary router device on the primary router device. Using the same near-field communication authentication and binding method, the next-level routing device is bound to the previous-level routing device in sequence until a routing backbone network with no more than the preset maximum number of layers and no more than the preset maximum number of subordinate devices mounted on each routing device is constructed. Terminal communication devices are entered into the corresponding routing devices through near-field communication authentication, so that each routing device records the routing information of its directly connected subordinate routing devices and terminal communication devices. In the near-field communication process, if the communication method is Ethernet or cellular network communication, the upper-level routing device writes the network IP address and authentication information to the lower-level device through near-field communication, and the lower-level device sends its device unique identifier to the upper-level routing device for storage; if the communication method is serial bus communication, the upper-level routing device and the lower-level device exchange the communication baud rate and device unique identifier through near-field communication.

[0011] Furthermore, the terminal communication device connects to the intelligent sensor device via a standard communication interface, including the following: The standard communication interface adopts a standard 5-wire serial communication interface, which includes a positive power supply pin, a transmit pin, a receive pin, a negative power supply pin, and a connection status pin. In the terminal communication device, the connection status pin is configured to a default pull-up input state, so that the connection status pin maintains a high level signal when no smart sensor device is connected. In the intelligent sensor device, the corresponding connection status pin is connected to a low-level signal; when the intelligent sensor device is inserted into the standard communication interface of the terminal communication device and a valid connection is established, the connection status pin on the terminal communication device side is pulled low by the low-level signal on the intelligent sensor device side, and the terminal communication device determines that an intelligent sensor device has been connected by detecting the change of the level status of the connection status pin from high level to low level. After determining that a smart sensor device has been connected, the terminal communication device establishes a serial communication link with the smart sensor device through the transmit pin and receive pin, and obtains the device name, installation location, working mode and data acquisition parameters configured by the smart sensor device.

[0012] Further, in step S3, the device scan is performed, and the hierarchical cascading paths between the smart sensor device, the terminal communication device, and each level of routing device are recorded sequentially. A global device link table containing all access devices is constructed, including the following: Upon initial power-on, a global device scanning process is initiated, whereby the lowest-level terminal communication device reads the unique device identifier of the connected smart sensor device. The terminal communication device associates its own unique device identifier with the unique device identifier of the connected smart sensor device and uploads it to the directly connected last-level routing device. The last-level routing device records the cascading relationship between the terminal communication device and the smart sensor device. Each level of routing device sequentially uploads its own set of unique device identifiers recorded for its downstream devices to its next-level routing device, until the set is aggregated at the first-level main routing device. For any first-level routing device, a mapping relationship between the unique device identifier and the routing path of all its descendant routing devices, terminal communication devices, and smart sensor devices is recorded. The first-level master routing device summarizes the unique device identifiers and hierarchical cascading paths of all routing devices, terminal communication devices, and smart sensor devices in the entire network to construct the global device link table for accurate addressing during subsequent bidirectional data transmission.

[0013] Furthermore, in step S4, the data retrieval of buffers at all levels of devices through a polling read mechanism during the data upload phase includes the following: The intelligent sensor device collects sensor data according to the configured acquisition cycle, adds the unique identifier of the intelligent sensor device to the sensor data, encapsulates it into a sensor data packet, and sends it to the data buffer of the terminal communication device; each level of routing device sequentially sends polling data reading commands to the next level device directly connected to it; When the next-level device being polled is a terminal communication device, if there are unread sensor data packets in the data buffer of the terminal communication device, the terminal communication device will upload the sensor data packets to the routing device that sent the polling command. If the data buffer is empty, the terminal communication device will return an idle response to the routing device, and the routing device will skip the current terminal communication device and poll the next device. After the routing device obtains the sensor data packets of all its downstream devices, it will package all the obtained data packets and store them in its own routing data buffer, waiting for the polling read command from the next-level routing device. The routing devices at each level will execute the above polling and packaging process step by step from bottom to top, until the first-level main routing device polls and obtains the packaged data of the entire network, and completes the data aggregation.

[0014] Furthermore, in step S4, the path matching performed through the downlink routing and forwarding mechanism during the downlink data phase for routing and status determination of the data to be transmitted includes the following: When a control command needs to be sent from the primary main routing device to the target smart sensor device, the primary main routing device parses the unique identifier of the target device carried in the control command; the primary main routing device searches the global device link table, matches the hierarchical cascading path corresponding to the unique identifier of the target device, determines the next-hop secondary routing device, and forwards the control command to the secondary routing device; Upon receiving the control command, the secondary routing device determines the corresponding sub-routing device or terminal communication device at the next level based on its stored routing path mapping relationship, and continues to forward the control command downwards. The control command is forwarded level by level downwards along the hierarchical cascade path between routing devices until it reaches the terminal communication device directly connected to the target intelligent sensor device. The terminal communication device parses the control command and sends it to the target intelligent sensor device through a standard communication interface. The target intelligent sensor device then executes the corresponding control action and reports the execution result up the original path to the primary main routing device.

[0015] Furthermore, the data interaction between the intelligent sensor device and the terminal communication device adopts a unified command frame format, including the following: All multi-byte data in the command frame format is transmitted in big-endian mode, and the entire frame data is checked using MODBUS CRC16 for error control. The structure of the command frame includes, in sequence: a fixed 2-byte start frame 0xAA55, a 1-byte command type, a 2-byte data length, n bytes of data content, and a 2-byte CRC checksum; The structure of the return command frame includes, in sequence: a fixed 2-byte return start frame 0x55AA, a 1-byte command type, a 2-byte data length, n bytes of data content, and a 2-byte CRC checksum; The command types include general commands and special commands; The general commands include device version number query command 0x01, unique device number query command 0x02, get working mode command 0x03, set working mode command 0x04, device sensor introduction command 0x05, device sensor interface introduction command 0x06, device sensor data structure query command 0x07, device soft reset command 0x0A, device factory reset command 0x0B, and firmware upgrade command 0x0C; the special commands include MODBUS read data interface command 0xF1, MODBUS write data interface command 0xF2, and large language model communication interface command 0xF3.

[0016] Furthermore, the intelligent sensor device supports multiple operating modes, including an automated acquisition mode, a MODBUS mode, and a large language model invocation mode. In the automated acquisition mode, the main controller of the intelligent sensor device reads configuration parameters from its internal flash memory. The configuration parameters include a 1-byte low-power mode identifier, a 1-byte number of sensor data, and n sets of sensor data configuration parameters. Each set of sensor data configuration parameters includes a 1-byte parameter sequence number and a 4-byte acquisition cycle. The low-power mode identifier corresponds to the following operating modes: normal mode 0x00, sleep mode 0x01, stop mode 0x02, and standby mode 0x03. In normal mode, the main controller and peripherals of the smart sensor device are continuously powered. In sleep mode, the main controller turns off the CPU clock, maintains power supply to the analog-to-digital converter, timer, and serial port peripherals, and retains the random access memory and register data. It can be woken up in microseconds by interrupt or external signal. In the stop mode, the main controller shuts down the system's high-speed clock and peripheral power supply, maintaining only the low-speed real-time clock and retaining the random access memory and register data. It is woken up in milliseconds via a real-time clock timer alarm or an external interrupt. In the standby mode, except for the real-time clock and backup register which are powered independently, the power supply to the main controller, peripherals, and memory is cut off. It is woken up by a dedicated wake-up pin or a real-time clock timer alarm.

[0017] Furthermore, when the intelligent sensor device operates in automated acquisition mode and is configured in low-power mode, the workflow includes: Step 1: System initialization, complete the initialization configuration of the basic clock and peripherals; Step 2: Read the operating mode from the flash memory to determine if it is configured as a low-power mode. If it is configured as a low-power mode, proceed to Step 3; otherwise, proceed to Step 4. Step 3: Determine whether it is configured to standby mode. If it is configured to standby mode, read the 4-byte timestamp saved when the last data was collected from the backup register as the timing reference data, and execute Step 4. If it is another low-power mode, execute Step 4 directly. Step 4: Iterate through and load the timing data of each sensor in sequence; Step 5: Calculate the difference between the current timestamp of the system's real-time clock module and the 4-byte timestamp of the last acquisition to determine whether the set acquisition period has been reached. If it has, acquire the corresponding sensor data and update the last acquisition timestamp, then proceed to Step 6; otherwise, return to Step 4. Step 6: Determine whether all sensor data that meet the current timing requirements have been collected. If yes, proceed to Step 7; otherwise, return to Step 4. Step 7: Send the collected sensor data to the terminal communication device through the standard communication interface, and determine whether it is currently configured in low power mode. If it is configured in low power mode, proceed to step 8; otherwise, return to step 4. Step 8: If configured for standby mode, the current timing reference data is written to the backup register, and then the control system enters the corresponding low-power mode to hibernate, waiting for the next wake-up signal. When the intelligent sensor device is running in the large language model invocation mode, the intelligent sensor device and the large language model interact through standardized JSON messages. The interaction process includes: The large language model sends downlink messages to the target intelligent sensor device through the primary routing device, multi-level sub-routing devices and terminal communication devices. The downlink messages include: a query intelligent sensor capability message for actively acquiring sensor hardware parameters, acquisition capabilities and execution control capabilities, which includes a command type field, a target device unique identifier field and an 8-byte millisecond-level timestamp field. The smart sensor data message is used to acquire specified monitoring parameters on demand. It includes a command type field, a target device unique identifier field, a timestamp field, and a set of physical quantity names to be read field. The system also includes a smart sensor control write message for issuing control commands, which contains a command type field, a target device unique identifier field, a timestamp field, a low-power mode and sampling frequency configuration parameter field, and an actuator control array field containing the actuator name and action command. After receiving and parsing the downlink message, the target smart sensor device returns a corresponding uplink message to the large language model. The uplink message includes: a sensor capability return message containing a sensor function overview, basic information, data acquisition capabilities, and device control capabilities; a data read reply message containing real-time values, current operating mode, fault status, and actuator status; and a control write reply message containing command execution description information, updated operating mode and sampling parameters, and updated actuator status. Attached Figure Description

[0018] Figure 1 This is an overall flowchart of an embodiment of an automatic networking method for intelligent devices based on bus communication. Figure 2 This is a flowchart illustrating the construction of a network topology based on a step-by-step near-field communication (NFC) authentication method in an embodiment of an automatic networking method for smart devices based on bus communication. Figure 3 This is a schematic diagram of the data communication frame format between an intelligent sensor device and a terminal communication device in an embodiment of an automatic networking method for intelligent devices based on bus communication. Figure 4 This is a low-power workflow diagram of an intelligent sensor device in an automated data acquisition mode, as described in an embodiment of an automatic networking method for intelligent devices based on bus communication. Detailed Implementation

[0019] The following detailed description illustrates the specific implementation method: An automatic networking method for intelligent devices based on bus communication. For example... Figure 1 As shown, the method includes the following steps: S1. Obtain the device identification information and communication configuration parameters of the routing devices and terminal communication devices at all levels to be networked, and obtain the set of devices to be networked. The device identification information includes a unique device identifier, and the communication configuration parameters include communication mode and communication handshake parameters.

[0020] In specific implementation, the device's unique identifier is a globally unique 128-bit UUID (Universally Unique Identifier), used to uniquely identify the device within the network. The communication method refers to the physical medium and protocol type used between devices, including but not limited to Wi-Fi, Zigbee, LoRa, 4G, Narrowband Internet of Things (NB-IoT), 5G, Ethernet, RS-485 bus, RS-232 serial bus, and CAN bus. The communication handshake parameters refer to the configuration parameters required to establish a stable connection. For example, in Ethernet or cellular network communication, handshake parameters include the network IP address, subnet mask, gateway address, and authentication token; in RS-485, RS-232, or CAN bus communication, handshake parameters include the communication baud rate (e.g., 9600bps, 115200bps), data bits, stop bits, and parity bits.

[0021] S2. Based on the device identification information and the communication configuration parameters, the set of devices to be networked is accessed through a step-by-step near-field communication authentication method, establishing a multi-level tree network topology consisting of a primary router, multiple sub-routers, and terminal communication devices. The terminal communication devices connect to the smart sensor devices via standard communication interfaces to achieve data interaction. In this embodiment, the multi-level tree network topology supports a maximum of five layers. Each router can connect to a maximum of 256 terminal communication devices or sub-routers. Each terminal communication device can only connect to one smart sensor device.

[0022] Specifically, such as Figure 2As shown, the steps for constructing a network topology using tiered Near Field Communication (NFC) authentication are as follows: **Main Router Initialization:** First, select a device as the primary main router. Configure the basic information of the main router using the corresponding host computer, including setting administrator and authorized personnel accounts, and entering the NFC card information of authorized personnel into the main router's database, completing the initialization of NFC authorization identity information. **Secondary Router Entry:** Power on the primary main router. The operator logs in using the administrator account or authenticates by swiping an authorized NFC card to access the main router's "Device Network Management Interface." The secondary router to be connected is brought close to the NFC reading area of ​​the primary main router. The primary main router reads the device information (including UUID, communication method, and communication parameters) recorded in the secondary router's built-in NFC tag. **Parameter Distribution and Binding:** The main router automatically distributes the corresponding network configuration based on the read communication method. If the secondary router communicates with the primary router via Ethernet, Wi-Fi, or cellular network (4G / 5G / NB-IoT), the primary router will assign it a static IP address (such as 192.168.1.10) and authentication key, and write them into the secondary router's memory via NFC; at the same time, the secondary router will send its UUID and store it in the primary router's mounted device database.

[0023] If RS-485 bus communication is used, both parties confirm the communication baud rate of 115200bps via NFC and assign a unique bus slave address (e.g., 0x02) to the secondary router. Building down level by level: Using the same NFC authentication and binding method described above, the operator, holding an authorized terminal, sequentially binds the tertiary router to the corresponding secondary router, then binds the quaternary router to the tertiary router, and so on, until a routing backbone network meeting the actual scenario requirements and with no more than five layers is constructed. Terminal device access: After the deployment of routing devices at each level is completed, terminal communication devices are attached to the corresponding routing devices according to the needs of the on-site sensor distribution.

[0024] Similarly, NFC authentication is used to input the UUID and communication parameters of the terminal communication device into its directly connected routing device. At this time, each routing device records the routing information of its directly connected next-level sub-routing device and the terminal communication device in its local non-volatile memory (Flash). Sensor physical connection: The smart sensor device is inserted into the terminal communication device through a standard communication interface. In this embodiment, the standard communication interface uses a standard 5-wire serial communication interface, with pins defined as: VCC (positive power supply), TX (data transmission), RX (data reception), GND (negative power supply), and STA (connection status pin). Hardware connection detection mechanism: The STA pin on the terminal communication device side is internally pulled up to a high level through a resistor, and its default state is high. The STA pin on the smart sensor device side is internally grounded (GND, i.e., low level).

[0025] When the smart sensor device is plugged into the terminal communication device, the STA pin makes physical contact, and the STA pin level on the terminal communication device side is pulled low. The main controller of the terminal communication device periodically detects the level status of the STA pin through the GPIO port. Once a change from high to low is detected, it determines that a smart sensor device has been connected and supplies power to it. Parameter configuration: After the smart sensor device is connected, the operator can configure the basic information of the sensor through the display screen on the terminal communication device or the matching NFC configuration terminal, including the installation location (e.g., "Room 201, 2nd Floor, Building 3"), device name (e.g., "Living Room Smoke Sensor"), operating mode (e.g., "Automatic Acquisition Mode"), and data acquisition parameters.

[0026] S3. After the multi-level tree network topology is established, a device scan is performed to sequentially record the hierarchical cascading paths between the smart sensor device, the terminal communication device, and the routing devices at each level, and to construct a global device link table containing all access devices.

[0027] After the network topology is built and the system is powered on for the first time, the primary router initiates a global device scan process to build a global device link table. The specific steps are as follows: The lowest-level terminal communication device sends a device information query command to the connected smart sensor device via a standard 5-wire serial port to obtain the smart sensor device's UUID. The terminal communication device associates its own UUID with the obtained smart sensor device's UUID, forming a "terminal-sensor" node pair, and uploads it to the directly connected last-level router. The last-level router concatenates the received node pair information with its own UUID to form a cascaded path segment (e.g., [last-level router UUID] -> [terminal UUID] -> [sensor UUID]), and uploads it to the next-level router. Routers at each level forward and accumulate cascaded path information sequentially from bottom to top. Each router establishes and updates a local routing table, recording the topology relationships of all its descendant nodes. Finally, all path information is aggregated at the primary router. The primary routing device integrates the cascading relationships of all routing devices, terminal communication devices, and smart sensor devices across the entire network to construct a global device link table. For example, for a smoke sensor deployed in Room 201, 2nd Floor, Building 3 of the residential complex, its record format in the global device link table is: [Sensor UUID] Location: 3-2-201 Link Path: A_0 (Primary) -> B_3 (Secondary, Building 3) -> C_2 (Thirdary, 2nd Floor) -> Terminal_201 -> Sensor. This global device link table is stored in the non-volatile memory of the primary routing device and serves as the sole basis for bidirectional data transmission addressing.

[0028] S4. Based on the global device link table, during the data upload phase, data is retrieved from the buffers of each level of device through a polling read mechanism, and during the data downlink phase, path matching is performed through a downlink routing forwarding mechanism to perform routing addressing and status judgment on the data to be transmitted, so as to obtain the target transmission path and data status results.

[0029] In this embodiment, step S4 specifically includes a data upload polling mechanism and a data downlink forwarding mechanism: Data Upload Polling Mechanism: When the intelligent sensor device is working, it collects environmental data according to the configured acquisition cycle (e.g., once per second), adds its own UUID to the data, encapsulates it into sensor data packets in a unified command frame format, and sends them to the terminal communication device via serial port. The terminal communication device temporarily stores the received data packets in its local data buffer. Each level of routing device adopts a timed polling mechanism. Taking the third-level routing device as an example, it sequentially sends data read commands to all its downstream terminal communication devices. If the polled terminal communication device has unread data packets in its buffer, it immediately uploads the data packets to the third-level routing device and clears its local buffer; if there is no data, it returns an idle response (e.g., 0x00). After receiving the idle response, the routing device immediately skips the current terminal and polls the next terminal. After the third-level routing device collects data from all downstream terminals, it packages these data packets into a large packet and stores it in its own data buffer. The second-level routing device polls the third-level routing device in the same way, and the first-level main routing device polls the second-level routing devices, ultimately achieving bottom-up orderly aggregation of network data.

[0030] Downlink data forwarding mechanism: When the primary router needs to send a control command to a specific smart sensor device (e.g., target UUID S_99), the primary router parses the command and retrieves S_99 from the global device link table. It matches the corresponding complete path: A_0 -> B_1 -> C_3 -> Terminal_5 -> S_99. The primary router encapsulates the control command and specifies the next-hop target as secondary router B_1, then sends it to the bus. Upon receiving the command, B_1 parses it to determine the final target as S_99 and checks its local routing table to find that it should be forwarded to tertiary router C_3. The command is forwarded precisely down the hierarchy, ultimately delivered to the smart sensor S_99 for execution by Terminal_5 via a standard serial port.

[0031] S5. Based on the target transmission path and the data status result, send the data to be transmitted along the target transmission path to the corresponding target device, and execute the corresponding control action according to the data status result to output the network communication result.

[0032] Based on the path and data status determined in step S4, data is transmitted bidirectionally within the tree network. Uplink: Data packets aggregated to the primary router are parsed, extracting real-time physical quantities (such as temperature, humidity, and smoke concentration) and device status (such as no fault, disconnection fault, and over-range anomaly) from each sensor. The primary router outputs this data to the monitoring screen or pushes it to the cloud server to complete the status assessment. Downlink: After receiving the control command, the target intelligent sensor device's main controller parses the command content, drives the associated actuators (such as relays, motors, and buzzers) to perform corresponding actions (such as activating the alarm or shutting off the valve), and returns the execution status (such as "buzzer alarm activated") along the original path to the primary router, outputting the network communication result.

[0033] In yet another embodiment, the data interaction specification between the intelligent sensor device and the terminal communication device is as follows: Figure 3 As shown, both parties use a unified command frame format for half-duplex asynchronous serial communication: Data format: All multi-byte data (such as data length, CRC check code, sensor readings) are transmitted in big-endian mode, that is, the high byte first and the low byte last.

[0034] Verification method: The MODBUS CRC16 checksum algorithm is used. The checksum occupies 2 bytes and is calculated from all data bytes after the start frame and before the checksum.

[0035] Command frame structure (sent from terminal communication device or routing device to smart sensor device): Byte offset Field Name Length (bytes) Fixed value / explanation 0 ~ 1 Send start frame 2 Fixed at 0xAA55 2 Command type 1 See command definitions below. 3 ~ 4 Data length 2 Number of bytes in subsequent data fields 5 ~ (4+n) Data content n Specific command parameters (5+n) ~ (6+n) CRC check code 2 2-byte CRC16 value Return command frame structure (replied back to the sender by the smart sensor device): Byte offset Field Name Length (bytes) Fixed value / explanation 0 ~ 1 Return to the starting frame 2 Fixed at 0x55AA 2 Command type 1 Consistent with the command type of the sent frame 3 ~ 4 Data length 2 Number of bytes in subsequent data fields 5 ~ (4+n) Data content n The specific data or status value returned (5+n) ~ (6+n) CRC check code 2 2-byte CRC16 value Command type definition: 1. General commands (can be sent in any mode, with consistent return format): 0x01: Device version number query. Send: 0xAA55 01 0000 E115 (no parameters, data length is 0). Return: 0x55AA 01 0004 00000001 6463 (data length is 4 bytes, indicating firmware version number is v0.0.0.1).

[0036] 0x02: Unique Device ID (UUID) lookup. Send: 0xAA55 02 0000 A515. Return: 0x55AA 020010 12345678ABCDEF12345678ABCDEF12 7160 (Returns a 16-byte UUID).

[0037] 0x03: Get working mode. Send: 0xAA55 03 0000 5914. Return: 0x55AA 03 [data length][mode byte] [configuration parameters] [CRC] (mode byte: 0x01 automated acquisition, 0x02 MODBUS, 0x03 large model call).

[0038] 0x04: Set operating mode. Send: 0xAA55 04 0006 01 00 01 01 0000EA60 [CRC] (Sets the operating mode to automatic acquisition, normal power consumption, 1 sensor, serial number 01, period 60000ms). Return: 0x55AA 040001 01 66D5 (A return of 0x01 indicates successful setting, 0x00 indicates failure).

[0039] 0x05: Device sensor introduction. Send: 0xAA55 05 0001 01 81D4 (Parameter 0x01 indicates local mode, 0x02 indicates web page mode). Return: In local mode, returns a UTF-8 encoded Chinese text introduction of the sensor; in web page mode, returns the URL string of the introduction web page.

[0040] 0x06: Device sensor interface introduction. Send: 0xAA55 06 0000 9514. Return: Returns a URL containing all function interface descriptions in UTF-8 encoding.

[0041] 0x07: Device sensor data structure query. Send: 0xAA55 07 0000 6915. Return: Returns the sensor data structure. For example, for an electrical parameter sensor containing 5 parameters: voltage, current, power, power factor, and power consumption, the return value is: 0x05 0x02 0x02 0x04 0x01 0x04, indicating that the total number of parameters is 5, and each parameter occupies 2, 2, 4, 1, and 4 bytes respectively.

[0042] 0x0A: Device soft reset. Sending 0xAA55 0A 0000 C517 and receiving 0x55AA 0A 0001 01 95D7 indicates a successful reset.

[0043] 0x0B: Device has been restored to factory settings. Sending 0xAA55 0B 0000 3916 and receiving 0x55AA 0B 0001 0169D6 indicates success.

[0044] 0x0C: Firmware upgrade. Sending 0xAA55 0C 0000 4D17 and receiving 0x55AA 0C 0001 01 06D7 indicates that the device has entered Bootloader upgrade mode.

[0045] 2. Dedicated commands (perform specific data interactions based on the working mode): 0xF1: MODBUS data read interface. Send: 0xAA55 F1 0002 01 03 8B80 (Reads parameters with sequence numbers 0x01 and 0x03, such as voltage and power). Return: 0x55AA F1 0006 00E8 00000934 8F38 (Returns 6 bytes of data; the first 2 bytes 0x00E8 represent a voltage of 232V, and the last 4 bytes 0x00000934 represent a power of 2356W).

[0046] 0xF2: MODBUS write data interface. Send: 0xAA55 F2 0008 01 02 0BB8 00000078 1905 (Writes 2 bytes to sequence number 0x01 at a speed of 3000 r / min, writes 4 bytes to sequence number 0x02 at an angle of 120°). Return: 0x55AA F20001 01 EEE6 (Returning 0x01 indicates successful write).

[0047] 0xF3: Large Language Model Communication Interface. Send: 0xAA55 F3 [Data Length] [ASCII Code of JSON String] [CRC]. Return: 0x55AA F3 [Data Length] 01 [ASCII Code of JSON Reply Content] [CRC] (Status byte 0x01 indicates successful transmission and parsing).

[0048] In another implementation, the smart sensor device operates with a low-power mechanism in automated data acquisition mode.

[0049] In automated acquisition mode, the main controller of the smart sensor device reads configuration parameters from its internal Flash memory. The format of the configuration parameters is: [1-byte low-power mode identifier] + [1-byte number of sensor data] + n sets * [1-byte parameter sequence number + 4-byte acquisition period].

[0050] Low power mode definition: Normal mode (0x00): The main controller and all sensor peripherals are continuously powered, and the CPU runs at full speed. It is suitable for scenarios with extremely high real-time requirements and no power consumption limitations.

[0051] Sleep Mode (0x01): Only the CPU core clock is turned off, but power is maintained to peripherals such as the ADC, timers, and serial ports. RAM and register data are fully preserved. Power consumption is reduced to the milliampere level, and the program can be quickly woken up within microseconds by any external interrupt or serial port receive interrupt. After waking up, the program resumes execution from where it was paused.

[0052] Stop Mode (0x02): Power off high-speed system clocks (such as HSE / HSI) and most peripherals, maintaining only a low-speed external clock (such as LSE) to drive the real-time clock (RTC) module. RAM and register data are fully preserved. Power consumption is reduced to the microampere level. It can be woken up by an RTC timer alarm interrupt or an external GPIO interrupt, with a millisecond delay before waking up.

[0053] Standby Mode (0x03): Except for the RTC clock module and backup registers, which are powered by an independent backup power supply, the power supply to the main controller core, all peripherals, and internal SRAM is cut off. All running data in RAM is lost. Power consumption is reduced to the nanoampere level, and the system can only be woken up by the rising edge signal on the dedicated wake-up pin (WKUP) or by the RTC timer alarm. Upon waking up, the system is equivalent to a power-on reset, and the program executes from the beginning.

[0054] Detailed workflow of automated data acquisition mode: such as Figure 4 As shown, the automated data collection process involves the following steps: Step 1: Power on the system. The main controller performs system initialization and configures the basic system clock, GPIO pins and peripheral interfaces.

[0055] Step 2: The main controller reads the saved operating mode and configuration parameters from a specified sector of the internal Flash memory and determines whether the low-power mode flag is greater than 0x00. If it is in low-power mode, proceed to step 3; otherwise, proceed directly to step 4.

[0056] Step 3: Determine if it is in standby mode (0x03). If so, since waking up from standby will cause RAM data loss, the main controller reads the 4-byte timestamp saved during the last data acquisition from the backup register (such as the RTC_BKP_DR register of STM32) as timing reference data, and then executes step 4; if it is in sleep mode or stop mode, since the RAM data is not lost, step 4 is executed directly.

[0057] Step 4: The main controller loads the timing of each sensor data in the configuration parameters and initializes the traversal pointer.

[0058] Step 5: The main controller reads the real-time timestamp of the current RTC module and calculates the difference between it and the timestamp of the last acquisition by the sensor on that channel. It then determines whether the difference is greater than or equal to the configured acquisition period. If the condition is met, the corresponding sensor is started to acquire data, the timestamp of the last acquisition by that sensor is updated, and step 6 is executed; if the acquisition time has not been reached, the process continues to iterate through the next sensor and returns to step 4.

[0059] Step 6: Determine if all sensor data that meets the timing requirements has been traversed and collected. If yes, proceed to Step 7; otherwise, return to Step 4 to continue traversing.

[0060] Step 7: The main controller packages the collected sensor data into a unified command frame format and sends it to the data buffer of the terminal communication device via a standard 5-wire serial port. It then determines whether the device is currently configured for low-power mode. If it is, proceed to step 8; otherwise, clear the temporary variables and return to step 4 to wait for the next acquisition cycle.

[0061] Step 8: If configured for standby mode (0x03), the main controller writes the latest timing reference data (the timestamp of the next data collection from each sensor) into the backup register to prevent data loss in case of power failure. Then, a standby instruction is written to the power control register, and the system cuts off the main power supply and enters standby sleep mode, waiting for the RTC alarm to wake it up. If configured for sleep or stop mode, the corresponding low-power instruction (such as __WFI()) is directly called, and the system enters the corresponding sleep state, waiting for a timer interrupt to wake it up.

[0062] In another embodiment, the working mechanism of the smart sensor device in the Large Language Model (LLM) invocation mode will be described in detail. In this mode, the Large Language Model interacts with the smart sensor device through a tree network using standardized JSON messages.

[0063] Downlink message protocol format (large model distributed): Query Smart Sensor Capability Message (Static Query): Used when a large model is first connected or the device is restarted to obtain the sensor's hardware parameters, data acquisition items, and control capabilities. The message includes a command type field (such as "capability_query"), a target device unique identifier field, and an 8-byte millisecond-level timestamp field.

[0064] Read smart sensor data messages (dynamic reading): Used for large models to actively acquire specified real-time monitored physical quantities. The message includes a command type field (e.g., "data_read"), a target device unique identifier field, a timestamp field, and a set of names of the physical quantities to be read field.

[0065] Intelligent sensor control write message (control dispatch): This is used by large models to autonomously adjust device parameters or drive actuators based on analysis results. The message includes a command type field (such as "control_write"), a target device unique identifier field, a timestamp field, low-power mode and sampling frequency configuration parameter fields, and an actuator control array field containing the actuator name and action instructions.

[0066] Uplink message protocol format (sensor response): Sensor capability response message: Includes a brief introduction to sensor functions, basic information, data acquisition capabilities, and device control capabilities, consisting of a command type field (such as "capability_response"), a target device unique identifier field, a timestamp field, and a capability description field.

[0067] Data read response message: contains real-time values, current operating mode, fault status and actuator status, and consists of command type field (such as "data_response"), target device unique identifier field, timestamp field, operating mode field, fault status field and sensor reading field.

[0068] Control write response message: contains instruction execution description information, updated operating mode and sampling parameters, updated actuator status, and consists of command type field (such as "control_ack"), target device unique identifier field, timestamp field, execution result description field, current operating mode and sampling parameter field, and updated actuator status field.

[0069] The specific interaction process under the large model invocation mode: In actual deployments, the large language model is deployed on a cloud server or a local high-performance computing unit. When the large language model needs to interact with the intelligent sensor devices on site, the interaction process is as follows: the large language model generates a downlink JSON message in the above format and sends it to the primary router device through the API interface.

[0070] After receiving the JSON message, the primary router parses the target device's UUID and retrieves the device from the global device link table. Once a matching transmission path is found, the primary router encapsulates the JSON message as data within a large-model-specific command frame 0xF3 (i.e., 0xAA55 + 0xF3 + data length + JSON string ASCII code + CRC16 checksum). This command frame is forwarded down the matched transmission path, eventually reaching the terminal communication device directly connected to the target smart sensor device. The terminal communication device then sends the command frame to the smart sensor device via a standard 5-wire serial port.

[0071] After receiving the command frame, the main controller of the smart sensor device first performs a CRC16 check. If the check passes, the command type is determined to be 0xF3. The JSON string is then extracted and parsed. The smart sensor device executes the corresponding operation based on the command type field in the JSON message (such as reading the ADC pin to calculate temperature and humidity, or controlling the GPIO pin to drive a buzzer relay).

[0072] After execution, the smart sensor device generates a corresponding uplink JSON message and encapsulates it into a dedicated large-model return frame (i.e., 0x55AA + 0xF3 + data length + 0x01 + ASCII code of JSON reply content + CRC16 checksum), and sends it to the terminal communication device via serial port. The terminal communication device and routing devices at each level then report this return frame up the original path to the primary routing device.

[0073] The primary router removes the frame header and trailer, extracts the uplink JSON message, and returns it to the large language model via API. The large language model then uses the returned JSON message to perform further reasoning and decision-making.

[0074] In practical use: The overall network topology based on bus communication includes terminal devices and routing devices. Each routing device at each level connects to multiple sub-routing devices or terminal communication devices, ultimately forming a tree structure. This network topology supports up to five layers, and each routing device can connect to up to 256 terminal communication devices or sub-routing devices. Each terminal communication device can only connect to one smart sensor device. The routing devices at each level have the same function, performing only data recording and data forwarding.

[0075] In the tree-like topology of intelligent terminals, the core devices include three categories: terminal communication devices, intelligent sensor devices, and routing devices. Each type of device performs its own function and works together to ensure the stability of bus communication and the efficiency of data interaction. The specific components and functions are as follows: Terminal communication devices and sensor devices together constitute the terminal sensing and execution unit of the topology. They work collaboratively to complete the core tasks of data acquisition, command reception, and execution. Specifically, the terminal communication device acts as a bridge for data interaction, enabling data communication between the routing device and the intelligent sensor device. The intelligent sensor device, integrating different types of sensors or execution devices, is the core carrier for data acquisition and action execution. After collecting environmental data, the sensors send the data to the upper-layer routing device through the terminal communication device. Simultaneously, it receives control messages from the routing device and forwards them to the intelligent sensor device via the terminal communication device, thereby executing corresponding actions or commands to achieve environmental monitoring and intelligent control of the equipment.

[0076] Intelligent sensor devices form the foundation for sensing and execution in intelligent networking. They primarily consist of five parts: a main controller, sensors, indicator lights, a communication interface, and a reset button. The structure is simple and highly adaptable. The main controller controls the sensor's data acquisition, receives control commands forwarded from terminal communication devices, drives the execution devices to complete corresponding actions, and performs preliminary data processing to ensure data validity. Indicator lights display the operating status of the intelligent sensor devices, such as normal acquisition, execution in progress, or fault, facilitating troubleshooting. The communication interface matches the standard interface of the terminal communication devices, enabling rapid connection and ensuring efficient data and command transmission. This device can integrate sensing sensors such as temperature and humidity sensors, light sensors, and infrared human body sensors, or execution devices such as intelligent switches, motors, and alarms, depending on the application scenario, meeting the monitoring and control needs of different scenarios. Here, "sensor / execution device" does not refer to a single sensor; a single intelligent sensor device can integrate multiple types of sensors, such as temperature, humidity, voltage, and current sensors.

[0077] The communication interface adopts a standard 5-wire serial communication method (i.e., VCC - TX - RX - GND - STA, corresponding to the positive power supply, transmit pin, receive pin, negative power supply, and connection status pin, respectively). The connection status pin is used to detect whether the smart sensor device is connected. It is implemented by the terminal communication device using a pull-up input (high level) by default, while the smart sensor's pin is connected to a low level. When the smart sensor is effectively connected to the terminal, the connection status pin of the terminal communication device will go low. Therefore, the presence of a smart sensor can be determined by detecting the state of this pin.

[0078] Sensors: including but not limited to temperature and humidity sensors, light sensors, human infrared sensors and other sensing sensors, or actuation devices such as smart switches, motors, alarms and other actuators.

[0079] Main controller: The main controller contains code for sensor acquisition / control execution devices, controlling the LED operating status, and communicating with external devices.

[0080] Indicator lights: When the equipment is running normally, the Run indicator light flashes once every 1 second; it is always on. When the equipment is in sleep mode, the indicator light flashes once every 180 seconds. When the indicator light is off, it indicates that the equipment is faulty.

[0081] The sensor supports multiple operating modes, including automated data acquisition mode, MODBUS mode, and large language model calling mode. The mode and other parameter settings need to be configured through the accompanying host computer.

[0082] Sensor command frame format (all data is in big-endian mode, MODBUS CRC16 checksum): Send: Start frame (fixed 0xAA55, 2 bytes) + command type (1 byte) + data length (2 bytes) + data (n bytes) + CRC check (2 bytes).

[0083] Return: Start frame (fixed 0x55AA, 2 bytes) + command type (1 byte) + data length (2 bytes) + data (n bytes) + CRC check (2 bytes).

[0084] The command types include general commands and special commands. General commands return the same result regardless of the operating mode. Special commands return different results and send different data formats in different modes. The following are just some commonly used commands. Different commands will be added and adjusted as needed in the future.

[0085] The general commands are as follows: 0x01: Device version number (no parameters); 0x02: Unique device ID (UUID) (no parameters); 0x03: Obtain the working mode; 0x04: Set the operating mode; 0x05: Device sensor description (no parameters); 0x06: Device Sensor Interface Introduction (No Parameters); 0x07: Device sensor data structure (no parameters); 0x0A: Device soft reset (no parameters); 0x0B: Device reset to factory settings (no parameters); 0x0C: Firmware upgrade (no parameters).

[0086] The specific commands are as follows: 0xF1: MODBUS data read interface; 0xF2: MODBUS write data interface; 0xF3: Large language model communication interface.

[0087] Example of using the general command, device version number lookup (0x01): send: start frame Command type Data length data CRC check 0xAA55 0x01 0x0000 0x00 0xE115 return: start frame Command type Data length data CRC check 0x55AA 0x01 0x0004 0x00000001 0x6463 The returned data is 4 bytes long and indicates that the current device version number is v0.0.0.1.

[0088] Example of using the unique device ID (UUID) lookup (0x02): send: start frame Command type Data length data CRC check 0xAA55 0x02 0x0000 0x00 0xA515 return: start frame Command type Data length data CRC check 0x55AA 0x02 0x0010 0x12345678ABCDEF12345678ABCDEF12 0x7160 The returned data is 16 bytes long and indicates that the current device's unique UUID is 0x12345678ABCDEF12345678ABCDEF12.

[0089] Example of using the "Get Working Mode (0x03)" function: send: start frame Command type Data length data CRC check 0xAA55 0x03 0x0000 0x00 0x5914 return: start frame Command type Data length data CRC check 0x55AA 0x03 0xXXXX …… 0xXXXX The returned data length is xxxx, where the first byte is the current working mode. If it is 0x01, it means that the current working mode is automatic acquisition mode (0x01: automatic acquisition mode; 0x02: MODBUS mode; 0x03: large language call mode). The remaining bytes are configuration parameters, which are only present in automatic acquisition mode.

[0090] Example of setting the working mode (0x04): send: start frame Command type Data length Data (1-byte mode + n-byte configuration parameters) CRC check 0xAA55 0x04 0x000X (The modes are: 0x01: Automated data acquisition mode; 0x02: MODBUS mode; 0x03: Large language call mode) 0xXXXX return: start frame Command type Data length data CRC check 0x55AA 0x04 0x0001 0x01 0x66D5 The returned data is 1 in length, and the returned data indicates that the setting was successful (0x01: setting successful; 0x00: setting failed).

[0091] Device sensor introduction (0x05) Usage example: send: start frame Command type Data length data CRC check 0xAA55 0x05 0x0001 0x01 (0x01: Local mode; 0x02: Web page mode;) 0x81D4 return: start frame Command type Data length data CRC check 0x55AA 0x05 0xXXXX …… 0xXXXX The returned data length is XX. In local mode, it returns the Chinese sensor description in UTF-8 encoding; in web mode, it returns the web address of the device sensor description, which can be viewed through the webpage (mainly for some complex smart sensor devices, the FLASH may not be able to store the corresponding description completely).

[0092] (6) Introduction to Device Sensor Interfaces (0x06) Usage Example: send: start frame Command type Data length data CRC check 0xAA55 0x06 0x0000 0x00 0x9514 return: start frame Command type Data length data CRC check 0x55AA 0x05 0xXXXX …… 0xXXXX The returned data has a length of XX, and returns the URLs of all function interfaces in UTF-8 encoding.

[0093] Example of using the device sensor data structure (0x07) send: start frame Command type Data length data CRC check 0xAA55 0x07 0x0000 0x00 0x6915 return: start frame Command type Data length data CRC check 0x55AA 0x07 0xXXXX …… 0xXXXX The returned data length is XX, and it returns the sensor data structure (the returned data structure is not completely consistent for each type of sensor, but its basic format is the number of sensor data + data type. For example, for an electrical parameter sensor with 5 data points [2 bytes of voltage, 2 bytes of current, 4 bytes of power, 1 byte of power factor, and 4 bytes of power consumption], the returned data is 0x05 0x02 0x02 0x04 0x01 0x04, which respectively indicate that there are a total of 5 data points. Each data point variable occupies 2 bytes, 2 bytes, 4 bytes, 1 byte, and 4 bytes respectively. The order of the sensor data variable names can be viewed by parsing the data returned by the "Device Sensor Introduction (0x05)" command).

[0094] Example of using device soft reset (0x0A): send: start frame Command type Data length data CRC check 0xAA55 0x0A 0x0000 0x00 0xC517 return: start frame Command type Data length data CRC check 0x55AA 0x0A 0x0001 0x01 0x95D7 The returned data is 1 unit long, and the returned data indicates that the soft reset was successful (0x01: success; 0x00: failure).

[0095] Example of using the device to restore factory settings (0x0B): send: start frame Command type Data length data CRC check 0xAA55 0x0B 0x0000 0x00 0x3916 return: start frame Command type Data length data CRC check 0x55AA 0x0B 0x0001 0x01 0x69D6 The returned data is 1 unit long and indicates that the device has been restored to factory settings (0x01: success; 0x00: failure).

[0096] Firmware upgrade (0x0C) usage example: send: start frame Command type Data length data CRC check 0xAA55 0x0C 0x0000 0x00 0x4D17 return: start frame Command type Data length data CRC check 0x55AA 0x0C 0x0001 0x01 0x06D7 The returned data is 1 unit long, indicating that the firmware upgrade mode has been successfully entered (0x01: success; 0x00: failure), and the firmware update is about to begin.

[0097] Specialized command, MODBUS data read interface (0xF1) usage example: The following describes a scenario where an electrical parameter sensor contains 2 bytes of voltage (corresponding to serial number 0x01, as per the documentation), 2 bytes of current (corresponding to serial number 0x02), 4 bytes of power (corresponding to serial number 0x03), 1 byte of power factor (corresponding to serial number 0x04), and 4 bytes of power consumption (corresponding to serial number 0x05). If the voltage and power values ​​need to be collected, the content sent would be: start frame Command type Data length data CRC check 0xAA55 0xF1 0x0002 0x01 03 0x8B80 The returned content is n bytes of all corresponding sequence numbers: start frame Command type Data length data CRC check 0x55AA 0xF1 0x00 06 0x00 E8 00 00 09 34 0x8F38 The returned data length is 6 (2 bytes of current + 4 bytes of power), the returned data is voltage 232V (0x00 E8), and the returned power is 2356W (0x00 00 09 34).

[0098] Example of using the MODBUS write data interface (0xF2): The following describes a stepper motor with two parameters: a 2-byte speed (corresponding to serial number 0x01, refer to the documentation) and a 4-byte angle (corresponding to serial number 0x02). To make it rotate 120° (0x00000078) at a speed of 3000 r / min (0x0BB8), the content to be sent is: start frame Command type Data length data CRC check 0xAA55 0xF2 0x0002 0x01 02 0BB8 00000078 (List all the serial numbers first, then the data in sequence) 0x1905 The returned content is n bytes of all corresponding sequence numbers: start frame Command type Data length data CRC check 0x55AA 0xF2 0x00 01 0x01 0xEEE6 The returned data is 1 unit long, and the returned data indicates that the write was successful (0x01: success; 0x00: failure).

[0099] Example of using the large language model communication interface (0xF3): The large language model communication interface is mainly used for data transmission; the actual data parsing is handled internally by the controller. The data represents the JSON data exchanged.

[0100] start frame Command type Data length data CRC check 0xAA55 0xF3 0xXXXX 0xXXXX 0xXXXX The returned content is n bytes of all corresponding sequence numbers: start frame Command type Data length state data CRC check 0x55AA 0xF3 0xXXXX 0x01 0xXXXX 0xXXXX The returned status is 1, indicating that the transmission was successful (0x01: success; 0x00: failure).

[0101] The automated data acquisition mode is mainly for scenarios that require periodic collection of sensor data, such as environmental monitoring (weather temperature, equipment operating status [voltage, current], etc.). These scenarios only require periodic collection of the corresponding data and reporting to the corresponding server.

[0102] The implementation process is as follows: First, connect the communication interface of the intelligent sensor device to the host computer. After the connection, read the operating mode and other parameters into the interface by reading the command (using the command to obtain the working mode (0x03)) so as to perform secondary parameter configuration. When it is necessary to modify the corresponding parameters, complete the corresponding parameter configuration according to the page prompts. The specific configuration parameters are shown below. After completing the parameters, click the save button to write the parameters into the FLASH of the main controller.

[0103] Its configuration parameters include: 1 byte of low-power mode (including normal mode [0x00], sleep mode [0x01], stop mode [0x02], and standby mode [0x03]) + 1 byte of sensor data quantity + n sensor data configuration parameters [1 byte parameter number + 4 bytes acquisition period (in milliseconds)]. For example, an electrical parameter sensor contains 2 bytes of voltage (corresponding to number 0x01, subject to the documentation), 2 bytes of current (corresponding to number 0x02), 4 bytes of power (corresponding to number 0x03), 1 byte of power factor (corresponding to number 0x04), and 4 bytes of power consumption (corresponding to number 0x05). Now, it is necessary to collect voltage, current, and power data, and configure the voltage and current to be collected every 10 minutes, and the power to be collected every minute. The corresponding configuration parameters are 0x00 0x03 0x01 0x00 0x00 0xEA 0x60 0x02 0x00 0x00 0xEA 0x60 0x03 0x000x00 0x17 0x70, where: Low-power mode byte: Select as needed (example defaults to normal mode 0x00) Sensor data quantity: 3 channels of data acquisition, corresponding to byte 0x03 3 sets of sensor acquisition configurations (1-byte parameter number + 4-byte acquisition period, milliseconds) Voltage: Serial number 0x01, 10 minutes = 60000ms → 4-byte cycle 0x0000EA60 Current: Serial number 0x02, 10 minutes = 60000ms → 4-byte cycle 0x0000EA60 Power: Serial number 0x03, 1 minute = 6000ms → 4-byte cycle 0x00001770 Normal mode [0x00]: The device works continuously. For scenarios where power consumption is not sensitive or real-time requirements are extremely high, all data is updated and recorded in real time, and all peripherals are powered on continuously, including the main controller and external sensors.

[0104] Sleep mode [0x01]: Designed for scenarios that are power-sensitive but require fast response, such as short-term waiting for events or low-frequency wake-up, such as button-triggered reporting or instantaneous external signal acquisition; only the CPU clock is turned off, while peripherals such as ADC, timers, and serial ports are kept powered and running, and all data in RAM and registers is retained. Any interrupt or external signal can wake up quickly in microseconds, and after waking up, it can continue running directly from the pause point without re-initializing the device.

[0105] Stop Mode [0x02]: Medium-low power consumption mode, designed for long-term timed acquisition and minute-level periodic reporting scenarios, such as timed monitoring of electrical parameters and polling acquisition of ambient temperature and humidity; it shuts down the high-speed system clock and power supply to most peripherals, with only the low-speed RTC clock running continuously, and RAM and register data are fully preserved; it only supports RTC timed alarm and external interrupt pin wake-up, and after wake-up, it needs to wait for the high-speed clock to stabilize again, resulting in a millisecond-level wake-up delay. The overall power consumption is much lower than sleep mode, making it the preferred mode for battery-powered timed acquisition devices.

[0106] Standby Mode [0x03]: The device's lowest power consumption sleep mode, designed for scenarios with ultra-long interval data collection and long-term unattended operation, such as monthly energy consumption statistics and long-term static monitoring; except for the RTC and backup register which are powered independently, the main controller, all peripherals, and memory power supplies are all cut off, and all RAM and running register data are lost; it can only be woken up by the dedicated WKUP wake-up pin or the RTC timer alarm. Wake-up is equivalent to power-on reset of the device, and the program starts from scratch. Key operating parameters need to be stored in the backup register in advance. The device's sleep power consumption can be as low as microamps / nanoamps, greatly extending battery life.

[0107] The detailed processing flow is as follows: Step 1: After the system initialization is completed, the basic system clock and peripherals are initialized. Proceed to Step 2. Step 2: Read the operating mode from FLASH, and then determine whether it is a low power mode. If it is, proceed to step 3; otherwise, proceed to step 4. Step 3: Determine if it is in standby mode. If so, read the timing data from the backup register, which is the 4-byte timestamp of the last data acquisition. Otherwise, proceed to step 4. Step 4: Load the next sensor data timing time (iterate through all sensor timing times starting from sequence number 0); Step 5: Determine if the data acquisition time has been reached. This is done by comparing the difference between the timestamp of the system's RTC real-time clock module and the 4-byte timestamp of the last data acquisition from the current sensor. If the time is met, acquire the sensor data and update the data acquisition timestamp, then proceed to step 6; otherwise, proceed to step 4. Step 6: Determine whether all sensor data that meet the timing requirements have been collected. If yes, proceed to step 7; otherwise, proceed to step 4. Step 7: Send all collected data to the terminal communication device through the communication interface, and then determine whether the current mode is low power mode. If so, proceed to step 8; otherwise, proceed to step 4. Step 8: Determine if it is in standby mode. If so, write the timing data to the backup register (data in RAM will be lost when entering standby mode and needs to be stored in the backup register), and then enter the corresponding low-power mode to wait for the next wake-up.

[0108] MODBUS mode is used as a general sensor, that is, according to the MODBUS protocol requirements, data acquisition and device control are completed. Its specific format varies depending on the sensor data type. The acquired data format is 1 byte parameter number + n bytes parameter value. For example, taking an electrical parameter sensor as an example, an electrical parameter sensor contains 2 bytes of voltage (corresponding to serial number 0x01, subject to the document description), 2 bytes of current (corresponding to serial number 0x02), 4 bytes of power (corresponding to serial number 0x03), 1 byte of power factor (corresponding to serial number 0x04), and 4 bytes of power consumption (corresponding to serial number 0x05). Now, if voltage, current and power data need to be acquired, it is sent according to the special command (1). If device control is required, it is sent according to the special command 2. In this mode, it can work independently without relying on terminal communication equipment and routers.

[0109] As the core sensing gateway to the physical world, intelligent sensors rely on a standardized bus communication architecture to automatically network multiple types of devices. Data transmission is completed through a unified protocol and JSON-standardized messages, enabling large language models to build a complete application loop of "acquisition - standardized transmission - semantic understanding - intelligent control". Traditional embedded development requires separate adaptation and debugging for different sensors and communication modules, resulting in messy protocols and high development barriers, which seriously restricts the integration of large models with intelligent devices. The calling mode of this solution completely solves this pain point. The large language model does not need to adapt to the underlying hardware logic and private protocols of various devices. It can connect to all networked sensors through a single standardized interface, efficiently completing sensor data parsing, logical reasoning, fault diagnosis, and multi-device linkage control. There is no need to manually preset complex operating rules, which greatly simplifies the embedded development process and shortens the development cycle.

[0110] This significantly improves the compatibility and versatility of large-scale language models with intelligent sensing devices, effectively avoiding problems such as device connection failures, abnormal data transmission, and command execution deviations that occur with traditional docking methods. Relying on a unified bus standardized interaction mechanism, various sensor data can be input into the large language model in a regular and stable manner, ensuring the accuracy and stability of the model's inference results. It also supports intelligent functions such as natural language interaction and autonomous device control, adapting to various IoT embedded scenarios, significantly lowering the entry barrier to embedded technology, and providing an efficient and feasible technical path for the deep integration and large-scale application of large-scale language models and intelligent hardware.

[0111] To meet the needs of different smart sensors, the following standard message format has been designed: Downlink messages: Downlink messages are sent by the large model to the smart sensor through routing devices and communication terminal devices (where routing devices and terminal devices are not necessary; the large model can directly connect to the smart sensor through a serial port or forward the data to the smart sensor through the communication terminal device) in order to obtain the capabilities of the smart sensor, read data, and write data.

[0112] ① Query the JSON template for smart sensor capabilities (static query command); Purpose: This message is sent during the initial handshake of the large model, device restart, and device capability update. It is used to actively acquire the inherent hardware parameters, acquisition capabilities, fault detection, and execution control capabilities of the sensors, complete the cognitive modeling of the device by the large model, and the device returns a complete sensor capability description message.

[0113] ② Read the JSON template of smart sensor data (dynamic reading command); Applications: Large models actively issue data reading commands to acquire specified monitoring parameters from sensors, equipment operating status, fault information, and actuator status as needed. It supports fixed-point reading and batch reading, and is suitable for AI real-time data monitoring and status analysis scenarios.

[0114] ③ Write smart sensor data / control data into a JSON template (and issue control commands); Applications: Based on the analysis results of sensor data, the large model actively sends out control commands to switch equipment operating modes, adjust sampling parameters, control actuator actions, trigger fault alarms, etc., so as to realize the autonomous control of sensors and supporting equipment by the large model.

[0115] Uplink messages: Uplink messages are different data returned by smart sensors based on different instructions sent by the big data model.

[0116] (1) Query Smart Sensor Capability Return Information: When the large model sends a query smart sensor capability command, the smart sensor will reply with the following basic information and the capabilities it can provide.

[0117] (2) Read smart sensor data and reply information: The device returns the corresponding real-time data, operating mode, fault status and actuator status according to the read list. The message is lightweight and adapted to high-frequency interaction.

[0118] (3) Intelligent sensor writes control response information: The large model sends configuration parameters and actuator control commands to realize equipment mode switching, sampling parameter adjustment, alarm and linkage control.

[0119] The following example illustrates the interaction flow: The example device is the SHT30 high-precision temperature and humidity sensor, with a unique device ID of 48FFEA97-CB11-4CDC-8200-722B1409B978. It can achieve high-precision acquisition of both ambient temperature and humidity parameters. The temperature measurement range is -40℃ to 125℃, and the humidity measurement range is 0%RH to 100%RH. The default sampling frequency is 10Hz, and it supports high-speed acquisition up to 50Hz. The device has self-diagnostic capabilities for three types of faults: disconnection detection, data over-range detection, and power supply abnormality detection. It supports four low-power operation modes and is equipped with a buzzer actuator that can receive large-scale commands to activate / deactivate the alarm function. It is suitable for indoor environmental monitoring, smart homes, industrial temperature control, and other scenarios.

[0120] (1) Complete interactive process for querying sensor capabilities Process scenario: The system is powered on and initialized, the large model is connected to the device for the first time, and all static capabilities of the sensors are actively queried to complete the device cognitive modeling, providing parameter benchmarks for subsequent data analysis and control.

[0121] 1) The large model issues a query command JSON; 2) SHT30 sensor response capability data (JSON); Process Description: The large model accurately addresses the device through a unique device ID. After receiving the command, the sensor returns a full set of static capability parameters. Based on this, the large model grasps the core information of the device, such as acquisition accuracy, range, fault detection capability, and controllable actuators, and completes the device adaptation initialization.

[0122] (2) Complete interactive process for reading real-time sensor data Process Scenario: The large model monitors the environmental status in real time, and reads the real-time temperature and humidity data of SHT30, equipment operation mode, fault status and buzzer working status as needed for environmental analysis and status assessment.

[0123] 1) The large model issues a JSON data retrieval command; 2) The SHT30 sensor replies with real-time data in JSON format; Process Description: The large model reads the core parameters of temperature and humidity. The sensors return real-time collected data, equipment operating status and actuator status as needed. The messages are lightweight and efficient, supporting the large model to judge the current environmental status in real time and providing data support for intelligent decision-making.

[0124] (3) Sensor writing control complete interactive process Process Scenario: When the large model detects abnormal ambient temperature and humidity, equipment failure, or triggers early warning conditions, it issues a control command to activate the buzzer alarm, thereby achieving intelligent linkage control of the equipment.

[0125] 1) The large model sends out JSON control commands; 2) The SHT30 sensor returned the execution result in JSON format.

[0126] The terminal communication device is the key link connecting smart sensor devices and routing devices, including a main controller, indicator lights, communication modules, communication interfaces, and a display screen. The main controller, as the core of the terminal communication device, is responsible for coordinating the operation of all components, processing data uploaded by smart sensor devices, parsing instructions issued by the routing device, and ensuring orderly data forwarding. Indicator lights display the device's operating status, such as power on, normal communication, data transmission in progress, and fault alarms, allowing maintenance personnel to quickly assess the device's working condition. The communication module supports standardized bus communication protocols and is responsible for establishing a stable communication connection with the upper-layer routing device, enabling wireless or wired data transmission. The communication interface adopts a unified standard interface design, allowing flexible connection to various smart sensor devices and solving interface compatibility issues between different sensors. NFC tags are used for unique device identification, facilitating router identification, network management, and fault location of the terminal communication device, improving the intelligence and convenience of network setup. The display screen primarily displays device status, location, fault information, and also allows for configuring smart sensor parameters, such as the smart sensor device's name and installation location.

[0127] The routing device is the core of the communication relay in the entire tree-like topology, undertaking the critical responsibilities of data forwarding and network scheduling. It is responsible for forwarding data uploaded by sub-routing devices or terminal communication devices to the next-level routing device, and simultaneously forwarding control data sent by the next-level routing device to the corresponding sub-routing devices or terminal communication devices, achieving bidirectional data transmission and precise command delivery across the entire network. The routing device has a more complex set of components, mainly including a main controller, indicator lights, buttons, a touchscreen, a communication module, a communication interface, and an NFC communication module, with the following functions: The main controller, as the core management unit of the routing device, is responsible for coordinating data forwarding, network management, and device identification. It can automatically allocate communication resources according to preset rules and handle network events such as device access and disconnection, ensuring efficient routing forwarding. Indicator lights display the operating status of the routing device, such as power status, communication connection status, data forwarding status, and network status, providing a clear picture of the device's operation. Buttons are used for manual configuration of device parameters, such as network address, communication protocol, and the number of devices that can be mounted, facilitating on-site debugging and maintenance. The screen displays the device's core parameters, the number of currently mounted devices, data forwarding rate, and network status, enabling visualized monitoring of the device's operating status. The communication module supports standardized bus communication protocols, allowing simultaneous communication connections with upstream routing devices, downstream sub-routers, or terminal communication devices, ensuring stable data forwarding. Multiple communication methods are supported, including but not limited to WIFI, Zigbee, LoRa, 4G, NB-IoT, 5G, Ethernet, RS485, RS232, and CAN. The communication interface adopts a unified standard design, allowing flexible connection to various sub-routers or terminal communication devices to adapt to different networking needs. NFC is also included. The communication module is used to identify the network configuration information of the connected routing devices, enabling rapid identification and network management of terminal communication devices and sub-routers. It can automatically count the number of connected devices and issue an alarm when the number of connected devices approaches the upper limit of 256 to avoid communication failures caused by excessive connection. It can also be used for identity authentication, ensuring that only administrator users have the authority to connect devices.

[0128] To ensure data communication between different smart sensor devices, networking is required first. The implementation method is as follows: First, select a device as the primary router. The device is configured via a host computer, including administrator and authorized user accounts, NFC authorization information, etc. This device serves as the central hub for all data. Then, at least one secondary router is selected as needed. Then power on the main router, authenticate the device using the administrator account or NFC card, and enter the device network management interface. Then connect the secondary router device ( ) respectively close to the primary router ( The device's card reading area completes the secondary routing device ( For device entry, the same method is used to add at least one tertiary routing device to each secondary routing device. The network structure must meet the networking requirements and not exceed five routing layers, with each layer containing no more than 256 devices. Each routing device's NFC tag records the current device's information, including communication methods (including but not limited to WIFI, Zigbee, LoRa, 4G, NB-IoT, 5G, Ethernet, 485, 232, CAN, etc.) and communication parameters (different communication methods require automatic identification; for example, when using 4G, NB-IoT, 5G, or Ethernet, the upstream router transmits the network IP address and authentication information to the downstream router via NFC, while the downstream router sends its unique UUID to the upstream router; both are stored in their respective storage areas. If using 485, 232, or CAN, the communication includes communication speed and device UUID information). Simultaneously, basic device information, including but not limited to installation location and name, is entered on each routing device's interface. This is primarily for operators to quickly identify device locations; the communication process is not discussed in detail here, as it is not the focus of the invention. Then, as needed, connect the corresponding terminal communication devices to each routing device. Terminal communication devices can be mounted on routing devices at different levels. The same NFC authentication method is used to record the terminal communication device information into the corresponding routing device, so that each routing device records the routing information of the sub-routing devices and terminal communication devices mounted at the next level. Next, connect the smart sensors to the terminal communication devices as needed, and configure the corresponding smart sensor configuration information (installation location, device name, working mode, data acquisition parameters, etc.) on the communication terminal devices to facilitate operators in distinguishing different devices, completing the network setup. Finally, deploy these devices to the corresponding sites.

[0129] Before the device is powered on for the first time, a device scan process is performed, which records the link information of each smart sensor. For example, for a smart sensor device under a three-level routing device ( In the third-level routing device ( ) will record The device's UUID, in the secondary routing device ( ) will record and The device's UUID, in the primary routing device ( ) will record and and The device's UUID is used to build a complete device link table, ensuring accurate delivery during data transmission and reception.

[0130] In automatic acquisition mode and large language model working mode, the intelligent sensor device periodically collects corresponding sensor data and adds a device UUID data segment to the data, which is then sent to the data buffer of the communication terminal device. Then, each level of routing sequentially polls the next level device and sends a data read command. When the data buffer of the communication terminal device has data, the data is read into the buffer of the current routing device; otherwise, the current device is skipped. This continues until all devices have completed data reading. Then, all the buffered data is packaged and sent to the next level routing device. All the next level routing devices use the same method to complete the acquisition of data from all devices.

[0131] When data needs to be sent downwards from the primary router, for example through the primary router ( Towards intelligent sensor devices ( It will forward messages to the next level routing device based on the device link table decremented after the initial power-on, until the corresponding device is reached.

[0132] Taking the comprehensive smoke alarm monitoring network of a residential community as a specific application scenario, the three-level tree topology routing architecture of this invention is adopted to realize the comprehensive smoke data collection, abnormal alarm, and accurate device location of the community. The specific network structure and network deployment are as follows.

[0133] The hardware architecture of the scenario is defined as follows: The equipment deployed in the community property center serves as the primary router, responsible for the core functions of data aggregation, alarm command issuance, and network device management; each building in the community corresponds to a secondary router, and all data from devices in a single building are uniformly aggregated to the corresponding secondary router; each floor in the building corresponds to a tertiary router, responsible for the data collection and forwarding of all resident terminal devices on that floor; each resident's indoor unit is equipped with an independent terminal communication device and a smoke sensor, serving as the lowest-level terminal sensing unit in the entire network.

[0134] Specific network deployment scale: The community has a total of 20 buildings, each building has 10 floors, and each floor has 6 resident terminal devices. The overall network strictly follows the design specifications of a single floor with a maximum of 256 devices and a maximum of 5 layers, which fully meets the scenario load requirements.

[0135] Network Setup and Workflow: Following the NFC hierarchical authentication networking method of this invention, the administrator account and NFC authorization information for the primary router device are first configured at the property management center. Then, the secondary router devices in 20 buildings are sequentially registered into the primary router network via NFC authentication. Each building's secondary router device is then bound to the tertiary router devices on each of the building's 10 floors. Each floor's tertiary router devices are authenticated via NFC, registering the terminal communication devices and smoke sensor devices of the 6 households on that floor. Simultaneously, location information such as building number, floor number, and household number is entered into each level of device, establishing a precise mapping relationship between device location and UUID.

[0136] During operation, indoor smoke sensors in each resident's home periodically collect smoke concentration data, uploads it along with the device's UUID to the terminal device buffer, and collects data from all resident terminals on that floor in a polling manner. The data is then packaged and uploaded to the building's secondary router. The building's secondary router aggregates data from all floors in the building and uploads it to the community's primary main router. When a sensor in a household detects abnormal smoke and triggers an alarm, the alarm data, carrying the unique device UUID and location information, is uploaded level by level. The primary main router can accurately locate the alarm building, floor, and apartment number based on the network link table, achieving comprehensive smoke monitoring and precise alarm source tracing throughout the community, meeting the practical application needs of community security alarms.

[0137] In another embodiment, another method is disclosed, including the following: S1. Obtain the device identification information and communication configuration parameters of the routing devices and terminal communication devices at all levels to be networked, and obtain the set of devices to be networked, wherein the device identification information includes a unique device identifier, and the communication configuration parameters include communication mode and communication handshake parameters; S2. Based on the device identification information and the communication configuration parameters, the set of devices to be networked is accessed through a step-by-step near-field communication authentication method to establish a multi-level tree network topology structure consisting of a primary main routing device, multiple sub-routing devices, and terminal communication devices. The terminal communication devices are connected to the smart sensor devices through a standard communication interface to achieve data interaction. S3. After the multi-level tree network topology is established, perform device scanning, record the hierarchical cascading paths between the smart sensor device, the terminal communication device and the routing devices at each level in sequence, and construct a global device link table containing all access devices; S4. Based on the global device link table, during the data upload phase, data is retrieved from the buffers of each level of device through a polling reading mechanism, and during the data downlink phase, path matching is performed through a downlink routing forwarding mechanism. The data interaction between the smart sensor device and the terminal communication device adopts a unified command frame format for error control and routing addressing, and the target transmission path and data status result are obtained by matching the path and judging the status. S5. Based on the target transmission path and the data status result, send the data to be transmitted to the corresponding target device along the target transmission path in the unified command frame format, and execute the corresponding control action according to the data status result to output the network communication result.

[0138] All multi-byte data in the unified command frame format are transmitted in big-endian mode, and the entire frame data is checked using MODBUS CRC16 for error control. The structure of the command frame includes, in sequence: a fixed 2-byte start frame 0xAA55, a 1-byte command type, a 2-byte data length, n bytes of data content, and a 2-byte CRC checksum; The structure of the return command frame includes, in sequence: a fixed 2-byte return start frame 0x55AA, a 1-byte command type, a 2-byte data length, n bytes of data content, and a 2-byte CRC checksum; The command types include general commands and special commands; The dedicated command includes the large language model communication interface command 0xF3, wherein the n-byte data content is a formatted JSON data message output by the large language model and verified by constraint logic schema and character conversion.

[0139] The intelligent sensor device supports multiple operating modes, including automated acquisition mode, MODBUS mode, and large language model calling mode. In automated acquisition mode, the main controller of the intelligent sensor device extracts configuration parameters, including a 1-byte low-power mode identifier, a 1-byte sensor data quantity, and n sets of acquisition configurations containing parameter sequence numbers and acquisition cycles; the low-power mode identifier includes normal mode 0x00, sleep mode 0x01, stop mode 0x02, and standby mode 0x03.

[0140] When the device is configured for automatic data acquisition mode and is operating in standby mode 0x03, the data acquisition logic of the smart sensor is as follows: The smart sensor collects data at a set period of time. Timed data acquisition, and its time difference The calculation method is as follows: ; in, The timestamp is in milliseconds from the current real-time clock. The timestamp of the last data acquisition, stored in the backup register at the millisecond level, is used when... When flipping, it is done through the following relation: ; Calibration difference, when determined At that time, the main controller activates the environmental sensors to collect environmental data and... Write the data to the backup register; after the acquisition is completed, the main controller writes the latest timing reference data to the backup register, and then issues a standby control command to cut off the power supply to the kernel and peripherals, retaining only the RTC clock module driver.

[0141] When the device is operating in large language model invocation mode, the data interaction between the large language model and the smart sensor device includes the following steps: The large language model in the cloud is deployed with a device awareness agent. After the device handshake is completed, the awareness agent calls a general command to obtain the sensor capability words and creates the corresponding schema rule base. When the large language model needs to send control requests to the target sensor, the perception agent module generates downlink control decisions based on the toolchain, performs constraint decoding based on the schema rule base, verifies and generates a formatted downlink JSON message containing device_uuid, command_type and current system timestamp fields, filters and retryes to correct non-compliant fields, to ensure that the data type and boundary values ​​of the downlink JSON message are compatible with the corresponding schema rule base; The downlink JSON message that passes the verification is sent to the primary router device, which then executes the command encapsulation and distributes it level by level according to the global device link table. The target sensor receives the instruction, performs the action after CRC verification, and reports and sends the generated uplink JSON reply frame.

[0142] To bridge the gap between the highly flexible semantic output of a large language model and the high-precision physical bus communication control layer, the cloud system deployed a Device Perception Agent and a Format Constraints Filter on the API side of the LLM.

[0143] S301. Ability Cognitive Modeling: When the SHT30 temperature and humidity sensor with the unique identifier 48FFEA97-CB11-4CDC-8200-722B1409B978 is powered on and connected to the system, the large language model agent first triggers 0x05 (sensor introduction query) and 0x07 (data structure query) through the primary main router. The sensor returns information that the device's temperature measurement range is -40℃ to 125℃ and that it has a buzzer alarm control action. The agent registers this static parameter to the global session context's Prompt as the model's Tool Parameters data.

[0144] S302. Dynamic rule validation of JSON Schema: To ensure that the JSON output by the large language model does not contain garbled characters or out-of-range attribute values, a standard JSON schema template for intelligent sensor-controlled writing is defined: During the cloud inference phase, the system uses forced structured generation (e.g., constraint decoding with limited logits probability / JSON Mode constraints) to make the LLM tend to output only key-value pairs that satisfy the schema constraints. If an illusion occurs during generation (e.g., baud rate is written into the instruction), the filtering layer immediately rejects the output with an error message and performs a self-debugging rollback until the validation is successful. Then, the semi-structured output generated by the large model is parsed into a JSON text string that conforms to the above schema specification.

[0145] S303. Command Packaging and Protocol Bus Transmission Mechanism: The cloud performs binary ASCII encoding mapping on the verified JSON message (e.g., "capability_query" is converted into a character stream array [0x63, 0x61, 0x70, ...]). The primary router device places this ASCII character stream into the data segment of the large language model-specific command frame 0xF3. The primary router calculates the 2-byte checksum 0xXXXX at the end of the entire frame using the MODBUSCRC16 algorithm. The data packet is distributed using global link table addressing and is ultimately transmitted to the terminal main chip for reverse parsing.

[0146] When using a 32-bit real-time clock (RTC) to monitor periodic events, the timestamp reaches... After approximately 4,294,967,295 milliseconds (equivalent to 49.71 days), the hardware will reset the count and restart. In step S5, the system introduces a logical judgment algorithm to effectively avoid deadlock failures in periodic judgments caused by overflow and toggle cycles. Let the preset sampling period be... Milliseconds (1 minute), the last recorded time value. The current system time has been flipped and reset. .

[0147] Subtraction using conventional methods: ; At this time, directly with The comparison will cause logical confusion with negative numbers. We should use an unsigned overflow compensation mechanism instead. ; Substituting the data, we calculate: ; because The logic continues in a loop. When Run to In milliseconds: ; because The system successfully triggered a new power supply to the data collector and overwrote the current timestamp register value of 60000 into the backup register. This overflow scheme decouples the risk of program crashes caused by runtime boundary issues.

[0148] The above are merely embodiments of the present invention. The invention is not limited to the fields covered by these embodiments. Commonly known structures and characteristics in the solutions are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are able to access all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A method for automatic networking of intelligent devices based on bus communication, characterized in that, Includes the following steps: S1. Obtain the device identification information and communication configuration parameters of the routing devices and terminal communication devices at all levels to be networked, and obtain the set of devices to be networked, wherein the device identification information includes a unique device identifier, and the communication configuration parameters include communication mode and communication handshake parameters; S2. Based on the device identification information and the communication configuration parameters, the set of devices to be networked is accessed through a step-by-step near-field communication authentication method to establish a multi-level tree network topology structure consisting of a primary main routing device, multiple sub-routing devices, and terminal communication devices. The terminal communication devices are connected to the smart sensor devices through a standard communication interface to achieve data interaction. S3. After the multi-level tree network topology is established, a device scan is performed to sequentially record the hierarchical cascading paths between the intelligent sensor device, the terminal communication device and the routing devices at each level, and to construct a global device link table containing all access devices. S4. Based on the global device link table, during the data upload phase, data is retrieved from the buffers of each level of device through a polling reading mechanism, and during the data downlink phase, path matching is performed through a downlink routing forwarding mechanism to perform routing addressing and status judgment on the data to be transmitted, so as to obtain the target transmission path and data status result. S5. Based on the target transmission path and the data status result, send the data to be transmitted along the target transmission path to the corresponding target device, and execute the corresponding control action according to the data status result to output the network communication result.

2. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, In step S2, the topology access of the set of devices to be networked is performed through a step-by-step near-field communication authentication method, establishing a multi-level tree network topology structure consisting of a primary main routing device, multiple sub-routing devices, and terminal communication devices, including the following: Configure administrator and authorized personnel accounts on the primary router device and enter the corresponding near-field communication authorization identity information; using the operation terminal authenticated by the near-field communication authorization identity information, bring the secondary router device close to the near-field communication sensing area of ​​the primary router device, read the near-field communication tag built into the secondary router device to obtain its unique device identifier and communication configuration parameters, and complete the entry and binding of the secondary router device on the primary router device. Using the same near-field communication authentication and binding method, the next-level routing device is bound to the previous-level routing device in sequence until a routing backbone network with no more than the preset maximum number of layers and no more than the preset maximum number of subordinate devices attached to each routing device is constructed. Terminal communication devices are entered into the corresponding routing devices through near-field communication authentication, so that each routing device records the routing information of its directly connected subordinate routing devices and terminal communication devices. In the near-field communication process, if the communication method is Ethernet or cellular network communication, the upper-level routing device writes the network IP address and authentication information to the lower-level device through near-field communication, and the lower-level device sends its device unique identifier to the upper-level routing device for storage; if the communication method is serial bus communication, the upper-level routing device and the lower-level device exchange the communication baud rate and device unique identifier through near-field communication.

3. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, The terminal communication device connects to the smart sensor device via a standard communication interface, including the following: The standard communication interface adopts a standard 5-wire serial communication interface, which includes a positive power supply pin, a transmit pin, a receive pin, a negative power supply pin, and a connection status pin. In the terminal communication device, the connection status pin is configured to a default pull-up input state, so that the connection status pin maintains a high level signal when no smart sensor device is connected. In the intelligent sensor device, the corresponding connection status pin is connected to a low-level signal; when the intelligent sensor device is inserted into the standard communication interface of the terminal communication device and a valid connection is established, the connection status pin on the terminal communication device side is pulled low by the low-level signal on the intelligent sensor device side, and the terminal communication device determines that an intelligent sensor device has been connected by detecting the change of the level status of the connection status pin from high level to low level. After determining that a smart sensor device has been connected, the terminal communication device establishes a serial communication link with the smart sensor device through the transmit pin and receive pin, and obtains the device name, installation location, working mode and data acquisition parameters configured by the smart sensor device.

4. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, In step S3, device scanning is performed, and the hierarchical cascading paths between the smart sensor device, the terminal communication device, and each level of routing device are recorded sequentially. A global device link table containing all access devices is constructed, including the following: Upon initial power-on, a global device scanning process is initiated, whereby the lowest-level terminal communication device reads the unique device identifier of the connected smart sensor device. The terminal communication device associates its own unique device identifier with the unique device identifier of the connected smart sensor device and uploads it to the last-level routing device directly connected to it. The last-level routing device records the cascading relationship between the terminal communication device and the smart sensor device. Each routing device at each level sequentially uploads its own set of unique identifiers for its downstream devices to its upstream routing device, until the set is aggregated to the primary routing device. For any level of routing device, a mapping relationship between the device unique identifier and the routing path is recorded for all its descendant level routing devices, terminal communication devices and smart sensor devices. The primary routing device aggregates the unique device identifiers and hierarchical cascading paths of all routing devices, terminal communication devices, and smart sensor devices in the entire network to construct the global device link table for accurate addressing during subsequent bidirectional data transmission.

5. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, In step S4, the data retrieval from the buffers of each level of device through a polling read mechanism during the data upload phase includes the following: The intelligent sensor device collects sensor data according to the configured acquisition cycle, adds the unique identifier of the intelligent sensor device to the sensor data, encapsulates it into a sensor data packet, and sends it to the data buffer of the terminal communication device; each level of routing device sequentially sends polling data reading commands to the next level device directly connected to it; When the next-level device being polled is a terminal communication device, if there are unread sensor data packets in the data buffer of the terminal communication device, the terminal communication device will upload the sensor data packets to the routing device that sent the polling command. If the data buffer is empty, the terminal communication device will return an idle response to the routing device, and the routing device will skip the current terminal communication device and poll the next device. After the routing device obtains the sensor data packets from all its downstream devices, it packages all the obtained data packets into a centralized package and stores them in its own routing data buffer, waiting for the polling and reading command from the upstream routing device. Each routing device at each level executes the above polling and packaging process step by step from bottom to top, until the primary routing device polls and obtains the packaged data of the entire network, thus completing the data aggregation.

6. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, In step S4, the path matching performed through the downlink routing and forwarding mechanism during the downlink data phase for routing and status determination of the data to be transmitted includes the following: When it is necessary to send a control command from the primary main routing device to the target intelligent sensor device, the primary main routing device parses the unique identifier of the target device carried in the control command. The primary routing device retrieves the global device link table, matches the hierarchical cascading path corresponding to the unique identifier of the target device, determines the next-hop secondary routing device, and forwards the control command to the secondary routing device. Upon receiving the control command, the secondary routing device determines the corresponding sub-routing device or terminal communication device at the next level based on its stored routing path mapping relationship, and continues to forward the control command downwards. The control command is forwarded level by level downwards along the hierarchical cascade path between routing devices until it reaches the terminal communication device directly connected to the target intelligent sensor device. The terminal communication device parses the control command and sends it to the target intelligent sensor device through a standard communication interface. The target intelligent sensor device then executes the corresponding control action and reports the execution result up the original path to the primary main routing device.

7. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, The data interaction between the intelligent sensor device and the terminal communication device adopts a unified command frame format, including the following: All multi-byte data in the command frame format is transmitted in big-endian mode, and the entire frame data is checked using MODBUS CRC16 for error control. The structure of the command frame includes, in sequence: a fixed 2-byte start frame 0xAA55, a 1-byte command type, a 2-byte data length, n bytes of data content, and a 2-byte CRC checksum; The structure of the return command frame includes, in sequence: a fixed 2-byte return start frame 0x55AA, a 1-byte command type, a 2-byte data length, n bytes of data content, and a 2-byte CRC checksum; The command types include general commands and special commands; The general commands include device version number query command 0x01, unique device number query command 0x02, get working mode command 0x03, set working mode command 0x04, device sensor introduction command 0x05, device sensor interface introduction command 0x06, device sensor data structure query command 0x07, device soft reset command 0x0A, device factory reset command 0x0B, and firmware upgrade command 0x0C; the special commands include MODBUS read data interface command 0xF1, MODBUS write data interface command 0xF2, and large language model communication interface command 0xF3.

8. The method for automatic networking of intelligent devices based on bus communication as described in claim 1, characterized in that, The intelligent sensor device supports multiple operating modes, including automated acquisition mode, MODBUS mode, and large language model calling mode. In the automated acquisition mode, the main controller of the intelligent sensor device reads configuration parameters from its internal flash memory. The configuration parameters include a 1-byte low-power mode identifier, a 1-byte number of sensor data, and n sets of sensor data configuration parameters. Each set of sensor data configuration parameters includes a 1-byte parameter sequence number and a 4-byte acquisition cycle. The low-power mode identifier corresponds to the following operating modes: normal mode 0x00, sleep mode 0x01, stop mode 0x02, and standby mode 0x03. In normal mode, the main controller and peripherals of the smart sensor device are continuously powered. In sleep mode, the main controller turns off the CPU clock, maintains power supply to the analog-to-digital converter, timer, and serial port peripherals, and retains the random access memory and register data. It can be woken up in microseconds by interrupt or external signal. In the stop mode, the main controller shuts down the system's high-speed clock and peripheral power supply, maintaining only the low-speed real-time clock and retaining the random access memory and register data. It is woken up in milliseconds via a real-time clock timer alarm or an external interrupt. In the standby mode, except for the real-time clock and backup register which are powered independently, the power supply to the main controller, peripherals, and memory is cut off. It is woken up by a dedicated wake-up pin or a real-time clock timer alarm.

9. The method for automatic networking of intelligent devices based on bus communication as described in claim 8, characterized in that, When the intelligent sensor device operates in automated acquisition mode and is configured in low-power mode, the workflow includes: Step 1: System initialization, complete the initialization configuration of the basic clock and peripherals; Step 2: Read the operating mode from the flash memory to determine if it is configured as a low-power mode. If it is configured as a low-power mode, proceed to Step 3; otherwise, proceed to Step 4. Step 3: Determine if the system is configured for standby mode. If it is configured for standby mode, read the 4-byte timestamp saved during the last data acquisition from the backup register as the timing reference data, and then execute Step 4. If it is configured for other low-power modes, then execute Step 4 directly. Step 4: Iterate through and load the timing data of each sensor in sequence; Step 5: Calculate the difference between the current timestamp of the system's real-time clock module and the 4-byte timestamp of the last acquisition to determine whether the set acquisition period has been reached. If it has, acquire the corresponding sensor data and update the last acquisition timestamp, then proceed to Step 6; otherwise, return to Step 4. Step 6: Determine whether all sensor data that meet the current timing requirements have been collected. If yes, proceed to Step 7; otherwise, return to Step 4. Step 7: Send the collected sensor data to the terminal communication device through the standard communication interface, and determine whether it is currently configured in low power mode. If it is configured in low power mode, proceed to step 8; otherwise, return to step 4. Step 8: If configured for standby mode, the current timing reference data is written to the backup register, and then the control system enters the corresponding low-power mode to hibernate, waiting for the next wake-up signal. When the intelligent sensor device is running in the large language model invocation mode, the intelligent sensor device and the large language model interact through standardized JSON messages. The interaction process includes: The large language model sends downlink messages to the target intelligent sensor device through the primary routing device, multi-level sub-routing devices and terminal communication devices. The downlink messages include: a query intelligent sensor capability message for actively acquiring sensor hardware parameters, acquisition capabilities and execution control capabilities, which includes a command type field, a target device unique identifier field and an 8-byte millisecond-level timestamp field. The smart sensor data message is used to acquire specified monitoring parameters on demand. It includes a command type field, a target device unique identifier field, a timestamp field, and a set of physical quantity names to be read field. The system also includes a smart sensor control write message for issuing control commands, which contains a command type field, a target device unique identifier field, a timestamp field, a low-power mode and sampling frequency configuration parameter field, and an actuator control array field containing the actuator name and action command. After receiving and parsing the downlink message, the target smart sensor device returns a corresponding uplink message to the large language model. The uplink message includes: a sensor capability return message containing a sensor function overview, basic information, data acquisition capabilities, and device control capabilities; a data read reply message containing real-time values, current operating mode, fault status, and actuator status; and a control write reply message containing command execution description information, updated operating mode and sampling parameters, and updated actuator status.

10. An automatic networking system for intelligent devices based on bus communication, characterized in that, The method described in any one of claims 1-9 was adopted.

Images