Battery flow state monitoring method, device, equipment and medium

Abstract

The embodiment of the disclosure discloses a battery flow state monitoring method, device, equipment and medium, relates to the technical field of data processing, and comprises the following steps: in response to the online of a battery device, querying the flow state of the battery device; in the case that the flow state is normal use and the remaining flow time is greater than a preset value, determining that the battery device is normally started and logged in; in the case that the flow state is not activated, determining that the battery device starts to use a new flow package, performing network query to obtain flow characteristic information; in the case that the flow state is that the remaining flow time is less than or equal to the preset value, processing according to a preset timing task processing flow; in the case that the flow state is that the remaining flow time is zero or there is no remaining flow, determining that the battery device is online by flow recharge. Thus, the flow state of the battery device is updated in real time, a large number of invalid queries are avoided, the query accuracy is improved, and the problem of frequent query interfaces is effectively avoided.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of data processing, in particular to a battery flow state monitoring method and device, equipment and medium. BACKGROUND

[0002] The flow state of a battery device is usually queried by a third party providing an API to query the flow state and the package situation. A common practice is to request a third-party interface to query the flow information of the device at a fixed time every day, and record the current flow state of the device. When a user queries the device list (or needs to be reminded when the flow expires), the result of the last time query is returned. This way, the flow state is usually not updated in time, which cannot bring good product experience to the user. In addition, requesting the query interface of the third party too frequently will also be limited by the query result of the third party (not returning correct data, abnormal reminding), resulting in that the flow data requested by part of the products cannot be updated, and even the flow data of part of the products is abnormal.

[0003] Therefore, how to monitor the real-time changes of the flow state of the battery device is a problem to be solved at present. SUMMARY

[0004] Embodiments of the present disclosure provide a battery flow state monitoring method and device, electronic equipment and computer readable storage medium, which aims to at least solve one of the technical problems in the related art to some extent.

[0005] In a first aspect, the embodiments of the present disclosure provide a battery flow state monitoring method, which comprises:

[0006] In response to the online state of the battery device being online, querying the flow state of the battery device recorded in the local database;

[0007] In the case that the flow state is normal use and the remaining flow time is greater than a preset value, determining that the battery device is normally started and logged in, and not performing network query;

[0008] In the case that the flow state is not activated, determining that the battery device starts to use a new flow package, performing network query to obtain flow feature information, and updating the flow feature information in the local database;

[0009] In the case that the flow state is that the remaining flow time is less than or equal to a preset value, processing according to a preset timing task processing flow;

[0010] In the case that the flow state is that the remaining flow time is zero or there is no remaining flow, determining that the battery device is online for flow recharge, performing network query to obtain flow feature information, and updating the flow feature information in the local database.

[0011] In a second aspect, the embodiments of the present disclosure further provide a battery flow state monitoring device, which comprises:

[0012] The query module is configured to query the flow state of the battery device recorded in the local database in response to the online state of the battery device being online.

[0013] The first determination module is configured to determine that the battery device is normally started and logged in, and not to perform network query in the case that the flow state is normal use and the remaining flow time is greater than a preset value.

[0014] The second determination module is configured to determine that the battery device starts to use a new flow package in the case that the flow state is not activated, perform network query to obtain flow feature information, and update the flow feature information in the local database.

[0015] The third determination module is configured to process according to a preset timing task processing flow in the case that the flow state is that the remaining flow time is less than or equal to a preset value.

[0016] The fourth determination module is configured to determine that the battery device is flow recharging online in the case that the flow state is that the remaining flow time is zero or there is no remaining flow, perform network query to obtain flow feature information, and update the flow feature information in the local database.

[0017] In a third aspect, the embodiments of the present disclosure further provide an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is executed by the processor to implement the steps in the battery flow state monitoring method.

[0018] In a fourth aspect, the embodiments of the present disclosure further provide a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in the battery flow state monitoring method.

[0019] In a fifth aspect, the embodiments of the present disclosure further provide a computer program product or a computer program, which comprises computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to perform the method provided in various optional implementation manners of the embodiments of the present disclosure.

[0020] In the embodiments of the present disclosure, in response to the online state of the battery device being online, the flow state of the battery device recorded in the local database is queried, and then in the case that the flow state is normal use and the remaining flow time is greater than a preset value, it is determined that the battery device is normally started and logged in, no network query is performed, in the case that the flow state is not activated, it is determined that the battery device is a new flow package for use, network query is performed to obtain flow characteristic information, and the flow characteristic information is updated in the local database, in the case that the flow state is that the remaining flow time is less than or equal to the preset value, processing is performed according to the preset timing task processing flow, and in the case that the flow state is that the remaining flow time is zero or there is no remaining flow, it is determined that the battery device is a flow recharge online, network query is performed to obtain flow characteristic information, and the flow characteristic information is updated in the local database. Therefore, the flow state of the battery device is updated in real time, and the flow query is requested in real time only when the real state changes, avoiding a large number of invalid queries, improving the query accuracy, and effectively avoiding the problem of frequent query interfaces.

[0021] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the present disclosure, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and other drawings can also be obtained by those skilled in the art without creative labor.

[0023] Figure 1 is a flow diagram of a battery flow state monitoring method provided by an embodiment of the present disclosure;

[0024] Figure 2 is a first device flow state management automation flowchart provided by an embodiment of the present disclosure;

[0025] Figure 3 is a second device flow state management automation flowchart provided by an embodiment of the present disclosure;

[0026] Figure 4 is a device flow state management full life cycle diagram provided by an embodiment of the present disclosure;

[0027] Figure 5 is another flow diagram of a battery flow state monitoring method provided by an embodiment of the present disclosure;

[0028] Figure 6is a structural schematic diagram of a battery flow state monitoring device provided by an embodiment of the present disclosure.

[0029] Figure 7 is a structural schematic diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0030] Some embodiments of the present disclosure will be described in detail herein with reference to the drawings, in which some embodiments of the present disclosure are shown by way of example. The following description is, unless otherwise indicated, related to the accompanying drawings, in which the same numbers in different drawings represent the same or similar elements. Various changes, modifications, and equivalents of the methods, devices, and / or systems described herein will become apparent to those skilled in the art after a study of the following description. For example, the order in which the operations are described is merely an example and is not intended to be limiting, as any number of the described operations can be combined in any order and / or omitted, except for those operations that must occur in a particular order. Additionally, for the sake of brevity and clarity, descriptions of features that are well known in the art can be omitted.

[0031] The implementations described in some embodiments of the present disclosure below do not represent all implementations consistent with the present disclosure. Instead, they are merely examples of apparatuses and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0032] It should be noted that the execution subject of the battery flow state monitoring method of the present embodiment can be a battery flow state monitoring device, which can be configured in any type of electronic device, without limitation.

[0033] In the present embodiment, the battery flow state monitoring method will be executed by taking the battery flow state monitoring device as the execution subject, without limitation.

[0034] It should be noted that the order of the following embodiments is not intended to limit the priority of the embodiments.

[0035] Figure 1 is a flowchart of a battery flow state monitoring method according to the first embodiment of the present disclosure.

[0036] As shown in Figure 1 , the method comprises:

[0037] In step 101, in response to the online state of the battery device being online, the flow state of the battery device recorded in the local database is queried.

[0038] The flow state can be inactive, in use, used up, expired, etc., without limitation.

[0039] Specifically, when the online state of the battery device is online, the system will preferentially query the device traffic state recorded in the local database.

[0040] As an embodiment, the initialization of the traffic state can be automatically completed when the device is just produced and warehoused, so as to ensure that the user can query the network traffic information of the device without starting up subsequently. After the device is produced on the production line, the information is synchronized to the cloud platform through the production detection tool and the warehousing operation is completed. At this time, the system automatically triggers the traffic state initialization task. During the warehousing process, the system first adds the traffic data query task to the delay queue (the task information includes: device serial number, task joining time, etc. core identifier). In this way, it can avoid blocking the warehousing process due to the time-consuming API query, and ensure that the warehousing operation responds quickly (asynchronous processing improves system efficiency).

[0041] When the system starts, a separate monitoring thread can be started to continuously monitor the tasks in the delay queue. When the task enters the queue, the monitoring thread automatically takes out the task, parses the device serial number and other information, and initiates a request through the traffic query API interface.

[0042] Among them, the core data returned by the API interface includes:

[0043] Package basic information: package name, package state (not activated / in use / used up / expired);

[0044] Time information: package activation time, package expiration time.

[0045] Among them, after the monitoring thread parses the data, the following information can be updated to the local database:

[0046] Current traffic state of the device (such as "not activated" "in use");

[0047] Complete traffic package data (package name, activation time, etc.);

[0048] API query time (used for subsequent data timeliness judgment);

[0049] Package expiration time (provides a basis for time comparison for scheduled tasks).

[0050] Step 102, in the case that the traffic state is normal use and the remaining traffic time is greater than a preset value, determining that the battery device is normally started and logged in, and not performing network query.

[0051] Among them, the remaining traffic time can be the time to expiration, which is not limited here.

[0052] Among them, the preset value can be 30 days, which is not limited here.

[0053] It should be noted that if the traffic state is normal use and the remaining traffic time is greater than the preset value, it means that the traffic is normal, and the expiration time still has time more than the preset value, and at this time it is normal to boot and log in, and api network query traffic package is not required, the battery device is normally booted and normally online.

[0054] Specifically, the system identifies two states of online and offline by listening to device state changes. The following are four state change scenarios:

[0055] 1. Normal boot: device online (trigger subsequent traffic detection logic);

[0056] 2. Online after recharging traffic: device goes from offline to online (trigger subsequent traffic detection logic);

[0057] 3. Normal shutdown: device offline (no traffic detection triggered);

[0058] 4. Abnormal offline after traffic is used up: device offline (no traffic detection triggered).

[0059] Specifically, after the device is online, the system first queries the traffic state and traffic data of the device in the local database, and handles according to the state recorded locally:

[0060] If the local record traffic state is normal (and the expiration time is > 30 days), that is, the device traffic state in the local database is marked as "normal", and the expiration time of the package being used is more than 30 days from the current time, it can be determined as "normal boot login", and there is no need to call API to query the traffic package, and the process ends at this time.

[0061] Step 103, in the case of traffic state not activated, determine that the battery device is starting to use a new traffic package, perform network query to obtain traffic feature information, and update the traffic feature information in the local database.

[0062] It should be noted that if the device traffic state is marked as not activated in the local database (indicating that a new traffic package may be started), API network query needs to be performed to obtain traffic package information and update the local database. The specific steps are as follows: call API to query traffic package information, and the API returns data in the form of a list, including detailed information of each package:

[0063] Basic information: package name, package id, traffic package size;

[0064] State related: state (not activated / in use / used up / expired), activation time, expiration time.

[0065] After that, packages with a traffic package size of ≤5Mb can be excluded (test packages are not involved in state determination).

[0066] Then group by package id, classify the remaining packages by "package id", and each group corresponds to an independent list (there may be multiple states for the same id package, such as historical packages and current packages).

[0067] It should be noted that for each group (by package id), the group state is marked according to the package state and expiration time, and the rules are as follows:

[0068]

[0069] Specifically, according to the marking results of all groups, the overall traffic state of the device can be determined (finally saved to the local database), and the rules are as follows:

[0070]

[0071] Further, the local database can be updated, and the following information can be written to the local database:

[0072] The overall traffic state after parsing (such as "normal" and "fast expiration");

[0073] The expiration time of the package being used (extracted from the "in use" package returned by the API);

[0074] The timestamp of this API query.

[0075] Step 104, in the case where the traffic state is less than or equal to the preset value, the preset timing task processing process is performed.

[0076] It should be noted that if the state recorded in the local database is fast expiration, it means that the traffic is still normal at this time, and in this case, the preset timing task can be processed.

[0077] As a possible implementation, in response to the current time being a specified time, the first battery device in the target time period without state change is queried from the local database, the network query is performed to obtain the traffic feature information of the first battery device, and the traffic feature information is updated in the local database.

[0078] Wherein, the specified time can be 01:00:00 every day, which is not limited here. The system will perform task processing at this time every day, first query the device that has not changed any state for more than half a year in the local database, and the device is basically not used for half a year, at this time the traffic package of the device is basically expired. Query the device through the API, and save the data to the local database;

[0079] The target time period can be six months, and there is no specific limit here.

[0080] The first battery device can be a battery device that has not undergone a state change during the target time period.

[0081] In this scenario, the query could be for the first battery device that hasn't shown any status changes for over six months, or for devices in the local database that haven't experienced any status changes for over six months (approximately 183 days) (defined by default as "unused for six months"). The data plans for these devices have likely expired. The system queries the latest data for these devices via an API interface. After parsing the data returned by the API, it updates and saves it to the local database, ensuring that the status of long-term unused devices matches the actual status. This resolves the issue of "status not syncing after long-term idle devices' data plans expire," preventing long-term data lag in local data.

[0082] One possible implementation involves first querying the local database for second battery devices with an expiration date less than one day away. Then, determining the expiration time of the data plan stored in the local database for the second battery device and the current system time. Next, based on the data plan expiration time and the current system time, determining the remaining time before expiration. Then, based on the remaining time before expiration, determining the delay execution duration of the delay queue, and generating a delay task and its execution time based on the delay execution duration. The delay task is then added to the delay queue. When the thread listening to the delay queue detects that the delay task has reached its execution time, it performs a network query to obtain the data traffic characteristic information of the second battery device and updates the data traffic characteristic information in the local database.

[0083] As one implementation method, the system filters a set of second battery devices from the local database according to a predetermined strategy, selecting those with data plan expiration dates less than one day away. This filtering is based on the data plan expiration date field stored in the local database, accurately locating devices nearing expiration and narrowing down the scope for subsequent processing. For the selected second battery devices, the system extracts their data plan expiration dates from the local database and calculates the remaining time before the data plan expires by combining this with the current system time and using the time difference. This remaining time accurately reflects the countdown period before the data plan expires. Based on the calculated remaining time, the system determines the delay execution duration for the corresponding tasks in the delay queue. Based on this duration, a delayed task containing the task execution logic and execution time is generated, clearly defining the task triggering conditions and execution content. A thread monitoring the delay queue continuously monitors the task status in the queue. When the execution time of a delayed task is detected, a network query operation is triggered, calling the relevant interface to obtain the data traffic characteristic information of the second battery device. After obtaining the information, the data traffic characteristic information is updated to the corresponding device record in the local database according to the data format and storage specifications, completing the real-time synchronization of the device's data traffic status.

[0084] It can be understood that the above scenario queries the second battery device which is less than 1 day (24 hours) expired, based on the "traffic package expiration time" stored in the local database (the time is automatically calculated and saved when the device is warehoused, online, offline or interface query), compares the "system current time" with the "device package expiration time", and obtains the "remaining time to expiration" (i.e. "delay execution time"). The device information and the corresponding "delay time" are added to the delay queue, and the queue listening thread is triggered to execute at the "expiration time". The listening thread queries the latest state through the API at the "last second" of the device expiration, and if the user has not recharged, the device state is immediately updated to "expired". Through "precise delay to expiration time", the state is updated in real time with the least number of queries (only at the expiration moment).

[0085] As shown in Figure 2 After the timing task is triggered, the list of devices whose traffic package expiration time (expire_time) and current time difference is less than 1 day is queried from the local database first, and after the database returns the list, the timing task calculates the delay duration according to the difference between expire_time and the current time, generates a task containing the delay information and adds it to the delay queue; when the task in the delay queue reaches the trigger time, the queue listening thread senses it, calls the traffic query API to obtain the real-time traffic data of the device, the API returns the traffic state, package data and other information, and the queue listening thread updates the traffic state of the corresponding device in the local database (such as marking it as expired) according to these information. Through the cooperation of timing task, local database, delay queue, listening thread and traffic query API, the traffic state of the near-expiration device is accurately and timely updated.

[0086] As a possible implementation manner, first, the third battery device whose distance to the expiration time is greater than the first time and less than the second time in the local database is queried, then the traffic package expiration time stored in the local database of the third battery device and the system current time are determined, then based on the traffic package expiration time and the system current time, the remaining time of the third battery device to the first time is determined, then according to the remaining time to the first time, the delay execution duration of the delay queue is determined, and based on the delay execution duration, the delay task and the execution time are generated, then the delay task is added to the delay queue, and when the thread monitoring the delay queue detects that the delay task reaches the execution time, the network query is executed to obtain the traffic feature information of the third battery device, and the traffic feature information is updated in the local database.

[0087] That is to say, when the system executes the flow, first, the third battery device in the first time interval to the second time interval (for example, the first time is 30 days away from the expiration time, and the second time is 31 days away from the expiration time) from the expiration time is screened out according to the local database; then, the traffic package expiration time of the third battery device stored in the local database is extracted, and the remaining time of the third battery device from the first time is calculated based on the current time of the system; based on the remaining time, the delay execution time of the corresponding task in the delay queue is determined, and then the delay task containing the execution time and other information is generated and added to the queue; when the thread monitoring the delay queue detects that the task execution time arrives, the network query operation is triggered to obtain the traffic feature information of the third battery device, and finally the information is updated to the local database, so as to realize the accurate and delayed update management of the device traffic state in a specific time interval, and to ensure that the device traffic data is effectively synchronized at the required time node of the business. For example, after querying the devices that will expire within 30-31 days, the remaining time from the current system time to "30 days away from the expiration time" is calculated (for example, if there are 2 days left to "30 days away from the expiration time", the execution is delayed for 2 days);

[0088] After joining the delay queue, the queue monitoring thread triggers the execution at the time point of "30 days away from the expiration time". When executing, the API is queried and updated to the "about to expire" state.

[0089] As shown in Figure 3 After the timing task is triggered, the device list satisfying the condition of "30 days <= expire_time-current time <= 31 days" is queried from the local database, the database returns the list, the timing task calculates the delay time according to the rule of "30 days-(expire_time-current time)", generates a task containing the delay information and adds it to the delay queue; when the task in the delay queue reaches the trigger time, the queue monitoring thread senses it, calls the traffic query API to obtain the device traffic data, the API returns the traffic state, the remaining time of the package and other information, and the queue monitoring thread updates the fast expiration mark (such as setting is_near_expire=1) of the corresponding device in the local database according to the information. Through the cooperation of the timing task, the local database, the delay queue, the monitoring thread and the traffic query API, the accurate marking and updating of the fast expiration state of the device expiring in the next 30 days are realized.

[0090] In step 105, when the traffic state is zero or there is no remaining traffic, it is determined that the battery device is online for traffic recharge, a network query is performed to obtain the traffic feature information, and the traffic feature information is updated in the local database.

[0091] It should be noted that in the case of the flow state being the remaining flow time being zero or no remaining flow, the state recorded by the local database is that the flow has expired, indicating that the flow of the device has been recharged, at which time an API query is required, and after analyzing the data queried back, the new device flow state and package data are saved to the local database.

[0092] As a possible implementation, when the system monitors that the flow state of the battery device presents the remaining flow time zero, such as the flow package has expired, or is in the condition of no remaining flow, that is, the flow has been completely exhausted, and at this time the device changes from offline state to online state, it can be determined that the battery device is flow recharge online. The system immediately performs a network query action and initiates a request to the API interface of the related operator or device management platform. The system can obtain flow feature information, including the basic information of the package, such as the package name, the corresponding package ID and the specific size of the flow package; also contains state information, which clearly shows that the current package is in the state of inactivation, use, use up or expiration; time information, which can obtain the activation time of the package, that is, the starting time of the package after this recharge, and the expiration time of the package, etc. After analyzing the data queried back, the new device flow state and package data are saved to the local database.

[0093] Figure 4 From left to right, there are three modules. The left module listens to the change of the device online state, queries the historical flow state from the local database when the device is online, and processes according to the state (normal, inactivation, expiration, and flow excess to call API to query the latest state and update the database). The middle module starts a timing task at 01:00 every day, filters devices with unchanged state for more than half a year, expired within 1 day, and expired within 30 days from the database, directly calls API to synchronize the state and update the database for the devices with unchanged state for more than half a year, generates corresponding delay tasks for the devices expired within 1 day and 30 days, and adds them to the delay queue for execution. The right module generates a delay task of 1 minute when the device is warehoused, calls API to query flow data after the listening thread is triggered, and initializes the storage to the local database after analysis. Through the cooperative mechanism of "real-time state listening - timing task batch processing - warehousing initialization and archiving", the device is covered from warehousing to state change and long-term idling, forming a closed loop of data production, consumption and feedback, and realizing precise management of the whole life cycle of the device flow state.

[0094] In the embodiments of the present disclosure, in response to the online state of the battery device being online, the flow state of the battery device recorded in the local database is queried, and then in the case that the flow state is normal use and the remaining flow time is greater than the preset value, it is determined that the battery device is normally started and logged in, and no network query is performed. In the case that the flow state is not activated, it is determined that the battery device is used for the beginning of a new flow package, a network query is performed to obtain flow characteristic information, and the flow characteristic information is updated in the local database. In the case that the flow state is that the remaining flow time is less than or equal to the preset value, processing is performed according to the preset timing task processing flow. In the case that the flow state is that the remaining flow time is zero or there is no remaining flow, it is determined that the battery device is online for flow recharge, a network query is performed to obtain flow characteristic information, and the flow characteristic information is updated in the local database. Thus, the flow state of the battery device is updated in real time, and the flow query is requested in real time only when the real state changes, avoiding a large number of invalid queries, improving the query accuracy, and effectively avoiding the problem of frequent query interfaces.

[0095] Figure 5 is a flow diagram of a battery flow state monitoring method according to a second embodiment of the present disclosure.

[0096] As shown in Figure 5 , the method comprises:

[0097] Step 201, in response to the battery device being in a production completion state, the attribute information of the battery device is entered into the cloud platform through a production detection tool.

[0098] As an implementation manner, after the production line completes the production of the battery device, the device identity information needs to be synchronized to the cloud platform, such as the serial number, model, production batch, and other basic attributes of the battery, which are the only identifier for subsequent management of the device. The production detection tool (such as detection software and hardware terminal of the production line) pushes the device attributes to the cloud platform through an interface (API) or file import, and the cloud platform creates a basic file for the device in the database.

[0099] Step 202, in response to the attribute information of the battery device being entered into the cloud platform, a flow data query task corresponding to the battery device is added to a delay queue.

[0100] Wherein, after the attribute information of the battery device is entered into the cloud platform, the traffic state of the battery device (such as the traffic package information taken out of the factory) needs to be synchronized, but the main process cannot be blocked (otherwise the response of entering the cloud platform will be slow), so the traffic data query task corresponding to the battery device can be added to the delay queue. Among them, for the cloud platform or the back-end system, the traffic data query task can be generated after the device attribute entry event is successful, and added to the delay queue (such as using Redis delay queue, Java DelayQueue, etc.).

[0101] Thus, the main process does not need to wait for the traffic query event to end, and quickly responds to the front-end / production line operation. The device entry and traffic query are separated, and subsequent changes to the traffic query logic (such as changing the interface, adding verification) do not affect the production line process.

[0102] Step 203, performing other tasks in addition to the traffic data query task.

[0103] Among them, the system is multi-task parallel, after adding the traffic data query task to the delay queue, the main thread can continue to process other businesses (such as generating production reports, triggering quality inspection processes, notifying warehouse storage, etc.). In this way, the system throughput can be improved, and the traffic data query task can be prevented from dragging down the overall efficiency, especially in high-concurrency scenarios such as production lines and cloud platforms.

[0104] Step 204, in response to system initialization, establishing a listening thread to listen to whether the traffic data query task is put into the delay queue, wherein the delay queue is used for asynchronously storing the traffic data query task.

[0105] Specifically, in the system startup phase, the ability to process the delay queue task needs to be pre-set. By creating a dedicated listening thread, the delay queue is continuously monitored to ensure that the tasks in the queue can be captured and disposed of in a timely manner, avoiding task loss due to system start-stop or process interruption, and ensuring the continuity and reliability of the traffic query task processing process.

[0106] As an example, in the system startup script or initialization code logic, the initialization monitoring thread is started through multi-threaded programming means (independent thread or thread pool mode). The thread continuously checks the delay queue state through periodic polling (such as setting a 100ms polling interval) or queue blocking monitoring mechanism. The delay queue can be implemented based on a memory queue (such as Java's ConcurrentLinkedQueue, which extends the delay logic), or rely on middleware construction (such as the RabbitMQ delay queue plug-in, the ZSet structure of Redis, which uses its ordered and score features to implement delay task management). In this way, a full-time, high-reliability task monitoring mechanism can be built to ensure that the traffic query task is traceable and executable throughout its life cycle, providing a solid foundation for subsequent traffic state synchronization processes, avoiding the risk of task loss, and ensuring system business process closure.

[0107] Step 205, in response to the monitoring thread listening to the traffic data query task placed in the delay queue, determining the battery device corresponding to the traffic data query task, and calling the third-party traffic interface to obtain the traffic data corresponding to the battery device.

[0108] As an example, after the monitoring thread captures the traffic query task in the delay queue, it can be linked to a third-party traffic service (such as an operator or a traffic provider platform) to obtain battery device traffic data. Through task analysis and interface calling, the external traffic data acquisition channel is opened to provide data sources for device traffic state synchronization. The thread parses the device unique identifier (such as the serial number) from the task payload and concatenates the request parameters according to the third-party interface protocol specification. Based on the HTTP protocol, a RESTful API request is initiated, or through the SDK encapsulated client tool, the third-party traffic query interface is called, and the JSON / XML format data returned by the interface is received.

[0109] Step 206, analyzing the traffic data to obtain the traffic feature information of the battery device, wherein the traffic feature information includes at least one or more of the following: traffic state, traffic package data, interface query time, and package expiration time.

[0110] It can be understood that the original data returned by the third-party interface needs to be standardized and processed to extract traffic state, package information, query time, and other key features. Through structured analysis, scattered data is converted into information units that can be recognized and utilized by the system, providing data support for local database storage and business logic linkage. Using a JSON parsing library (Python's json module, Java's Jackson framework), the interface returned data is deserialized into a program object (such as a dictionary or an entity class). According to business requirements, core fields are extracted from the parsed data:

[0111] Flow state: Mark the device flow package activation, use, expiration and other states (such as "not activated", "expired");

[0112] Package data: Cover the basic information of the package name, flow quota, etc.

[0113] Time information: Record the interface query time (for data freshness verification), package expiration time (provide time basis for subsequent expiration reminder logic).

[0114] Step 207, based on the flow feature information, update the local database.

[0115] Specifically, the parsed structured flow feature information can be stored in the local database (such as MySQL, MongoDB). By associating the database record with the device identifier, the inventory device flow state is updated, or the flow information file is initialized for new devices, ensuring that the device flow state in the system is synchronized with the third-party data in real time, providing accurate data foundation for business query and state monitoring.

[0116] Step 208, in response to the online state of the battery device being offline, query the device state of the battery device in the local database.

[0117] Specifically, when the system detects that the online state of the battery device is switched to offline, the current flow state and related parameters of the device are obtained from the local database. This step serves as a pre-checking link to provide a basis for determining whether to trigger external query. Based on the unique identifier of the device, the device record is read from the local database through a database query statement, and the core fields such as the remaining flow time are extracted.

[0118] Step 209, if the flow state is normal use and the remaining flow time is greater than the preset value, determine that the battery device is normally powered off and offline, otherwise, perform network query to obtain flow feature information, and update the flow feature information in the local database.

[0119] Optionally, if the device flow state is "normal use" and the remaining flow valid time is greater than the preset threshold (such as 30 days), it is determined that it is normally powered off and offline, and no additional operation is needed.

[0120] Optionally, if the above conditions are not met (such as the flow state is "not activated", "soon expired", "expired", or the remaining flow valid time is less than or equal to the preset threshold), the latest flow data needs to be obtained through API call and updated to the local database after parsing.

[0121] That is, if the flow state recorded in the local record is "normal", it is determined that the device is normally powered off and offline (no flow-related abnormalities), and no additional operation is needed, maintaining the existing record in the local database.

[0122] If the locally recorded traffic status is "not activated", the device offline may exist traffic status abnormality (this is an irregular scenario, only triggered in special exceptions). The traffic query API needs to be called to obtain the latest data, and after parsing, the traffic status and associated information (such as package data, activation status, etc.) of the device in the local database are updated.

[0123] If the locally recorded traffic status is "fast expiration", the state indicates that the device traffic package is close to expiration, and the offline may be related to traffic depletion. The traffic query API needs to be called to obtain the real-time traffic usage, and after parsing, the latest status (such as "used up" "still in the valid period" etc.) and package data are updated to the local database.

[0124] If the locally recorded traffic status is "expired", the device offline in this state may exist abnormality (such as the user has recharged but the local has not been synchronized, which is an irregular scenario). The traffic query API needs to be called to obtain the latest data, and if there is a recharge operation, the new traffic status (such as "in use") and package information (new package name, validity period, etc.) are updated to the local database after parsing.

[0125] In the embodiment of the present application, first, in response to the battery device being in a production completion state, the attribute information of the battery device is entered into the cloud platform through a production detection tool, then in response to the attribute information of the battery device being entered into the cloud platform, the traffic data query task corresponding to the battery device is added to the delay queue, then other tasks except the traffic data query task are executed, then in response to system initialization, a listening thread is established to listen whether the traffic data query task is put into the delay queue, wherein the delay queue is used for asynchronous storage of the traffic data query task, then in response to the listening thread listening to the traffic data query task put into the delay queue, the battery device corresponding to the traffic data query task is determined, and a third-party traffic interface is called to obtain the traffic data corresponding to the battery device, the traffic data is parsed to obtain the traffic feature information of the battery device, wherein the traffic feature information at least includes one or more of the following: traffic state, traffic package data, interface query time, package expiration time, then based on the traffic feature information, the local database is updated, then in response to the online state of the battery device being offline, the device state of the battery device in the local database is queried, in the case that the traffic state is normal use and the remaining traffic time is greater than a preset value, it is determined that the battery device is normally powered off, otherwise, network query is performed to obtain the traffic feature information, and the traffic feature information is updated in the local database. After the battery device is produced, the attribute information is entered into the cloud platform through the production detection tool, the delay queue is combined to asynchronously process the traffic data query task, which can ensure that the initialization data is timely entered and does not block the execution of other tasks, thereby improving the efficiency of data preparation before the device is online. Through the listening thread monitoring the delay queue, once there is a query task, the interface is automatically called to obtain and parse the traffic feature information, and the local database is updated synchronously, so as to ensure that the local data is consistent with the actual traffic state of the device. When offline, whether it is normal shutdown is determined in combination with the traffic state and the remaining time in the local database, if it is not normal offline (such as caused by traffic problem), network query is automatically triggered and data is updated, thereby avoiding the lag of the traffic state caused by device offline, and ensuring the accuracy of data in the offline scene.

[0126] In order to better implement the battery traffic state monitoring method of the present disclosure, the present disclosure also provides a battery traffic state monitoring device based on the above battery traffic state monitoring method. The meanings of the terms are the same as in the above battery traffic state monitoring method, and the specific implementation details can be referred to the description in the method embodiment.

[0127] Please refer to Figure 6 , Figure 6 is a structural schematic diagram of the battery traffic state monitoring device provided by the embodiment of the present disclosure. The battery traffic state monitoring device 400 comprises:

[0128] The query module 410 is configured to query the flow state of the battery device recorded in the local database in response to the online state of the battery device being online.

[0129] The first determination module 420 is configured to determine that the battery device is normally started and logged in, and not perform network query, in the case that the flow state is normal use and the remaining flow time is greater than a preset value.

[0130] The second determination module 430 is configured to determine that the battery device is used for a new flow package, perform network query to obtain flow characteristic information, and update the flow characteristic information in the local database in the case that the flow state is not activated.

[0131] The third determination module 440 is configured to perform processing according to a preset timing task processing flow in the case that the flow state is that the remaining flow time is less than or equal to a preset value.

[0132] The fourth determination module 450 is configured to determine that the battery device is flow recharge online, perform network query to obtain flow characteristic information, and update the flow characteristic information in the local database in the case that the flow state is that the remaining flow time is zero or no remaining flow.

[0133] Optionally, the apparatus further comprises:

[0134] The query unit is configured to query the device state of the battery device in the local database in response to the online state of the battery device being offline.

[0135] The determination unit is configured to determine that the battery device is normally shut down and logged out in the case that the flow state is normal use and the remaining flow time is greater than a preset value, or otherwise, perform network query to obtain flow characteristic information, and update the flow characteristic information in the local database.

[0136] Optionally, the query module 410 is further configured to:

[0137] In response to system initialization, establish a listening thread to listen to whether the flow data query task is put in the delay queue, wherein the delay queue is used to asynchronously store the flow data query task.

[0138] In response to the listening thread listening to the flow data query task put in the delay queue, determine the battery device corresponding to the flow data query task, and call a third-party flow interface to obtain flow data corresponding to the battery device.

[0139] parsing the traffic data to obtain traffic feature information of the battery device, wherein the traffic feature information at least includes one or more of the following: traffic state, traffic package data, interface query time, package expiration time;

[0140] updating the local database based on the traffic feature information.

[0141] Optionally, the query module 410 is further configured to:

[0142] in response to the battery device being in a production completion state, entering attribute information of the battery device into a cloud platform through a production detection tool;

[0143] in response to the attribute information of the battery device being entered into the cloud platform, adding the traffic data query task corresponding to the battery device to the delay queue;

[0144] performing other tasks in addition to the traffic data query task.

[0145] Optionally, the third determination module 440 is specifically configured to:

[0146] in response to the current time being a specified time, querying a first battery device that has not undergone a state change within a target time period from the local database, performing network query to obtain traffic feature information of the first battery device, and updating the traffic feature information in the local database.

[0147] Optionally, the third determination module 440 is specifically configured to:

[0148] querying a second battery device in the local database that is less than one day away from the expiration time;

[0149] determining a traffic package expiration time stored in the local database and a system current time of the second battery device;

[0150] determining a remaining time to expiration according to the traffic package expiration time and the system current time;

[0151] determining a delay execution duration of a delay queue according to the remaining time to expiration, and generating a delay task and an execution time based on the delay execution duration;

[0152] adding the delay task to the delay queue, and in response to a thread listening to the delay queue detecting that the delay task reaches the execution time, performing network query to obtain traffic feature information of the second battery device, and updating the traffic feature information in the local database.

[0153] Optionally, the third determination module 440 is specifically configured to:

[0154] querying a third battery device in the local database which is greater than the first time and less than the second time from the expiration time;

[0155] determining the traffic package expiration time and the system current time stored in the local database by the second battery device;

[0156] determining the remaining time of the third battery device from the first time based on the traffic package expiration time and the system current time;

[0157] determining the delay execution duration of the delay queue according to the remaining time from the first time, and generating the delay task and the execution time based on the delay execution duration;

[0158] adding the delay task to the delay queue, and when the thread listening to the delay queue detects that the delay task reaches the execution time, performing network query to obtain the traffic characteristic information of the third battery device, and updating the traffic characteristic information in the local database.

[0159] In the embodiments of the present disclosure, in response to the online state of the battery device being online, the traffic state of the battery device recorded in the local database is queried, and then in the case that the traffic state is normal use and the remaining traffic time is greater than the preset value, it is determined that the battery device is normally started and logged in, and no network query is performed. In the case that the traffic state is not activated, it is determined that the battery device is used for the beginning of a new traffic package, and network query is performed to obtain the traffic characteristic information, and the traffic characteristic information is updated in the local database. In the case that the traffic state is that the remaining traffic time is less than or equal to the preset value, it is processed according to the preset timing task processing procedure, and in the case that the traffic state is that the remaining traffic time is zero or there is no remaining traffic, it is determined that the battery device is online for traffic recharge, network query is performed to obtain the traffic characteristic information, and the traffic characteristic information is updated in the local database. Therefore, the traffic state of the battery device is updated in real time, and the traffic query is requested only when the real state changes, avoiding a large number of invalid queries, improving the query accuracy, and effectively avoiding the problem of frequent query interfaces.

[0160] In addition, the present disclosure also provides an electronic device, as shown in Figure 7 The electronic device shows the structure schematic diagram of the electronic device related to the present disclosure, specifically:

[0161] The electronic device can include a processor 501 with one or more processing cores, a memory 502 with one or more computer readable storage media, a power supply 503, and an input unit 504. Those skilled in the art can understand that Figure 7The electronic device structure shown in the figure does not constitute a limitation on the electronic device, and can include more or fewer components than shown, or combine certain components, or arrange different components. Among them:

[0162] The processor 501 is the control center of the electronic device, connects various parts of the entire electronic device through various interfaces and lines, and performs various functions of the electronic device and processes data by running or executing software programs and / or modules stored in the memory 502 and calling data stored in the memory 502, thereby overall monitoring the electronic device. Optionally, the processor 501 can include one or more processing cores; preferably, the processor 501 can integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application program, etc., and the modem processor mainly processes wireless communication. It can be understood that the above-mentioned modem processor can also not be integrated into the processor 501.

[0163] The memory 502 can be used to store software programs and modules, and the processor 501 executes various functions and data processing by running the software programs and modules stored in the memory 502. The memory 502 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), etc.; the data storage area can store data created according to the use of the electronic device, etc. In addition, the memory 502 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state memory device. Accordingly, the memory 502 can also include a memory controller to provide access for the processor 501 to the memory 502.

[0164] The electronic device also includes a power supply 503 for supplying power to various components, and preferably the power supply 503 can be logically connected to the processor 501 through a power management system, so as to realize functions such as management of charging, discharging, and power consumption management through the power management system. The power supply 503 can also include one or more direct current or alternating current power supplies, a recharging system, a power supply device debugging circuit, a power supply converter or inverter, a power supply state indicator, and any other components.

[0165] The electronic device can also include an input unit 504, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0166] Although not shown, the electronic device can further include a display unit and the like, which will not be described here. Specifically, in the present embodiment, the processor 501 in the electronic device will load the executable file corresponding to the process of one or more application programs into the memory 502 according to the following instructions, and run the application program stored in the memory 502 by the processor 501, thereby implementing the steps in any of the battery flow state monitoring methods provided by the embodiments of the present disclosure.

[0167] The specific implementation of each of the above operations can refer to the previous embodiments, which will not be described here.

[0168] Those skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructions, or by instructions controlling related hardware, which can be stored in a computer readable storage medium and loaded and executed by a processor.

[0169] To this end, the present disclosure provides a computer readable storage medium, which stores a computer program capable of being loaded by a processor to execute the steps in any of the battery flow state monitoring methods provided by the present disclosure.

[0170] The specific implementation of each of the above operations can refer to the previous embodiments, which will not be described here.

[0171] The computer readable storage medium can include a read only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0172] Since the instructions stored in the computer readable storage medium can execute the steps in any of the battery flow state monitoring methods provided by the present disclosure, the beneficial effects that can be achieved by any of the battery flow state monitoring methods provided by the present disclosure can be achieved, which will not be described here for the sake of brevity.

[0173] The above describes in detail the battery flow state monitoring method, device, electronic device and computer readable storage medium provided by the present disclosure. The principles and implementation manners of the present disclosure are described by applying specific examples in this paper, and the above embodiment descriptions are only used to help understand the method and core idea of the present disclosure; at the same time, for those skilled in the art, according to the idea of the present disclosure, the specific implementation manner and application range will be changed, and the above description should not be understood as limiting the present disclosure.

Claims

1. A method of monitoring the state of flow of a battery, characterized by, The method comprises the following steps: In response to the online state of the battery device being online, querying the traffic state of the battery device recorded in the local database; In the case that the traffic state is normal use and the remaining traffic time is greater than a preset value, determining that the battery device is normally started and logged in, and not performing network query; In the case that the traffic state is not activated, determining that the battery device is used for the first time with a new traffic package, performing network query to obtain traffic feature information, and updating the traffic feature information in the local database; In the case that the traffic state is that the remaining traffic time is less than or equal to a preset value, processing according to a preset timing task processing procedure; In the case that the traffic state is that the remaining traffic time is zero or there is no remaining traffic, determining that the battery device is online after traffic recharge, performing network query to obtain traffic feature information, and updating the traffic feature information in the local database.

2. The method of claim 1, wherein, The method further comprises the following steps: In response to the online state of the battery device being offline, querying the device state of the battery device in the local database; In the case that the traffic state is normal use and the remaining traffic time is greater than a preset value, determining that the battery device is normally turned off and logged out, otherwise, performing network query to obtain traffic feature information, and updating the traffic feature information in the local database.

3. The method of claim 1, wherein, Before the step of responding to the online state of the battery device being online, the method further comprises the following steps: In response to system initialization, establishing a listening thread to listen to whether a traffic data query task is put into a delay queue, wherein the delay queue is used to asynchronously store the traffic data query task; In response to the listening thread listening to the traffic data query task put into the delay queue, determining a battery device corresponding to the traffic data query task, and calling a third-party traffic interface to obtain traffic data corresponding to the battery device; Analyzing the traffic data to obtain traffic feature information of the battery device, wherein the traffic feature information at least includes one or more of the following: traffic state, traffic package data, interface query time, and package expiration time; Based on the traffic feature information, updating the local database.

4. The method of claim 3, wherein, Before the step of responding to system initialization, the method further comprises the following steps: In response to the battery device being in a production completion state, using a production detection tool to input attribute information of the battery device into a cloud platform; In response to the attribute information of the battery device being input into the cloud platform, adding the traffic data query task corresponding to the battery device into the delay queue; Performing other tasks in addition to the traffic data query task.

5. The method of claim 1, wherein, The processing according to the preset timing task processing procedure comprises the following steps: In response to the current time being a specified time, querying a first battery device from the local database which has not changed state within a target time period, performing network query to obtain traffic feature information of the first battery device, and updating the traffic feature information in the local database.

6. The method of claim 1, wherein, The processing according to the preset timing task processing procedure comprises the following steps: Querying a second battery device from the local database which is less than one day away from the expiration time; determining a traffic package expiration time stored in the local database and a system current time of the second battery device; determining a remaining time to expiration according to the traffic package expiration time and the system current time; determining a delay execution duration of a delay queue according to the remaining time to expiration, and generating a delay task and an execution time based on the delay execution duration; adding the delay task to the delay queue, and when a thread listening to the delay queue detects that the delay task reaches the execution time, performing a network query to obtain traffic characteristic information of the second battery device, and updating the traffic characteristic information in the local database.

7. The method of claim 1, wherein, the processing according to the preset timing task processing procedure comprises: querying a third battery device with a remaining time to expiration greater than a first time and less than a second time in the local database; determining a traffic package expiration time stored in the local database and a system current time of the third battery device; determining a remaining time to the first time of the third battery device based on the traffic package expiration time and the system current time; determining a delay execution duration of a delay queue according to the remaining time to the first time, and generating a delay task and an execution time based on the delay execution duration; adding the delay task to the delay queue, and when a thread listening to the delay queue detects that the delay task reaches the execution time, performing a network query to obtain traffic characteristic information of the third battery device, and updating the traffic characteristic information in the local database.

8. A battery flow state monitoring device, characterized by, comprises: a querying module, configured to query a traffic state of a battery device recorded in a local database in response to an online state of the battery device being online; a first determining module, configured to determine that the battery device is normally started and logged in without performing a network query in a case where the traffic state is normal use and a remaining traffic time is greater than a preset value; a second determining module, configured to determine that the battery device starts to use a new traffic package and perform a network query to obtain traffic characteristic information in a case where the traffic state is not activated, and update the traffic characteristic information in the local database; a third determining module, configured to process according to a preset timing task processing procedure in a case where the traffic state is that the remaining traffic time is less than or equal to a preset value; a fourth determining module, configured to determine that the battery device is traffic recharge online, perform a network query to obtain traffic characteristic information, and update the traffic characteristic information in the local database in a case where the traffic state is that the remaining traffic time is zero or there is no remaining traffic.

9. An electronic device, comprising: comprise a memory and a processor; the memory stores a computer program, and the processor is configured to run the computer program in the memory to execute the method in any one of claims 1 to 7.

10. A storage medium, characterized by The storage medium is configured to store a computer program, and the computer program is loaded by a processor to execute the method in any one of claims 1 to 7.

Images