A remote water valve controller management method and system

Abstract

The application discloses a remote water valve controller management method and system, the method comprises the following steps: determining a main and standby Bluetooth management hub and a connected water valve controller based on the Bluetooth signal strength; then analyzing the device message, extracting the communication hop count and the sensor reading for K-means clustering, and dividing the area water feature group; after receiving the user opening instruction, the adjacent devices in the same feature group are screened for horizontal cross comparison of sensor data to test the device reliability and issue the control instruction; when the cloud network is disconnected, the message is routed to the standby hub for verification and execution through the connected water valve controller. The method improves the accuracy of multi-data collaborative research and judgment and the edge offline disaster recovery relay capability of the water valve controller management system.

Description

Technical Field

[0001] This invention relates to the field of automatic water valve control, and in particular to a remote water valve controller management method and system. Background Technology

[0002] With the widespread adoption of IoT technology in smart water management, remote valve-controlled water meters are being used extensively in various scenarios. Existing systems typically employ communication modes where terminals directly connect to the cloud or rely on a single local gateway. However, because water valves are often installed in enclosed environments with severe signal obstruction, such as pipe wells, this single link is highly susceptible to regional device outages due to local network fluctuations or gateway failures. The existing network architecture lacks dynamic networking disaster recovery and multi-level routing and relay capabilities, posing a serious "single point of failure" risk and making it difficult to guarantee communication reliability in complex environments.

[0003] The core functions of existing control systems (such as water bill calculation, access control, and command issuance) heavily rely on cloud computing power. If a base station experiences a network outage or platform malfunction, the devices lose control, disrupting normal water usage for users. Furthermore, in the face of emergencies such as external power outages, traditional dual-power water valves often only perform simple mechanical shut-off actions, lacking low-power survival strategies and dynamic abnormal node removal mechanisms that deeply integrate with edge computing and communication networks. The system as a whole lacks edge autonomy capabilities in offline and low-voltage environments, resulting in high maintenance and troubleshooting costs. Summary of the Invention

[0004] This invention provides a remote water valve controller management method and system. By constructing a primary and backup central self-organizing network and a relay mechanism for connecting nodes, it effectively solves the potential for single-point communication failures in complex environments and significantly improves the system's disaster recovery and offline autonomous capabilities.

[0005] To achieve the above objectives, a first aspect of this application provides a remote water valve controller management method, comprising: Identify all water valve controllers within the Bluetooth communication range of each Bluetooth management hub; if a water valve controller is within the Bluetooth communication range of several Bluetooth management hubs, designate the Bluetooth management hub with the highest Bluetooth signal strength as the primary Bluetooth management hub, and the other Bluetooth management hubs as backup Bluetooth management hubs, with the water valve controller serving as the interconnected water valve controller; when arranging each Bluetooth management hub, ensure that at least one interconnected water valve controller is included within the Bluetooth communication range; Each Bluetooth management hub periodically uploads the usage data of each user and the operating data of each water valve controller to the cloud, and downloads the water fee calculation model from the cloud. Each water valve controller sends a device water control protocol message to the Bluetooth management center via a Bluetooth channel; the data content segment of the device water control protocol message includes the Bluetooth communication hop count and the readings of all sensors; each Bluetooth management center generates a protocol message vector based on the device water control protocol message and performs K-means clustering on all protocol message vectors, and generates a device communication list based on the clustering results, with each cluster center corresponding to a type of regional water use characteristic group; After receiving the user's opening command, the water valve controller generates a user water control protocol message according to the opening command and sends the user water control protocol message to the Bluetooth management center; the data content segment of the user water control protocol message includes the user ID and available water flow; the device water control protocol message and the user water control protocol message are encapsulated and parsed using the same basic data frame format; After receiving the user's water control protocol message, the Bluetooth management center filters water valve controllers in the device communication list that have a Bluetooth communication hop count less than a preset hop count threshold and belong to the same area water use characteristic group. Based on the filtering results, it reads all the device water control protocol messages to verify the device reliability of the water valve controller. After the equipment reliability test is passed, the Bluetooth management center generates control commands based on the water fee calculation model, and the water valve controller drives the water valve to perform corresponding opening and closing actions according to the control commands. When the main Bluetooth management center detects a disconnection from the cloud, it routes and relays the received user water control protocol message to the adjacent backup Bluetooth management center through the connecting water valve controller. The backup Bluetooth management center then performs the water fee calculation model verification and control command issuance on its behalf.

[0006] In one possible implementation of the first aspect, the same basic data frame format includes: Start bit: Occupies 1 byte, is fixedly configured as the mapping code of the main Bluetooth management hub, and is used for frame synchronization and preliminary legality verification of the communication receiving end; Data length bit: occupies 1 byte and is used to dynamically identify the total number of bytes in the subsequent data content segment; Data content segment: occupies n bytes, where n is a positive integer, and is used to carry specific communication hop count, sensor readings, user ID, or available water flow information; Check bit: Occupies 1 byte, located at the end of the data frame, and is used to perform integrity algorithm verification on the data content segment.

[0007] In one possible implementation of the first aspect, the verification of the device reliability of the water valve controller specifically includes: Extract the sensor readings of the water valve controller that is currently sending the user water control protocol message; The sensor readings are compared laterally with the sensor readings of other water valve controllers within the same area water usage characteristic group that have been selected. If the difference in the sensor readings is within a preset safety threshold range, the water valve controller is deemed to have passed the equipment reliability test; otherwise, the generation and issuance of the control command are blocked.

[0008] In one possible implementation of the first aspect, the process for determining the security threshold range is as follows: Obtain the first Bluetooth communication hop count of the current water valve controller and the second Bluetooth communication hop count of the other water valve controllers; Calculate the absolute difference between the first Bluetooth communication hop count and the second Bluetooth communication hop count, and use it as the network topology distance parameter; Extract the cluster standard deviation and cluster center value of the regional water use characteristic group to which the current water valve controller belongs; A basic threshold is set based on the cluster standard deviation, and the network topology distance parameter is multiplied by the cluster center value and the preset pipe loss attenuation coefficient to obtain the hop count compensation threshold. The base threshold is added to the hop count compensation threshold to generate the final dynamic safety threshold, and the preset safety threshold range is defined based on the dynamic safety threshold.

[0009] In one possible implementation of the first aspect, the readings of all sensors include instantaneous flow data collected by the pulse flow meter, mechanical opening data of the motor actuator fed back by the position sensor, and a fault alarm flag bit; the writing process of the fault alarm flag bit is as follows: if the mechanical opening data of the water valve controller is in the open state, and the instantaneous flow data is continuously zero for a preset time, it is determined that a water source interruption or mechanical jamming abnormality has occurred, and the value of the fault alarm flag bit in the data content segment of the equipment water control protocol message is set to 1.

[0010] In one possible implementation of the first aspect, the process of generating and clustering the protocol message vector specifically includes: The average water consumption, instantaneous flow fluctuation rate, and environmental water pressure attenuation gradient of the water valve controller within a set historical time period are extracted as basic feature dimensions. After normalizing the values ​​of different feature dimensions, a multi-dimensional state feature vector is constructed as the protocol message vector. The K-means clustering algorithm is used to iteratively cluster the multidimensional state feature vectors of each water valve controller.

[0011] In one possible implementation of the first aspect, the routing relay step when the main Bluetooth management hub detects a disconnection from the cloud specifically includes: When the water valve controller fails to receive a heartbeat confirmation packet from the main Bluetooth management center for several consecutive cycles, it determines that the main control link is disconnected and activates the offline relay mode. The connected water valve controller parses its locally stored backup routing table and selects the Bluetooth management hub with the best signal from multiple backup Bluetooth management hubs to establish a connection based on the real-time scanned Bluetooth signal reception strength indication value. The Bluetooth management hub with the best signal takes over the device communication list of the currently disconnected area, uses the latest water fee calculation model cached locally to verify the user water control protocol message transmitted by the relay, and transmits the control command back to the target water valve controller through the connected water valve controller.

[0012] In one possible implementation of the first aspect, the steps of generating control commands and driving the water valve in the water fee calculation model specifically include: The Bluetooth management hub calculates the preset opening duration or the maximum allowed total number of flow pulses based on the available water flow in the user water control protocol message and the rate parameters in the water fee calculation model. The preset opening duration or the maximum allowed total number of flow pulses is encapsulated in a control command and sent to the corresponding water valve controller. When the water valve controller is in the open state, it monitors and accumulates the number of pulses passing through the pulse flow meter in real time. When the accumulated number of pulses reaches the maximum allowable total number of flow pulses or the time reaches the preset opening duration, the underlying microcontroller actively triggers the emergency interrupt program, drives the motor valve to perform mechanical valve closing action, and generates an actual consumption flow message, stores it in the local memory, and waits for the network to be restored before packaging and uploading.

[0013] In one possible implementation of the first aspect, the water valve controller is equipped with a main external DC power supply module and a built-in backup battery power supply module; When the water valve controller detects that the main external DC power supply module has lost power and switches to the built-in backup battery power supply module, it triggers a low-power survival strategy. Under the low-power survival strategy, the water valve controller refuses to respond to any opening commands other than the emergency valve closing command, reduces the broadcast frequency of sending the device water control protocol messages, and sets a low-power operation flag in the data content segment of the message. When performing device reliability checks, the Bluetooth management hub identifies water valve controllers with low battery operation flags, marks their status as unreliable, and dynamically removes them from the list of valid cross-validation reference nodes of the regional water use characteristic group.

[0014] A second aspect of this application provides a remote water valve controller management system, including a cloud, several Bluetooth management hubs, and several water valve controllers; The cloud is used to store and distribute water fee calculation models, and to receive user usage data and operating data of each water valve controller uploaded by the Bluetooth management center. The Bluetooth management hub includes a first processor, a first memory, and a communication module; the first memory pre-stores a computer program, which, when executed by the first processor, performs the following functions: The communication module determines the water valve controller within the Bluetooth communication range, and the main Bluetooth management center and backup Bluetooth management center are determined based on the Bluetooth signal strength. The device receives the water control protocol message sent by the water valve controller, extracts the Bluetooth communication hop count and sensor readings to generate the protocol message vector, and uses the K-means clustering algorithm to divide the regional water use feature groups to generate the device communication list. After receiving the user's water control protocol message, the device filters the reference nodes of the same area water use characteristic group in the device communication list and performs device reliability verification. After verification, control commands are generated and issued based on the water fee calculation model. The water valve controller includes a second processor, a second memory, a sensor acquisition module, a motor actuator, and a Bluetooth communication module; The sensor acquisition module is used to acquire sensor readings including flow rate and actuator status; The Bluetooth communication module is used, under the control of the second processor, to send device water control protocol messages or user water control protocol messages encapsulated in a basic data frame format, and to receive the control commands. The motor actuator is used to drive the water valve to perform opening and closing actions according to the control command; The node in the water valve controller marked as the connected water valve controller is configured to act as a routing relay node to route the user water control protocol message to the adjacent backup Bluetooth management center when the main Bluetooth management center loses connection with the cloud, so that the backup Bluetooth management center can perform the verification and command issuance on its behalf.

[0015] Compared to existing technologies, this invention constructs a self-organizing network comprising a primary and backup Bluetooth management hub and a water valve controller. The primary control hub collects device messages sent by the underlying water valve controllers, extracts sensor readings and communication hop counts to construct a multi-dimensional feature vector, and uses a K-means clustering algorithm to divide the regional water usage feature groups. Upon receiving a user activation command, the hub selects adjacent nodes within the same feature group for lateral cross-verification, determines device reliability based on a dynamic safety threshold generated from the network topology hop count, and issues control commands after passing the verification. When the primary control hub loses connection with the cloud, it automatically activates an offline relay mode, routing and transparently transmitting messages to the backup hub via the water valve controller to perform model verification and command issuance. This invention effectively eliminates the risk of single-point communication failures in complex network environments, upgrades isolated monitoring to feature group collaborative analysis, significantly reduces the false alarm rate caused by fluctuations in physical operating conditions, and significantly improves the system's disaster recovery and edge autonomy capabilities. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a remote water valve controller management method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a remote water valve controller management system provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] To resolve the above issues, please refer to [link / reference]. Figure 1 An embodiment of the present invention provides a remote water valve controller management method, comprising: S10. Determine all water valve controllers within the Bluetooth communication range of each Bluetooth management hub; if a water valve controller is within the Bluetooth communication range of several Bluetooth management hubs, designate the Bluetooth management hub with the highest Bluetooth signal strength as the primary Bluetooth management hub, and the other Bluetooth management hubs as backup Bluetooth management hubs, with the water valve controller serving as the interconnected water valve controller; when arranging each Bluetooth management hub, ensure that at least one interconnected water valve controller is included within the Bluetooth communication range; S11. Each Bluetooth management hub periodically uploads the usage data of each user and the operating data of each water valve controller to the cloud, and downloads the water fee calculation model from the cloud.

[0019] S12. Each water valve controller sends a device water control protocol message to the Bluetooth management center via a Bluetooth channel; the data content segment of the device water control protocol message includes the Bluetooth communication hop count and the readings of all sensors; each Bluetooth management center generates a protocol message vector based on the device water control protocol message and performs K-means clustering on all protocol message vectors, and generates a device communication list based on the clustering results, with each cluster center corresponding to a type of regional water use characteristic group.

[0020] S13. After receiving the user's opening command, the water valve controller generates a user water control protocol message according to the opening command and sends the user water control protocol message to the Bluetooth management center; the data content segment of the user water control protocol message includes the user ID and available water flow; the device water control protocol message and the user water control protocol message are encapsulated and parsed using the same basic data frame format; S14. After receiving the user's water control protocol message, the Bluetooth management center filters water valve controllers in the device communication list whose Bluetooth communication hop count is less than a preset hop count threshold and belong to the same area water use characteristic group. Based on the filtering results, it reads all the device water control protocol messages to verify the device reliability of the water valve controller.

[0021] S15. After passing the equipment reliability test, the Bluetooth management center generates control commands based on the water fee calculation model, and the water valve controller drives the water valve to perform corresponding opening and closing actions according to the control commands. When the main Bluetooth management center detects a disconnection from the cloud, it routes and relays the received user water control protocol message to the adjacent backup Bluetooth management center through the connecting water valve controller. The backup Bluetooth management center then performs the water fee calculation model verification and control command issuance on its behalf.

[0022] The implementation principle of S10-S11 lies in dynamically constructing a self-organizing mesh topology based on the strength of wireless radio frequency signals. It uses Bluetooth communication spatial overlap to filter out "connecting water valve controllers" with bidirectional communication capabilities as physical relay anchors. Simultaneously, the cloud-based "water fee calculation model" (i.e., billing rules and business logic) is pre-buried and cached in the primary and backup management hubs. Through these steps, the fragile architecture of traditional star networks, which heavily rely on a single central gateway, is broken. This not only significantly alleviates the concurrent communication pressure on cloud servers by front-loading edge computing power, but also makes the system more likely to achieve offline autonomy in extreme network outage environments, reserving a robust physical redundancy channel for route takeover.

[0023] S12 employs the K-means clustering algorithm from unsupervised machine learning. It integrates parameters representing network topological distance (i.e., Bluetooth hop count H, representing the number of routing and forwarding steps a data packet takes from the terminal to the central hub) with multi-source parameters representing the physical conditions of the pipeline network (i.e., sensor reading matrix S, such as instantaneous flow rate and water pressure) to construct a high-dimensional feature vector V=[H,S1,S2,…]. Through iterative optimization, devices with similar distances in the multi-dimensional feature space are grouped into the same cluster center. This allows the management system to use AI algorithms to logically reconstruct the hydraulic connectivity diagram of the physical pipeline network, integrating previously isolated terminal devices into "regional water use characteristic groups" with similar water usage habits and shared water pressure fluctuations, providing a group data foundation for subsequent accurate troubleshooting.

[0024] The core principles of S13-S14 are "service / equipment protocol reuse" and "group collaborative self-verification." After receiving a user's valve opening service request, the central control first limits the spatial distance (extracting nodes with Bluetooth communication hop counts less than a preset hop count threshold, which defines the allowable reference radius for physical distance), and then only performs horizontal comparison of sensor data among neighboring nodes belonging to the same "regional water use characteristic group." This utilizes group data with similar physical locations and operating conditions to combat the unreliability of individual hardware and effectively avoids misjudgments. For example, when the instantaneous flow reading of a requesting node drops abnormally, if all neighboring nodes in the same cluster show the same attenuation trend, the system can determine that it is a sudden drop in the overall water pressure of the pipeline network rather than a leak or blockage in a local device, thereby greatly improving the anti-interference capability and accuracy of equipment status verification.

[0025] The S15 integrates edge automation control with a multi-hop self-organizing network emergency routing mechanism. Under normal conditions, the central hub directly calls the locally cached model to complete the closed-loop command issuance. However, when the backbone uplink network (cloud) fails, the system triggers an abnormal takeover routing. User packets from the disconnected area are relayed horizontally through the "Connecting Water Valve Controller" as a physical springboard to the "Backup Bluetooth Management Hub" in the adjacent healthy network to perform authentication calculations. This eliminates the fatal flaw of "single point of failure" in traditional IoT architectures, ensuring that even in adverse conditions such as partial base station downtime or main control gateway power failure, the system can still rely on offline adjacent network mesh interconnection to complete billing and valve opening services, greatly guaranteeing the business continuity and resilience of water management.

[0026] It should be noted that the aforementioned 'Bluetooth communication hop count' refers to the total number of radio frequency link segments traversed by a device's water control protocol message from the source water valve controller, after passing through several Bluetooth routing relays, before finally reaching the target Bluetooth management hub in a Bluetooth ad hoc network topology. This parameter not only characterizes the network communication distance in this system but also serves as a fundamental parameter for mapping the physical distance within the pipeline network. For a water valve controller A, the Bluetooth communication hop count between it and the nearest water valve controller B is 1. If the Bluetooth communication hop count between water valve controller B and the nearest water valve controller C is 1, then the Bluetooth communication hop count between water valve controller A and water valve controller C is 2.

[0027] In summary, compared to existing technologies, the aforementioned remote water valve management method essentially represents an architectural leap from "single-machine passive control" to "edge swarm intelligence." The system lays the groundwork through a physical-layer disaster recovery topology (S10, S11), utilizes AI clustering algorithms (S12) to divide the physical pipe network into clusters, and then employs swarm cross-validation (S13, S14) to filter abnormal fluctuations when services are triggered. Finally, it combines this with an offline rerouting mechanism (S15) to form a highly reliable service closed loop. This series of interconnected steps solves the three major technical challenges commonly faced by IoT terminals in complex underground pipe network environments: communication silos, false alarms, and single-point network outages.

[0028] For example, the same basic data frame format includes: Start bit: Occupies 1 byte, is fixedly configured as the mapping code of the main Bluetooth management hub, and is used for frame synchronization and preliminary legality verification of the communication receiving end.

[0029] Data length bit: occupies 1 byte and is used to dynamically identify the total number of bytes in the subsequent data content segment.

[0030] Data content segment: Occupies n bytes, where n is a positive integer, and is used to carry specific communication hop count, sensor readings, user ID, or available water flow information.

[0031] Check bit: Occupies 1 byte, located at the end of the data frame, and is used to perform integrity algorithm verification on the data content segment.

[0032] The introduction of the start bit means that in complex radio electromagnetic environments (such as dense pipe shafts), the receiver (MCU's serial port or Bluetooth buffer pool) will continuously receive various radio frequency noises. This section uses a fixed-configuration "master Bluetooth management hub mapping code" (e.g., a specific hash value of the master hub MAC address, set as a constant Code). master The receiving end uses a sliding window in the byte stream as a start marker. Only when a matching code is captured... masterOnly when the system is in a certain state will a wake-up interrupt be triggered, and the system will enter the receiving state. This achieves "precise frame synchronization" and "spatial anti-crosstalk". On the one hand, it avoids false triggering of the system caused by garbled characters or environmental noise, reducing the unnecessary power consumption of the underlying hardware; on the other hand, it effectively isolates adjacent Bluetooth self-organizing networks that do not belong to the same management area, preventing unauthorized command intrusion across network areas.

[0033] The introduction of the data length bit defines the precise boundary of the subsequent "data content segment," with a value set to L (theoretically 1 ≤ L ≤ 255 since it occupies 1 byte). After the receiving MCU parses this bit, it starts a precise counter of length L, and immediately closes the receiving window after capturing the specified number of bytes, no longer waiting blindly. This achieves "dynamic elastic scaling" of communication messages. The system eliminates the bandwidth waste caused by traditional fixed-length messages (e.g., padding empty bytes when sending only a valve opening command). This allows the network to adapt to both short packets (e.g., second-level heartbeat detection) and long packets (e.g., uploading monthly historical traffic sequences), greatly optimizing channel occupancy and reducing total RF transmission power consumption.

[0034] The data content segment is an abstract, highly scalable payload container with a length of n bytes (n=L). Depending on the application scenario, different protocol dictionaries can be nested within it. For example, when the message type is "Device Water Control Protocol," the first two bytes are allocated to the Bluetooth hop count H, and the subsequent bytes are allocated to the sensor reading matrix S; when it is "User Water Control Protocol," it is mapped to the user ID (UID) and authorized water volume Vauth. This achieves both "unified underlying protocol" and "lightweight microcontroller." Whether it's complex network topology parameters, environmental sensor data, or billing instructions from the business layer, everything is transmitted transparently within the same underlying pipeline. This allows the MCU at the water valve end to maintain only one set of parsing code (simplified instruction set), significantly saving on Flash and RAM storage overhead.

[0035] At the sending end, the CPU uses a specific hash checksum algorithm (such as XOR or CRC8) to perform mathematical operations on the data content segment, resulting in a 1-byte checksum. Tx The checksum is placed at the end of the frame. After receiving n bytes of data, the receiving end recalculates the local checksum using a homomorphic algorithm. Rx If Checksum Tx =Checksum RxIf the data is found to be valid, it is deemed legitimate. This constitutes a "data anti-tampering and anti-distortion defense line" in extremely weak network environments. Signal fading in underground pipe networks can easily cause individual bits to flip (e.g., a digit 0 becomes a 1). The checksum mechanism ensures that the system can accurately identify and discard contaminated and incomplete data frames, thereby avoiding catastrophic consequences such as "water volume garbled billing errors" or "mechanical damage caused by incorrect motor drive."

[0036] For example, the equipment reliability test for the water valve controller specifically includes: Extract the sensor readings of the water valve controller that is currently sending the user water control protocol message.

[0037] The sensor readings are compared laterally with the sensor readings of other water valve controllers within the same selected water usage characteristic group in the same area.

[0038] If the difference in the sensor readings is within a preset safety threshold range, the water valve controller is deemed to have passed the equipment reliability test; otherwise, the generation and issuance of the control command are blocked.

[0039] The system extracts the sensor readings of the water valve controller that is currently requesting action (set as the parameter to be verified). Si Instead of comparing it with static values, the sensor readings of other neighboring water valves within the same "regional water use characteristic group" are extracted (set as environmental baseline reference parameters). Sref The system performs lateral deviation calculation. The system calculates the difference Δ between the two values ​​in real time. S =∣ Si Sref | and assess whether the difference falls within a preset safety threshold. Within this range, its technical effectiveness lies in using group data with similar physical hydraulic conditions as a "dynamic reference," effectively eliminating false anomalies caused by normal environmental fluctuations such as sudden drops in global water pressure and regional water usage peaks. If a sensor in a device experiences hardware damage or metering drift, its individual reading will inevitably deviate significantly from the group's safety envelope. In this case, the system will forcibly intercept the issued control commands, thereby avoiding accidental valve opening (causing flooding) or accidental closing (causing water outages) due to sensor malfunction. This greatly reduces the malfunction rate of equipment under complex operating conditions, ensuring the safety of the physical pipeline network and user property.

[0040] For example, the process of determining the security threshold range is as follows: Obtain the first Bluetooth communication hop count of the current water valve controller and the second Bluetooth communication hop count of the other water valve controllers; The absolute difference between the first Bluetooth communication hop count and the second Bluetooth communication hop count is calculated and used as the network topology distance parameter.

[0041] Extract the cluster standard deviation and cluster center value of the regional water use characteristic group to which the current water valve controller belongs.

[0042] A basic threshold is set based on the cluster standard deviation, and the network topology distance parameter is multiplied by the cluster center value and the preset pipe loss attenuation coefficient to obtain the hop count compensation threshold.

[0043] The base threshold is added to the hop count compensation threshold to generate the final dynamic safety threshold, and the preset safety threshold range is defined based on the dynamic safety threshold.

[0044] Assume a user water valve currently requesting opening has a sensor reading of Si and a Bluetooth hop count of Hi. Adjacent water valves in the same cluster have sensor readings of Sj and Bluetooth hop counts of Hj. Cluster baseline parameters: The cluster center value of this "regional water use characteristic group" generated by K-means clustering is Scenter, and the standard deviation of historical data within this cluster is σcluster. Available water flow: The user's pre-authorized water volume Vauth carried in the message.

[0045] Therefore, the formula for calculating the dynamic safety threshold Tsafe can be set as follows: Tsafe=(α σcluster)+(β |Hi Hj∣ Scenter)+γ f(Vauth) Among them, the basic tolerance α σcluster: Utilizing the inherent statistical characteristics (standard deviation) of K-means clustering, with α as the basic tolerance coefficient. This ensures that the threshold conforms to the daily fluctuation patterns of the pipeline network in this area. Topology hop count compensation β |Hi Hj∣ Scenter. |Hi Hj| represents the topological distance between the two water valves in the network. β is the preset single-hop pipe loss attenuation coefficient. The larger the difference in the number of hops, the greater the physical distance, and the larger the compensation value for this factor, thus resulting in a wider range of generated thresholds and effectively preventing network pressure drop caused by physical distance from being misjudged as equipment failure. Flow dynamic weight γ f(Vauth): If the available water flow requested by the user this time is very large (such as enterprise-level water release), the system predicts that the pipeline pressure will fluctuate greatly, so the threshold is further relaxed appropriately through weight γ.

[0046] In a specific application scenario, assume the instantaneous flow cluster center value of a certain regional pipeline network is 100 L / min, and the standard deviation is 5 L / min. A user requests to enable node A (communication hop count H_A=1), and the system selects node B (communication hop count H_B=4) from the same cluster for horizontal comparison. At this point, the hop count difference between the two is ΔH=|1-4|=3 hops. Since 3 hops represent a relatively long physical pipeline and multiple bends between the devices, there is natural pipe loss.

[0047] If a fixed threshold is used (e.g., an absolute difference of 10 L / min), normal water pressure attenuation due to physical distance can easily trigger false alarms. However, using the dynamic model of this invention, the system automatically adds jump compensation (e.g., for every jump difference, the allowable error increases by 2% of the center value). At this time, the dynamic safety threshold will automatically widen to: basic deviation + (3 × 2% × 100) = a 6 L / min increase in the error range.

[0048] For example, the readings of all the sensors include instantaneous flow data collected by the pulse flow meter, mechanical opening data of the motor actuator fed back by the position sensor, and fault alarm flag bit; the writing process of the fault alarm flag bit is as follows: if the mechanical opening data of the water valve controller is in the open state, and the instantaneous flow data is continuously zero for a preset time, it is determined that a water source interruption or mechanical jamming abnormality has occurred, and the value of the fault alarm flag bit in the data content segment of the equipment water control protocol message is set to 1.

[0049] For example, the generation and clustering process of the protocol message vector specifically includes: The average water consumption, instantaneous flow fluctuation rate, and environmental water pressure attenuation gradient of the water valve controller within a set historical time period are extracted as basic feature dimensions.

[0050] After normalizing the values ​​of different feature dimensions, a multi-dimensional state feature vector is constructed as the protocol message vector.

[0051] The K-means clustering algorithm is used to iteratively cluster the multidimensional state feature vectors of each water valve controller.

[0052] Traditional control logic is typically "open-loop" (the valve is assumed to be open after the MCU issues a drive command). This solution, however, implements a closed-loop mechanism at the edge (local water valve) using dual heterogeneous data cross-validation (physical action + fluid state). The system defines three core variables: mechanical opening state (set as...). 1 for on, 0 for off), instantaneous flow rate (set to...) ), and the decision time window (set to (This is used to eliminate the physical lag time of water flow arrival).

[0053] When the MCU detects feedback from the position sensor (This proves the motor is indeed rotating), and the system starts the timer; if in During the window period, the flow meter feedback The value remains 0, which violates basic physical fluid laws. At this point, the underlying microcontroller does not need to wait for computing power support from the cloud or central hub, but directly triggers a hardware-level interrupt locally, setting the "fault alarm flag" in the message to 1.

[0054] Ultra-fast local device protection (anti-dry burning / anti-overload): The anomaly detection logic is embedded in the device's underlying layer, enabling the system to respond in milliseconds to seconds when encountering situations such as no water in the upstream pipeline (water source interruption) or motor stalling due to foreign objects. This not only prevents the water pump from dry burning or the motor coil from burning out due to continuous high current, but also prevents metering errors caused by the water valve being partially stuck.

[0055] Traditional "single point of failure" faults often only report "loss of connection" or "abnormality," making it impossible for maintenance personnel to pinpoint the problem. This mechanism, by integrating mechanical opening and flow data, accurately identifies the fault type, significantly reducing the maintenance costs associated with manual downhole troubleshooting. Moreover, it only requires setting a single bit or byte to 1 in the existing data packet to transmit a high-priority critical alarm to the upper-level gateway, without increasing the load on conventional communication.

[0056] For example, the routing relay step when the main Bluetooth management hub detects a disconnection from the cloud specifically includes: When the water valve controller fails to receive a heartbeat confirmation packet from the main Bluetooth management center for several consecutive cycles, it determines that the main control link is disconnected and activates the offline relay mode.

[0057] The water valve controller parses its locally stored backup routing table and selects the Bluetooth management hub with the best signal from among multiple backup Bluetooth management hubs to establish a connection based on the real-time scanned Bluetooth signal reception strength indication value.

[0058] The Bluetooth management hub with the best signal takes over the device communication list of the currently disconnected area, uses the latest water fee calculation model cached locally to verify the user water control protocol message transmitted by the relay, and transmits the control command back to the target water valve controller through the connected water valve controller.

[0059] The Unicom water valve controller is not merely a passively receiving terminal, but also an edge node with network sniffing capabilities. It autonomously determines the health of the uplink by monitoring the heartbeat frequency between itself and the main hub. Upon detecting a disconnection, the system doesn't rigidly switch to a fixed backup node, but instead triggers a real-time scan of Bluetooth broadcast packets in the environment. Using the Received Signal Strength Indicator (RSSI) physical layer parameter, it dynamically assesses the current electromagnetic environment, selects the backup hub with the best link quality, and reconstructs the communication topology. Upon receiving a relay request, the backup hub, utilizing the previously cached "device communication list" and "water fee calculation model" (during normal network connectivity), directly takes over the management of the original main hub in its local memory. The Unicom water valve then acts as a "reverse proxy router," transparently transmitting the control commands generated by the backup hub back to the target water valve. Even if the main network base station of the entire community experiences a power outage or the cloud server crashes, the underlying water valve can still complete cross-validation and prepaid deduction logic within the "local area network." For end users, they can still use water normally by scanning codes or opening valves via Bluetooth, truly achieving "uninterrupted service even when the network is down." By having the "connection water valve" located in the signal convergence area take on the task of routing and relaying, there is no need to deploy expensive industrial-grade repeaters on-site, which greatly reduces the hardware deployment and maintenance costs of large-scale IoT coverage.

[0060] For example, the steps of generating control commands and driving the water valve in the water fee calculation model specifically include: The Bluetooth management hub calculates the preset opening duration or the maximum allowed total number of flow pulses for this valve opening based on the available water flow in the user water control protocol message and the rate parameters in the water fee calculation model.

[0061] The preset opening duration or the maximum allowed total number of flow pulses is encapsulated in a control command and sent to the corresponding water valve controller.

[0062] When the water valve controller is in the open state, it monitors and accumulates the number of pulses passing through the pulse flow meter in real time. When the accumulated number of pulses reaches the maximum allowable total number of flow pulses or the time reaches the preset opening duration, the underlying microcontroller actively triggers the emergency interrupt program, drives the motor valve to perform mechanical valve closing action, and generates an actual consumption flow message, stores it in the local memory, and waits for the network to be restored before packaging and uploading.

[0063] Traditional billing models typically involve water meters running continuously, with billing occurring periodically in the cloud. This solution employs the "edge prepaid" principle. The Bluetooth management hub (edge ​​gateway) acts as the billing engine, accurately converting the user's abstract "money (available water flow / balance)" into physical parameters that the underlying microcontroller (MCU) can directly obtain and access: "maximum number of pulses" or "maximum number of seconds."

[0064] After the control command is issued, the water valve MCU does not use inefficient "software polling (checking every few seconds to see if it has arrived)," but instead writes the received "target pulse count" into an internal high-speed hardware counter. As the water flows and the impeller rotates, the counter automatically decrements by 1 for each pulse generated by the Hall sensor. The instant the counter reaches zero, it triggers the MCU's highest-level hardware interrupt, directly outputting a level to drive the motor to close the valve without any code-level waiting. After the valve closes, the system generates a transaction message containing the consumption amount, but does not require immediate network upload. Instead, it uses "asynchronous storage" to write the message to local non-volatile memory (such as EEPROM or Flash), waiting for the network to become idle or recover before packaging and "delivering" the data.

[0065] If the decision to shut off a valve is made based on the cloud or a central control system, water can continue flowing for a few seconds during network congestion, potentially leading to negative overdrafts in user accounts. This solution delegates the authority for "quantitative shut-off" to the MCU at the very end of the valve, achieving microsecond-level precision in valve closure, ensuring no leaks and protecting the water company's revenue. The central control system only needs to issue a single command (e.g., open the valve, limit to 5000 pulses). The valve does not need to communicate with the outside world during execution, and the MCU can even enter a shallow sleep state during counting (only the pulse counter remains active), significantly reducing battery power consumption. Combined with the aforementioned network outage rerouting mechanism and the "local water flow caching" in this step, the system achieves true "offline prepayment." Even if a user purchases water by card or Bluetooth in a completely offline environment, the device can still accurately supply water and record transactions, ensuring "zero data loss" even under extreme conditions.

[0066] For example, the water valve controller is equipped with a main external DC power supply module and a built-in backup battery power supply module.

[0067] When the water valve controller detects that the main external DC power supply module has lost power and switches to the built-in backup battery power supply module, it triggers a low-power survival strategy.

[0068] Under the low-power survival strategy, the water valve controller refuses to respond to any opening commands other than the emergency valve closing command, reduces the broadcast frequency of the device water control protocol messages, and sets a low-power operation flag in the data content segment of the message.

[0069] When performing device reliability checks, the Bluetooth management hub identifies water valve controllers with low battery operation flags, marks their status as unreliable, and dynamically removes them from the list of valid cross-validation reference nodes of the regional water use characteristic group.

[0070] When the hardware detects a disconnection in the main DC power supply, the system seamlessly switches to the backup battery and immediately triggers a state machine reversal at the software level, entering a low-power survival strategy. In this state, the microcontroller actively shields unnecessary high-energy-consuming physical actions (refusing to open valves, retaining only the interrupt response for emergency valve closure), significantly lengthens the sleep cycle of RF communication to reduce packet transmission frequency, and sets a specific "low-power operation flag" in the underlying data frame. Simultaneously, the management center uses this flag for reputation assessment, determining that the sensor sampling frequency and accuracy of the node no longer possess high fidelity due to frequency reduction protection, and then isolates it from the cross-validation list of the "regional water use characteristic group" at the algorithm logic layer. This, on the one hand, maximizes the locking of battery power consumption under power outage conditions, ensuring that the equipment has sufficient "defense" to cope with extreme situations requiring emergency valve closure, such as sudden pipe bursts; on the other hand, by dynamically removing "sub-healthy" low-power nodes from the reference pool, it fundamentally prevents data drift caused by individual voltage instability or sampling lag from contaminating the verification benchmark of the entire group, ensuring the high accuracy and robustness of the network-wide collaborative judgment algorithm.

[0071] Compared to existing technologies, this invention constructs a self-organizing network comprising a primary and backup Bluetooth management hub and a water valve controller. The primary control hub collects device messages sent by the underlying water valve controllers, extracts sensor readings and communication hop counts to construct a multi-dimensional feature vector, and uses a K-means clustering algorithm to divide the regional water usage feature groups. Upon receiving a user activation command, the hub selects adjacent nodes within the same feature group for lateral cross-verification, determines device reliability based on a dynamic safety threshold generated from the network topology hop count, and issues control commands after passing the verification. When the primary control hub loses connection with the cloud, it automatically activates an offline relay mode, routing and transparently transmitting messages to the backup hub via the water valve controller to perform model verification and command issuance. This invention effectively eliminates the risk of single-point communication failures in complex network environments, upgrades isolated monitoring to feature group collaborative analysis, significantly reduces the false alarm rate caused by fluctuations in physical operating conditions, and significantly improves the system's disaster recovery and edge autonomy capabilities.

[0072] See Figure 2 Another embodiment of this application provides a remote water valve controller management system, including a cloud 1, several Bluetooth management hubs 2 and several water valve controllers 3.

[0073] The cloud 1 is used to store and distribute the water fee calculation model, and to receive user usage data and operation data of each water valve controller 3 uploaded by the Bluetooth management center 2. The Bluetooth management hub 2 includes a first processor 20, a first memory 21, and a communication module 22; the first memory 21 contains a pre-stored computer program, which, when executed by the first processor 20, performs the following functions: The water valve controller 3 within the Bluetooth communication range is determined by the communication module 22, and the main Bluetooth management center and the backup Bluetooth management center are determined according to the Bluetooth signal strength. The device receives the water control protocol message sent by the water valve controller 3, extracts the Bluetooth communication hop count and sensor readings to generate the protocol message vector, and uses the K-means clustering algorithm to divide the regional water use feature groups to generate the device communication list. After receiving the user's water control protocol message, the device filters the reference nodes of the same area water use characteristic group in the device communication list and performs device reliability verification. After verification, control commands are generated and issued based on the water fee calculation model.

[0074] The water valve controller 3 includes a second processor 30, a second memory 31, a sensor acquisition module 32, a motor actuator 33, and a Bluetooth communication module 34.

[0075] The sensor acquisition module 32 is used to acquire sensor readings including flow rate and actuator status.

[0076] The Bluetooth communication module 34 is used, under the control of the second processor 30, to send device water control protocol messages or user water control protocol messages encapsulated in a basic data frame format, and to receive the control commands.

[0077] The motor actuator 33 is used to drive the water valve to perform opening and closing actions according to the control command.

[0078] The node in the water valve controller 3 marked as the connected water valve controller is configured to act as a routing relay node to route the user water control protocol message to the adjacent backup Bluetooth management center when the main Bluetooth management center is disconnected from the cloud 1, so that the backup Bluetooth management center can perform the verification and command issuance on its behalf.

[0079] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the remote water valve controller management system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be elaborated upon here.

[0080] Compared to existing technologies, this invention constructs a self-organizing network comprising a primary and backup Bluetooth management hub and a water valve controller. The primary control hub collects device messages sent by the underlying water valve controllers, extracts sensor readings and communication hop counts to construct a multi-dimensional feature vector, and uses a K-means clustering algorithm to divide the regional water usage feature groups. Upon receiving a user activation command, the hub selects adjacent nodes within the same feature group for lateral cross-verification, determines device reliability based on a dynamic safety threshold generated from the network topology hop count, and issues control commands after passing the verification. When the primary control hub loses connection with the cloud, it automatically activates an offline relay mode, routing and transparently transmitting messages to the backup hub via the water valve controller to perform model verification and command issuance. This invention effectively eliminates the risk of single-point communication failures in complex network environments, upgrades isolated monitoring to feature group collaborative analysis, significantly reduces the false alarm rate caused by fluctuations in physical operating conditions, and significantly improves the system's disaster recovery and edge autonomy capabilities.

[0081] One embodiment of this application provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the remote water valve controller management method described above.

[0082] One embodiment of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the remote water valve controller management method described above.

[0083] The computer device may be a smartphone, tablet, desktop computer, or cloud server, among other computing devices. This computer device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the figures are merely examples of computer devices and do not constitute a limitation on the computer device. It may include more or fewer components than illustrated, or a combination of certain components, or different components, such as input / output devices, network access devices, etc.

[0084] The processor referred to can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0085] In some embodiments, the memory may be an internal storage unit of the computer device, such as a hard drive or RAM. In other embodiments, the memory may be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory may include both internal and external storage units of the computer device. The memory is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory can also be used to temporarily store data that has been output or will be output.

[0086] This application provides a computer program product that, when run on a computer device, enables the computer device to execute the steps described in the various method embodiments above.

[0087] In the several embodiments provided in this application, it will be understood that each block in the flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.

[0088] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A remote water valve controller management method, characterized in that, include: Identify all water valve controllers within the Bluetooth communication range of each Bluetooth management hub; If a water valve controller is within the Bluetooth communication range of several Bluetooth management hubs, the Bluetooth management hub with the highest Bluetooth signal strength is designated as the primary Bluetooth management hub, and the other Bluetooth management hubs are designated as backup Bluetooth management hubs. The water valve controller is designated as a connected water valve controller. When arranging the various Bluetooth management hubs, at least one connected water valve controller is ensured to be included within the Bluetooth communication range. Each Bluetooth management hub periodically uploads the usage data of each user and the operating data of each water valve controller to the cloud, and downloads the water fee calculation model from the cloud. Each water valve controller sends a device water control protocol message to the Bluetooth management center via a Bluetooth channel; the data content segment of the device water control protocol message includes the Bluetooth communication hop count and the readings of all sensors; each Bluetooth management center generates a protocol message vector based on the device water control protocol message and performs K-means clustering on all protocol message vectors, and generates a device communication list based on the clustering results, with each cluster center corresponding to a type of regional water use characteristic group; After receiving the user's opening command, the water valve controller generates a user water control protocol message according to the opening command and sends the user water control protocol message to the Bluetooth management center; the data content segment of the user water control protocol message includes the user ID and available water flow; the device water control protocol message and the user water control protocol message are encapsulated and parsed using the same basic data frame format; After receiving the user's water control protocol message, the Bluetooth management center filters water valve controllers in the device communication list that have a Bluetooth communication hop count less than a preset hop count threshold and belong to the same area water use characteristic group. Based on the filtering results, it reads all the device water control protocol messages to verify the device reliability of the water valve controller. After the equipment reliability test is passed, the Bluetooth management center generates control commands based on the water fee calculation model, and the water valve controller drives the water valve to perform corresponding opening and closing actions according to the control commands. When the main Bluetooth management center detects a disconnection from the cloud, it routes and relays the received user water control protocol message to the adjacent backup Bluetooth management center through the connecting water valve controller. The backup Bluetooth management center then performs the model verification of the water fee calculation model and issues control commands on its behalf.

2. The remote water valve controller management method as described in claim 1, characterized in that, The same basic data frame format includes: Start bit: Occupies 1 byte, is fixedly configured as the mapping code of the main Bluetooth management hub, and is used for frame synchronization and preliminary legality verification of the communication receiving end; Data length bit: occupies 1 byte and is used to dynamically identify the total number of bytes in the subsequent data content segment; Data content segment: occupies n bytes, where n is a positive integer, and is used to carry specific communication hop count, sensor readings, user ID, or available water flow information; Check bit: Occupies 1 byte, located at the end of the data frame, and is used to perform integrity algorithm verification on the data content segment.

3. The remote water valve controller management method as described in claim 1, characterized in that, The verification of the reliability of the water valve controller specifically includes: Extract the sensor readings of the water valve controller that is currently sending the user water control protocol message; The sensor readings are compared laterally with the sensor readings of other water valve controllers within the same area water usage characteristic group that have been selected. If the difference in the sensor readings is within a preset safety threshold range, the water valve controller is deemed to have passed the equipment reliability test; otherwise, the generation and issuance of the control command are blocked.

4. The remote water valve controller management method as described in claim 3, characterized in that, The process for determining the range of the safety threshold is as follows: Obtain the first Bluetooth communication hop count of the current water valve controller and the second Bluetooth communication hop count of the other water valve controllers; Calculate the absolute difference between the first Bluetooth communication hop count and the second Bluetooth communication hop count, and use it as the network topology distance parameter; Extract the cluster standard deviation and cluster center value of the regional water use characteristic group to which the current water valve controller belongs; A basic threshold is set based on the cluster standard deviation, and the network topology distance parameter is multiplied by the cluster center value and the preset pipe loss attenuation coefficient to obtain the hop count compensation threshold. The base threshold is added to the hop count compensation threshold to generate the final dynamic safety threshold, and the preset safety threshold range is defined based on the dynamic safety threshold.

5. A remote water valve controller management method according to claim 1 or 3, characterized in that, The readings of all sensors include instantaneous flow data collected by the pulse flow meter, mechanical opening data of the motor actuator fed back by the position sensor, and fault alarm flag bit; the writing process of the fault alarm flag bit is as follows: if the mechanical opening data of the water valve controller is in the open state, and the instantaneous flow data is continuously zero for a preset time, it is determined that a water source interruption or mechanical jamming abnormality has occurred, and the value of the fault alarm flag bit in the data content segment of the equipment water control protocol message is set to 1.

6. The remote water valve controller management method as described in claim 1, characterized in that, The process of generating and clustering the protocol message vectors specifically includes: The average water consumption, instantaneous flow fluctuation rate, and environmental water pressure attenuation gradient of the water valve controller within a set historical time period are extracted as basic feature dimensions. After normalizing the values ​​of different feature dimensions, a multi-dimensional state feature vector is constructed as the protocol message vector. The K-means clustering algorithm is used to iteratively cluster the multidimensional state feature vectors of each water valve controller.

7. The remote water valve controller management method as described in claim 1, characterized in that, The routing relay step when the main Bluetooth management hub detects a disconnection from the cloud specifically includes: When the water valve controller fails to receive a heartbeat confirmation packet from the main Bluetooth management center for several consecutive cycles, it determines that the main control link is disconnected and activates the offline relay mode. The connected water valve controller parses its locally stored backup routing table and selects the Bluetooth management hub with the best signal from multiple backup Bluetooth management hubs to establish a connection based on the real-time scanned Bluetooth signal reception strength indication value. The Bluetooth management hub with the best signal takes over the device communication list of the currently disconnected area, uses the latest water fee calculation model cached locally to verify the user water control protocol message transmitted by the relay, and transmits the control command back to the target water valve controller through the connected water valve controller.

8. The remote water valve controller management method as described in claim 1, characterized in that, The steps of generating control commands and driving the water valves based on the water fee calculation model specifically include: The Bluetooth management hub calculates the preset opening duration or the maximum allowed total number of flow pulses based on the available water flow in the user water control protocol message and the rate parameters in the water fee calculation model. The preset opening duration or the maximum allowed total number of flow pulses is encapsulated in a control command and sent to the corresponding water valve controller. When the water valve controller is in the open state, it monitors and accumulates the number of pulses passing through the pulse flow meter in real time. When the accumulated number of pulses reaches the maximum allowable total number of flow pulses or the time reaches the preset opening duration, the underlying microcontroller actively triggers the emergency interrupt program, drives the motor valve to perform mechanical valve closing action, and generates an actual consumption flow message, stores it in the local memory, and waits for the network to be restored before packaging and uploading.

9. The remote water valve controller management method as described in claim 1, characterized in that, The water valve controller is equipped with a main external DC power supply module and a built-in backup battery power supply module; When the water valve controller detects that the main external DC power supply module has lost power and switches to the built-in backup battery power supply module, it triggers a low-power survival strategy. Under the low-power survival strategy, the water valve controller refuses to respond to any opening commands other than the emergency valve closing command, reduces the broadcast frequency of sending the device water control protocol messages, and sets a low-power operation flag in the data content segment of the message. When performing device reliability checks, the Bluetooth management hub identifies water valve controllers with low battery operation flags, marks their status as unreliable, and dynamically removes them from the list of valid cross-validation reference nodes of the regional water use characteristic group.

10. A remote water valve controller management system, characterized in that, This includes the cloud, several Bluetooth management hubs, and several water valve controllers; The cloud is used to store and distribute water fee calculation models, and to receive user usage data and operating data of each water valve controller uploaded by the Bluetooth management center. The Bluetooth management hub includes a first processor, a first memory, and a communication module; the first memory pre-stores a computer program, which, when executed by the first processor, performs the following functions: The communication module determines the water valve controller within the Bluetooth communication range, and the main Bluetooth management center and backup Bluetooth management center are determined based on the Bluetooth signal strength. The device receives the water control protocol message sent by the water valve controller, extracts the Bluetooth communication hop count and sensor readings to generate the protocol message vector, and uses the K-means clustering algorithm to divide the regional water use feature groups to generate the device communication list. After receiving the user's water control protocol message, the device filters the reference nodes of the same area water use characteristic group in the device communication list and performs device reliability verification. After verification, control commands are generated and issued based on the water fee calculation model. The water valve controller includes a second processor, a second memory, a sensor acquisition module, a motor actuator, and a Bluetooth communication module; The sensor acquisition module is used to acquire sensor readings including flow rate and actuator status; The Bluetooth communication module is used, under the control of the second processor, to send device water control protocol messages or user water control protocol messages encapsulated in a basic data frame format, and to receive the control commands. The motor actuator is used to drive the water valve to perform opening and closing actions according to the control command; The node in the water valve controller marked as the connected water valve controller is configured to act as a routing relay node to route the user water control protocol message to the adjacent backup Bluetooth management center when the main Bluetooth management center loses connection with the cloud, so that the backup Bluetooth management center can perform the verification and command issuance on its behalf.

Images