Electronic price tag cluster communication method and device based on load awareness and storage medium

Abstract

The invention discloses an electronic price tag cluster communication method and device based on load awareness and a storage medium, and relates to the technical field of price tag management, and the electronic price tag cluster communication method based on load awareness comprises the steps: collecting communication dimension data and scene dimension data of an electronic price tag; processing the communication dimension data and the scene dimension data based on a load evaluation model, and dividing the electronic price tags into three load levels, namely a high load level, a medium load level and a low load level; generating a price tag updating task for the to-be-updated data of the electronic price tags in each sub-cluster based on the load levels of the electronic price tags; if it is judged that the preset condition is triggered, the transmission frequency of each electronic price tag is determined based on the condition type of the preset condition and a load feedback result obtained through sub-cluster network delay calculation; and scheduling and executing a price tag updating task based on the transmission frequency and the communication channel of the electronic price tag. The technical effect of reducing the updating delay of the electronic price tag can be achieved.

Description

Technical Field

[0001] This application relates to the field of price tag management technology, and in particular to a load-aware electronic price tag cluster communication method, device and storage medium. Background Technology

[0002] With the digital upgrade of scenarios such as new retail and smart warehousing, the application scale of electronic price tags continues to expand, and the number of price tags in some supermarkets and logistics centers has exceeded 10,000.

[0003] Currently, the industry mostly uses low-power wide-area network (LPWAN) technology to build price tag communication networks, employing a star topology and centrally receiving and distributing data through a gateway. To balance power consumption and transmission efficiency, related technologies often employ a batch polling update mechanism, and some also introduce collision avoidance algorithms to reduce transmission interference in small to medium-scale scenarios.

[0004] However, when the number of price tags reaches tens of thousands or more, the capacity of a single LoRa channel is limited, and concurrent transmission by multiple devices can easily cause signal conflicts, ultimately leading to network congestion. Summary of the Invention

[0005] The main objective of this application is to provide a load-aware electronic price tag cluster communication method, device, and storage medium, aiming to solve the technical problem that the single-channel capacity of electronic price tags is limited, and the concurrent transmission of multiple devices can easily cause signal conflicts, ultimately leading to network congestion.

[0006] To achieve the above objectives, this application provides a load-aware electronic shelf label cluster communication method, which includes: The system collects communication dimension data and scenario dimension data for electronic price tags. The communication dimension data includes the amount of data to be transmitted, signal strength, and historical communication success rate. The scenario dimension data includes the regional attributes and promotional activity status in supermarket scenarios and the frequency of shelf movement in warehouse scenarios. Based on the load assessment model, communication dimension data and scenario dimension data are processed, and electronic price tags are divided into three load levels: high load, medium load, and low load. The electronic price tags in each sub-cluster are updated based on their load level to generate price tag update tasks. The electronic price tags are divided into sub-clusters according to their physical location, and each sub-cluster is allocated a communication channel. If the preset conditions are triggered based on the scenario dimension data, the transmission frequency of each electronic price tag is determined based on the condition type of the preset conditions and the load feedback result obtained from the sub-cluster network latency calculation. Based on the transmission frequency and the communication channel of the electronic price tag, the price tag update task is scheduled and executed to push price tag data to the electronic price tag.

[0007] In one embodiment, the step of processing communication dimension data and scenario dimension data based on a load assessment model to classify electronic price tags into three load levels—high load, medium load, and low load—includes: The amount of data to be transmitted, signal strength, and historical communication success rate in the communication dimension data are assigned the first weight, the second weight, and the third weight, respectively. The regional attributes, promotional activity status, and shelf movement frequency in the scenario dimension data are assigned the fourth weight, the fifth weight, and the sixth weight, respectively. The weighted communication dimension data and scenario dimension data are normalized using a load assessment model to obtain the comprehensive load value of each electronic price tag. If the overall load value is greater than the first threshold, the corresponding electronic price tag is determined to be of a high load level; If the overall load value is less than or equal to the first threshold and greater than the second threshold, the corresponding electronic price tag is determined to be of medium load level. If the overall load value is less than or equal to the second threshold, the corresponding electronic price tag is determined to be of low load level, where the first threshold is greater than the second threshold.

[0008] In one embodiment, the step of normalizing the weighted communication dimension data and scenario dimension data using a load assessment model to obtain the comprehensive load value of each electronic price tag includes: Multiply the amount of data to be transmitted in the communication dimension data by the first weight, the signal strength by the second weight, and the historical communication success rate by the third weight to obtain the weighted amount of data to be transmitted, the weighted signal strength, and the weighted historical communication success rate. The weighted communication dimension data are mapped to standard intervals to obtain the standardized values ​​of the communication dimension. The larger the amount of data to be transmitted, the larger the standardized value; the weaker the signal strength, the larger the standardized value; and the lower the historical communication success rate, the larger the standardized value. Multiply the regional attributes in the scene dimension data by the fourth weight, the promotional activity status by the fifth weight, and the shelf movement frequency by the sixth weight to obtain the weighted regional attributes, the weighted promotional activity status, and the weighted shelf movement frequency. The weighted scenario dimension data are mapped to standard intervals to obtain the standardized values ​​of the scenario dimensions. The standardized values ​​of core areas are greater than those of non-core areas, the standardized values ​​of promotional states are greater than those of non-promotional states, and the standardized values ​​of higher shelf movement frequency are greater. The comprehensive load value of each electronic price tag is obtained by summing the standardized values ​​of the communication dimension and the scenario dimension using a load assessment model.

[0009] In one embodiment, before the step of generating a price tag update task based on the load level of the electronic price tags in each sub-cluster, the following steps are included: In response to the initial data of electronic price tags in each sub-cluster, identify duplicate instructions in the initial data; The initial data of electronic price tags in each sub-cluster are merged and processed based on repeated instructions to obtain the data to be updated for electronic price tags in each sub-cluster.

[0010] In one embodiment, the step of generating a price tag update task based on the load level of the electronic price tags in each sub-cluster, using the data to be updated for the electronic price tags, includes: Collect the data to be updated for electronic price tags in each sub-cluster. The data to be updated includes price change information, inventory status data and location change records. The data to be updated is classified according to the load level of the electronic shelf labels. The data to be updated for high load level electronic shelf labels is classified into the first data group, the data to be updated for medium load level electronic shelf labels is classified into the second data group, and the data to be updated for low load level electronic shelf labels is classified into the third data group. Perform duplicate checks on the data to be updated within the same data group, merge the data with the same content, and retain the unique identifier information; Based on the priority sorting of data groups, the data to be updated after merging in each data group is packaged into price tag update tasks. Each price tag update task includes a task identifier, the target electronic price tag address, and the corresponding data content to be updated.

[0011] In one embodiment, the preset conditions include supermarket promotion conditions, warehouse high-frequency movement conditions, and price stability conditions. The supermarket promotion condition is that there is a promotional activity status identifier in the scenario dimension data. The warehouse high-frequency movement condition is that the shelf movement frequency in the scenario dimension data reaches a set value. The price stability condition is that the price in the scenario dimension data is in a period of no change.

[0012] In one embodiment, the step of determining the transmission frequency of each electronic price tag based on scene-dimensional data to trigger a preset condition, the condition type of the preset condition, and the load feedback result calculated based on the sub-cluster network latency includes: Calculate the average and fluctuation values ​​of the sub-cluster network latency, and use the average and fluctuation values ​​as the load feedback results. If the average value exceeds the first latency threshold or the fluctuation value exceeds the fluctuation threshold, the sub-cluster network is determined to be in a congested state. If the supermarket promotion conditions are triggered and the sub-cluster network is not congested, the transmission frequency of the corresponding electronic shelf label will be set to the first high-frequency mode; if the sub-cluster network is congested, the transmission frequency of the corresponding electronic shelf label will be adjusted to the second high-frequency mode, and the frequency of the second high-frequency mode is lower than that of the first high-frequency mode. If the warehouse high-frequency movement condition is triggered and the sub-cluster network is not in a congested state, the transmission frequency of the corresponding electronic price tag will be set to the third high-frequency mode; if the sub-cluster network is in a congested state, the transmission frequency of the corresponding electronic price tag will be adjusted to the fourth high-frequency mode, and the frequency of the fourth high-frequency mode is lower than that of the third high-frequency mode. If the price stabilization condition is triggered, the transmission frequency of the corresponding electronic price tag will be set to low-frequency mode, which has a lower frequency than all high-frequency modes.

[0013] In one embodiment, after the step of scheduling and executing a price tag update task based on the transmission frequency and the communication channel of the electronic price tag to push price tag data to the electronic price tag, the following steps are included: If the price tag data push fails, retry based on preset rules; If the retry fails, the price tag update task will be marked as pending so that it can be executed first after the network is restored. If the network is offline, the local cached price tag update task will be executed in the order of task generation timestamps after the network is connected.

[0014] In addition, to achieve the above objectives, this application also provides a load-aware electronic price tag cluster communication device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the load-aware electronic price tag cluster communication method described above.

[0015] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program for implementing a load-aware electronic price tag cluster communication method is stored. The program for implementing the load-aware electronic price tag cluster communication method is executed by a processor to implement the steps of the load-aware electronic price tag cluster communication method as described above.

[0016] This application provides a load-aware electronic shelf tag cluster communication method. First, it collects communication dimension data and scenario dimension data of the electronic shelf tags. The communication dimension data includes the amount of data to be transmitted, signal strength, and historical communication success rate. The scenario dimension data includes regional attributes in supermarket scenarios, promotional activity status, and shelf movement frequency in warehouse scenarios. Based on a load assessment model, the communication dimension data and scenario dimension data are processed to classify the electronic shelf tags into three load levels: high load, medium load, and low load. The update data of the electronic shelf tags within each sub-cluster is used to generate shelf tag update tasks based on the load level of the electronic shelf tags. The electronic shelf tags are divided into sub-clusters according to their physical location, and each sub-cluster is allocated a communication channel. If a preset condition is triggered based on the scenario dimension data, the transmission frequency of each electronic shelf tag is determined based on the condition type and the load feedback result calculated based on the sub-cluster network latency. Based on the transmission frequency and the communication channel of the electronic shelf tag, the shelf tag update task is scheduled and executed to push shelf tag data to the electronic shelf tags.

[0017] In summary, this application utilizes a multi-dimensional data collection and intelligent scheduling mechanism to comprehensively assess the network load of electronic shelf labels from both communication and scenario perspectives. It categorizes devices into high, medium, and low load levels and divides them into sub-clusters based on physical location, allocating independent communication channels to each sub-cluster, thereby reducing signal conflicts and channel contention. Simultaneously, the system can trigger dynamic transmission frequency adjustments based on scenario conditions such as promotional activities and shelf movement, and, combined with sub-cluster network latency feedback, prioritize shelf label update tasks in high-load or critical scenarios. Through this hierarchical and differentiated communication strategy, network concurrency conflicts are significantly reduced, channel resource utilization is improved, and data transmission efficiency is enhanced, effectively solving the network congestion problem under large-scale shelf label deployment and achieving the technical effect of reducing electronic shelf label update latency. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the load-aware electronic price tag cluster communication method of this application. Figure 2This is a flowchart illustrating Embodiment 4 of the load-aware electronic price tag cluster communication method of this application; Figure 3 This is a flowchart illustrating Embodiment Six of the Load-Aware Electronic Price Tag Cluster Communication Method of this application; Figure 4 This is a schematic diagram of the hardware structure involved in the load-aware electronic price tag cluster communication device of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] Currently, the industry mostly uses low-power wide-area network (LPWAN) technology to build price tag communication networks, employing a star topology and centrally receiving and distributing data through a gateway. To balance power consumption and transmission efficiency, related technologies often use a batch polling update mechanism, and some also introduce collision avoidance algorithms to reduce transmission interference in small to medium-scale scenarios. However, when the number of price tags reaches tens of thousands or more, the single-channel capacity of LoRa is limited, and concurrent transmission by multiple devices can easily cause signal collisions, ultimately leading to network congestion.

[0025] This application employs a multi-dimensional data acquisition and intelligent scheduling mechanism to comprehensively assess the network load of electronic shelf labels from both communication and scenario perspectives. It categorizes devices into high, medium, and low load levels and further divides them into sub-clusters based on physical location, allocating independent communication channels to each sub-cluster, thereby reducing signal conflicts and channel contention. Simultaneously, the system can trigger dynamic transmission frequency adjustments based on scenario conditions such as promotional activities and shelf movement, and, combined with sub-cluster network latency feedback, prioritize shelf label update tasks in high-load or critical scenarios. Through this hierarchical and differentiated communication strategy, network concurrency conflicts are significantly reduced, channel resource utilization is improved, and data transmission efficiency is enhanced, effectively solving the network congestion problem under large-scale shelf label deployment and achieving the technical effect of reducing electronic shelf label update latency.

[0026] It should be noted that the execution subject of this embodiment can be a load-aware electronic shelf label cluster communication system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a load-aware electronic shelf label cluster communication device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a load-aware electronic shelf label cluster communication system as the execution subject as an example to describe this embodiment and the following embodiments.

[0027] Based on this, Embodiment 1 of this application proposes a load-aware electronic price tag cluster communication method, please refer to... Figure 1 The load-aware electronic price tag cluster communication method includes steps S10-S50: Step S10: Collect communication dimension data and scenario dimension data of electronic price tags. The communication dimension data includes the amount of data to be transmitted, signal strength, and historical communication success rate. The scenario dimension data includes the regional attributes in supermarket scenarios, the status of promotional activities, and the frequency of shelf movement in warehouse scenarios.

[0028] In this embodiment, communication dimension data is a set of indicators reflecting the data transmission status between the electronic shelf label and the network. The amount of data to be transmitted is the total amount of incomplete data that the electronic shelf label currently needs to send or receive. The signal strength is the strength of the wireless signal between the electronic shelf label and the communication gateway. The historical communication success rate is the proportion of the number of times the electronic shelf label successfully transmitted data in the past period to the total number of transmissions. Scenario dimension data is a set of information reflecting the application scenario characteristics of the electronic shelf label. The regional attribute is the functional classification of the area where the electronic shelf label is located in the supermarket scenario. The promotion activity status is whether a promotion is being carried out in the corresponding area in the supermarket scenario and the duration of the activity. The shelf movement frequency is the number of times the shelf where the electronic shelf label is located is moved per unit time in the warehouse scenario.

[0029] As an optional implementation, communication dimension data is collected in real time through the built-in communication module of the electronic shelf label. The amount of data to be transmitted is counted by the local storage unit of the shelf label and the size of the untransmitted data packets is reported every second. The signal strength is detected and recorded by the communication module every 15 seconds. The historical communication success rate is calculated by the server based on the transmission records of the past 12 hours. Scenario dimension data is obtained by connecting to the supermarket ERP system and the warehouse WMS system. The regional attributes are synchronized with the regional classification bound to the shelf in the system. The status of promotional activities is pushed by the supermarket system when the activity starts or stops. The frequency of shelf movement is counted and uploaded by the warehouse system at 30-minute intervals.

[0030] As another optional implementation method, communication dimension data adopts a combination of timed collection and threshold triggering. The amount of data to be transmitted is collected every 3 minutes. If it exceeds 50KB, it is collected immediately. Signal strength is automatically collected when the price tag initiates a transmission request. Historical communication success rate is updated daily. Scene dimension data is collected with manual assistance. Regional attributes are entered by staff when the price tag is installed. Promotional activity status is confirmed by recognizing supermarket promotional poster information. Shelf movement frequency is collected and uploaded in real time by shelf displacement sensors.

[0031] Step S20: Based on the load assessment model, process the communication dimension data and the scenario dimension data to divide the electronic price tag into three load levels: high load, medium load, and low load.

[0032] In this embodiment, the load assessment model is an algorithm model that comprehensively analyzes communication dimension data and scenario dimension data to quantify the network resource requirements of electronic shelf labels. High load level is the level where electronic shelf labels have high network resource requirements and failure to allocate them first may lead to transmission delays. Medium load level is the level where electronic shelf labels have moderate network resource requirements and resources can be allocated normally. Low load level is the level where electronic shelf labels have low network resource requirements and resources can be allocated without affecting high load and medium load shelf labels.

[0033] As an optional implementation, the load assessment model adopts a random forest model. First, the communication dimension data and the scenario dimension data are standardized. The amount of data to be transmitted (0-200KB) is mapped to 0-0.3, the signal strength (-130dBm to -40dBm) is mapped to 0-0.2, the historical communication success rate (0%-100%) is mapped to 0-0.2, the regional attributes (fresh produce area 0.15, food area 0.1, daily necessities area 0.05), the promotional activity status (active 0.15, inactive 0), and the shelf movement frequency (0-15 times / hour) is mapped to 0-0.15. The standardized data is input into the trained model, and the output is a load score of 0-1, where 0.7-1 corresponds to a high load level, 0.3-0.7 corresponds to a medium load level, and 0-0.3 corresponds to a low load level.

[0034] As an alternative implementation, the load assessment model employs a weighted scoring algorithm, setting the following weights: data volume to be transmitted (0.3), signal strength (0.2), historical communication success rate (0.2), regional attribute (0.15), promotional activity status (0.1), and shelf movement frequency (0.05). Each indicator is scored numerically: data volume to be transmitted ≥80KB (10 points), 40-80KB (6 points), <40KB (2 points); signal strength ≥-60dBm (10 points), -80 to -60dBm (6 points), <-80dBm (2 points); historical communication success rate ≥95% (10 points), 80%-95% (6 points), <80% (2 points); regional attribute: fresh produce (10 points), food (6 points), daily necessities (2 points); promotional activity status: active (10 points), inactive (2 points); shelf movement frequency ≥8 times / hour (10 points), 3-8 times / hour (6 points), <3 times / hour (2 points). A weighted total score is calculated, with 8-10 points corresponding to a high load level, 4-8 points corresponding to a medium load level, and 0-4 points corresponding to a low load level.

[0035] Step S30: Generate a price tag update task based on the load level of the electronic price tag and the data to be updated of the electronic price tag in each sub-cluster. The electronic price tag is divided into sub-clusters according to its physical location, and a communication channel is allocated to each sub-cluster.

[0036] In this embodiment, a sub-cluster is a small set of electronic price tags formed by dividing all electronic price tags according to their physical locations, and each sub-cluster contains a certain number of electronic price tags; the communication channel is a wireless frequency band or logical channel for transmitting data between the electronic price tags and the gateway; the price tag update task is an instruction containing the update priority of the data content to be updated identified by the electronic price tag, which is used to guide the system to push data.

[0037] As an optional implementation, sub-clusters are divided according to the physical space grid of supermarkets or warehouses. In the supermarket scenario, the grid is divided into 8m×8m grids, and each sub-cluster contains 60-80 price tags. A fixed LoRa communication channel is allocated to each sub-cluster. When generating a price tag update task, the data of high-load price tags to be updated in the sub-cluster is integrated into a priority task package, the data of medium-load price tags is integrated into a regular task package, and the data of low-load price tags is integrated into a delayed task package. The task package includes the update time limit of the price tag ID data type.

[0038] As another optional implementation, sub-clusters are divided according to functional areas and physical locations. In a warehousing scenario, price tags in the same shelf column are divided into a sub-cluster, with each sub-cluster containing 30-50 price tags. Dynamic channel allocation is adopted. After the initial channel allocation, the occupancy rate is detected in real time. If the occupancy rate exceeds 65%, an idle channel is reallocated. When generating a price tag update task, priority is set according to the load level. High-load tasks have priority 1, medium-load tasks have priority 2, and low-load tasks have priority 3. The task carries channel information to ensure accurate reception of price tags.

[0039] Step S40: If a preset condition is triggered based on the scene dimension data, the transmission frequency of each electronic price tag is determined based on the condition type of the preset condition and the load feedback result obtained based on the sub-cluster network latency calculation.

[0040] In this embodiment, the preset condition is a pre-set scenario event that triggers the transmission frequency adjustment, the condition type is the specific category of the preset condition, the sub-cluster network latency is the average time from when the price tag sends a data request to when it receives a response within the sub-cluster, the load feedback result is the current network load status determined based on the sub-cluster network latency, and the transmission frequency is the time interval between the electronic price tag and the gateway for data transmission.

[0041] As an optional implementation, the preset conditions include that the frequency of shelf movement in the warehouse scenario during the promotional activity in the supermarket scenario is ≥10 times / hour. The condition type is divided into promotion-triggered type and movement-triggered type. After determining the preset conditions, the network latency of the sub-cluster is calculated. ≤400ms indicates a light load, 400-900ms indicates a moderate load, and >900ms indicates a heavy load. Under the promotion-triggered condition, the transmission frequency of price tags is 1 minute / time for high load, 5 minutes / time for medium load, and 12 minutes / time for low load. When the load is heavy, the transmission frequency of all price tags is reduced by 25%. Under the movement-triggered condition, the transmission frequency of price tags is 30 seconds / time for high load, 3 minutes / time for medium load, and 8 minutes / time for low load. When the load is light, the transmission frequency of all price tags is increased by 20%.

[0042] As another optional implementation, the preset conditions include that the frequency of shelf movement in the fresh food area of ​​a supermarket from 7 to 9 am is ≥6 times / hour for 20 consecutive minutes in the warehouse scenario. The condition type is divided into time period area trigger type and continuous movement trigger type. The average network latency of the sub-cluster over the past 3 minutes is calculated. ≤350ms is light load, 350-850ms is medium load, and >850ms is heavy load. Under the time period area trigger type, high load price tags are moved 30 seconds / time, medium load 2 minutes / time, and low load 6 minutes / time. When the load is heavy, the frequency of high load price tags is prioritized and the medium and low load frequency is extended to 1.4 times. Under the continuous movement trigger type, high load price tags are moved 25 seconds / time, medium load 1 minute / time, and low load 4 minutes / time. When the load is light, the medium and low load frequency is shortened to 0.7 times.

[0043] The preset conditions include supermarket promotion conditions, warehouse high-frequency movement conditions, and price stability conditions. The supermarket promotion condition is that there is a promotional activity status identifier in the scenario dimension data. The warehouse high-frequency movement condition is that the shelf movement frequency in the scenario dimension data reaches a set value. The price stability condition is that the price in the scenario dimension data is in a period of no change.

[0044] Step S50: Based on the transmission frequency and the communication channel of the electronic price tag, schedule and execute the price tag update task to push price tag data to the electronic price tag.

[0045] In this embodiment, scheduling execution is the process by which the system arranges the execution of price tag update tasks according to priority and time order based on transmission frequency and communication channel information; price tag data is the data used to update the content displayed on electronic price tags, including commodity price, inventory quantity, promotional information, and commodity code.

[0046] As an optional implementation, a priority scheduling algorithm is adopted to establish a task scheduling queue. High-load price tag update tasks are placed at the front of the queue, and medium and low load tasks are placed at the back. According to the sub-cluster communication channel and transmission frequency, the system sends tasks on the designated channel at corresponding intervals. For example, when the high-load price tag frequency is 1 minute / time, it is sent once per minute. When pushing price tag data, fragmented transmission is adopted. If the data volume exceeds 10KB, it is divided into 2KB small data packets and sent sequentially to ensure stable transmission.

[0047] As another optional implementation, a time-slice round-robin scheduling combined with load feedback is adopted. The time is divided into 15-second time slices, and the sub-cluster channel is allocated to the cluster task in the corresponding time slice. The number of time slices occupied by the price tag is determined according to the transmission frequency. High-load price tags occupy 4 time slices every 1 minute, medium-load price tags occupy 1 time slice every 5 minutes, and low-load price tags occupy 1 time slice every 10 minutes. Before pushing, the channel idle status is detected. If it is idle, it is sent immediately. If it is busy, it waits for the next time slice. At the same time, the number of time slices is adjusted according to real-time load feedback. Sub-clusters with heavy loads have more time slices.

[0048] For example, a large warehouse (10,000 square meters, 15,000 electronic shelf labels) needs to conduct a quarterly inventory check. The warehouse shelves are divided by aisles, and some shelves are frequently moved due to replenishment needs. Data on the amount of data to be transmitted (average 75KB for frequently moved shelf labels), signal strength (average -60dBm), and historical communication success rate (average 92%) are collected through a shelf label communication module. This data is then integrated with the warehouse management system (WMS) to obtain scenario-based data, including shelf movement frequency (12 times / hour for some shelves). No supermarket scenario data is available. A weighted scoring algorithm is used. 75KB of data to be transmitted earns 10 points (weight 3); a signal strength of -60dBm earns 10 points (weight 2); a historical communication success rate of 92% earns 6 points (weight 1.2); no regional attributes or promotional activity status earns 2 points each (weighted 0.3 and 0.2 respectively); and a shelf movement frequency of 12 times / hour earns 10 points (weight 0.5). The total score is 3+2+1.2+0.3+0.2+0.5=7.2 points. Frequently moved shelf price tags are classified as medium-load level, and other shelf price tags are classified as low-load level. Sub-clusters are divided according to warehouse aisles, totaling 30 sub-clusters, each containing 500 price tags. A dynamic LoRa channel is allocated to each sub-cluster. When generating price tag update tasks, medium-load price tag data is integrated into a regular task package, and low-load price tag data is integrated into a delayed task package. Based on a shelf movement frequency of 12 times / hour, a preset condition was triggered, with the condition type being movement-triggered. The average network latency of the sub-cluster was calculated to be 380ms, and the load feedback indicated a light load. The transmission frequency for medium-load price tags was determined to be 3 minutes / time, and for low-load price tags, 8 minutes / time. Due to the light load, the transmission frequency was increased by 20%, adjusted to 2 minutes 30 seconds / time for medium load and 6 minutes 40 seconds / time for low load. A time-slice round-robin scheduling method was adopted, with a time slice set to 15 seconds. Medium-load price tags occupied 10 time slices every 2 minutes 30 seconds, and low-load price tags occupied 4 time slices every 6 minutes 40 seconds. Before pushing price tag data, the channel was checked; if idle, it was sent, and if busy, it waited. At the same time, the number of time slices for the medium-load sub-cluster was increased based on real-time load feedback. Ultimately, the inventory data update for 15,000 price tags was successfully completed.

[0049] This embodiment achieves a comprehensive understanding of the communication status and scenario characteristics of electronic price tags through multi-dimensional data collection, providing accurate data support for load assessment; the load assessment model accurately classifies the load levels of price tags to avoid blind resource allocation; sub-clusters are divided according to physical location and channels are allocated to reduce signal conflicts and lower the risk of network congestion; the transmission frequency is dynamically adjusted based on scenario conditions and load feedback to ensure critical needs while avoiding resource waste.

[0050] Based on any of the above embodiments, in Embodiment 2 of this application, step S20 includes: Step S21: Assign corresponding weights to the communication dimension data and the scenario dimension data respectively: assign the amount of data to be transmitted in the communication dimension data as the first weight, the signal strength as the second weight, and the historical communication success rate as the third weight; assign the regional attribute in the scenario dimension data as the fourth weight, the promotional activity status as the fifth weight, and the shelf movement frequency as the sixth weight.

[0051] In this embodiment, the first weight is a coefficient that measures the impact of the amount of data to be transmitted on the load assessment. The larger the data volume, the higher the contribution of the indicator corresponding to this weight to the load level determination. The second weight is a coefficient that reflects the importance of signal strength stability to the load assessment. The weaker the signal, the more this indicator needs to be included in the load risk consideration. The third weight is a coefficient that reflects the reference value of historical communication success rate for current load judgment. The lower the success rate, the more priority should be given to ensuring resources for the transmission of this price tag. The fourth weight is a coefficient that distinguishes the differences in load demand between different functional areas (such as supermarket fresh food area and warehouse replenishment area). The fifth weight is a coefficient that reflects whether promotional activities increase the demand for data transmission. The sixth weight is a coefficient that correlates the frequency of shelf movement with the demand for data update frequency.

[0052] As the first optional implementation method (dynamic weight configuration), for supermarket scenarios, the system connects to the supermarket ERP system to obtain the promotion intensity and regional sales popularity in real time: if the fresh food section is in the peak promotion period, the first weight is set to 0.3 (high amount of data to be transmitted), the fifth weight is set to 0.15 (significant promotion impact), and the sixth weight is set to 0 (no shelf movement); if it is not the promotion period, the fifth weight is lowered to 0.05 and the third weight is raised to 0.25 (prioritizing transmission stability). The weight values ​​are dynamically updated every hour according to the scenario data.

[0053] As a second optional implementation method (fixed weight + scenario adaptation), the following basic weights are preset for the warehousing scenario: first weight 0.25, second weight 0.2, third weight 0.2, fourth weight 0.1, fifth weight 0 (no promotion), and sixth weight 0.25 (significant impact of shelf movement); when the frequency of shelf movement is detected to exceed 10 times / hour per day, the sixth weight is temporarily increased to 0.3, and the fourth weight is simultaneously decreased to 0.05 to adapt to the load assessment requirements of high-frequency movement scenarios.

[0054] Step S22: Normalize the weighted communication dimension data and scenario dimension data using the load assessment model.

[0055] In this embodiment, normalization is the process of converting weighted indicators of different dimensions (such as the amount of data to be transmitted "KB", signal strength "dBm", success rate "%)) into a unified numerical range of 0-1, with the aim of eliminating evaluation bias caused by differences in data magnitude; the load assessment model is a comprehensive algorithm model that integrates weight calculation, normalization algorithm and threshold determination, and the core of this process is to perform normalization operation.

[0056] As the first optional implementation method (Min-Max normalization), for scenarios where the data distribution is relatively concentrated (such as supermarkets during non-promotional periods), the formula is adopted: Normalized value = (weighted index value - minimum index value) / (maximum index value - minimum index value); For example, if the weighted range of the amount of data to be transmitted is 5-50, and the weighted value of a certain price tag is 30, then the normalized value = (30-5) / (50-5) ≈ 0.56, ensuring that the index value is evenly distributed in the 0-1 range.

[0057] As a second optional implementation method (Z-Score normalization), for scenarios with large data fluctuations (such as peak periods of warehouse replenishment), the formula is used: Normalized value = (Weighted index value - Index mean) / Index standard deviation; For example, if the weighted mean of historical communication success rate is 0.8 and the standard deviation is 0.15, and the weighted value of a certain price tag is 0.5, then the normalized value = (0.5-0.8) / 0.15 = -2, and then it is transformed into a range of 0-1 by shifting (such as the final value = 0.2) to adapt to the impact of extreme data on the evaluation results.

[0058] Step S23: Calculate the comprehensive load value of each electronic price tag based on the normalization processing result.

[0059] In this embodiment, the comprehensive load value is the final quantified value obtained by summing the normalized communication dimension data and the scene dimension data. The value range is 0-1, which directly reflects the overall demand of electronic price tags for network resources. The calculation logic is: "Comprehensive load value = normalized amount of data to be transmitted + normalized signal strength + normalized historical communication success rate + normalized regional attributes + normalized promotional activity status + normalized shelf movement frequency".

[0060] As an optional implementation, the system first verifies the validity of each normalized indicator during calculation (e.g., removing abnormal data with signal strength normalized values ​​>1 or <0 and replacing them with historical averages), and then accumulates the indicator values ​​in a preset order: first, the three normalized indicators of the communication dimension are accumulated, and then the three normalized indicators of the scene dimension are accumulated, finally obtaining the comprehensive load value; for example, if the sum of the normalized values ​​of a certain price tag in the communication dimension is 0.45 and the sum of the normalized values ​​in the scene dimension is 0.3, its comprehensive load value = 0.45 + 0.3 = 0.75.

[0061] Step S24: Based on the comparison between the comprehensive load value and the preset threshold, classify the load level of the electronic price tag: if the comprehensive load value is greater than the first threshold, it is determined to be a high load level; if the comprehensive load value is less than or equal to the first threshold but greater than the second threshold, it is determined to be a medium load level; if the comprehensive load value is less than or equal to the second threshold, it is determined to be a low load level, wherein the first threshold is greater than the second threshold.

[0062] In this embodiment, the first threshold is a critical value that distinguishes between high load and medium load, which is set by the system based on historical network congestion data (usually corresponding to the load value when the network resource utilization rate is 80%); the second threshold is a critical value that distinguishes between medium load and low load, corresponding to the load value when the network resource utilization rate is 40%; the load level is a classification result based on the comprehensive load value, reflecting the priority of the price tag's network resource demand.

[0063] As an optional implementation, for scenarios with more than 10,000 price tags, the backend management module presets a first threshold of 0.7 and a second threshold of 0.3: when the comprehensive load value of a price tag in a supermarket's fresh food section is 0.82 (>0.7), it is determined to be a high load level; when the comprehensive load value of a price tag on a regular warehouse shelf is 0.5 (0.3<0.5≤0.7), it is determined to be a medium load level; when the comprehensive load value of a price tag in a supermarket's daily necessities section is 0.25 (≤0.3), it is determined to be a low load level; the thresholds can be calibrated every 3 months based on quarterly network load statistics.

[0064] For example, taking a large supermarket promotion scenario with tens of thousands of electronic price tags as an example, the load level is divided as follows: For the fresh food promotion area, the first weight is 0.3 (high amount of data to be transmitted), the second weight is 0.2 (signal affected by refrigeration equipment), the third weight is 0.2 (transmission success rate needs to be guaranteed), the fourth weight is 0.15 (fresh food area is the core area), the fifth weight is 0.1 (promotion activities), and the sixth weight is 0 (no shelf movement); Min-Max normalization is used, and the weighted range of the amount of data to be transmitted is 5-60. The weighted value of a certain fresh food price tag is 45, and the normalized value is (45-5) / (60-5)≈0.73. The sum of the normalized values ​​of other indicators is 0.12; After verifying that there is no abnormal data, the comprehensive load value is 0.73+0.12=0.85; Since 0.85>the first threshold of 0.7, the fresh food price tag is determined to be of high load level, and communication channels are allocated in the future.

[0065] As a third optional implementation, for supermarket scenarios, the system connects to both the customer's marketing management system and display management system via API: Data Acquisition Layer: Real-time promotional data (such as promotional area range, promotional product SKUs, list of merchants with near-expiry products, and number of days until expiry) is obtained from the marketing management system; regional display planning data (such as the physical coordinates of the fresh produce and daily necessities areas, and the binding relationship between price tags and areas) is obtained from the display management system. Algorithm Classification Layer: An algorithm model is used to establish a "region-marketing attribute" mapping relationship. If a region simultaneously meets the criteria of "display method is fresh produce area" and "marketing data shows it is in a promotional period," it is automatically classified as a high-load area. If a region meets the criteria of "marketing data shows it is a near-expiry product merchant coverage area" (number of days until expiry ≤ 7 days) and "display method is regular sales area," it is classified as a medium-load area. Loading Area; If an area meets the criteria of "display method is daily necessities area" and "marketing data has no promotions or near-expiry product associations", it is classified as a low-load area; Weight Adaptation Layer: Adjust the scene dimension weights according to the load area type divided by the algorithm: The fourth weight (regional attribute) of the high-load area (promotion area, fresh food area) is increased to 0.2 and the fifth weight (promotion activity status) is increased to 0.15; The fourth weight of the medium-load area (near-expiry merchant area) is set to 0.12 and the newly added "near-expiry attribute weight" (belonging to the scene dimension supplementary indicator) is set to 0.08; The fourth weight of the low-load area (daily necessities area) is decreased to 0.05 and the fifth weight is set to 0.03; The weight adjustment results are synchronized to the load assessment process in real time and updated every 2 hours according to marketing data (e.g., after the promotion ends, the original promotion area is automatically adjusted from the high-load area to the regular area, and the corresponding weight is adjusted down accordingly).

[0066] For example, a supermarket is running a fresh produce promotion on the weekend. The marketing system reports that the promotion area covers fresh produce sections 1-3, while near-expiry goods are concentrated in regular sales sections 5-6. The display system reports that sections 1-3 are fresh produce display areas, and sections 7-10 are daily necessities display areas. The fusion algorithm model automatically determines that sections 1-3 (fresh produce promotion area) are high-load areas, sections 5-6 (near-expiry goods section) are medium-load areas, and sections 7-10 (daily necessities section) are low-load areas. Correspondingly, the fourth weight (regional attribute) is adjusted as follows: high-load area 0.2, medium-load area 0.12, low-load area 0.05; and the fifth weight (promotional activity status) is adjusted as follows: high-load area 0.15, medium-load area 0.05, low-load area 0.03, ensuring that the scenario dimension weights accurately match the actual load requirements.

[0067] This implementation method deeply integrates customer marketing data with display methods, avoiding the subjectivity of simply relying on manual setting of regional load, and making the load judgment of the scenario dimension more in line with actual business needs. Compared with the traditional fixed area weight method, it can dynamically adapt to changes in marketing scenarios such as promotions and near-expiration, further improving the accuracy of the load assessment model, providing a more reliable basis for prioritizing the allocation of resources for price tags in high-load areas, helping to alleviate network congestion problems in large-scale price tag scenarios, and making the electronic price tag update latency lower than existing technologies.

[0068] This embodiment refines the steps of weight assignment, normalization, comprehensive value calculation, and threshold determination, making the load level classification logic clearer and more traceable. Compared with the single-dimensional load judgment in the prior art, multi-dimensional weighting and scenario-based normalization can more accurately identify high-demand price tags, providing a clear basis for subsequent resource allocation. This makes the network congestion relief effect in large-scale price tag scenarios more significant, and the electronic price tag update delay is lower than that of the prior art.

[0069] Based on any of the above embodiments, in Embodiment 3 of this application, step S22 includes: Step S221: Multiply the amount of data to be transmitted in the communication dimension data by the first weight, the signal strength by the second weight, and the historical communication success rate by the third weight to obtain the weighted amount of data to be transmitted, the weighted signal strength, and the weighted historical communication success rate.

[0070] In this embodiment, the weighted amount of data to be transmitted is the product of the amount of data to be transmitted and the first weight, which is used to quantify the impact of the data amount on the network load. The larger the data amount, the higher the value, and the more obvious the load demand. The weighted signal strength is the product of the signal strength and the second weight. The signal strength is in dBm. The more negative the value, the weaker the signal. This product can reflect the correlation between signal stability and load. The weighted historical communication success rate is the product of the historical communication success rate and the third weight. The success rate is in percentage. This value can reflect the reference significance of past transmission reliability for current load demand. The first weight, the second weight, and the third weight are preset coefficients based on the degree of influence of each indicator of the communication dimension on the load. The sum of the three must be adapted to the sum of the weights of the scenario dimension to balance the evaluation result.

[0071] As an optional implementation method, for supermarket scenarios with tens of thousands of electronic shelf labels, the first weight is set to 0.3, the second weight to 0.2, and the third weight to 0.2. If the amount of data to be transmitted for an electronic shelf label in a fresh produce area is 60KB, the signal strength is -65dBm, and the historical communication success rate is 92%, then the weighted amount of data to be transmitted = 60 × 0.3 = 18, the weighted signal strength = -65 × 0.2 = -13, and the weighted historical communication success rate = 92 × 0.2 = 18.4.

[0072] Step S222: Map the weighted communication dimension data to standard intervals to obtain standardized communication dimension values. The larger the amount of data to be transmitted, the larger the standardized value; the weaker the signal strength, the larger the standardized value; and the lower the historical communication success rate, the larger the standardized value.

[0073] In this embodiment, the standard interval is a numerical range of 0-1, used to unify the magnitude of communication data with different dimensions and avoid evaluation bias due to unit differences; the standardized value of the communication dimension is the result of the weighted communication data after mapping processing. This value can directly participate in the subsequent load summation, and its change rule is positively correlated with the load demand. That is, when the amount of data to be transmitted is high, the signal is weak, and the success rate is low, a high standardized value represents a high load demand; the mapping processing is the calculation process of converting the weighted data to the standard interval. It is necessary to first count the extreme values ​​of the indicators of the same type of price tag as the mapping boundary.

[0074] As an optional implementation method, the Min-Max mapping method is used to determine the boundaries: the maximum value of the amount of data to be transmitted in the tens of thousands of price tags is 100KB and the minimum value is 5KB, the maximum value of the signal strength is -50dBm and the minimum value is -120dBm, and the maximum value of the historical communication success rate is 100% and the minimum value is 60%. The standardized value of the amount of data to be transmitted = (18-5×0.3) / (100×0.3-5×0.3) = (18-1.5) / (30-1.5)≈0.56; the standardized value of the signal strength = (-50×0.2-(-13)) / (-50×0.2-(-120×0.2)) = (-10+13) / (-10+24)≈0.21; the standardized value of the historical communication success rate = (100×0.2-18.4) / (100×0.2-60×0.2) = (20-18.4) / (20-12) =0.2; the final sum of the standardized values ​​of the communication dimensions = 0.56+0.21+0.2=0.97.

[0075] Step S223: Multiply the regional attributes in the scene dimension data by the fourth weight, the promotional activity status by the fifth weight, and the shelf movement frequency by the sixth weight to obtain the weighted regional attributes, the weighted promotional activity status, and the weighted shelf movement frequency.

[0076] In this embodiment, the weighted regional attribute is the product of the regional attribute and the fourth weight. The regional attribute is assigned a value according to its functional importance, with core areas (such as fresh produce areas and promotional areas) assigned a higher value than non-core areas (such as daily necessities areas). This product can reflect the impact of regional functions on the load. The weighted promotional activity status is the product of the promotional activity status and the fifth weight. It is assigned a value of 1 when active and 0 when inactive. This product can quantify the load increment in promotional scenarios. The weighted shelf movement frequency is the product of the shelf movement frequency and the sixth weight. The frequency is in units of times / hour. This product can reflect the real-time transmission demand in dynamic scenarios. The fourth, fifth, and sixth weights are preset coefficients based on the degree of influence of each indicator in the scenario dimension on the load. They need to complement the sum of the communication dimension weights to ensure a balanced evaluation.

[0077] As an optional implementation, for supermarket scenarios, the fourth weight is set to 0.15, the fifth weight to 0.1, and the sixth weight to 0 (supermarkets have no shelf movement requirements). Core areas are assigned a value of 1, non-core areas are assigned a value of 0, activities are assigned a value of 1, and non-activities are assigned a value of 0. If a price tag is located in the core fresh produce area and is in a promotional activity, then the weighted area attribute = 1 × 0.15 = 0.15, the weighted promotional activity status = 1 × 0.1 = 0.1, and the weighted shelf movement frequency = 0 × 0 = 0.

[0078] Step S224: Map the weighted scene dimension data to standard intervals to obtain the standardized values ​​of the scene dimensions. The standardized values ​​of the core area are greater than those of the non-core area, the standardized values ​​of the promotional state are greater than those of the non-promotional state, and the higher the frequency of shelf movement, the greater the standardized value.

[0079] In this embodiment, the scene dimension standardized value is a 0-1 range value obtained by mapping the weighted scene data. It is used to unify the magnitude with the communication dimension standardized value to ensure that the influence of each dimension is balanced when summing. Its change rules are directly related to the business scenario load requirements. Core areas, promotion status, and high mobile frequency all correspond to higher standardized values ​​because the need to update price tag data is more urgent in these scenarios.

[0080] As an optional implementation, the Min-Max mapping method is adopted: the weighted maximum value of regional attributes is 0.15 (core area) and the minimum value is 0 (non-core area); the weighted maximum value of promotional activity status is 0.1 (in progress) and the minimum value is 0 (out of progress); the weighted maximum value of shelf movement frequency is 0 (supermarket scenario) and the minimum value is 0. Therefore, the standardized value of regional attributes = 0.15 / 0.15 = 1, the standardized value of promotional activity status = 0.1 / 0.1 = 1, and the standardized value of shelf movement frequency = 0 / 0 = 0. The final sum of standardized values ​​for the scenario dimensions = 1 + 1 + 0 = 2. To balance with the sum of communication dimensions (0-0.7 weight corresponds to 0-0.7 standardized sum), it is converted to 1 according to the weight ratio (0.3 scenario weight corresponds to 0-1 standardized sum).

[0081] Step S225: Summing the standardized values ​​of the communication dimension and the standardized values ​​of the scenario dimension using the load assessment model to obtain the comprehensive load value of each electronic price tag.

[0082] In this embodiment, the comprehensive load value is the sum of the standardized values ​​of the communication dimension and the standardized values ​​of the scene dimension, with a value range of 0-2 (0-1 after conversion for the communication dimension 0-0.7, and 0-1 after conversion for the scene dimension 0-0.3). This value can intuitively reflect the overall load demand of the price tag. The higher the value, the higher the demand for network resources for the price tag, which is the core basis for subsequent classification of high, medium and low load levels.

[0083] As an optional implementation, the sum of the standardized values ​​of the communication dimension, 0.97 (approximately 0.97 after being weighted by 0.7), is added to the sum of the standardized values ​​of the scene dimension, 1 (1 after being weighted by 0.3), to obtain the comprehensive load value = 0.97 + 1 = 1.97. Since a threshold range needs to be matched in actual applications (such as 0-2 corresponding to the subsequent 0-1 threshold), it is finally adjusted proportionally to 1.32 to ensure that it is compatible with the load level judgment standard.

[0084] For example, a large supermarket with tens of thousands of electronic shelf labels is conducting a promotional activity in its fresh produce section. The system obtains communication data for a certain fresh produce shelf label, which shows a data volume of 60KB to be transmitted, a signal strength of -65dBm, and a historical communication success rate of 92%. The scenario data is: the area attribute is the core fresh produce area, the promotional activity status is "in progress," and there is no need for shelf movement. The system first calculates weighted communication data with a first weight of 0.3, a second weight of 0.2, and a third weight of 0.2, and then uses the Min-Max mapping method to obtain a total standardized value of 0.97 for the communication dimension. Next, it calculates weighted scenario data with a fourth weight of 0.15, a fifth weight of 0.1, and a sixth weight of 0, and similarly uses the Min-Max mapping method to obtain a total standardized value of 1 for the scenario dimension. Finally, the two are added together and adjusted proportionally to obtain a comprehensive load value of 1.32, providing a quantitative reference for subsequently judging the load level of the shelf label.

[0085] It should be noted that the data communication dimension can distinguish the load level based on data such as the communication frequency of electronic price tags; the load level of price tags can be switched freely through intelligent algorithms. For example, when the communication frequency and other data of a high-load price tag drop to a certain threshold within a specific period, the system will automatically downgrade the price tag.

[0086] This embodiment eliminates the interference of different dimensional data on load assessment by weighting, standardizing and summing communication and scenario-dimensional data step by step, making the comprehensive load value more accurately reflect the actual network demand of the price tag. Compared with the existing technology that judges the load based on only a single data (such as the amount of data to be transmitted), the multi-dimensional integrated assessment logic can more comprehensively cover network status and business scenario factors, providing a reliable basis for resource allocation in scenarios with tens of thousands of price tags, thereby effectively alleviating network congestion problems and making the electronic price tag update delay lower than that of the existing technology.

[0087] Based on any embodiment, in Embodiment 4 of this application, referring to Figure 2 Before the step of generating a price tag update task based on the load level of the electronic price tags in each sub-cluster, the following steps are included: Step A10: In response to the initial data of the electronic price tags in each sub-cluster, determine the duplicate instructions in the initial data.

[0088] In this embodiment, the initial data is the set of original data update requests reported by electronic price tags in each sub-cluster to the system, including information such as price tag identifier, content to be updated, and request time; duplicate instructions are instructions in the initial data that are completely identical, or whose update targets and update content are the same but whose price tag identifiers partially overlap, such as multiple price tags simultaneously requesting to update the same price of the same product, or different price tags requesting to perform the same inventory status marking operation; responding to initial data refers to the triggering action of the system to start the instruction analysis process after receiving the initial data reported by all price tags in the sub-cluster. As an optional implementation, for supermarket sub-cluster scenarios, the system first receives initial data according to the sub-cluster dimension, and breaks down each instruction into three core fields: "update type (price / inventory / promotion), update content (specific value / status), and associated product code". Duplicate determination is achieved by calculating the combined hash value of these three fields: if the combined hash values ​​of different price tag instructions are exactly the same, it is determined to be a duplicate instruction; for example, if 20 price tags in a fresh food sub-cluster all report "price update - product A to 9.9 yuan - code 001", after the system calculates the combined hash value, it identifies these 20 instructions as duplicate instructions and marks the number of times they are repeated and the list of price tag identifiers involved.

[0089] Step A20: Based on the repeated instructions, the initial data of the electronic price tags in each sub-cluster are merged and processed to obtain the data to be updated for the electronic price tags in each sub-cluster.

[0090] In this embodiment, the merging process refers to the process by which the system deduplicates and integrates the identified duplicate instructions, retains one core instruction and associates it with all related price tag identifiers, and at the same time eliminates completely duplicate redundant instructions; the data to be updated is a simplified data set obtained after the merging process, which includes the deduplicated instruction content, associated price tag range and update priority, and can be directly used to generate subsequent price tag update tasks; the core purpose of the merging process is to reduce the amount of data transmission and instruction execution redundancy. As an optional implementation, the system adopts a merging mode of "core instruction + associated price tag pool" for duplicate instructions: taking the duplicate instruction "price update - product A to 9.9 yuan - code 001" identified in the data as an example, one core instruction is retained, and the 20 price tag identifiers involved are integrated into an "associated price tag pool" and appended to the core instruction; at the same time, independent instructions without duplicates in the initial data (such as a price tag requesting "inventory update - product B to 100 pieces - code 002") are directly retained; finally, the data to be updated is formed, which includes "deduplicated core instruction + independent instructions", reducing redundant instructions by 19 compared to the initial data.

[0091] This embodiment effectively eliminates redundant instructions in the initial data by adding duplicate instruction identification and merging processing before generating the price tag update task, reducing repetitive operations in subsequent data transmission and task execution. Compared with the existing technology of directly generating tasks based on the original initial data, the amount of data to be updated is significantly reduced, reducing the bandwidth occupation of the sub-cluster communication channel and alleviating network transmission pressure. At the same time, the simplified data to be updated makes subsequent task scheduling more efficient, avoiding update delays caused by duplicate instructions occupying resources, and ultimately making the electronic price tag update delay lower than that of the existing technology.

[0092] Based on any of the above embodiments, in Embodiment 5 of this application, step S30 includes: Step S301: Collect the data to be updated for electronic price tags in each sub-cluster. The data to be updated includes price change information, inventory status data, and location change records.

[0093] In this embodiment, the data to be updated is a dynamic set of information that the electronic shelf labels need to be synchronized to the display. Among them, the price change information is the specific value of the price adjustment, the effective time, and the original price record, which is used to ensure that the price displayed on the shelf is consistent with the system. The inventory status data is the current inventory quantity of the product, the inventory warning threshold, and the inventory change time, which is used to indicate out-of-stock or replenishment information. The location change record is the coordinates of the shelf where the electronic shelf label is located in the warehousing scenario after it is moved, the change time, and the associated product code, which is used to accurately locate the product location. The sub-cluster is a small set of shelf labels divided according to physical location. The collection operation is carried out independently within the sub-cluster to avoid cross-cluster data interference.

[0094] As an optional implementation, for the fresh produce sub-cluster (containing 200 electronic price tags) in a supermarket scenario, the system receives data to be updated in real time through the sub-cluster gateway: price change information includes the daily fresh produce discount price (e.g., pork adjusted from 30 yuan / kg to 25 yuan / kg, effective at 8:00 AM) and the original price record; inventory status data includes the current inventory of each fresh produce (e.g., cabbage remaining 50kg, warning threshold 20kg); due to the lack of frequent shelf movement in supermarket scenarios, location change records are empty; for the replenishment sub-cluster (containing 150 electronic price tags) in a warehouse scenario, the system collects location change records including the coordinates after the shelf is moved (e.g., shelf A moved from area B1 to B2, coordinates X1Y2), inventory status data including the inventory quantity after replenishment (e.g., laundry detergent replenished to 100 bottles), and price change information is empty.

[0095] Step S302: Classify the data to be updated according to the load level of the electronic shelf labels. The data to be updated for high load level electronic shelf labels is classified into the first data group, the data to be updated for medium load level electronic shelf labels is classified into the second data group, and the data to be updated for low load level electronic shelf labels is classified into the third data group.

[0096] In this embodiment, the load level is a price tag resource demand level (high, medium, low) based on communication and scenario dimension data. The first data group is the set of data to be updated for high-load price tags, which should be prioritized for communication resource allocation. The second data group is the set of data to be updated for medium-load price tags, which is processed in the normal order. The third data group is the set of data to be updated for low-load price tags, which can be executed after the high and medium load data are processed. The classification operation is to achieve differentiated task scheduling and avoid delays in processing high-demand data.

[0097] As an optional implementation, for the supermarket fresh food sub-cluster, 120 electronic shelf labels are classified as high-load level due to promotional activities, and their data to be updated (mainly price change information) is assigned to the first data group; 50 electronic shelf labels are classified as medium-load level because they are located in the regular sales area, and their data to be updated (mainly inventory status data) is assigned to the second data group; 30 electronic shelf labels are classified as low-load level because the product prices are stable and the inventory is sufficient, and their data to be updated (a small amount of inventory records) is assigned to the third data group; the classification results are synchronized to the task scheduling module of the sub-cluster gateway in real time.

[0098] Step S303: Perform duplicate detection on the data to be updated within the same data group, merge the data to be updated with the same content, and retain the unique identifier information.

[0099] In this embodiment, duplicate detection identifies operations with identical information within the same data group by comparing data content. For example, in price change information, "Product A price adjusted to 20 yuan" appears repeatedly in multiple price tag data. Merging identical content integrates duplicate data to be updated into a single unified data, reducing data transmission volume. Unique identification information is the unique ID of each electronic price tag, used to associate the merged data with the target price tag, ensuring that the data is accurately pushed to the corresponding device and avoiding data ownership confusion caused by merging.

[0100] As an optional implementation, for the first data group (high-load data of the fresh produce sub-cluster), the system uses a data hash comparison method to detect duplicates: calculate the hash value of each price change information, and if the hash values ​​of multiple price change information tags are the same (e.g., 10 price tags all contain "lettuce price adjusted to 5 yuan / jin"), then merge these duplicate information tags into a unified data tag "lettuce price adjusted to 5 yuan / jin", while retaining the unique IDs of these 10 price tags (e.g., SN001-SN010), forming a combination of "unified data + target price tag ID list", thereby reducing the channel resources occupied by duplicate data.

[0101] Step S304: Based on the priority sorting of data groups, the data to be updated after merging in each data group is packaged into price tag update tasks. Each price tag update task includes a task identifier, the target electronic price tag address, and the corresponding data content to be updated.

[0102] In this embodiment, the priority sorting is based on the processing order set according to the load level of the data group, that is, the priority of the first data group > the priority of the second data group > the priority of the third data group, to ensure that high-demand data is transmitted first; the price tag update task is a data packet that can be identified and executed by the communication system, wherein the task identifier is a unique code composed of sub-cluster number + timestamp + task sequence number, used to track the task execution status; the target electronic price tag address is the communication address of the electronic price tag (such as LoRa address, NB-IoT address), used to locate the target device; the data content to be updated is the merged unified data, associated with the target price tag ID list.

[0103] As an optional implementation, the system first processes the first data group according to priority: the merged "lettuce price adjusted to 5 yuan / jin" data is packaged with a list of 10 price tag IDs into a task, the task identifier is set as "fresh food sub-cluster 01-202509280800-001", the target electronic price tag address is the LoRa communication address of these 10 price tags (such as L001-L010), and the data content to be updated is "lettuce price adjusted to 5 yuan / jin"; after all tasks in the first data group are packaged, the second data group (such as the merged data task of "cabbage inventory remaining 50kg") and the third data group (such as the merged data task of "radish inventory sufficient") are packaged in sequence. Each task contains a complete task identifier, target address and data content.

[0104] It should be noted that the model will set different weights for data based on different scenarios. For example, in a supermarket scenario, price data will be the first weight, and in a warehouse scenario, inventory will be the first weight.

[0105] This embodiment collects, classifies, merges, and packages the data to be updated in steps. On the one hand, it merges identical content through duplicate detection, reducing the network bandwidth consumption of redundant data and avoiding channel congestion caused by invalid data. On the other hand, it sets priorities based on load levels to ensure that key data of high-load price tags (such as price changes during promotional periods) are transmitted first. Compared with the indiscriminate data transmission method in the prior art, it can make more efficient use of communication resources, further alleviate the network congestion problem in large-scale price tag scenarios, and make the electronic price tag update delay lower than that of the prior art.

[0106] Based on any of the above embodiments, in Embodiment Six of this application, referring to Figure 3 Step S40 includes: Step S401: Calculate the average and fluctuation values ​​of the sub-cluster network latency, and use the average and fluctuation values ​​as load feedback results. If the average value exceeds the first latency threshold or the fluctuation value exceeds the fluctuation threshold, the sub-cluster network is determined to be in a congested state.

[0107] In this embodiment, the average latency of the sub-cluster network is the arithmetic mean of the data transmission delays of all electronic price tags within the sub-cluster over a preset time period (e.g., 5 minutes), reflecting the overall network transmission efficiency. The sub-cluster network latency fluctuation value is the square root of the sum of squares of the deviations of each transmission delay from the average value within the preset time period, reflecting the network transmission stability. The load feedback result is a quantitative information reflecting the sub-cluster network load status, composed of the average value and the fluctuation value. The first latency threshold is a preset threshold value for judging whether the network is congested, calibrated by the system based on historical network data. The fluctuation threshold is a preset threshold value for judging whether the network is congested, avoiding data loss due to unstable transmission. Congestion refers to an operating state where network transmission efficiency is low and signal conflicts are frequent, at which time the transmission frequency needs to be adjusted to alleviate the pressure.

[0108] As an optional implementation, for the supermarket fresh food sub-cluster (containing 200 electronic price tags), the system counts the transmission delay data of each price tag every 5 minutes: the delay data within a certain period is 400ms, 450ms, 380ms, 520ms, and 480ms, the average value is calculated as (400+450+380+520+480) / 5=446ms, and the fluctuation value is √[((400-446)²+(450-446)²+(380-446)²+(520-446)²+(480-446)²) / 5]≈53ms; the preset first delay threshold is 500ms and the fluctuation threshold is 80ms. Since 446ms<500ms and 53ms<80ms, it is determined that the sub-cluster network is not in a congested state.

[0109] In step S402, if the supermarket promotion conditions are triggered and the sub-cluster network is not in a congested state, the transmission frequency of the corresponding electronic shelf label is set to the first high-frequency mode; if the sub-cluster network is in a congested state, the transmission frequency of the corresponding electronic shelf label is adjusted to the second high-frequency mode, and the frequency of the second high-frequency mode is lower than that of the first high-frequency mode.

[0110] In this embodiment, the supermarket promotion condition refers to the triggering event in the scenario dimension data where the "regional attribute is promotion area" and the "promotion activity status is active", which is common in supermarket fresh food and snack areas and other promotional scenarios; the first high-frequency mode is a high transmission frequency mode used when the network is not congested under the supermarket promotion condition, which is used to ensure the real-time update of price and inventory data during the promotion period; the second high-frequency mode is a transmission frequency mode used when the network is congested under the supermarket promotion condition, which alleviates network pressure by appropriately reducing the frequency, while also taking into account the need for updating promotional data.

[0111] As an optional implementation, when the supermarket's fresh food sub-cluster triggers promotional conditions (weekend discount activities in the fresh food section) and the network is not congested, the system sets the transmission frequency of all electronic price tags in the sub-cluster to the first high-frequency mode (1 minute / time) to ensure that the discount price and remaining inventory are synchronized every 1 minute; if subsequent statistics show that the average network latency of the sub-cluster rises to 550ms (exceeding the first latency threshold of 500ms), the network is determined to be congested, and the transmission frequency is immediately adjusted to the second high-frequency mode (2 minutes / time) to reduce the number of concurrent transmissions and alleviate congestion.

[0112] Step S403: If the warehouse high-frequency movement condition is triggered and the sub-cluster network is not in a congested state, the transmission frequency of the corresponding electronic price tag is set to the third high-frequency mode; if the sub-cluster network is in a congested state, the transmission frequency of the corresponding electronic price tag is adjusted to the fourth high-frequency mode, and the frequency of the fourth high-frequency mode is lower than that of the third high-frequency mode.

[0113] In this embodiment, the high-frequency movement condition in the warehouse refers to the triggering event in the scenario dimension data where "shelf movement frequency ≥ preset movement threshold (e.g., 8 times / hour)", which is common in dynamic scenarios such as warehouse replenishment areas and sorting areas; the third high-frequency mode is a high transmission frequency mode used when the network is not congested under the high-frequency movement condition in the warehouse, used to synchronize shelf location and inventory change data in real time; the fourth high-frequency mode is a transmission frequency mode used when the network is congested under the high-frequency movement condition in the warehouse, which reduces network load while ensuring the accuracy of location data.

[0114] As an optional implementation, the warehouse replenishment sub-cluster (containing 150 electronic price tags) experiences a shelf movement frequency of 10 times / hour due to morning replenishment needs (exceeding the preset threshold of 8 times / hour), triggering the warehouse high-frequency movement condition. At this time, the average network latency is 320ms (lower than the first latency threshold of 400ms; the threshold for warehouse scenarios differs from that for supermarket scenarios). The system sets the transmission frequency to the third high-frequency mode (30 seconds / time) to synchronize the position coordinates of the shelves after movement in real time. If the average network latency rises to 450ms during peak replenishment periods (exceeding the threshold), congestion is detected, and the system is adjusted to the fourth high-frequency mode (1 minute / time) to balance data real-time performance and network stability.

[0115] Step S404: If the price stabilization condition is triggered, the transmission frequency of the corresponding electronic price tag is set to low frequency mode, and the frequency of low frequency mode is lower than that of all high frequency modes.

[0116] In this embodiment, the price stability condition refers to the triggering event in the scenario dimension data where "price change information has not been updated for a continuous preset period of time (e.g., 24 hours)" and "the promotional activity status is inactive". This is common in static scenarios such as supermarket daily necessities areas and warehouse regular storage areas. The low-frequency mode is a low transmission frequency mode used when the price stability condition is met, which is used to reduce invalid data transmission and save network resources.

[0117] As an optional implementation, if the supermarket daily necessities sub-cluster (containing 300 electronic shelf labels) has no price changes and no promotional activities for 48 consecutive hours, triggering the price stability condition, the system sets the transmission frequency of the electronic shelf labels in the sub-cluster to a low-frequency mode (10 minutes / time), synchronizing the inventory status only once every 10 minutes (without frequent changes). Compared with the high-frequency mode (minimum 30 seconds / time), this significantly reduces the number of transmissions and reserves network resources for high-load sub-clusters.

[0118] For example, a company simultaneously operates a large supermarket and a warehousing center with tens of thousands of electronic shelf labels: When the supermarket's fresh produce section triggers a promotion, the system first calculates the average network latency of this sub-cluster to be 446ms and the fluctuation value to be 53ms, determining that there is no congestion, and sets the transmission frequency to 1 minute / time (first high-frequency mode); when the warehousing replenishment area triggers a high-frequency movement condition, the average network latency is 320ms, set to 30 seconds / time (third high-frequency mode); as the supermarket promotion enters its peak in the afternoon, the network latency of the fresh produce sub-cluster rises to 550ms, and is adjusted to 2 minutes / time (second high-frequency mode); the latency of the warehousing replenishment area rises to 450ms due to the increase in equipment, and is adjusted to 1 minute / time (fourth high-frequency mode); when the supermarket's daily necessities section triggers a price stabilization condition, it remains at 10 minutes / time (low-frequency mode). Each sub-cluster dynamically adjusts its frequency according to the conditions and network status to ensure orderly data transmission.

[0119] Furthermore, the scenario-dimensional change model considers whether there is a jump in load level. If a scenario jumps in load level, the model will comprehensively calculate the load level after the scenario change based on both the scenario dimension and the communication dimension. For example, if the load area in the scenario dimension shifts to a high-load area and the communication level of that area is medium-load (near-expiry food), the model will comprehensively determine that the load level after the scenario dimension change is a high-medium load area.

[0120] This embodiment accurately determines the congestion status by first calculating the average and fluctuation values ​​of network latency, and then matching differentiated transmission frequency modes according to different scenario conditions. This not only ensures the real-time data of key scenarios such as promotions and high-frequency mobile applications, but also reduces invalid network occupation by reducing the frequency during congestion and using low-frequency transmission in static scenarios. Compared with the fixed transmission frequency method in the prior art, it can more flexibly adapt to changes in network load, effectively alleviate network congestion problems in large-scale price tag scenarios, and make the electronic price tag update latency lower than that of the prior art.

[0121] Based on any of the above embodiments, in Embodiment Seven of this application, after step S50, the following is included: Step S51: If the price tag data push fails, retry based on preset rules.

[0122] In this embodiment, a price tag data push failure refers to the system sending an update task to the electronic price tag according to the specified transmission frequency and communication channel, but failing to receive a receipt confirmation signal from the price tag within a preset time. This may be caused by network signal fluctuations, temporary channel occupancy, or other reasons. The preset rules are pre-set retry strategies, including the number of retries, the retry time interval, and the retry termination conditions, which are used to ensure the push success rate while avoiding frequent retries that consume network resources. The retry operation is the process by which the system sends the update task to the failed price tag again according to the preset rules, aiming to improve the data push success rate through multiple attempts.

[0123] As an optional implementation, for electronic price tags in supermarket scenarios, the preset rule sets the number of retries to 3, with retry intervals of 10 seconds, 20 seconds, and 30 seconds respectively (using incremental intervals to avoid repeatedly occupying the channel in a short period of time). If no confirmation signal is received after 3 retries, the retry process is terminated. For example, if a high-load price tag in a fresh produce area fails to be pushed for the first time, the system initiates the first retry after 10 seconds. If it fails, it initiates the second retry after 20 seconds. If it fails again, it initiates the third retry after 30 seconds. The retry process stops after all 3 retry attempts fail.

[0124] Step S52: If the retry fails, mark the price tag update task as pending so that it can be executed first after the network is restored.

[0125] In this embodiment, "retry failure" refers to the state where the price tag data has not been successfully pushed after completing all retries according to preset rules; "pending processing" is a special marker added to failed tasks (such as the "PENDING" status code), used to quickly identify tasks that need further processing in the system task list; "priority execution" means that when the network status returns to normal (such as signal strength recovery and channel idleness), the system prioritizes the tasks with the "pending processing" marker for push, ensuring that the price tag data that has not been successfully updated is synchronized first, and avoiding task backlog that leads to data lag.

[0126] As an optional implementation, the system creates an independent "pending queue" for tasks that fail to retry in the task management module. In addition to marking the "PENDING" status code, each task is also associated with the failure time, target price tag ID, and failure reason (such as "weak signal" or "channel conflict"). When the network monitoring module detects that the sub-cluster network latency drops from 1200ms to 400ms (returning to normal), it automatically triggers the priority push mechanism of the pending queue, and sends update tasks to the price tags marked with pending status in order of failure time from earliest to latest. For example, the fresh food price tag task that failed at 8:00 am is processed first, and then the daily necessities price tag task that failed at 8:10 am is processed.

[0127] Step S53: If the network is disconnected, the price tag update task is cached locally so that it can be executed in the order of task generation timestamps after the network is connected.

[0128] In this embodiment, the network outage state refers to the complete interruption of the communication link between the electronic price tag and the gateway (such as gateway failure or complete signal blockage), and the system is unable to initiate any data push; local caching is the operation of storing the price tag update tasks to be executed in the gateway's local storage unit (such as SD card or flash memory) to avoid task loss when the network is out of service; the task generation timestamp is the time information (accurate to the second) recorded when each task is created, and execution in timestamp order means that after the network is connected, the system pushes the cached tasks in the order in which the tasks are generated to ensure the timeliness of task execution and conform to the time logic of data updates in the business scenario.

[0129] As an optional implementation, for warehousing scenarios, when the gateway detects an interruption in the communication link with the sub-cluster price tags (no price tag signal received for 60 consecutive seconds), it automatically stores the update tasks to be pushed (such as shelf location change records and inventory data) to local flash memory. Each task is saved in the format of "generation timestamp-task content-target price tag ID". For example, Task 1 (timestamp 09:05:30), Task 2 (timestamp 09:06:15), and Task 3 (timestamp 09:07:20) generated during the network outage are all cached locally. When the network is restored after 15 minutes of outage, the system pushes the three tasks in the order of 09:05:30, 09:06:15, and 09:07:20 to ensure that the warehouse price tags synchronize information according to the actual data update order.

[0130] For example, a large warehouse with tens of thousands of electronic price tags experienced a network outage at 9:00 AM due to a temporary gateway failure. At this time, the system needed to push inventory update tasks to 100 price tags in the replenishment area (Task A, timestamp 09:00:00) and location change tasks to 50 price tags in the shelf movement area (Task B, timestamp 09:00:45). After detecting the network outage, the system immediately cached Task A and Task B in the gateway's local flash memory. At 9:10 AM, the gateway failure was repaired, and the network returned to normal. The system first pushed Task A in timestamp order, successfully updating the inventory data of the 100 price tags in the replenishment area. When pushing Task B, 10 price tags failed to push due to weak signal. The system initiated 3 retries according to preset rules (intervals of 10 seconds, 20 seconds, and 30 seconds). 3 price tags still failed to retry, and the system marked the tasks of these 3 price tags as "PENDING" pending processing. Subsequently, after the network detected improved signal strength, these 3 pending tasks were pushed first, eventually completing the update of all price tag data.

[0131] Furthermore, after a price tag data push fails, the load level of that price tag will gradually decrease, triggering a re-push mechanism. After multiple push failures and when the load level is low, the model will mark it as an abnormal price tag push. The load level will be restored and data will be pushed again once the network or host computer signal returns to normal.

[0132] This embodiment effectively addresses task execution issues under abnormal scenarios such as network fluctuations and network outages through a post-processing workflow that includes retrying failed pushes, marking failed retryes as pending, and local caching during network outages. Compared to existing technologies that directly discard tasks after push failures, this workflow significantly reduces the risk of data loss, ensuring that price tag data can ultimately be successfully synchronized. Furthermore, by prioritizing the execution of pending tasks and executing cached tasks based on timestamps, the timeliness and sequence of data updates are guaranteed, further optimizing the reliability of data transmission in large-scale price tag scenarios, resulting in lower electronic price tag update latency and data loss rates compared to existing technologies.

[0133] This application provides a load-aware electronic price tag cluster communication device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the load-aware electronic price tag cluster communication method in Embodiment 1 above.

[0134] The following is for reference. Figure 4This document illustrates a structural schematic diagram of a load-aware electronic shelf label cluster communication device suitable for implementing embodiments of this application. The load-aware electronic shelf label cluster communication device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The load-aware electronic price tag cluster communication device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0135] like Figure 4 As shown, the load-aware electronic shelf label cluster communication device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the load-aware electronic shelf label cluster communication device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the load-aware electronic shelf label cluster communication device to exchange data wirelessly or via wired communication with other devices. Although load-aware electronic shelf label cluster communication devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0136] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0137] The load-aware electronic price tag cluster communication device provided in this application, employing the load-aware electronic price tag cluster communication method described in the above embodiments, can solve the technical problems of limited single-channel capacity of electronic price tags, signal conflicts easily caused by concurrent transmission of multiple devices, and ultimately network congestion. Compared with the prior art, the beneficial effects of the load-aware electronic price tag cluster communication device provided in this application are the same as those of the load-aware electronic price tag cluster communication device provided in the above embodiments, and other technical features in this load-aware electronic price tag cluster communication device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0138] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0140] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the load-aware electronic price tag cluster communication method in the above embodiments.

[0141] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0142] The aforementioned computer-readable storage medium may be included in a load-aware electronic price tag cluster communication device; or it may exist independently and not be assembled into a load-aware electronic price tag cluster communication device.

[0143] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the load-aware electronic shelf label cluster communication device, the load-aware electronic shelf label cluster communication device collects communication dimension data and scenario dimension data of the electronic shelf label. The communication dimension data includes the amount of data to be transmitted, signal strength, and historical communication success rate. The scenario dimension data includes the regional attributes in the supermarket scenario, the status of promotional activities, and the frequency of shelf movement in the warehouse scenario. Based on the load assessment model, the communication dimension data and the scene dimension data are processed, and the electronic price tags are divided into three load levels: high load, medium load, and low load. The data to be updated for the electronic price tags within each sub-cluster is used to generate price tag update tasks based on the load level of the electronic price tags. The electronic price tags are divided into sub-clusters according to their physical location, and each sub-cluster is allocated a communication channel. If a preset condition is triggered based on the scene dimension data, the transmission frequency of each electronic price tag is determined based on the condition type and the load feedback result calculated based on the sub-cluster network latency. Based on the transmission frequency and the communication channel of the electronic price tag, the price tag update task is scheduled and executed to push price tag data to the electronic price tags.

[0144] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0146] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0147] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described load-aware electronic shelf label cluster communication method. This solves the technical problem of limited single-channel capacity of electronic shelf labels, signal conflicts easily caused by concurrent transmission of multiple devices, ultimately leading to network congestion. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the load-aware electronic shelf label cluster communication method provided in the above embodiments, and will not be repeated here.

[0148] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the load-aware electronic price tag cluster communication method described above.

[0149] The computer program product provided in this application can solve the technical problem that the limited single-channel capacity of electronic price tags and the signal collisions caused by concurrent transmission of multiple devices can lead to network congestion. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the load-aware electronic price tag cluster communication method provided in the above embodiments, and will not be repeated here.

[0150] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A load-aware electronic price tag cluster communication method, characterized in that, The load-aware electronic price tag cluster communication method includes: The system collects communication dimension data and scenario dimension data for electronic price tags. The communication dimension data includes the amount of data to be transmitted, signal strength, and historical communication success rate. The scenario dimension data includes the regional attributes and promotional activity status in supermarket scenarios and the frequency of shelf movement in warehouse scenarios. Based on the load assessment model, the communication dimension data and the scenario dimension data are processed, and the electronic price tag is divided into three load levels: high load, medium load, and low load. The electronic price tags in each sub-cluster are updated based on their load level to generate a price tag update task. The electronic price tags are divided into sub-clusters according to their physical location, and each sub-cluster is allocated a communication channel. If a preset condition is triggered based on the scenario dimension data, the transmission frequency of each electronic price tag is determined based on the condition type of the preset condition and the load feedback result obtained from the sub-cluster network latency calculation. Based on the transmission frequency and the communication channel of the electronic price tag, the price tag update task is scheduled and executed to push price tag data to the electronic price tag.

2. The load-aware electronic price tag cluster communication method as described in claim 1, characterized in that, The step of processing the communication dimension data and the scenario dimension data based on the load assessment model to classify electronic price tags into three load levels: high load, medium load, and low load includes: The amount of data to be transmitted, signal strength, and historical communication success rate in the communication dimension data are assigned first weight, second weight, and third weight, respectively; and the regional attributes, promotional activity status, and shelf movement frequency in the scenario dimension data are assigned fourth weight, fifth weight, and sixth weight, respectively. The weighted communication dimension data and scenario dimension data are normalized using a load assessment model to obtain the comprehensive load value of each electronic price tag. If the overall load value is greater than the first threshold, the corresponding electronic price tag is determined to be of a high load level; If the overall load value is less than or equal to the first threshold and greater than the second threshold, the corresponding electronic price tag is determined to be of medium load level. If the overall load value is less than or equal to the second threshold, the corresponding electronic price tag is determined to be of a low load level, wherein the first threshold is greater than the second threshold.

3. The load-aware electronic price tag cluster communication method as described in claim 2, characterized in that, The step of normalizing the weighted communication dimension data and scenario dimension data using a load assessment model to obtain the comprehensive load value of each electronic price tag includes: Multiply the amount of data to be transmitted in the communication dimension data by the first weight, the signal strength by the second weight, and the historical communication success rate by the third weight to obtain the weighted amount of data to be transmitted, the weighted signal strength, and the weighted historical communication success rate. The weighted communication dimension data are mapped to standard intervals to obtain the standardized values ​​of the communication dimension. The larger the amount of data to be transmitted, the larger the standardized value; the weaker the signal strength, the larger the standardized value; and the lower the historical communication success rate, the larger the standardized value. Multiply the regional attributes in the scene dimension data by the fourth weight, the promotional activity status by the fifth weight, and the shelf movement frequency by the sixth weight to obtain the weighted regional attributes, the weighted promotional activity status, and the weighted shelf movement frequency. The weighted scenario dimension data are mapped to standard intervals to obtain the standardized values ​​of the scenario dimensions. The standardized values ​​of core areas are greater than those of non-core areas, the standardized values ​​of promotional states are greater than those of non-promotional states, and the standardized values ​​of higher shelf movement frequency are greater. The comprehensive load value of each electronic price tag is obtained by summing the standardized values ​​of the communication dimension and the scenario dimension using a load assessment model.

4. The load-aware electronic price tag cluster communication method as described in claim 1, characterized in that, Before the step of generating a price tag update task based on the load level of the electronic price tags in each sub-cluster, the following steps are included: In response to the initial data of the electronic price tags in each sub-cluster, the duplicate instructions in the initial data are determined; Based on the repeated instructions, the initial data of the electronic price tags in each sub-cluster are merged and processed to obtain the data to be updated for the electronic price tags in each sub-cluster.

5. The load-aware electronic price tag cluster communication method as described in claim 1, characterized in that, The step of generating a price tag update task based on the load level of the electronic price tags in each sub-cluster, using the data to be updated for the electronic price tags, includes: Collect the data to be updated for electronic price tags in each sub-cluster, including price change information, inventory status data, and location change records; The data to be updated is classified according to the load level of the electronic shelf labels. The data to be updated for high load level electronic shelf labels is classified into the first data group, the data to be updated for medium load level electronic shelf labels is classified into the second data group, and the data to be updated for low load level electronic shelf labels is classified into the third data group. Perform duplicate checks on the data to be updated within the same data group, merge the data with the same content, and retain the unique identifier information; Based on the priority sorting of data groups, the data to be updated after merging in each data group is packaged into price tag update tasks. Each price tag update task includes a task identifier, the target electronic price tag address, and the corresponding data content to be updated.

6. The load-aware electronic price tag cluster communication method as described in claim 1, characterized in that, The preset conditions include supermarket promotion conditions, warehouse high-frequency movement conditions, and price stability conditions. Among them, the supermarket promotion condition is that there is a promotional activity status identifier in the scenario dimension data, the warehouse high-frequency movement condition is that the shelf movement frequency in the scenario dimension data reaches a set value, and the price stability condition is that the price in the scenario dimension data is in a period of no change.

7. The load-aware electronic price tag cluster communication method as described in claim 6, characterized in that, The step of determining the transmission frequency of each electronic price tag based on the scene dimension data to trigger a preset condition, the condition type of the preset condition, and the load feedback result obtained from the sub-cluster network latency calculation, includes: Calculate the average and fluctuation values ​​of the sub-cluster network latency, and use the average and fluctuation values ​​as load feedback results. If the average value exceeds a first latency threshold or the fluctuation value exceeds a fluctuation threshold, the sub-cluster network is determined to be in a congested state. If the supermarket promotion conditions are triggered and the sub-cluster network is not congested, the transmission frequency of the corresponding electronic shelf label will be set to the first high-frequency mode; if the sub-cluster network is congested, the transmission frequency of the corresponding electronic shelf label will be adjusted to the second high-frequency mode, and the frequency of the second high-frequency mode is lower than that of the first high-frequency mode. If the warehouse high-frequency movement condition is triggered and the sub-cluster network is not in a congested state, the transmission frequency of the corresponding electronic price tag will be set to the third high-frequency mode; if the sub-cluster network is in a congested state, the transmission frequency of the corresponding electronic price tag will be adjusted to the fourth high-frequency mode, and the frequency of the fourth high-frequency mode is lower than that of the third high-frequency mode. If the price stabilization condition is triggered, the transmission frequency of the corresponding electronic price tag will be set to low-frequency mode, which has a lower frequency than all high-frequency modes.

8. The load-aware electronic price tag cluster communication method as described in claim 1, characterized in that, After the step of scheduling and executing the price tag update task based on the transmission frequency and the communication channel of the electronic price tag to push price tag data to the electronic price tag, the following steps are included: If the price tag data push fails, a retry will be performed based on preset rules; If the retry fails, the price tag update task will be marked as pending so that it can be executed first after the network is restored. If the network is offline, the price tag update task is cached locally so that it can be executed in the order of task generation timestamps after the network is connected.

9. A load-aware electronic price tag trunking communication device, characterized in that, The load-aware electronic price tag cluster communication device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the load-aware electronic price tag cluster communication method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the load-aware electronic price tag cluster communication method as described in any one of claims 1 to 8.

Images