Data processing method and level sensor

Abstract

This application discloses a data processing method and a liquid level sensor. The method includes: acquiring sampling data obtained by continuous sampling of the liquid level sensor based on a preset sampling period, and writing the sampling data into a buffer; packaging and uploading the sampling data in the buffer to a monitoring platform based on a preset upload frequency, the monitoring platform including a fire monitoring platform and a business monitoring platform; when the power of the liquid level sensor is below a first preset value, packaging and uploading the sampling data in the buffer to the business monitoring platform; when the power of the liquid level sensor reaches or exceeds the first preset value but is below a second preset value, merging and uploading multiple consecutive data packets obtained in the packaging to the business monitoring platform and the fire monitoring platform; when the power of the liquid level sensor reaches or exceeds the second preset value, sequentially uploading each data packet obtained in the packaging to the business monitoring platform and the fire monitoring platform. This application can improve the service life of the liquid level sensor and meet the needs of data-driven collaborative management.

Description

Technical Field

[0001] This application belongs to the field of liquid level sensor technology, specifically relating to data processing methods and liquid level sensors. Background Technology

[0002] Liquid level sensors are pressure sensors used to measure liquid levels and are widely used in wastewater treatment, water conservancy and municipal engineering, and fire monitoring. Current liquid level sensor programming logic only supports single-channel data upload to the enterprise monitoring platform, resulting in a limited data upload channel and management dimensions, failing to meet the needs of cross-departmental and cross-platform data-driven collaborative management. Therefore, how to achieve multi-platform data collaborative management is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0003] The purpose of this application is to improve the service life of liquid level sensors and to meet the needs of cross-departmental and cross-platform data-driven collaborative management.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a data processing method is provided, applied to a liquid level sensor, the method comprising:

[0006] Acquire the sampling data obtained by the liquid level sensor through continuous sampling based on a preset sampling period, and write the sampling data into a buffer; The sampled data in the buffer is packaged and uploaded to the monitoring platform based on a preset upload frequency. The monitoring platform includes a fire monitoring platform and a business monitoring platform. During the process of packaging and uploading the sampled data to the monitoring platform, if the power of the liquid level sensor is detected to be below a first preset value, the system controls the packaging and uploading of the sampled data in the buffer to the business monitoring platform. When the power of the liquid level sensor is detected to be above the first preset value and below the second preset value, the system controls the merging and uploading of multiple consecutive data packets obtained in a package to the business monitoring platform and the fire monitoring platform, wherein the second preset value is greater than the first preset value; When the power level of the liquid level sensor is detected to be above the second preset value, the system controls the sequential uploading of each packaged data packet to the business monitoring platform and the fire monitoring platform.

[0007] The above technical solution has the following advantages or beneficial effects: Through the parallel transmission architecture of dual monitoring platforms, the same sampled data written to the buffer is packaged and uploaded to the monitoring platform. The fire monitoring platform and the business monitoring platform receive and process the data independently. This breaks down data silos, achieves seamless integration between enterprise operation and maintenance and government supervision, and meets the needs of multi-span collaborative management in digital urbanization.

[0008] In addition, during the process of uploading the sampled data to the monitoring platform, when the power of the liquid level sensor is in the low power range (i.e. below the first preset value), only the core business monitoring platform is uploaded, and the transmission to the non-essential fire monitoring platform is shut down. This ensures that all the limited power is used to guarantee the continuity of core business data, which significantly extends the service life and effective service cycle of the liquid level sensor in the low power range.

[0009] When the level sensor's battery level is in the medium range (i.e., above the first preset value and below the second preset value), the controller merges multiple consecutive data packets obtained from the packet and uploads them to the business monitoring platform and the fire monitoring platform. This reduces the number of handshakes during data packet transmission over the network, which not only meets the needs of cross-departmental collaborative management (dual transmission) but also effectively suppresses the additional energy consumption caused by dual transmission through the merging mechanism, thus achieving an optimized balance between functionality and battery life.

[0010] When the liquid level sensor's power is in the high power range (i.e., above the second preset value), the control will sequentially upload the packaged data packets to the business monitoring platform and the fire monitoring platform. Each data packet can be sent to the business monitoring platform and the fire monitoring platform immediately and individually, realizing the data-driven collaborative management needs across departments and platforms, while ensuring the highest real-time performance and integrity of the data.

[0011] Most importantly, a tiered transmission strategy ensures uninterrupted fire data transmission around the clock: regardless of whether the level sensor is in the low, medium, or high power range, the data upload path to the fire monitoring platform remains valid. When the level sensor is in the low power range and only the business monitoring platform is used for transmission, fire-related safety data can be relayed and synchronized through the business monitoring platform, ensuring that critical safety information such as fire water pressure and level is never completely lost due to equipment power issues under any circumstances. This fundamentally meets the highest level of data reliability requirements of intelligent fire protection systems.

[0012] According to one aspect of the embodiments of this application, the method further includes: The network status of the monitoring platform is detected according to a preset detection cycle, and the network status includes offline status and online status. If any of the monitoring platforms is detected to be offline for a preset number of consecutive times, a transmission error log will be generated, saved locally, and an alarm signal will be issued.

[0013] The above technical solution has the following advantages or beneficial effects: by actively detecting the network status of each monitoring platform through a preset detection cycle, when any monitoring platform is continuously detected to be offline for a preset number of times, it is determined to be a continuous transmission anomaly, and a transmission anomaly log is generated, saved locally, and an alarm signal is issued, which shortens the fault detection and response time and provides accurate fault information for operation and maintenance personnel.

[0014] According to one aspect of the embodiments of this application, the method further includes: If all the monitoring platforms are online, the sampled data will be deleted from the buffer after it is successfully uploaded. If some or all of the monitoring platforms are offline, the sampling data will be deleted from the buffer after the offline monitoring platforms are restored to online status and the sampling data is successfully uploaded to the restored online monitoring platforms.

[0015] The above technical solution has the following advantages or beneficial effects: if the monitoring platform is online, the sampled data will be deleted from the buffer after the sampled data is successfully uploaded, so as to release the storage space of the buffer.

[0016] If some or all of the monitoring platforms are offline, the sampled data will be deleted from the buffer after the offline monitoring platforms are restored to online status and the sampled data is successfully uploaded to the restored online monitoring platforms. This avoids data loss due to transmission failure and ensures data integrity.

[0017] According to one aspect of the embodiments of this application, the method further includes: The retry upload success rate of the monitoring platform within the historical statistical period is statistically analyzed. If the retry upload success rate is lower than the preset success rate threshold, the data upload frequency of the monitoring platform will be reduced and the retry backoff time will be extended. If the retry upload success rate is higher than or equal to the preset success rate threshold, the data upload frequency of the monitoring platform is restored.

[0018] The above technical solution has the following advantages or beneficial effects: If the statistical retry upload success rate is lower than the preset success rate threshold, the data upload frequency of the monitoring platform is reduced and the retry backoff time is extended to reduce invalid transmission attempts, further extend the service life of the liquid level sensor, and reduce network pressure; If the statistical retry upload success rate is higher than or equal to the preset success rate threshold, the data upload frequency of the monitoring platform is restored, thereby adapting to changes in the network environment, ensuring data real-time performance when the network quality is good (i.e., high retry upload success rate), and prioritizing the service life of the liquid level sensor and the transmission success rate when the network quality is poor (i.e., low retry upload success rate).

[0019] According to one aspect of the embodiments of this application, the method further includes: If only part of the monitoring platform is offline, the data packets to be supplemented for the offline monitoring platform are determined based on the first historical data packets received by the offline monitoring platform. When the monitoring platform, which was offline, returns to online status, the data packet to be supplemented is uploaded to the monitoring platform that has returned to online status.

[0020] The above technical solution has the following advantages or beneficial effects: it performs missing detection based solely on its own received historical data packets, eliminating the need for data interaction with other monitoring platforms, thus improving the independence and reliability of the monitoring platform; when a monitoring platform that was offline returns to online status, it uploads the missing data packets to the online monitoring platform to ensure that the data received by each monitoring platform is complete, avoiding data gaps caused by anomalies in some monitoring platforms.

[0021] According to one aspect of the embodiments of this application, the method further includes: If only part of the monitoring platform is offline, the first historical data packet received by the offline monitoring platform is compared with the second historical data packet received by the online monitoring platform, and the data packet to be supplemented for the offline monitoring platform is determined based on the comparison result. When the monitoring platform, which was offline, returns to online status, the data packet to be supplemented is uploaded to the monitoring platform that has returned to online status.

[0022] The above technical solution has the following advantages or beneficial effects: by using the complete data bit reference of the online monitoring platform, the missing data of the offline monitoring platform is supplemented, thereby effectively ensuring that the data received between the monitoring platforms are completely consistent.

[0023] According to one aspect of the embodiments of this application, the method further includes: Obtain the on-screen duration of the display screen of the liquid level sensor; When the screen-on time of the display reaches a set time threshold, the display is turned off until the liquid level sensor receives a trigger signal to control the display to turn on.

[0024] The above technical solution has the following advantages or beneficial effects: the display screen automatically counts after being turned on, and automatically turns off after reaching the set time threshold. The display screen only lights up again when it receives a trigger signal used to control the display screen to turn on, which reduces the overall power consumption of the liquid level sensor and further extends the service life of the liquid level sensor.

[0025] According to one aspect of the embodiments of this application, the method further includes: In response to the real-time collection command issued by the business monitoring platform, the sampled data currently written into the buffer is obtained, wherein the real-time collection command is the highest priority command; The sampled data already written into the buffer is packaged and uploaded to the business monitoring platform.

[0026] The above technical solution has the following advantages or beneficial effects: the business monitoring platform can issue real-time acquisition commands, and the liquid level sensor will immediately package and upload the sampling data in the current buffer to the business monitoring platform, so that maintenance personnel do not need to wait for the upload cycle and can obtain the real-time data of the liquid level sensor at any time, which greatly improves the efficiency of remote maintenance.

[0027] According to one aspect of the embodiments of this application, the method further includes: The sampling data obtained by the liquid level sensor is detected based on a preset threshold range; When the sampled data is detected to be within the normal threshold range, the process of uploading the sampled data in the buffer to the monitoring platform based on the preset upload frequency is controlled based on the power of the liquid level sensor. When the sampled data is detected to exceed the normal threshold range, the sampled data in the buffer is packaged and uploaded to the monitoring platform based solely on the preset upload frequency.

[0028] The above technical solution has the following advantages or beneficial effects: when the sampled data is detected to be within the normal threshold range, the power consumption of the liquid level sensor is controlled in a graded manner to reduce power consumption and extend the service life of the liquid level sensor; when the sampled data is detected to exceed the normal threshold range, the power consumption graded strategy is skipped and real-time dual transmission is maintained, thereby ensuring that emergencies such as abnormal fire water pressure and excessive liquid level can be reported in a timely manner, thus protecting the safety of people's lives and property.

[0029] According to one aspect of the embodiments of this application, a liquid level sensor is provided, comprising: The liquid level and pressure sensing module is used to collect sampling data of liquid level and pressure according to a set acquisition cycle; A display screen is used to display the sampling data; Local memory is used to store the sampled data, forming a buffer; The wireless communication module is used to communicate with multiple monitoring platforms. A button module is used to control the display screen to light up; The alarm module is used to send alarm signals; The control module is used to execute any of the methods described above.

[0030] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0031] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0032] 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. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0033] Figure 1 A flowchart of a data processing method according to an embodiment of this application is shown.

[0034] Figure 2 A logical schematic diagram of data distribution according to one embodiment of this application is shown.

[0035] Figure 3 A flowchart of a data processing method according to another embodiment of this application is shown.

[0036] Figure 4 A flowchart of a data processing method according to another embodiment of this application is shown.

[0037] Figure 5 A flowchart of a data processing method according to another embodiment of this application is shown.

[0038] Figure 6 A flowchart of a data processing method according to another embodiment of this application is shown.

[0039] Figure 7 A flowchart of a data processing method according to another embodiment of this application is shown.

[0040] Figure 8 A flowchart of a data processing method according to another embodiment of this application is shown.

[0041] Figure 9 A flowchart of a data processing method according to another embodiment of this application is shown.

[0042] Figure 10 A flowchart of a data processing method according to another embodiment of this application is shown. Detailed Implementation

[0043] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0044] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0045] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0046] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0047] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0048] Liquid level sensors are pressure sensors used to measure liquid levels and are widely used in wastewater treatment, water conservancy and municipal engineering, and fire monitoring. Current liquid level sensor programming logic only supports single-channel data upload to the enterprise monitoring platform, resulting in a limited data upload channel and management dimensions, failing to meet the needs of cross-departmental and cross-platform data-driven collaborative management. Therefore, how to achieve multi-platform data collaborative management is a technical problem that urgently needs to be solved by those skilled in the art.

[0049] Therefore, this application proposes a data processing method that can improve the service life of liquid level sensors and meet the needs of cross-departmental and cross-platform data-driven collaborative management.

[0050] Please see Figure 1 , Figure 1 A flowchart of a data processing method according to an embodiment of this application is shown. This application provides execution steps of a data processing method, including: S110: Acquire sampling data obtained by the liquid level sensor through continuous sampling based on a preset sampling period, and write the sampling data into the buffer.

[0051] S120 packages and uploads the sampled data in the buffer to the monitoring platform based on a preset upload frequency. The monitoring platform includes a fire monitoring platform and a business monitoring platform.

[0052] S130: During the process of uploading the sampled data to the monitoring platform, if the power of the liquid level sensor is detected to be below the first preset value, the system controls the uploading of the sampled data in the buffer to the business monitoring platform.

[0053] S140, when the power of the liquid level sensor is detected to be above the first preset value and below the second preset value, the control will merge and upload the multiple consecutive data packets obtained in the package to the business monitoring platform and the fire monitoring platform, wherein the second preset value is greater than the first preset value.

[0054] S150: When the power of the liquid level sensor is detected to be above the second preset value, the controller will sequentially upload the packaged data packets to the business monitoring platform and the fire monitoring platform.

[0055] The five steps described above are described in detail below.

[0056] In S110, the level sensor continuously samples the level / pressure parameters of the target monitoring point according to a preset sampling period and writes the collected sampling data into a local buffer. The preset sampling period is the time interval between two data acquisitions pre-configured by the level sensor and can be flexibly adjusted according to different application scenarios; for example, it can be set to 1 minute / time for sewage treatment sedimentation tanks and 30 seconds / time for fire-fighting water tanks. The local buffer is specifically a local circular buffer, a circular storage structure using a first-in-first-out (FIFO) mechanism. Unlike ordinary linear buffers, its storage space is logically organized into a ring, and when the write pointer reaches the end of the buffer, it automatically loops back to the beginning. When new sampling data is written, if the buffer is full, it automatically overwrites the oldest and successfully uploaded sampling data, ensuring that the memory does not overflow.

[0057] In some embodiments of this application, to prevent bit errors due to electromagnetic interference or other reasons during data storage or transmission, a Cyclic Redundancy Check (CRC) code for the sampled data is simultaneously calculated and stored when the sampled data is written to the circular buffer. The CRC check code is appended to the end of the data packet. When the data is read out and ready to be uploaded, the main control chip of the liquid level sensor recalculates the CRC value of the sampled data and compares it with the stored CRC value. If the comparison matches, it proves that the data is complete and undamaged; if they do not match, the data packet is discarded and a resampling or retransmission mechanism is triggered.

[0058] As can be seen, in this example, using a local circular buffer to cache sampled data perfectly adapts to the complex network environments of smart cities and smart fire protection. For example, in areas with unstable signal coverage, such as underground sewage wells in cities or reservoirs in remote mountainous areas, the circular buffer can automatically cache sampled data for several hours or even days when the network is temporarily interrupted, and automatically retransmit it after the network is restored, completely avoiding the data loss problem caused by network fluctuations in existing technologies. At the same time, the read-write decoupling feature of the circular buffer allows data acquisition and data uploading to operate independently without interference, ensuring the continuity of sampled data and the flexibility of uploading, laying a solid data foundation for multi-platform collaborative data management.

[0059] In S120, the level sensor reads sampled data from a local circular buffer based on a preset upload frequency, packages it into independent data packets, and uploads them in parallel to various monitoring platforms, including fire monitoring platforms and business monitoring platforms. The preset upload frequency refers to the time interval at which the level sensor sends independent data packets to the monitoring platform, typically greater than or equal to the sampling period. For example, if the sampling period is 30 seconds, the upload frequency can be set to 1 minute / time. Parallel transmission across dual monitoring platforms means that the level sensor simultaneously establishes communication connections with two independent monitoring platforms. The data transmission channels of the two independent monitoring platforms are independent and do not affect each other. The fire monitoring platform is the government fire department's regulatory platform, used for real-time monitoring of the status of fire hydrants in the jurisdiction and emergency dispatch command; the business monitoring platform is the company's own operation and maintenance management platform, used for equipment status monitoring, daily maintenance, and data statistical analysis.

[0060] In some embodiments of this application, the liquid level sensor can simultaneously establish communication connections with two or more independent monitoring platforms. The data transmission channels of the two or more independent monitoring platforms are independent of each other and do not affect each other. When more monitoring platforms (such as water management platforms) need to be added, only an independent sending queue and sending thread need to be added, and the existing acquisition and caching modules can be reused without modifying the overall architecture, which greatly improves the scalability and adaptability of the system.

[0061] The core of this step employs a "one source, multiple packets" distribution mechanism, generating multiple independent data packets from the same original sampling data, each adapted to the protocol requirements of different monitoring platforms. Specifically, the level sensor reads the original sampling data from the circular buffer and packages it into independent data packets adapted to the fire monitoring platform and the business monitoring platform, respectively, according to the protocol requirements of each of the two monitoring platforms. The transmission channels of each monitoring platform are physically / logically isolated and do not interfere with each other. Each independent data packet carries a unique device identifier, a unique data sequence number, a timestamp, a sampling value, and a CRC checksum. The platform side uses combination to achieve idempotent verification, avoiding data duplication and out-of-order processing.

[0062] As can be seen, in this example, the parallel transmission architecture of dual or even multiple monitoring platforms completely breaks down the data silos of traditional liquid level sensors, realizing the core requirement of multi-sectoral collaborative management in smart cities. In smart fire protection scenarios, fire departments can directly and in real-time obtain water pressure and liquid level data of all fire pools and fire hydrants within their jurisdiction without needing to go through an enterprise monitoring platform. When a fire occurs, they can grasp the fire water source situation immediately, accurately dispatch rescue forces, and significantly improve emergency response efficiency. At the same time, the enterprise operation and maintenance platform can still perform normal daily equipment management and data statistics, achieving seamless integration between government supervision and enterprise operation and maintenance, which is currently impossible to achieve with single monitoring platform transmission technology.

[0063] Please see Figure 2 , Figure 2 A logical schematic diagram of data distribution according to one embodiment of this application is shown. Figure 2 As shown, the liquid level sensor acquisition thread samples data at a preset cycle and writes it to the buffer. After the buffer temporarily stores the data, the distribution logic generates two independent data packets, which enter two independent sending queues respectively. Subsequently, sending threads A and B read the data packets from the queues and upload them to the business monitoring platform and the fire monitoring platform according to their respective transmission strategies. If a failure occurs during transmission or the platform goes offline, the thread will trigger a retry, backoff, or resend mechanism until the data is successfully uploaded.

[0064] In S130, when the level sensor's battery level is detected to be below a first preset value, the level sensor automatically switches to low-battery mode, only uploading the sampled data in the buffer to the business monitoring platform. The first preset value is a threshold for the remaining battery capacity of the level sensor, which can be set to 20% or other values. The business monitoring platform is the platform that ensures the basic operational functions of the level sensor, mainly used for equipment status monitoring, fault alarms, and basic data statistics; it represents the minimum functional requirement that the level sensor must guarantee.

[0065] The core of this step is a tiered power supply strategy based on the power level of the liquid level sensor, which reduces power consumption by shutting down unnecessary communication channels. When the liquid level sensor is in low power mode, it shuts down the communication channel with the fire monitoring platform, retaining only the communication function with the business monitoring platform, thus using all the limited power to ensure the transmission of core business data.

[0066] Taking urban river water level monitoring as an example, the level sensors are deployed in remote areas, making battery replacement costly. During the winter dry season, water levels remain low for extended periods with no flood risk, thus reducing the fire department's need for real-time river water level data. If the level sensor detects that its battery level has dropped to 18% (below the first preset value of 20%), it automatically switches to low-battery mode: continuously sending water level data to the water company's business monitoring platform for historical recording and trend analysis, but suspending transmission to the city's flood control command center's fire monitoring platform. This ensures that even when the battery is nearly depleted, the most basic water level recording function remains uninterrupted, providing the water company with a valuable maintenance window (e.g., planning a unified battery replacement next month).

[0067] As can be seen, in this embodiment, the low-battery single-platform transmission strategy can significantly extend the lifespan of the liquid level sensor in the low-battery range, making it particularly suitable for widely distributed and difficult-to-maintain monitoring nodes in smart cities. Examples include fire hydrants along city roads and river level monitoring points in remote areas. These nodes are numerous and geographically dispersed, making battery replacement extremely costly in terms of manpower and time. With this strategy, when the battery is low, the liquid level sensor can still maintain core operational functions for several months, avoiding equipment offline and monitoring blind spots caused by battery depletion, and significantly reducing the operation and maintenance costs of smart city infrastructure.

[0068] In S140, the core of this step is to reduce the power consumption of wireless communication by merging transmissions and reducing the number of handshakes. When the level sensor's battery level is detected to be above a first preset value and below a second preset value, the level sensor automatically switches to a medium-battery mode, merging multiple consecutive data packets obtained in a single packet, and then simultaneously uploading the merged data packets to both the business monitoring platform and the fire monitoring platform. The second preset value is greater than the first preset value; the second preset value is the intermediate threshold of the remaining battery capacity and can be set to 50% or other values. The data packet merging mechanism refers to splicing multiple independent sampling data packets into a composite data packet in chronological order, performing only one network handshake and transmission.

[0069] In the outdoor fire hydrant monitoring scenario of smart fire protection, the water pressure data of fire hydrants typically changes relatively smoothly, without requiring second-level real-time monitoring. Assuming there are hundreds of fire hydrants in an area, each independently sending data to the fire monitoring platform at high frequency would create enormous concurrent load on the platform. When the level sensor's battery level is between 30% (above 20%, below 50%), a medium-battery mode is automatically activated. This mode combines data from each set collection cycle (e.g., 3 times, 15 minutes) into a composite data packet, which is then simultaneously sent to both the business monitoring platform and the fire monitoring platform.

[0070] As can be seen, in this example, the data packet merging and transmission strategy for medium-level liquid levels achieves an optimized balance between functionality and battery life, perfectly adapting to the routine monitoring needs of smart fire protection. Under normal circumstances, fire departments need to continuously acquire status data of fire protection facilities, but the real-time requirements are slightly lower than in emergencies. By adopting merged transmission, both the fire monitoring platform and the business monitoring platform receive complete data, meeting the requirements of cross-departmental collaborative management. Furthermore, by reducing the number of handshakes, it effectively suppresses the additional energy consumption caused by dual transmissions, extending the overall battery life of the liquid level sensor.

[0071] In S150, the core of this step is to pursue optimal system performance, including data real-time performance, integrity, and independence, under the condition of sufficient energy budget. When the level sensor's battery level reaches or exceeds a second preset value, the level sensor automatically switches to high-battery mode, sequentially and in real-time uploading each packaged data packet to the business monitoring platform and the fire monitoring platform. The high-battery range can refer to a state where the battery's remaining capacity is greater than 50%, at which point the level sensor has sufficient power to support high-performance operation. Real-time dual transmission means that each sampled data is immediately packaged and simultaneously sent to both monitoring platforms after generation, without waiting for merging or delay. Data is transmitted in ascending order of ID to ensure data consistency. After receiving a data packet, the platform checks if the packet already exists; if it does, it discards the packet; otherwise, it stores and processes it.

[0072] As can be seen in this example, the high-power real-time dual-transmission strategy provides the highest data real-time performance and integrity, offering crucial support for emergency response in smart fire protection. In emergencies such as fires or burst pipes, the water level in fire tanks or the water pressure in fire hydrants changes rapidly. At this time, the level sensor operates in high-power mode, enabling it to upload every sampled data point to both the fire monitoring platform and the operational monitoring platform in real time. Fire departments can accurately grasp the dynamic changes in fire water sources through real-time data, adjust rescue plans promptly, and avoid rescue errors caused by data delays. Simultaneously, the enterprise operations and maintenance platform can also acquire data synchronously, enabling rapid equipment repair and minimizing losses.

[0073] As shown in S110-S150 above, through the parallel transmission architecture of the dual monitoring platforms, the same sampled data written to the buffer is packaged and uploaded to the monitoring platform. The fire monitoring platform and the business monitoring platform receive and process the data independently. This breaks down data silos, achieves seamless integration between enterprise operation and maintenance and government supervision, and meets the needs of multi-span collaborative management in digital urbanization.

[0074] In addition, during the process of uploading the sampled data to the monitoring platform, when the power of the liquid level sensor is in the low power range (i.e. below the first preset value), only the core business monitoring platform is uploaded, and the transmission to the non-essential fire monitoring platform is shut down. This ensures that all the limited power is used to guarantee the continuity of core business data, which significantly extends the service life and effective service cycle of the liquid level sensor in the low power range.

[0075] When the level sensor's battery level is in the medium range (i.e., above the first preset value and below the second preset value), the controller merges multiple consecutive data packets obtained from the packet and uploads them to the business monitoring platform and the fire monitoring platform. This reduces the number of handshakes during data packet transmission over the network, which not only meets the needs of cross-departmental collaborative management (dual transmission) but also effectively suppresses the additional energy consumption caused by dual transmission through the merging mechanism, thus achieving an optimized balance between functionality and battery life.

[0076] When the liquid level sensor's power is in the high power range (i.e., above the second preset value), the control will sequentially upload the packaged data packets to the business monitoring platform and the fire monitoring platform. Each data packet can be sent to the business monitoring platform and the fire monitoring platform immediately and individually, realizing the data-driven collaborative management needs across departments and platforms, while ensuring the highest real-time performance and integrity of the data.

[0077] Most importantly, a tiered transmission strategy ensures uninterrupted fire data transmission around the clock: regardless of whether the level sensor is in the low, medium, or high power range, the data upload path to the fire monitoring platform remains valid. When the level sensor is in the low power range and only the business monitoring platform is used for transmission, fire-related safety data can be relayed and synchronized through the business monitoring platform, ensuring that critical safety information such as fire water pressure and level is never completely lost due to equipment power issues under any circumstances. This fundamentally meets the highest level of data reliability requirements of intelligent fire protection systems.

[0078] Please see Figure 3 , Figure 3 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S210 detects the network status of the monitoring platform according to a preset detection cycle. The network status includes offline status and online status.

[0079] S220: If any monitoring platform is continuously detected to be offline for a preset number of times, a transmission abnormality log will be generated, saved locally, and an alarm signal will be issued.

[0080] The two steps described above are described in detail below.

[0081] In the S210, the level sensor periodically checks the network status of various monitoring platforms according to a preset detection cycle. The detected network status is divided into two types: offline and online. The preset detection cycle is the time interval between two pre-configured network status checks by the level sensor. It can be flexibly adjusted according to the stability requirements of different monitoring scenarios in smart cities. For example, it can be set to 30 seconds / time for monitoring fire pools in urban core areas, and 1 minute / time for weak signal scenarios such as fire hydrants and underground sewage wells in remote suburbs, balancing the timeliness of anomaly detection with the low-power operation requirements of the equipment. Online status means that the wireless communication link between the level sensor and the monitoring platform is uninterrupted, and data packets can be sent and received normally. Offline status means that the wireless communication link between the level sensor and the monitoring platform is interrupted, and data packet transmission and interaction cannot be completed. This includes transmission interruptions caused by network signal loss, platform server maintenance, communication module failure, etc.

[0082] In some embodiments of this application, the liquid level sensor independently detects the network status of the fire monitoring platform and the business monitoring platform. The network status detection processes of the two monitoring platforms are independent of each other and do not interfere with each other. An abnormal status of either monitoring platform will not affect the detection and transmission process of the other monitoring platform.

[0083] As can be seen, in this example, the method of periodically and independently detecting the network status of the dual monitoring platforms can accurately adapt to the complex communication environments in the fields of smart cities and smart fire protection. For example, in areas with frequent fluctuations in 4G / NB-IoT (narrowband Internet of Things) signals, such as urban underground pipe networks and remote mountain reservoirs, the liquid level sensor can continuously sense the connection status with the fire monitoring platform and the business monitoring platform, promptly capturing temporary interruptions or long-term anomalies in the communication link. This provides accurate status information for subsequent anomaly handling, data caching, and retransmission, ensuring the stability of data transmission across multiple platforms.

[0084] In the S220, when the level sensor continuously detects that any monitoring platform is offline, and the number of consecutive offline detections reaches a preset number, a corresponding transmission anomaly log is automatically generated and saved to the local storage unit, while simultaneously triggering an alarm signal. The preset number of detections is a pre-configured continuous offline detection threshold for the level sensor, which can be set to 3, 5, or other values ​​depending on the scenario requirements. This distinguishes between temporary signal fluctuations and continuous transmission failures, preventing false alarms triggered by momentary signal interruptions. The transmission anomaly log records key information about the transmission failure, including the time of the anomaly, the platform identifier (fire monitoring platform / business monitoring platform), the number of consecutive offline detections, the current sensor battery level, and the amount of data in the buffer zone. The local storage unit is the level sensor's built-in Flash memory, a non-volatile storage medium that ensures log data is not lost after power failure, facilitating subsequent on-site maintenance and troubleshooting. The alarm signal can be displayed via the level sensor's LED indicator and a local buzzer. For example, a flashing red indicator indicates the fire monitoring platform is offline, while a flashing yellow indicator indicates the business monitoring platform is offline.

[0085] Taking the monitoring of fire hydrants on urban roads in a smart fire protection city as an example, the liquid level sensor deployed in the old city detected that the communication with the fire monitoring platform was offline five times in a row due to signal interference from surrounding base stations (the preset number of times is five). The liquid level sensor immediately generated a transmission anomaly log containing the abnormal time, platform type, and signal strength and stored it in the built-in Flash. At the same time, it triggered the red LED indicator to flash periodically. On-site maintenance personnel can quickly locate the faulty equipment through the indicator.

[0086] As can be seen, in this embodiment, the combined strategy of continuous offline judgment, local log storage, and alarm signal triggering perfectly adapts to the operation and maintenance needs of wide-area monitoring nodes in smart cities. For the numerous dispersed monitoring devices such as fire hydrants, sewage wells, and reservoirs in cities, this strategy can accurately filter instantaneous signal fluctuations, recording and alarming only for persistent transmission failures. This avoids operational interference caused by invalid alarms and allows maintenance personnel to locate faulty equipment immediately. The locally stored anomaly logs can completely preserve fault details, providing data support for quickly troubleshooting communication failures and repairing transmission links, significantly improving the maintainability and operational reliability of smart city and smart fire monitoring systems.

[0087] In some embodiments of this application, two indicator lights are provided to indicate communication anomalies between the two monitoring platforms. When a monitoring platform malfunctions, the corresponding alarm indicator light will illuminate. Alternatively, a dual-color indicator light can be provided to determine which monitoring platform is experiencing a communication anomaly based on its color.

[0088] As shown in S210-S220 above, the network status of each monitoring platform is actively detected through a preset detection cycle. When any monitoring platform is continuously detected to be offline for a preset number of times, it is determined to be a continuous transmission anomaly. A transmission anomaly log is generated, saved locally, and an alarm signal is issued, which shortens the fault detection and response time and provides accurate fault information for operation and maintenance personnel.

[0089] Please see Figure 4 , Figure 4 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S310: If all monitoring platforms are online, the sampled data will be deleted from the buffer after it is successfully uploaded.

[0090] S320: If some or all of the monitoring platforms are offline, the sampled data will be deleted from the buffer after the offline monitoring platforms are restored to online status and the sampled data is successfully uploaded to the restored online monitoring platforms.

[0091] The two steps described above are described in detail below.

[0092] In S310, if the level sensor detects that all monitoring platforms are online, the sampled data will be deleted from the local buffer after it has been successfully uploaded to all monitoring platforms. "All monitoring platforms are online" means that the communication links between the fire monitoring platform and the business monitoring platform are intact, and the level sensor and both monitoring platforms can normally complete data transmission, response, and verification interactions. "Successful data upload" means that the level sensor receives data reception confirmation commands from both the fire monitoring platform and the business monitoring platform, and the platform side completes CRC verification and (device ID + data ID) idempotency verification, determining that the data is valid and error-free. The local buffer is a built-in circular buffer of the level sensor. Deleting the sampled data releases the corresponding data storage area, updates the buffer read and write pointers, and frees up storage space for newly collected sampled data.

[0093] The buffer data deletion operation is strongly linked to the data upload success status. The deletion action will only be performed after both monitoring platforms return a successful upload status, thus preventing accidental data deletion due to the monitoring platform not confirming receipt.

[0094] Taking the monitoring scenario of fire water tank in the core area of ​​a smart city as an example, the liquid level sensor of the fire water tank detects in real time that both the fire monitoring platform and the business monitoring platform are online. After the sampled water pressure and liquid level data are packaged and uploaded to the dual monitoring platforms and both receive a successful receipt, the corresponding data packet is immediately deleted from the circular buffer.

[0095] As can be seen in this example, the strategy of deleting cached data immediately upon successful upload when the dual monitoring platforms are online can promptly release the storage space of the circular buffer, preventing overflow due to data accumulation and ensuring the continuous and stable operation of the liquid level sensor data acquisition and storage process. This strategy is perfectly suited to monitoring scenarios with stable signals and smooth data transmission in the core areas of smart cities, keeping the buffer in a highly efficient and available state at all times, supporting the long-term uninterrupted operation of the liquid level sensor.

[0096] In S320, if the level sensor detects that some monitoring platforms are offline, or all monitoring platforms are offline, the corresponding sampled data in the buffer is retained until the offline monitoring platform returns to online status. The sampled data is then successfully resent to the restored online monitoring platform before being deleted from the buffer. Specifically, "some monitoring platforms offline" means that only one of the fire monitoring platform and the business monitoring platform is offline, while the other remains online; "all monitoring platforms offline" means that the communication link between both monitoring platforms is interrupted, and the level sensor cannot transmit data to either platform; "offline platform restored to online status" means that the network signal is restored, the platform server restarts, or the communication fault is resolved, and a stable communication link is re-established between the level sensor and the offline platform; "successful upload" means that the resent sampled data is normally received and verified by the restored online platform.

[0097] The buffer will prioritize retaining sampled data that has not yet been uploaded to all platforms until all monitoring platforms have completed receiving the data, and the data will not be overwritten by new data during the retention period to ensure that no data is lost.

[0098] Taking the smart fire protection system for monitoring fire hydrants in old urban areas as an example, the fire hydrant level sensor detects that the fire monitoring platform is offline due to server maintenance, while only the business monitoring platform is online. After the level sensor successfully uploads the sampled data to the business monitoring platform, it still retains the data in the circular buffer. After the fire monitoring platform is restored to online status, the level sensor resends the cached data to the fire monitoring platform. Once both monitoring platforms have successfully uploaded the data, the data is then deleted from the buffer.

[0099] As can be seen in this example, the strategy of deleting data only after the offline platform has been successfully restored and resent can completely avoid the problem of data loss due to network fluctuations and platform maintenance, and comprehensively ensure the integrity of smart fire protection and smart city monitoring data. This strategy is particularly suitable for monitoring scenarios with unstable signals and prone to platform downtime, such as urban underground sewage wells, fire hydrants in remote suburbs, and mountain reservoirs. Even in the event of a long-term network outage, the data can be completely resent after the network is restored, providing reliable data protection for smart city full-area monitoring and smart fire emergency supervision.

[0100] As shown in S310-S320 above, if all monitoring platforms are online, the sampled data will be deleted from the buffer after successful upload to free up storage space. If some or all monitoring platforms are offline, the sampled data will be deleted from the buffer after the offline platforms are restored to online status and the sampled data is successfully uploaded to them, thus avoiding data loss due to transmission failure and ensuring data integrity.

[0101] Please see Figure 5 , Figure 5 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S410, the success rate of retry uploads within the historical statistical period of the statistical monitoring platform.

[0102] S420: If the retry upload success rate is lower than the preset success rate threshold, the data upload frequency of the monitoring platform will be reduced and the retry backoff time will be extended.

[0103] S430: If the retry upload success rate is higher than or equal to the preset success rate threshold, the data upload frequency of the monitoring platform will be restored.

[0104] The three steps described above are described in detail below.

[0105] In the S410, the liquid level sensor performs real-time statistics on the data retry upload status of each monitoring platform within a preset historical statistical period, and calculates the retry upload success rate of the corresponding monitoring platform. The historical statistical period is a pre-configured time window for the liquid level sensor to statistically analyze transmission stability. It can be flexibly adjusted according to different scenarios such as smart cities and smart fire protection. For example, it can be set to 30 minutes for scenarios with stable signals, such as fire pools in urban core areas and municipal pipe networks, and to 1 hour for scenarios with fluctuating signals, such as fire hydrants in remote suburbs, mountain reservoirs, and underground sewage wells. The retry upload success rate is the ratio of the number of data packets successfully retried and uploaded by the monitoring platform to the total number of retry uploads within the historical statistical period. This ratio directly reflects the smoothness and stability of network transmission between the liquid level sensor and the corresponding monitoring platform.

[0106] The liquid level sensor independently calculates the retry upload success rate for both the fire monitoring platform and the business monitoring platform. The statistical logic of the two monitoring platforms is independent of each other and does not interfere with each other, which can accurately adapt to the different network conditions and transmission quality of the two monitoring platforms.

[0107] The liquid level sensor records the total number of retries and the number of successful retries for each monitoring platform in real time through its built-in counting unit. After the historical statistical period ends, it automatically performs ratio calculations, updates and synchronizes the retry upload success rate in real time, and provides accurate data for subsequent adaptive adjustment.

[0108] In S420, when the retry upload success rate of the monitoring platform, as statistically obtained from the liquid level sensor, is lower than a preset success rate threshold, an adaptive network degradation adjustment strategy is automatically executed. This reduces the data upload frequency of the monitoring platform and extends the retry backoff time after data transmission failure. The preset success rate threshold is a transmission stability judgment standard pre-configured by the liquid level sensor; in this embodiment, it is preferably set to 80%, used to distinguish between a high-quality network state and a network interference / degraded state. The data upload frequency is the time interval between the liquid level sensor sending data packets to the monitoring platform; reducing the upload frequency extends the data transmission time period and reduces the number of transmissions. The retry backoff time is the interval between data transmission failures and the next retry; extending the backoff time increases the waiting time after a failure, avoiding frequent invalid retries in a short period.

[0109] Taking the smart fire protection system for monitoring fire hydrants in remote urban areas as an example, the liquid level sensor deployed in the suburbs had a retry upload success rate of only 65% ​​in the past hour due to signal obstruction and frequency interference, which is lower than the preset threshold of 80%. The liquid level sensor automatically reduced the upload frequency from 1 minute / time to 5 minutes / time, and extended the retry backoff time from 30 seconds to 2 minutes.

[0110] This adjustment mechanism significantly reduces the wake-up frequency and power consumption of the wireless communication module by reducing invalid transmission attempts. At the same time, it avoids frequent retries from exacerbating network congestion and increasing the concurrent pressure on the platform server, thus adapting to the low power consumption and high stability operation requirements of wide-area monitoring nodes in smart cities.

[0111] In S430, when the retry upload success rate of the monitoring platform, as calculated by the level sensor, is higher than or equal to a preset success rate threshold, it is determined that the network transmission status between the sensor and the monitoring platform has stabilized. The system automatically restores the data upload frequency of the monitoring platform to the default normal standard, and simultaneously restores the default retry backoff duration. Restoring the data upload frequency means returning to the standard transmission interval initially configured for the level sensor, ensuring the real-time transmission of monitoring data; restoring the retry backoff duration means returning to the default retry waiting interval, ensuring that abnormal data can be quickly resent and reach the monitoring platform in a timely manner when the network is stable.

[0112] Taking the aforementioned suburban fire hydrant monitoring scenario as an example, once the surrounding signal interference is eliminated and the network link is restored, the liquid level sensor recalculates the retry upload success rate of the fire monitoring platform, which rises to 90%, reaching the preset success rate threshold. The upload frequency is immediately restored to 1 minute / time, and the retry backoff time is restored to 30 seconds, returning to the normal and efficient transmission state.

[0113] As shown in S410-S430 above, if the statistical retry upload success rate is lower than the preset success rate threshold, the data upload frequency of the monitoring platform is reduced and the retry backoff time is extended to reduce invalid transmission attempts, further extend the service life of the liquid level sensor, and reduce network pressure. If the statistical retry upload success rate is higher than or equal to the preset success rate threshold, the data upload frequency of the monitoring platform is restored, so as to adapt to changes in the network environment. When the network quality is good (i.e., the retry upload success rate is high), the real-time data is guaranteed, and when the network quality is poor (i.e., the retry upload success rate is low), priority is given to ensuring the service life of the liquid level sensor and the transmission success rate.

[0114] Please see Figure 6 , Figure 6 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S510, if only part of the monitoring platform is offline, then the data packets to be supplemented for the offline monitoring platform are determined based on the first historical data packets received by the offline monitoring platform.

[0115] S520: When a monitoring platform that was offline returns to online status, the data packets to be supplemented are uploaded to the monitoring platform that has returned to online status.

[0116] The two steps described above are described in detail below.

[0117] In S510, if the level sensor detects that only some monitoring platforms are offline while the rest are maintaining normal online transmission, the level sensor independently identifies and determines the missing data packets corresponding to the offline monitoring platforms based on the first historical data packets already received by the offline monitoring platforms. Here, "some monitoring platforms are offline" means that only one of the fire monitoring platform and the business monitoring platform has an interrupted communication link, while the other platform can normally complete data reception and response; "first historical data packets" refers to the last successfully received, verified, and confirmed data packet by the offline monitoring platform before the communication interruption. This data packet carries a unique data ID, device ID, and sampling timestamp, which is the core basis for determining data loss; "missing data packets" refers to all consecutive data packets that the level sensor has normally collected and buffered in the circular buffer during the monitoring platform's offline period but have not been successfully sent to that offline monitoring platform.

[0118] In some embodiments of this application, the liquid level sensor can automatically locate the data ID interruption range simply by comparing the latest data ID of the first historical data packet of the offline monitoring platform with the current data ID of the local buffer. It can independently lock the missing data packet without any data interaction with the online monitoring platform or relying on platform-side data comparison.

[0119] Taking the fire hydrant monitoring scenario in the core area of ​​a smart fire protection city as an example, the liquid level sensor detects that the fire monitoring platform is offline due to line maintenance, while the business monitoring platform is transmitting normally online. The liquid level sensor retrieves the last first historical data packet received by the fire monitoring platform before it went offline, whose data ID is 892. The latest cached data ID in the local circular buffer is 927. Based on this, the liquid level sensor directly identifies the data packets with data IDs 893 to 927 as the data packets to be supplemented by the fire monitoring platform.

[0120] In S520, once the level sensor periodically checks the network and determines that the previously offline monitoring platform has returned to online status and the communication link is stable, it immediately uploads the missing data packets identified in S510 to the restored online monitoring platform in ascending order of data ID, completing the fully automatic completion of missing data. The monitoring platform returning to online status means that the platform server has completed maintenance, the network signal has returned to normal, the communication link has been re-established, and the level sensor has successfully received the online response and handshake signal returned by the platform. The missing data packets are strictly resent in ascending order of data ID to ensure the continuity of data received by the platform. Simultaneously, the platform performs idempotency verification using a combination of (device ID + data ID) to avoid duplicate storage and data out-of-order processing.

[0121] In some embodiments of this application, the execution priority of the data completion process is higher than that of the regular periodic upload process. After all the data packets to be completed have been uploaded and confirmed to be successful, the sensor will then return to the default periodic upload mode to ensure data integrity.

[0122] Continuing with the above-mentioned urban fire hydrant monitoring scenario, once the fire monitoring platform's lines are repaired and restored to online status, the liquid level sensor immediately retransmits the missing data packets (IDs 893 to 927) one by one in sequence until the fire monitoring platform successfully receives them all, and then continues to perform the regular liquid level data cycle upload.

[0123] As can be seen from S510-S520 above, missing data detection is performed only based on the historical data packets received by the platform itself, without the need for data interaction with other monitoring platforms, which improves the independence and reliability of the monitoring platform. When a monitoring platform that is offline returns to online status, the missing data packets are uploaded to the monitoring platform that has returned to online status to ensure that the data received by each monitoring platform is complete and to avoid data gaps caused by abnormalities of some monitoring platforms.

[0124] Please see Figure 7 , Figure 7 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S610, if only part of the monitoring platform is offline, the first historical data packet received by the offline monitoring platform is compared with the second historical data packet received by the online monitoring platform, and the data packet to be supplemented for the offline monitoring platform is determined based on the comparison result.

[0125] S620: When a monitoring platform that was offline returns to online status, the data packets to be supplemented are uploaded to the monitoring platform that has returned to online status.

[0126] The two steps described above are described in detail below.

[0127] In S610, if the level sensor detects that only some monitoring platforms are offline while the rest are maintaining normal online transmission, the first historical data packets received by the offline monitoring platforms are compared with the second historical data packets received by the online monitoring platforms. Based on the comparison result, the missing data packets corresponding to the offline monitoring platforms are accurately determined. The second historical data packet refers to the latest data packet normally received by the online monitoring platform during the same period, whose data ID corresponds to a complete and continuous transmission record. The missing data packets also refer to all data packets corresponding to the missing data ID range of the offline monitoring platform, based on the complete data sequence of the online monitoring platform.

[0128] The comparison process only requires comparing the data IDs of the first historical data packet and the second historical data packet. Using the data ID of the second historical data packet from the online monitoring platform as a complete benchmark, the interruption point of the data ID of the first historical data packet from the offline monitoring platform is located. There is no need to transmit the complete data content, resulting in high comparison efficiency and accurate judgment.

[0129] Taking the monitoring scenario of fire pools in a smart fire protection city as an example, the liquid level sensor detects that the fire monitoring platform is offline due to server upgrades, while the business monitoring platform remains online. The last historical data packet received by the offline fire monitoring platform has a data ID of 1052, while the latest historical data packet received by the online business monitoring platform has a data ID of 1088. By comparing the two sets of data IDs, the liquid level sensor directly identifies data IDs 1053 to 1088 as the data packets to be supplemented by the fire monitoring platform.

[0130] For S620, please refer to the description in S520; further details will not be provided here.

[0131] As can be seen from S610-S620 above, the missing data of the monitoring platform in the offline state is supplemented by the complete data bit reference of the monitoring platform in the online state, thereby effectively ensuring that the data received between the monitoring platforms are completely consistent.

[0132] Please see Figure 8 , Figure 8 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S710, obtains the on-screen duration of the liquid level sensor's display.

[0133] S720 controls the screen to turn off when the screen-on time reaches a set time threshold until the liquid level sensor receives a trigger signal to control the screen to turn on.

[0134] The two steps described above are described in detail below.

[0135] In the S710, the level sensor acquires and tracks the screen-on time of its own display in real time. The display is an integrated LCD module on the level sensor, used to show key maintenance information such as current sampling data, remaining battery power, network status, and transmission results. It is a core interactive component for on-site equipment debugging and data viewing. Screen-on time refers to the continuous duration of the display from when it is turned on from a screen-off state to the current moment. The level sensor uses a built-in timer module to perform high-precision timing of the screen-on time down to the second. Timing starts synchronously regardless of whether the display is turned on by power-on, button press, or alarm, ensuring complete and accurate time tracking.

[0136] In the S720, when the screen-on time recorded by the level sensor reaches a pre-configured threshold, the display is immediately automatically turned off. The backlight power is cut off, and the display driver is shut down. The display is only reactivated and lit again when the level sensor receives a trigger signal to control the screen's on time. The set threshold is the maximum screen-on time preset by the level sensor to balance on-site monitoring needs with low-power operation. It can be flexibly adjusted according to smart city and smart fire protection scenarios. For example, it can be set to 15 seconds for frequently maintained scenarios such as core area fire pools and municipal pipe networks, and 10 seconds for low-frequency inspection scenarios such as remote fire hydrants and underground sewage wells. The trigger signal specifically refers to the trigger signal output by the level sensor's local button module, i.e., the level signal generated when maintenance personnel press the local view button.

[0137] It should be noted that after the display screen is turned off, the core functions of the liquid level sensor, such as sampling, buffering, dual-platform transmission, network detection, and abnormal alarm, all operate normally. Only the power consumption of the display module is turned off, which does not affect any monitoring and transmission process.

[0138] Taking the smart fire hydrant monitoring scenario in urban roads as an example, when maintenance personnel press the view button on the on-site liquid level sensor, the display screen lights up and shows the water pressure, power, and network status, and the liquid level sensor starts timing simultaneously; when the screen-on time reaches the set threshold of 10 seconds, the liquid level sensor automatically controls the display screen to turn off; if maintenance personnel need to view the data again, they can press the button again to trigger the screen-on signal, and the display screen will immediately resume display.

[0139] As can be seen from S710-S720 above, the display automatically counts down after it is turned on, and automatically turns off the screen after the set time threshold is reached. The display only lights up again when it receives a trigger signal used to control the display to turn on, which reduces the overall power consumption of the liquid level sensor and further extends the service life of the liquid level sensor.

[0140] Please see Figure 9 , Figure 9 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S810 responds to real-time acquisition commands issued by the business monitoring platform to obtain the sampled data currently written to the buffer. Real-time acquisition commands are the highest priority commands.

[0141] The S820 packages the sampled data already written to the buffer and uploads it to the business monitoring platform.

[0142] The two steps described above are described in detail below.

[0143] In the S810, the level sensor responds to the real-time acquisition command actively issued by the business monitoring platform and immediately acquires all the sampled data that has been successfully written into the local circular buffer. The real-time acquisition command is an instant data acquisition command issued by the business monitoring platform to the level sensor by maintenance personnel during remote maintenance, equipment inspection, and data verification in smart city and smart fire protection scenarios. This real-time acquisition command is set as the highest priority control command, and its execution priority is higher than all processes such as the sensor's regular periodic sampling, periodic uploading, power level transmission, and offline data retransmission. Once the command is received, the level sensor immediately interrupts the non-urgent tasks it is currently executing and prioritizes the real-time acquisition-related operations.

[0144] The real-time acquisition command carries the device's unique identifier, command type, and issuance timestamp. The liquid level sensor verifies the device's unique identifier and responds immediately after confirming the command's ownership, thus avoiding false triggering.

[0145] Taking the scenario of remote maintenance of smart fire protection as an example, when maintenance personnel carry out centralized maintenance of urban fire water source facilities, they do not need to go to the site of fire pools and fire hydrants. They can directly click the real-time data acquisition button on the business monitoring platform to send a real-time acquisition command to the corresponding liquid level sensor. After receiving the command, the liquid level sensor will first pause the current regular upload process and quickly retrieve the latest sampling data in the buffer.

[0146] In the S820, the level sensor immediately packages the current sampling data acquired in the S810 and written to the buffer according to the communication protocol standard of the business monitoring platform, and uploads the packaged data packet to the business monitoring platform with priority. The data packaging process follows the conventional data packet format, including the device's unique identifier, data ID, sampling timestamp, level / pressure sampling value, and CRC checksum, ensuring the consistency of data parsing and verification on the platform side. The upload process also follows the highest priority execution, without waiting for a preset upload cycle or being restricted by the current power level strategy, ensuring that the data can be transmitted back to the business monitoring platform as quickly as possible.

[0147] Continuing with the aforementioned remote maintenance scenario, after receiving the real-time acquisition command and retrieving data from the buffer, the level sensor immediately packages and uploads the data. Maintenance personnel can instantly view the sensor's latest status information, such as level, pressure, and power, on the business monitoring platform without waiting for the next regular upload cycle.

[0148] As shown in S810-S820 above, the business monitoring platform can issue real-time acquisition commands, and the liquid level sensor will immediately package and upload the sampling data in the current buffer to the business monitoring platform. This allows maintenance personnel to obtain real-time data from the liquid level sensor at any time without waiting for the upload cycle, which greatly improves the efficiency of remote maintenance.

[0149] Please see Figure 10 , Figure 10 A flowchart of a data processing method according to another embodiment of this application is shown. The method further includes: S910 detects the sampling data obtained from the liquid level sensor based on a preset threshold range.

[0150] S920, when the sampled data is detected to be within the normal threshold range, controls the process of uploading the sampled data in the buffer to the monitoring platform based on the power of the liquid level sensor and the preset upload frequency.

[0151] S930: When it detects that the sampled data exceeds the normal threshold range, it will only package and upload the sampled data in the buffer to the monitoring platform based on the preset upload frequency.

[0152] The three steps described above are described in detail below.

[0153] In the S910, the liquid level sensor performs real-time safety monitoring of the liquid level and water pressure sampling data it obtains, based on a preset threshold range. The preset threshold range is a normal data interval pre-configured by the liquid level sensor for different monitoring scenarios in smart cities and smart fire protection, used to distinguish between normal stable states and abnormal alarm states. This range can be flexibly configured for different application scenarios: for example, the normal threshold range for fire water tank levels can be set to 2.0m–4.5m, the normal threshold range for municipal fire hydrant water pressure can be set to 0.3MPa–0.6MPa, and the normal threshold range for municipal sewage well levels can be set to 0.1m–1.0m. Each time the main control chip of the liquid level sensor acquires a new set of sampling data, it immediately compares the value with the preset threshold range to quickly determine whether the sampling data is within or outside the normal range, providing a core judgment basis for subsequent data upload and control.

[0154] In some embodiments of this application, the preset threshold range can be remotely modified and distributed through the business monitoring platform to adapt to dynamic monitoring needs such as seasonal changes and operating condition adjustments, without requiring maintenance personnel to go to the site to debug the equipment.

[0155] In S920, when the liquid level sensor detects that the sampled data is within the normal threshold range, it determines that the current monitored target is in a safe and stable normal state. Then, based on the remaining battery level of the liquid level sensor, it performs hierarchical control over the entire process of uploading the sampled data in the buffer to the monitoring platform at a preset upload frequency. The battery-level hierarchical control follows the transmission strategy described above for low, medium, and high battery levels: when the battery level is below a first preset value, data is only uploaded to the business monitoring platform; when the battery level is between the first and second preset values, multiple consecutive data packets are merged and uploaded to the dual monitoring platform; when the battery level is above the second preset value, single data packets are uploaded to the dual monitoring platform sequentially in real time. This control logic aims to reduce power consumption and extend battery life, minimizing sensor power consumption during routine monitoring without safety risks.

[0156] Taking routine fire water source monitoring in smart cities as an example, the water level in urban fire water tanks is kept stable at 3.2m, which is within the normal threshold range of 2.0m to 4.5m. After the water level sensor detects normal data, it performs tiered uploading based on the current remaining power: when the power is 18%, data is only transmitted to the business monitoring platform; when the power is 35%, data packets are merged and uploaded to both platforms; and when the power is 65%, data is transmitted in real time to both platforms. This ensures that routine data is reported normally while effectively reducing equipment power consumption.

[0157] In the S930, when the liquid level sensor detects that the sampled data exceeds the normal threshold range, it determines that an emergency anomaly has occurred, such as insufficient fire water pressure, excessive liquid level, pipe rupture, or water source depletion. It immediately skips all power level control strategies and only uploads the sampled data in the buffer to the fire monitoring platform and business monitoring platform according to the preset upload frequency. Exceeding the normal threshold range includes dangerous states such as excessively low liquid level, excessively high liquid level, low water pressure, and excessive water pressure, which are key triggering conditions for intelligent fire emergency early warning. Skipping the power level control strategy means disregarding the remaining power of the sensor, eliminating power optimization methods such as single-platform transmission when low power is low and data packet merging transmission when medium power is high, and always maintaining synchronous real-time transmission across both platforms to ensure that abnormal data can be reported to the government fire supervision platform and the enterprise operation and maintenance platform simultaneously as soon as possible.

[0158] Abnormal data uploads have a higher priority than all regular transmission processes. Data packets will be marked with obvious abnormal identifiers. Upon receiving the data, the platform will immediately trigger multi-level warnings, including audible and visual alarms, SMS push notifications, platform pop-ups, and APP notifications, to remind administrators to respond and handle the situation quickly.

[0159] Taking a smart fire emergency scenario as an example, a fire water tank in a commercial district experienced a rapid drop in water level to 1.1m due to a ruptured water supply pipe, which is below the normal threshold of 2.0m. After the water level sensor detected the abnormal data, it immediately skipped the power level control regardless of whether the remaining power was in the low, medium, or high range. The abnormal water level data was then transmitted in real time to both the fire monitoring platform and the business monitoring platform. The fire rescue department and the operation and maintenance unit received the alarm simultaneously and quickly carried out repairs and emergency response.

[0160] As can be seen from S910-S930 above, when the detected sampling data is within the normal threshold range, the power consumption level control of the liquid level sensor is followed to reduce power consumption and extend the service life of the liquid level sensor; when the detected sampling data exceeds the normal threshold range, the power consumption level control strategy is skipped and real-time dual transmission is maintained, thereby ensuring that emergencies such as abnormal fire water pressure and excessive liquid level can be reported in a timely manner, thus protecting the safety of people's lives and property.

[0161] This application also proposes a liquid level sensor. As a core terminal device for smart city-wide monitoring and smart fire-fighting water source supervision, this liquid level sensor integrates multiple functions such as sensing and data acquisition, human-computer interaction, data caching, wireless transmission, local control, and anomaly alarm. All hardware modules operate collaboratively, and it can be stably deployed in scenarios such as fire pools, municipal fire hydrants, underground sewage wells, rivers and reservoirs, and municipal water supply networks. It perfectly meets the core requirements of smart fire protection and smart cities for low power consumption, high reliability, multi-platform collaboration, and easy maintenance of liquid level / pressure monitoring equipment.

[0162] The liquid level sensor specifically includes a liquid level and pressure sensing module, a display screen, a local memory, a wireless communication module, a button module, an alarm module, and a control module. The hardware structure and functional implementation of each module are as follows: A liquid level and pressure sensor module, electrically connected to the control module, is used to collect liquid level and pressure sampling data according to a set acquisition cycle. A display screen, also electrically connected to the control module, is used to display the sampling data. A local memory, electrically connected to the control module, is used to store the sampling data and internally build a buffer. A wireless communication module, electrically connected to the control module, is used to communicate with multiple monitoring platforms. A button module, electrically connected to the control module, is used to output a trigger signal to control the display screen to light up. An alarm module, electrically connected to the control module, is used to issue an alarm signal. The control module, as the core control unit of the liquid level sensor, is electrically connected to the liquid level and pressure sensor module, display screen, local memory, wireless communication module, button module, and alarm module, and is used to execute the data processing method described in any one of the embodiments of this application.

[0163] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0164] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data processing method, characterized by, Applied to a liquid level sensor, the method includes: Acquire the sampling data obtained by the liquid level sensor through continuous sampling based on a preset sampling period, and write the sampling data into a buffer; The sampled data in the buffer is packaged and uploaded to the monitoring platform based on a preset upload frequency. The monitoring platform includes a fire monitoring platform and a business monitoring platform. During the process of packaging and uploading the sampled data to the monitoring platform, if the power of the liquid level sensor is detected to be below a first preset value, the system controls the packaging and uploading of the sampled data in the buffer to the business monitoring platform. When the power of the liquid level sensor is detected to be above the first preset value and below the second preset value, the system controls the merging and uploading of multiple consecutive data packets obtained in the package to the business monitoring platform and the fire monitoring platform to reduce the number of handshakes. The second preset value is greater than the first preset value. When the power level of the liquid level sensor is detected to be above the second preset value, the system controls the sequential uploading of each packaged data packet to the business monitoring platform and the fire monitoring platform.

2. The method of claim 1, wherein, The method further includes: The network status of the monitoring platform is detected according to a preset detection cycle, and the network status includes offline status and online status. If any of the monitoring platforms is detected to be offline for a preset number of consecutive times, a transmission error log will be generated, saved locally, and an alarm signal will be issued.

3. The method of claim 2, wherein, The method further includes: If all the monitoring platforms are online, the sampled data will be deleted from the buffer after it is successfully uploaded. If some or all of the monitoring platforms are offline, the sampling data will be deleted from the buffer after the offline monitoring platforms are restored to online status and the sampling data is successfully uploaded to the restored online monitoring platforms.

4. The method of claim 3, wherein, The method further includes: The retry upload success rate of the monitoring platform within the historical statistical period is statistically analyzed. If the retry upload success rate is lower than the preset success rate threshold, the data upload frequency of the monitoring platform will be reduced and the retry backoff time will be extended. If the retry upload success rate is higher than or equal to the preset success rate threshold, the data upload frequency of the monitoring platform is restored.

5. The method of claim 3, wherein, The method further includes: If only part of the monitoring platform is offline, the data packets to be supplemented for the offline monitoring platform are determined based on the first historical data packets received by the offline monitoring platform. When the monitoring platform, which was offline, returns to online status, the data packet to be supplemented is uploaded to the monitoring platform that has returned to online status.

6. The method of claim 3, wherein, The method further includes: If only part of the monitoring platform is offline, the first historical data packet received by the offline monitoring platform is compared with the second historical data packet received by the online monitoring platform, and the data packet to be supplemented for the offline monitoring platform is determined based on the comparison result. When the monitoring platform, which was offline, returns to online status, the data packet to be supplemented is uploaded to the monitoring platform that has returned to online status.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Obtain the on-screen duration of the display screen of the liquid level sensor; When the screen-on time of the display reaches a set time threshold, the display is turned off until the liquid level sensor receives a trigger signal to control the display to turn on.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: In response to the real-time collection command issued by the business monitoring platform, the sampled data currently written into the buffer is obtained, wherein the real-time collection command is the highest priority command; The sampled data already written into the buffer is packaged and uploaded to the business monitoring platform.

9. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The sampling data obtained by the liquid level sensor is detected based on a preset threshold range; When the sampled data is detected to be within the normal threshold range, the process of uploading the sampled data in the buffer to the monitoring platform based on the preset upload frequency is controlled based on the power of the liquid level sensor. When the sampled data is detected to exceed the normal threshold range, the sampled data in the buffer is packaged and uploaded to the monitoring platform based solely on the preset upload frequency.

10. A liquid level sensor, characterized in that, include: The liquid level and pressure sensing module is used to collect sampling data of liquid level and pressure according to a set acquisition cycle; A display screen is used to display the sampling data; Local memory is used to store the sampled data, forming a buffer; The wireless communication module is used to communicate with multiple monitoring platforms; A button module is used to control the display screen to light up; The alarm module is used to send alarm signals; A control module for performing the method as described in any one of claims 1 to 9.

Images