Star flash terminal management method, star flash access point and star flash terminal management system

Abstract

The present application relates to a kind of star flash terminal management method, star flash access point and star flash terminal management system.The star flash terminal management method described in the present application includes: in response to receiving legal label broadcast, corresponding record information is generated based on legal label broadcast;MAC address is found in the first topological table of pre-set, and corresponding search result is obtained;Based on search result, update the first topological table, and obtain the second topological table;In response to receiving the topological query command issued by master unit, the latest second topological table of current time is sent to master unit;Master unit is used for comparing based on the second topological table and historical topological table, and when topological table and historical topological table exist preset difference, second topological table is sent to cloud platform.The star flash terminal management method described in the present application has the advantages that passive perception label topology can be perceived, and when change occurs, it is automatically reported.

Description

Technical Field

[0001] This invention belongs to the field of short-range wireless communication, and in particular relates to a method for managing satellite flash terminals, a satellite flash access point, and a satellite flash terminal management system. Background Technology

[0002] Low-power electronic tags (such as employee ID cards, asset tags, and battery box controllers) are typically battery-powered, requiring battery life of several months or even years. Therefore, they generally employ a duty cycle operating mode of "deep sleep + periodic wake-up broadcast + receiving gateway (AP / access point) connection and interaction + sleep again." With the advancement of the power Internet of Things (IoT) construction and industry digital transformation, the localization of terminals, secure wireless access, and independently controllable operating systems have become clear trends. SparkLink SLE, as a new generation of short-range wireless communication technology, possesses advantages such as low latency, high reliability, anti-interference, multiple connections, and link security, making it very suitable as a carrier between tags and gateways.

[0003] However, existing technologies have the following drawbacks: The AP cannot provide the platform with topology information for tags within its coverage area. The platform does not know which tags are online or which tags have been newly added / left within the coverage area of ​​a certain AP, making remote inventory and maintenance impossible; if a full poll is performed and reported every time, a large amount of uplink bandwidth is wasted when the number of tags is large. Summary of the Invention

[0004] Therefore, it is necessary to provide a StarFlash terminal management method, StarFlash access point, and StarFlash terminal management system that can passively sense the tag topology and automatically report changes when they occur, in order to address the above-mentioned technical problems.

[0005] In a first aspect, this application provides a StarSpark terminal management method, applied to a client unit of a StarSpark access point. The StarSpark access point includes a main control unit, a communication unit, and a client unit. The communication unit is used to communicate with a cloud platform, and the client unit communicates with multiple StarSpark terminals. The main control unit connects the communication unit and the client unit. The method includes: In response to receiving a legitimate tag broadcast, corresponding record information is generated based on the legitimate tag broadcast; the record information includes the MAC address corresponding to the legitimate tag broadcast and the timestamp of receiving the legitimate tag broadcast. The MAC address is searched in the preset first topology table to obtain the corresponding search result; the first topology table records the parameter information of the StarScan terminal of the client unit's historical communication. Based on the search results, update the first topology table to obtain the second topology table; In response to receiving a topology query command from the main control unit, the system sends the latest second topology table to the main control unit. The main control unit then compares the second topology table with the historical topology table, and sends the second topology table to the cloud platform when there are preset differences between the topology table and the historical topology table.

[0006] In one embodiment, based on the search result, the first topology table is updated to obtain the second topology table, including: If the search result shows that there is no MAC address in the first topology table and there is write space in the first topology table, write the MAC address and the corresponding timestamp into the first topology table to obtain the second topology table. If the search result shows that a MAC address exists in the first topology table, update the timestamp corresponding to the MAC address in the first topology table to obtain the second topology table; If the search result shows that there is no MAC address in the first topology table and there is no space to write to the first topology table, delete the historical MAC address with the oldest timestamp in the first topology table, and write the MAC address and its corresponding timestamp into the first topology table to obtain the second topology table.

[0007] In one embodiment, based on the search result, the first topology table is updated to obtain the second topology table, and the method further includes: Iterate through the MAC addresses and their corresponding timestamps in the first topology table; When any timestamp exceeds a preset duration relative to the current time, delete the MAC address corresponding to the timestamp to obtain the second topology table.

[0008] In one embodiment, the method further includes: In response to receiving a topology query request from the main control unit, the system sends the latest second topology table to the main control unit. The topology query request is sent from the cloud platform to the main control unit via the communication unit. And / or, In response to a preset first error, the latest second topology table is sent to the main control unit; the preset first error is that the tag does not exist.

[0009] In one embodiment, the method further includes: If no signal is received from the main control unit for a preset first time period, a reset command is generated. The reset command is used to instruct the main control unit to be powered off through the power gating pin and to reset the main control unit after a preset delay.

[0010] In one embodiment, when the MAC address of the StarScan access point changes, the method further includes: When the StarSpark access point is powered on, in response to the command to retrieve the local address, it obtains a new MAC address from the non-volatile storage of the StarSpark access point and sends the MAC address to the master control unit. The MAC address is used to instruct the master control unit to replace the placeholder in the preset topic template with the uppercase hexadecimal string corresponding to the current MAC address in order to update the corresponding topic template. The topic template is a publish / subscribe model topic between the StarSpark access point and the cloud platform.

[0011] In one embodiment, the method further includes: In response to the command to modify the AP address issued by the cloud platform, the new address corresponding to the local machine is obtained based on the command to modify the AP address; When the verification result shows that the new address is different from the old address of the local machine, the new address is written as the new MAC address into the non-volatile storage of the StarShock access point, and the corresponding write result is generated. The write result is sent to the main control unit, and a restart command is generated. The restart command is used to instruct the client unit to restart. The write result is used to instruct the main control unit to replace the placeholder in the preset theme template with the uppercase hexadecimal string corresponding to the current MAC address in order to update the corresponding theme template.

[0012] Secondly, this application also provides a StarSpark terminal management device, applied to a client unit of a StarSpark access point. The StarSpark access point includes a main control unit, a communication unit, and a client unit. The communication unit is used to communicate with a cloud platform, and the client unit communicates with multiple StarSpark terminals. The main control unit connects the communication unit and the client unit. The device includes: The information generation module is used to respond to the receipt of a legitimate tag broadcast and generate corresponding record information based on the legitimate tag broadcast; the record information includes the MAC address corresponding to the legitimate tag broadcast and the timestamp of receiving the legitimate tag broadcast. The lookup module is used to search for MAC addresses in a preset first topology table and obtain the corresponding lookup results; the first topology table records the parameter information of the StarScan terminal of the client unit's historical communication. The update module is used to update the first topology table based on the search results to obtain the second topology table; The first sending module is used to respond to the topology query command issued by the main control unit and send the latest second topology table at the current time to the main control unit; the main control unit is used to compare the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, it sends the second topology table to the cloud platform.

[0013] Thirdly, this application also provides a StarScan access point, including a main control unit, a communication unit, and a client unit; the communication unit is used to communicate with a cloud platform, and the client unit communicates with multiple StarScan terminals; the main control unit connects the communication unit and the client unit; the main control unit is used to implement the steps of the method described in any of the first aspects of this application.

[0014] Fourthly, this application also provides a StarSpark terminal management system, including the StarSpark access point, cloud platform, and multiple StarSpark terminals as described above; the cloud platform communicates with the StarSpark access point through the communication unit of the StarSpark access point; each StarSpark terminal communicates with the StarSpark access point through a client unit.

[0015] The aforementioned StarFlash terminal management method, StarFlash access point, and StarFlash terminal management system, in response to receiving a legitimate tag broadcast, generate corresponding record information based on the legitimate tag broadcast; search for the MAC address in a preset first topology table to obtain the corresponding search result; update the first topology table based on the search result to obtain a second topology table; in response to receiving a topology query command from the main control unit, send the latest second topology table to the main control unit; the main control unit compares the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, sends the second topology table to the cloud platform, enabling passive perception of tag topology and automatic reporting when changes occur. It achieves zero daily traffic overhead, reporting changes immediately, balancing real-time performance and uplink traffic. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a StarFlash terminal management method provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] It should be understood that the described embodiments are merely some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of the embodiments of this application.

[0020] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0021] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0022] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0023] The StarShine terminal management method provided in this application embodiment can be applied to a client unit of a StarShine access point. The StarShine access point includes a main control unit, a communication unit, and a client unit. The communication unit communicates with a cloud platform, and the client unit communicates with multiple StarShine terminals. The main control unit connects the communication unit and the client unit. In a specific example, the StarShine terminal can be a batch of low-power StarShine tags, which can also be simply referred to as StarShine tags or tags. The StarShine tag acts as a server, containing a controlled module, and communicates with the StarShine access point. The StarShine access point can also be called a tag access point (hereinafter referred to as AP, Access Point), including a main control MCU (equivalent to the main control unit), a WAPI module (equivalent to the communication unit), and a StarShine client (equivalent to the client unit). The cloud platform accesses the network via WAPI and communicates with the StarShine AP using MQTT (QoS1). The cloud platform can be implemented using a separate server or a server cluster composed of multiple servers.

[0024] It is understood that the solution provided in this application is not limited to SparkLink Low Energy (SLE), but can be extended to short-range / low-power communication systems with periodic wake-up broadcasts such as BLE, Zigbee, LoRa, and Wi-Fi; the wide area network can be replaced with 4G / 5G, Ethernet, Wi-Fi, etc., while the instruction and result closed-loop mechanism remains unchanged.

[0025] In one exemplary embodiment, such as Figure 1 As shown, a StarFlash terminal management method is provided. Taking the application of this method to the aforementioned client unit / StarFlash client as an example, the method includes the following steps 102 to 108. Wherein: Step 102: In response to receiving a legitimate tag broadcast, generate corresponding record information based on the legitimate tag broadcast; the record information includes the MAC address corresponding to the legitimate tag broadcast and the timestamp of receiving the legitimate tag broadcast.

[0026] Tag broadcasting can refer to the periodic transmission of broadcast messages by a StarSpark tag (SLE terminal node) on the broadcast channel, or it can refer to any broadcast message sent. A legitimate tag broadcast can be a broadcast message received by the StarSpark AP side after scanning and verifying that it was sent by a trusted tag. Upon receiving a legitimate tag broadcast, the StarSpark client generates corresponding record information based on the legitimate tag broadcast. The record information may include the MAC address (Media Access Control Address) of the StarSpark tag that sent the broadcast message and the timestamp of receiving the legitimate tag broadcast.

[0027] Step 104: Search for the MAC address in the preset first topology table to obtain the corresponding search result; the first topology table records the parameter information of the StarScan terminal that the client unit has communicated with in the past.

[0028] The first topology table is a list of tag information stored in the StarShine client. Each record stores parameter information for StarShine terminals that have communicated historically. This parameter information may include the MAC address and timestamp corresponding to each legitimate tag broadcast. The StarShine client searches the first topology table for the MAC address corresponding to the last received legitimate tag broadcast to determine whether the first topology table needs to be updated based on the search result.

[0029] Step 106: Based on the search results, update the first topology table to obtain the second topology table.

[0030] For example, the search results may include "MAC address found" and "MAC address not found". Updating the first topology table may include writing new records directly or replacing historical records in the first topology table that meet specific adjustments with new records to update the first topology table and obtain the second topology table.

[0031] Step 108: In response to receiving the topology query command issued by the main control unit, send the latest second topology table at the current time to the main control unit; the main control unit is used to compare the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, send the second topology table to the cloud platform.

[0032] The master control unit can periodically send topology query commands to client units, or send them based on preset trigger conditions. Upon receiving the topology query command from the master control unit, the client unit sends the latest second topology table to the master control unit. Furthermore, the master control unit maintains a historical topology table, which contains the MAC addresses of all tags managed by the StarSpark access point. If the MAC addresses in the second topology table are the same as those in the historical topology table, the master control unit does not report them to the cloud platform. If the MAC addresses in the second topology table change compared to the historical topology table (a change is considered complete if the number of MAC addresses differs or any element is mutually exclusive), the master control unit reports the new topology table to the cloud platform and saves it as the historical topology table for the next round.

[0033] In the aforementioned StarFlash terminal management method, upon receiving a legitimate tag broadcast, corresponding record information is generated based on the legitimate tag broadcast; the MAC address is searched in a preset first topology table to obtain the corresponding search result; based on the search result, the first topology table is updated to obtain a second topology table; upon receiving a topology query command from the main control unit, the latest second topology table is sent to the main control unit; the main control unit compares the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, it sends the second topology table to the cloud platform, enabling passive perception of tag topology and automatic reporting when changes occur. This method achieves zero daily traffic overhead, reporting changes immediately, balancing real-time performance and uplink traffic.

[0034] In one embodiment, based on the search result, the first topology table is updated to obtain the second topology table, including: If the search result shows that there is no MAC address in the first topology table and there is write space in the first topology table, write the MAC address and the corresponding timestamp into the first topology table to obtain the second topology table. If the search result shows that a MAC address exists in the first topology table, update the timestamp corresponding to the MAC address in the first topology table to obtain the second topology table; If the search result shows that there is no MAC address in the first topology table and there is no space to write to the first topology table, delete the historical MAC address with the oldest timestamp in the first topology table, and write the MAC address and its corresponding timestamp into the first topology table to obtain the second topology table.

[0035] The first topology table can have a preset capacity, which corresponds to the number of StarTrack tags managed by the StarTrack access point. For example, the capacity can be 100, but this application does not limit the specific number.

[0036] Specifically, the search results and corresponding update methods can be: If the MAC address already exists, only the timestamp is refreshed; if the MAC address does not exist and the capacity is not full, it is appended; if the capacity is full, the topology table is first aged and cleaned up before insertion, and if it is still full, the record with the oldest (longest unseen) timestamp is replaced. The aging and cleanup process removes expired entries that have not been seen for more than 600 seconds since the current time—that is, entries that automatically exit the topology within 10 minutes after the tag leaves the coverage area or fails.

[0037] In one embodiment, based on the search result, the first topology table is updated to obtain the second topology table, and the method further includes: Iterate through the MAC addresses and their corresponding timestamps in the first topology table; When any timestamp exceeds a preset duration relative to the current time, delete the MAC address corresponding to the timestamp to obtain the second topology table.

[0038] Specifically, after each update of the topology table, aging cleanup can be performed again: expired entries that have not been seen for more than 600 seconds since the current time are removed—that is, tags that leave the coverage area or fail within 10 minutes are automatically removed from the topology.

[0039] In one embodiment, the method further includes: In response to receiving a topology query request from the main control unit, the system sends the latest second topology table to the main control unit. The topology query request is sent from the cloud platform to the main control unit via the communication unit. And / or, In response to a preset first error, the latest second topology table is sent to the main control unit; the preset first error is that the tag does not exist.

[0040] Specifically, when there are relevant business needs, the cloud platform may send a topology query request to the StarSpark access point. This topology query request is sent to the main control unit via the communication unit, and then forwarded to the client unit by the main control unit. After receiving the topology query request from the main control unit, the client unit sends the latest second topology table to the main control unit.

[0041] In addition, when the AP side detects a "tag does not exist" error, it will automatically trigger a topology report, that is, send the second topology table to the cloud platform, so that the platform topology is eventually consistent with the actual tag status (self-healing closed loop).

[0042] Through the various topology reporting methods mentioned above, topology visibility and traffic controllability are achieved: passive perception through monotonic timestamps + aging cleanup + oldest replacement, combined with change-triggered reporting through 15-second polling + set comparison, the platform can remotely inventory and the daily uplink traffic is almost zero.

[0043] In existing technologies, there is a problem that the StarSpark module cannot self-heal after crashing / hanging. The AP's internal "main control MCU + StarSpark client chip" is a dual-chip architecture. When the StarSpark module program crashes or hangs, the main control MCU cannot detect it, causing the entire AP to silently fail and requiring manual power-off reset.

[0044] To address this issue, in one embodiment, the method further includes: If no signal is received from the main control unit for a preset first time period, a reset command is generated. The reset command is used to instruct the main control unit to be powered off through the power gating pin and to reset the main control unit after a preset delay.

[0045] Specifically, both the main control unit and the client unit monitor communication activity independently: if the main control MCU does not receive a valid frame for 60 consecutive seconds, it determines that the StarSpark module is abnormal, first powering off the StarSpark module via the power gating pin, and then resetting the entire AP system after a delay; if the StarSpark client does not receive a valid frame for 60 consecutive seconds, it resets its chip automatically. Neither side depends on the other's reset result; communication can be restored by resetting either side first.

[0046] Based on independent monitoring at both ends, the four-state parsing state machine can self-synchronize after interference from any byte stream; bidirectional 60-second frameless self-healing allows any chip to automatically recover from a crash, and the AP can operate unattended for a long time.

[0047] In existing technologies, there is a problem where the AP device address is fixed, and communication is interrupted after the address is remotely changed. The MQTT topics of the platform and the AP are bound to the AP's MAC address; once the AP address is remotely changed, all the original subscribed / published topics become invalid, and the AP and the platform lose contact. Existing technologies lack a mechanism for dynamically rebuilding topics after address changes.

[0048] To address this issue, in one embodiment, when the MAC address of the StarScan access point changes, the method further includes: When the StarSpark access point is powered on, in response to the command to retrieve the local address, it obtains a new MAC address from the non-volatile storage of the StarSpark access point and sends the MAC address to the master control unit. The MAC address is used to instruct the master control unit to replace the placeholder in the preset topic template with the uppercase hexadecimal string corresponding to the current MAC address in order to update the corresponding topic template. The topic template is a publish / subscribe model topic between the StarSpark access point and the cloud platform.

[0049] Specifically, communication between the Spark access point and the cloud platform can adopt a topic template mechanism: all subscription / publishing topics are defined in template form, where placeholders represent the MAC address of this AP (e.g., sparkApChannel / normal / <local address> / service / devPowerOn). When the MAC address of the Spark access point changes, the AP queries the local address from the Spark client after powering on (command 0x07). The client reads and returns the current MAC address from NV (Non-Volatile Storage); the main control MCU replaces the placeholders in the template with the actual MAC address in uppercase hexadecimal, generating all subscription and publish topics.

[0050] In other application scenarios, if the cloud platform actively sends a modification order for the AP address to the StarShine access point, the methods also include: In response to the command to modify the AP address issued by the cloud platform, the new address corresponding to the local machine is obtained based on the command to modify the AP address; When the verification result shows that the new address is different from the old address of the local machine, the new address is written as the new MAC address into the non-volatile storage of the StarShock access point, and the corresponding write result is generated. The write result is sent to the main control unit, and a restart command is generated. The restart command is used to instruct the client unit to restart. The write result is used to instruct the main control unit to replace the placeholder in the preset theme template with the uppercase hexadecimal string corresponding to the current MAC address in order to update the corresponding theme template.

[0051] Specifically, when the platform issues an instruction to modify the AP address (0x05), the StarSpark client verifies that "the target address is the local machine and the old and new addresses are different", writes it into NV, sends back the result, and restarts; after receiving the successful feedback, the main control MCU immediately rebuilds all MQTT topics with the new address to ensure that the AP and the platform do not communicate after the address change - solving the maintenance problem of "loss of connection after address change".

[0052] In one embodiment, this application also provides a StarScan access point, including a main control unit, a communication unit, and a client unit; the communication unit is used to communicate with a cloud platform, and the client unit communicates with multiple tags; the main control unit connects the communication unit and the client unit; the main control unit is used to implement the steps of the method as described in any of the first aspects of this application.

[0053] In one embodiment, this application also provides a StarSpark terminal management system, including the StarSpark access point, cloud platform, and multiple StarSpark terminals as described above; the cloud platform communicates with the StarSpark access point through the communication unit of the StarSpark access point; each StarSpark terminal communicates with the StarSpark access point through a client unit.

[0054] Specifically, the system consists of three layers: a cloud platform, StarShine APs, and StarShine tags. The cloud platform accesses the network via WAPI and communicates with the StarShine APs via MQTT (QoS1). The StarShine APs consist of three parts: a WAPI module, a main control MCU, and a StarShine client. The WAPI module provides MQTT capabilities via AT commands and securely accesses the network via WAPI (certificate authentication and national cryptographic algorithm encryption). The main control MCU (HC32F460, running the domestic PH-M Dianhong IoT operating system) is responsible for the MQTT protocol state machine, JSON command parsing, command queue, on-board serial port frame protocol, topology table maintenance, watchdog timer, and StarShine module power gating. The StarShine client (on-board BS21E chip, SLE Client + UART function) is responsible for slot-based multi-connection management, scanning / link establishment / SSAP transmission and reception, MAC topology table, and pending queue. The main control MCU and the StarShine client are interconnected via the on-board serial port (UART 115200, custom frame protocol). The StarShine tag (BS21E, SLE Server) has a built-in controlled module (such as the SIM218 communication module), and the power supply of the controlled module is gated by the tag's GPIO.

[0055] Platform → Tag Command Chain: The platform issues commands (including tag address tagAddr and command unique identifier randId) via WAPI AP using MQTT → WAPI module AT pass-through → Main control MCU parses JSON → packages into an onboard serial port frame → StarShine client → SLE scan / chain establishment / SSAP write request → tag execution. Tag → Platform Result Chain: Tag SSAP notification → StarShine client → onboard serial port frame → Main control MCU → MQTT event reporting (including randId).

[0056] In terms of security and independent controllability: the wide area network adopts WAPI secure access (certificate authentication and national cryptographic algorithm encryption), the air interface adopts SLE pairing authentication and link encryption, and the terminal main control runs the domestic PH-M Dianhong IoT operating system. The overall security and independent controllability level meet the requirements of power grid IoT and can be extended to other industry scenarios with security requirements.

[0057] The system manages tag topology updates through the following scheme: The system implements topology management through a three-tier mechanism: "passive client-side perception + main control-side comparison and debouncing + platform-on-demand query." 1. StarFlash client-side topology table: Upon receiving a valid tag broadcast via the scan callback, the tag's MAC address is written to a topology table with a capacity of 100. Each record carries a monotonic second-level timestamp (converted to monotonic seconds using system ticks to avoid interference from real-time jumps / rollbacks). If the record already exists, only the timestamp is refreshed; if it doesn't exist and the table isn't full, it's appended; if the table is full, aging cleanup is performed before insertion, and if it's still full, the record with the oldest (longest unseen) timestamp is replaced. After each update, aging cleanup is performed: expired entries that haven't been seen for more than 600 seconds are removed—tags automatically exit the topology within 10 minutes of leaving the coverage area or experiencing a failure. Furthermore, the aging threshold of 600 seconds is not a fixed value and can be adaptively adjusted according to the tag wake-up cycle.

[0058] 2. Main MCU Periodic Polling and Change-Triggered Reporting: The main MCU sends a topology query command (0x08) to the StarShine client every 15 seconds. The client returns a full list of MAC addresses. The main MCU performs a set-level comparison between the new list and the local old table (a change is considered complete if the number of entries differs or if any element is mutually exclusive). A full MQTT topology report (tagList array) is triggered only when the topology changes. Therefore: zero daily traffic overhead, reporting changes immediately, balancing real-time performance and uplink traffic.

[0059] For example, reporting rules can also be defined as incremental reporting (reporting only newly added / departed tags) and rich topology reporting with RSSI and most recent active time.

[0060] 3. Platform on-demand query: The platform can send topology query requests at any time via broadcast topic. Each AP will trigger a topology report upon receiving the request. The "label does not exist" error on the AP side will also automatically trigger a topology report, so that the platform topology and the actual label status are eventually consistent (self-healing closed loop).

[0061] Furthermore, the system can also achieve end-to-end association between instructions and results through the following scheme: Each control instruction issued by the platform carries a 4-byte random instruction identifier randId, which is transmitted transparently throughout the entire link, without parsing or rewriting: 1. Platform side: The control command message parameters include randId. When the main control MCU parses it, it splits it into 4-byte instruction identifiers according to big-endianness and writes them into the internal instruction structure; 2. Main MCU → StarShine client: The onboard serial port frame payload (6 bytes of tag address + 4 bytes of instruction identifier + 1 byte of command word + parameters) is transmitted as is; 3. StarShine client → Tag: SSAP Write request carries (command identifier + command word + parameters) as is; 4. After the tag is executed, the following information is returned: (instruction identifier + command word + status). The address change instruction includes the new address. 5. Result feedback and event reporting: The main control MCU reassembles the 4-byte instruction identifier in the feedback into randId and writes it into the MQTT execution result event (such as event.devPowerOnResult / post).

[0062] The platform uses randId to map "result events" to "issued instructions" one by one, enabling instruction-level tracking, timeout determination, and targeted retransmission; combined with AP-side scanning phase deduplication without chain building, it forms a security closed loop of "retransmission without repeated execution".

[0063] The onboard serial port frame protocol can be overlaid with encryption and freshness verification (random number / timestamp) to prevent replay; the broadcast vendor prefix filtering can be upgraded to whitelist / certificate filtering.

[0064] The response to the tag relocation command (0x02) includes an additional Signal Strength Indicator (RSSI) for this connection during the return transmission. This allows the platform to obtain air interface link quality information at the same time as the execution result, facilitating deployment assessment and fault location.

[0065] Furthermore, the system can also achieve reliable and self-healing dual-chip communication through the following scheme: the main control MCU (HC32F460) and the StarShine client (BS21E) communicate via the onboard serial port (UART 115200) using a custom frame protocol. The protocol is symmetrically implemented on both sides of the heterogeneous dual chips (using the same state machine and CRC algorithm): 1. Frame format: Frame header 0xAA (1 byte) + total length (2 bytes, big-endian) + payload (not exceeding 620 bytes) + CRC8 checksum (1 byte); CRC uses CRC-8 / MAXIM (polynomial 0x8C, initial value 0x00), covering the frame header, length and payload.

[0066] 2. Receiver state machine: Synchronization word → High byte of length → Low byte of length → Data, four-state parsing; if the length is invalid (less than 4 or greater than 624), return directly to the synchronization state; if the reception of the same frame times out (1 second), discard the fragmented frame and return to the synchronization state, ensuring self-synchronization after any byte stream interference.

[0067] 3. Bidirectional Timeout Self-Healing: The main control MCU monitors the time since the last successful frame reception. If no valid frames are received for 60 consecutive seconds, the StarSpark module is deemed faulty. Power is first cut off to the StarSpark module via the power gating pin, and after a delay, the entire AP system is reset—module-level fault self-healing requires no manual intervention. The StarSpark client also monitors for 60 seconds without frames, and automatically resets the chip upon timeout. Neither side depends on the other's reset result; communication can be restored by resetting either side first.

[0068] 4. Power gating of the StarShine module by the main control MCU: The power supply of the StarShine client chip is controlled by the power gating pin of the main control MCU. The power-on sequence and power-off reset can be controlled by the main control software.

[0069] The main control unit can record the number of times the star flash module is reset and the reasons, and report an alarm to the platform when the threshold is exceeded; the dual modules can be expanded to hot-swap between main and backup star flash modules.

[0070] Furthermore, the system can also achieve uninterrupted communication after the AP is remotely relocated using the following methods: 1. Topic Template Mechanism: All subscription / publishing topics are defined in the form of templates, where placeholders represent the MAC address of this AP (e.g., sparkApChannel / normal / <local address> / service / devPowerOn). 2. Boot-up binding: After the AP powers on, it queries the local address from the StarSpark client (command 0x07). The client reads and sends back the current MAC address from NV. The main control MCU replaces the placeholders in the template with the actual MAC address in uppercase hexadecimal string and generates all subscription and publishing topics. 3. Dynamic Reconstruction After Remote Address Change: When the platform issues an AP address modification command (0x05), the StarShine client verifies that "the target address is the local machine and the old and new addresses are different", writes it into NV, sends back the result, and restarts; after receiving the successful feedback, the main control MCU immediately reconstructs all MQTT topics with the new address to ensure that the AP and the platform do not communicate after the address change - solving the maintenance problem of "loss of connection after address change".

[0071] Furthermore, the platform's side protocol cooperation specifications include: Control command issuance topics: service.devPowerOn (power on controlled module), service.modifyWkTime (modify tag wake-up time, 10~60 seconds), service.modifyTagRf (modify tag RF parameters), service.modifyApRf (modify AP RF parameters); broadcast topics: broadcast.topo (topology request), broadcast.startup (startup notification); command response topics (*_reply) carrying response codes (200 Success, 400 Parameter Error, 401 Device Unauthenticated, 403 Insufficient Permissions, 404 Device Not Found, 500 Internal Error, 503 Device Busy); execution result event topics (event.*Result / post) carrying status codes (0~5, 255) and randId, tagAddr; attribute reporting topics (event.baseProperties / post, event.technicalProperties / post); topology reporting topics (event.topoReport / post, full tagList).

[0072] The StarFlash terminal management method, StarFlash access point, and StarFlash terminal management system provided in this application have at least the following technical advantages: 1. Topology visibility and traffic controllability: The passive perception of monotonous timestamps + aging cleanup + oldest replacement, combined with 15-second polling + aggregated comparison to trigger change reporting, allows the platform to conduct remote inventory and the daily uplink traffic is almost zero.

[0073] 2. End-to-end traceability: randId is used throughout the entire link, enabling the platform to perform instruction-level tracing, timeout determination, and targeted retransmission for each instruction; the address change response is accompanied by RSSI, which also provides link quality information.

[0074] 3. High reliability with dual chips: The on-board serial port frame protocol (frame header + length + CRC8 + state machine) is symmetrically implemented on heterogeneous dual chips. With bidirectional 60-second timeout self-healing (power failure reset / chip self-reset), the AP can operate unattended for a long time.

[0075] 4. Uninterrupted connection after address change: MQTT topic templates + placeholders are dynamically replaced, and the topic is automatically rebuilt after the AP is remotely relocated, so that operation and maintenance do not stop.

[0076] 5. Safe, compliant, and independently controllable: The main control MCU runs the domestic PH-M Dianhong IoT operating system, the wide area network adopts WAPI secure access (certificate authentication and national cryptographic algorithm encryption), and the air interface adopts SLE pairing authentication and link encryption. The overall security and independent controllability level meet the requirements of power grid IoT, and can be extended to other low-power remote control scenarios such as warehousing and logistics, asset management, personnel positioning, and industrial IoT.

[0077] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0078] Based on the same inventive concept, this application also provides a StarFlash terminal management device for implementing the StarFlash terminal management method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more StarFlash terminal management device embodiments provided below can be found in the limitations of the StarFlash terminal management method described above, and will not be repeated here.

[0079] In an exemplary embodiment, this application also provides a StarSpark terminal management device, applied to a client unit of a StarSpark access point. The StarSpark access point includes a main control unit, a communication unit, and a client unit. The communication unit is used to communicate with a cloud platform, and the client unit communicates with multiple StarSpark terminals. The main control unit connects the communication unit and the client unit. The device includes: The information generation module is used to respond to the receipt of a legitimate tag broadcast and generate corresponding record information based on the legitimate tag broadcast; the record information includes the MAC address corresponding to the legitimate tag broadcast and the timestamp of receiving the legitimate tag broadcast. The lookup module is used to search for MAC addresses in a preset first topology table and obtain the corresponding lookup results; the first topology table records the parameter information of the StarScan terminal of the client unit's historical communication. The update module is used to update the first topology table based on the search results to obtain the second topology table; The first sending module is used to respond to the topology query command issued by the main control unit and send the latest second topology table at the current time to the main control unit; the main control unit is used to compare the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, it sends the second topology table to the cloud platform.

[0080] In one embodiment, the update module includes: The first update submodule is used to write the MAC address and its corresponding timestamp into the first topology table when the search result is that there is no MAC address in the first topology table and there is write space in the first topology table, so as to obtain the second topology table. The second update submodule is used to update the timestamp corresponding to the MAC address in the first topology table when the search result shows that the MAC address exists in the first topology table, so as to obtain the second topology table. The third update submodule is used to delete the oldest historical MAC address in the first topology table when the search result is that there is no MAC address in the first topology table and there is no write space in the first topology table, and write the MAC address and the corresponding timestamp into the first topology table to obtain the second topology table.

[0081] In one embodiment, the update module further includes: The traversal unit is used to traverse the MAC addresses and their corresponding timestamps in the first topology table; The deletion unit is used to delete the MAC address corresponding to any timestamp when the time exceeds a preset duration relative to the current time, thereby obtaining the second topology table.

[0082] In one embodiment, the device further includes: The second sending module is used to respond to the topology query request sent by the main control unit and send the latest second topology table at the current time to the main control unit; the topology query request is sent by the cloud platform to the main control unit through the communication unit; And / or, The third sending module is used to send the latest second topology table to the main control unit in response to the occurrence of a preset first error; the preset first error is that the tag does not exist.

[0083] In one embodiment, the device further includes: The reset module is used to generate a reset command when no signal is received from the main control unit for a preset first time period. The reset command is used to instruct the main control unit to be powered off through the power gating pin and to reset the main control unit after a preset delay.

[0084] In one embodiment, when the MAC address of the StarScan access point changes, the device further includes: The fourth sending module is used to retrieve a new MAC address from the non-volatile storage of the StarSpark access point when it is powered on, in response to the command to obtain and query the local address, and send the MAC address to the main control unit. The MAC address is used to instruct the main control unit to replace the placeholder in the preset topic template with the uppercase hexadecimal string corresponding to the current MAC address in order to update the corresponding topic template. The topic template is a publish / subscribe model topic between the StarSpark access point and the cloud platform.

[0085] In one embodiment, the device further includes: The address verification module is used to respond to the AP address modification command issued by the cloud platform and obtain the new address corresponding to the local machine based on the AP address modification command; The address update module is used to write the new address as the new MAC address into the non-volatile storage of the StarShock access point and generate the corresponding write result when the verification result shows that the new address is different from the old address of the local machine. The fifth sending module is used to send the write result to the main control unit and generate a restart command; the restart command is used to instruct the client unit to restart; the write result is used to instruct the main control unit to replace the placeholder in the preset theme template with the uppercase hexadecimal string corresponding to the current MAC address in order to update the corresponding theme template.

[0086] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for managing a StarFlash terminal, characterized in that, A client unit is applied to a StarShine access point, wherein the StarShine access point includes a main control unit, a communication unit, and a client unit; the communication unit is used to communicate with the cloud platform, and the client unit communicates with multiple StarShine terminals. The main control unit connects the communication unit and the client unit; The method includes: In response to receiving a legitimate tag broadcast, corresponding record information is generated based on the legitimate tag broadcast; the record information includes the MAC address corresponding to the legitimate tag broadcast and the timestamp of receiving the legitimate tag broadcast. The MAC address is searched in a preset first topology table to obtain the corresponding search result; the first topology table records the parameter information of the StarFlash terminal in the historical communication of the client unit; Based on the search results, the first topology table is updated to obtain the second topology table; In response to receiving a topology query command from the main control unit, the system sends the latest second topology table to the main control unit. The main control unit compares the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, it sends the second topology table to the cloud platform.

2. The method according to claim 1, characterized in that, The step of updating the first topology table based on the search result to obtain the second topology table includes: When the search result indicates that the MAC address does not exist in the first topology table and the first topology table has write space, the MAC address and the corresponding timestamp are written into the first topology table to obtain the second topology table; When the search result indicates that the MAC address exists in the first topology table, the timestamp corresponding to the MAC address in the first topology table is updated to obtain the second topology table; When the search result indicates that the MAC address does not exist in the first topology table and the first topology table has no write space, the historical MAC address with the oldest timestamp in the first topology table is deleted, and the MAC address and the corresponding timestamp are written into the first topology table to obtain the second topology table.

3. The method according to claim 2, characterized in that, The step of updating the first topology table based on the search result to obtain the second topology table further includes: Iterate through the MAC addresses and their corresponding timestamps in the first topology table; When any of the timestamps exceeds a preset duration relative to the current time, the MAC address corresponding to the timestamp is deleted, and the second topology table is obtained.

4. The method according to claim 1, characterized in that, The method further includes: In response to receiving a topology query request from the main control unit, the cloud platform sends the latest version of the second topology table to the main control unit; the topology query request is sent by the cloud platform to the main control unit via the communication unit. And / or, In response to a preset first error, the latest second topology table at the current time is sent to the main control unit; the preset first error is that the tag does not exist.

5. The method according to claim 1, characterized in that, The method further includes: If no signal is received from the main control unit for a preset first time period, a reset command is generated; the reset command is used to instruct the main control unit to be powered off through the power gating pin and to reset the main control unit after a preset delay.

6. The method according to claim 1, characterized in that, When the MAC address of the StarShock access point changes, the method further includes: When the StarSpark access point is powered on, in response to the command to retrieve and query the local address, it retrieves the new MAC address from the non-volatile storage of the StarSpark access point and sends the MAC address to the main control unit. The MAC address is used to instruct the main control unit to replace the placeholder in the preset topic template with the uppercase hexadecimal string corresponding to the current MAC address, so as to update the corresponding topic template. The topic template is a publish / subscribe model topic between the StarSpark access point and the cloud platform.

7. The method according to claim 6, characterized in that, The method further includes: In response to receiving the AP address modification instruction issued by the cloud platform, the new address corresponding to the local machine is obtained based on the AP address modification instruction; When the verification result shows that the new address is different from the old address of the local machine, the new address is written as the new MAC address into the non-volatile storage of the StarSpark access point, and the corresponding write result is generated. The write result is sent to the main control unit, and a restart command is generated; the restart command is used to instruct the client unit to restart; the write result is used to instruct the main control unit to replace the placeholder in the preset theme template with the uppercase hexadecimal string corresponding to the current MAC address, so as to update the corresponding theme template.

8. A StarFlash terminal management device, characterized in that, A client unit is applied to a StarShine access point, wherein the StarShine access point includes a main control unit, a communication unit, and a client unit; the communication unit is used to communicate with the cloud platform, and the client unit communicates with multiple StarShine terminals. The main control unit connects the communication unit and the client unit; The device includes: The information generation module is used to generate corresponding record information based on the received legitimate tag broadcast in response to receiving the legitimate tag broadcast; the record information includes the MAC address corresponding to the legitimate tag broadcast and the timestamp of receiving the legitimate tag broadcast; The lookup module is used to look up the MAC address in a preset first topology table and obtain the corresponding lookup result; the first topology table records the parameter information of the StarShine terminal in the historical communication of the client unit; The update module is used to update the first topology table based on the search result to obtain the second topology table; The first sending module is used to respond to the topology query command issued by the main control unit and send the latest second topology table at the current time to the main control unit; the main control unit is used to compare the second topology table with the historical topology table, and when there is a preset difference between the topology table and the historical topology table, send the second topology table to the cloud platform.

9. A starburst access point, characterized in that, It includes a main control unit, a communication unit, and a client unit; the communication unit is used to communicate with a cloud platform, and the client unit communicates with multiple StarShine terminals; the main control unit connects the communication unit and the client unit; the main control unit is used to implement the steps of the method as described in any one of claims 1 to 7.

10. A StarFlash terminal management system, characterized in that, It includes the StarSpark access point, cloud platform, and multiple StarSpark terminals as described in claim 9; the cloud platform communicates with the StarSpark access point through the communication unit of the StarSpark access point; and each of the StarSpark terminals communicates with the StarSpark access point through the client unit.

Images