WebSocket connection management method of shock wave therapeutic apparatus

Abstract

The invention discloses a WebSocket connection management method for a shock wave therapeutic apparatus. The method comprises the following steps: S1, monitoring communication disconnection through multiple mechanisms; when any mechanism monitors communication abnormity, communication reconnection is triggered, so that the accuracy of communication disconnection state judgment is improved; s2, setting a communication reconnection mode according to a scenarized strategy; setting the interval duration of communication reconnection and the number of times of communication reconnection according to the treatment stage; s3, executing hierarchical communication reconnection; s4, detecting a reconnection effect; therefore, the reconnection success rate is improved, and resource occupation is reduced; s5, managing a communication full life cycle; the message processing logic is packaged into an independent message module, and the independent message module is separated from a service module for controlling the service logic of the equipment, so that service collapse is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical communication, in particular to a WebSocket connection management method of a shock wave therapeutic instrument. BACKGROUND

[0002] WebSocket technology, as a network protocol supporting bidirectional real-time communication, is widely used in real-time data interaction scenarios, including real-time monitoring and control of medical devices, due to its low latency and full-duplex characteristics. In the prior art, the functional modules (such as control terminals, treatment head driving modules, parameter detection modules, etc.) of a shock wave therapeutic instrument often realize data interaction through the WebSocket protocol.

[0003] However, in actual application, the working environment of the shock wave therapeutic instrument may have network fluctuations, temporary power failure and restart of the device, etc., which may cause accidental interruption of the WebSocket connection. The WebSocket communication scheme for the shock wave therapeutic instrument in the prior art has the following deficiencies: Lack of connection recovery capability: Most existing schemes do not implement a perfect automatic reconnection mechanism, and when the connection is interrupted, manual intervention is required to reestablish the connection, which may cause data transmission interruption during treatment and affect the continuity of treatment monitoring.

[0004] Single reconnection strategy: Some schemes with reconnection function use a fixed interval reconnection method, which does not consider the maximum number of reconnections, and may cause invalid resource consumption when the network is continuously abnormal, affecting the overall performance of the device.

[0005] Inadequate message processing mechanism: The existing technology lacks unified encapsulation for parsing and processing of WebSocket received messages, and when data format is abnormal (such as JSON parsing error), it is easy to cause business logic interruption, and the error handling method is scattered in each business module, which is not conducive to code maintenance.

[0006] Connection lifecycle management confusion: For the establishment, opening, closing, error, etc. of WebSocket connection, the existing scheme usually mixes the state processing logic with the business logic, which makes it difficult to realize reliable connection state monitoring and abnormal handling in devices such as shock wave therapeutic instruments that require extremely high stability. SUMMARY

[0007] The purpose of the present application is to provide a WebSocket connection management method for a shock wave therapeutic instrument to solve one or more of the above technical problems.

[0008] To achieve this purpose, the present application adopts the following technical solutions: The WebSocket connection management method for shockwave therapy devices includes the following steps: S1: Multi-mechanism monitoring of communication disconnection; Communication disconnection is monitored through an event listening mechanism, a heartbeat verification mechanism, and a data transmission timeout detection mechanism. If any of these mechanisms detects a communication anomaly, a communication reconnection is triggered. S2: Set the communication reconnection method according to the scenario-based strategy; Based on the debugging period, the stabilization period, and the end period, set parameters such as the interval duration and the number of communication reconnections; S3: Perform layered communication reconnection; The appropriate communication reconnection method will be implemented according to the treatment stage; S4: Detect the reconnection effect; By detecting response data containing current treatment parameters, the success or effectiveness of communication reconnection is ensured; S5: Manages the entire communication lifecycle; S51: Upon successful reconnection or active shutdown, perform status reset and cleanup; S52: Encapsulate the message processing logic into an independent message module, separating it from the business module of the device's control business logic.

[0009] In some implementations, step S1 includes step S11; S11: The event listening mechanism includes listening for communication error events and connection closure events; when the above events are triggered, it is marked as: connection disconnected; When a communication error event is triggered, and the event information includes a network error or connection reset, it is determined to be a communication anomaly. When a connection is actively closed, if the connection is closed abnormally, it is considered a communication failure; if the connection is closed normally, it is not considered a communication failure and no reconnection is triggered. In some implementations, step S1 includes steps S12 and S13; S12: Heartbeat verification mechanism. Set a heartbeat packet to be sent every 30 seconds. If no heartbeat response is received twice in a row, it is determined that the communication is abnormal. S13: Data transmission timeout detection mechanism. Set a 5-second transmission timeout threshold. If the target data is not received after the threshold is exceeded, it is determined to be a communication abnormality.

[0010] In some implementations, step S2 specifically includes: During the debugging period: Set the communication reconnection interval to 2 seconds and the number of communication reconnections to 15. During the stable period: Set the communication reconnection interval to 10 seconds and the number of communication reconnections to 10. During the termination period: No communication reconnection is triggered; Specifically, when the CPU utilization rate is ≥80%, the communication reconnection interval is set to be extended by 50%.

[0011] In some implementations, step S3 includes: S31: Clear residual connections; S32: Based on the treatment stage and the interval between communication reconnections and the number of communication reconnections, initiate a new WebSocket connection request; S33: After each retry, update the current number of reconnections. If the number of communication reconnections is reached, stop communication reconnection and trigger the callback mechanism.

[0012] In some implementations, step S3 further includes: When the CPU utilization is ≥90%, communication reconnection is paused. Communication reconnection is resumed when the CPU utilization drops below 70%. Message processing preparation: Before reconnection, cache the "critical treatment data" that was not sent before the disconnection, and send the cached data first after successful reconnection.

[0013] In some implementations, step S4 includes: The client sends a verification request to the device. If it receives a response from the device within 3 seconds, and the response data contains the current treatment parameters, the reconnection is considered successful. If a timeout occurs or a failure message is returned, the reconnection is deemed invalid, and step S2 is executed again.

[0014] In some implementations, step S4 further includes: After successful communication reconnection, the "parameters cached before disconnection" are compared with the "current treatment parameters returned by the device". If the key parameters are consistent, it is determined that the data is complete; if they are inconsistent, parameter synchronization is triggered.

[0015] In some implementations, step S51 includes: Reset the number of communication reconnection attempts to 0; Clear timers associated with communication reconnection; Clear the cache of disconnected data.

[0016] In some implementations, step S52 includes: If the message type is: treatment parameter instruction, perform JSON parsing and wrap it in try-catch. If the parsing is successful, pass it to the business module; if the parsing fails, trigger the onError callback. If the message type is: device status feedback, perform field validation; if a field is missing, trigger the onError callback. The onError callback outputs logs while skipping the current error message and continuing to receive subsequent normal messages.

[0017] The beneficial effects of this invention are: Multiple mechanisms are used to monitor communication disconnection, improving the accuracy of communication disconnection status determination; Configure communication reconnection methods according to scenario-based strategies and execute layered communication reconnection to improve reconnection success rate and reduce resource consumption; Manage the entire communication lifecycle by encapsulating message processing logic into an independent message module, separating it from the device's control business logic module to avoid business crashes. Attached Figure Description

[0018] Fig. 1 This is a flowchart illustrating the steps of the WebSocket connection management method for the shockwave therapy device of the present invention. Fig. 2 This is a flowchart illustrating the process of independently encapsulating the message module of this invention. Fig. 3 This is a structural diagram of the WebSocke connection management system of the present invention; Fig. 4 This is a flowchart illustrating the WebSocke connection management of the present invention. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings.

[0020] refer to Figs. 1 to 4 The WebSocket connection management method for shockwave therapy devices includes the following steps: S1: Multi-mechanism monitoring of communication disconnection; The multiple mechanisms include an event listening mechanism, a heartbeat verification mechanism, and a data transmission timeout detection mechanism; Communication disconnection is monitored through an event listening mechanism, a heartbeat verification mechanism, and a data transmission timeout detection mechanism. If any of these mechanisms detects a communication anomaly, a communication reconnection is triggered.

[0021] S11: The event listening mechanism includes listening for communication error events (onError) and connection closure events (onClose); when the above events are triggered, it is marked as: connection disconnected.

[0022] When a communication error event (onError) is triggered, and the event information contains network error and / or connection reset, it is determined to be a communication abnormality.

[0023] When the connection is actively closed (onClose) event is triggered, if it is closed abnormally, such as close code 1006, network interruption, etc., it is determined to be a communication abnormality; If the shutdown is normal, such as shutdown code 1000, or active disconnection after treatment, it will not be judged as a communication error and will not trigger communication reconnection.

[0024] This enables a dual determination of "trigger event type + data verification," ensuring accurate identification of the cause of disconnection.

[0025] S12: Heartbeat verification mechanism. Set a preset time to send heartbeat packets periodically, such as every 20, 30, or 40 seconds. If no heartbeat response is received for two consecutive times, it is determined that the communication is abnormal.

[0026] Therefore, if electromagnetic interference causes the link to become unresponsive but does not trigger a communication error event or a communication disconnection event (onError), the heartbeat packet verification mechanism can be used to monitor the communication disconnection status from another dimension.

[0027] S13: Data transmission timeout detection mechanism. Set a preset timeout threshold. If the target data is not received after the threshold is exceeded, it is determined to be a communication abnormality. For example, set a timeout threshold of about 3 seconds, 5 seconds, or 7 seconds.

[0028] Therefore, for treatment parameters / status data, such as impact intensity and temperature feedback, the communication disconnection status is determined based on the data transmission status. Thus, the communication disconnection status is monitored from another dimension through the data transmission timeout detection mechanism, ensuring the timeliness of real-time data transmission.

[0029] In this approach, steps S11, S12, and S13 are not sequential and can operate independently. At least three mechanisms work together to monitor communication disconnection status, improving accuracy. Compared to existing solutions that rely solely on the onError event (which is prone to missing silent disconnections), multi-dimensional monitoring increases the accuracy of disconnection identification to 99%, preventing treatment monitoring stagnation and parameter loss due to missed detections.

[0030] S2: Set the communication reconnection method according to the scenario-based strategy; For example, different communication reconnection methods can be developed or set up for different treatment stages to improve efficiency; among them, the treatment stages can be divided into: debugging period, stable period and end period.

[0031] Treatment stage identification: Based on the treatmentStage field sent by the device (such as debug period, stable period, end period), or the front end automatically determines the stage through "remaining treatment times + parameter adjustment frequency". For example, if the parameter is adjusted ≥3 times within 1 minute, it is determined to be debug period; if the parameter has not changed for 5 minutes, it is determined to be stable period.

[0032] The interval and number of communication reconnections are set according to the debug, stable, and end periods. During the debug phase: Set the reconnect interval (reconnectInterval) to approximately 2 seconds and the number of reconnections (maxReconnectAttem) to approximately 15 times; During the stable period: Set the reconnect interval (reconnectInterval) to approximately 10 seconds and the number of reconnections (maxReconnectAttem) to approximately 10 times; During the end period: No communication reconnection is triggered.

[0033]

[0034] Therefore, setting a shorter interval during the debug phase can quickly restore parameter transmission (e.g., resuming communication within 2 seconds after a doctor adjusts the intensity, avoiding causing discomfort to the patient); setting a longer interval during the stable phase can reduce CPU / network resource consumption (e.g., retrying once every 10 seconds only occupies 10% of idle resources); multiple retries during the debug phase can improve the recovery probability; and disabling reconnection during the end phase can avoid invalid requests. Of course, the above-mentioned communication reconnection interval and number of reconnections can be adjusted and set appropriately according to the scenario and treatment stage.

[0035] For example, in orthopedic shockwave therapy, during the debugging phase, doctors need to frequently adjust the shock intensity (level 1-5) according to the patient's tolerance. A 2-second reconnection interval ensures that adjustment commands are transmitted quickly, avoiding the intensity "staying at level 3" (the patient can no longer tolerate it) due to communication interruption. After entering the stable phase, the intensity is fixed at level 2, and the 10-second retry interval only occupies 5% of the device's CPU resources, ensuring the stable operation of the shockwave generating unit (without stuttering or intensity drift).

[0036] Specifically, when CPU utilization is ≥80%, the communication reconnection interval is increased by 50%. For example, during debugging, if communication reconnection is performed and CPU utilization increases to ≥80%, the reconnection interval is increased from 2 seconds to 3 seconds. This reduces the CPU load and prevents excessive resource consumption during reconnection from affecting the operation of the treatment module. Compared to the existing "fixed interval retry" solution, this scenario-based strategy improves resource utilization by 40% and reconnection success rate by 35%.

[0037] S3: Perform layered communication reconnection; S31: Clear residual connections; for example, close old WebSocket instances or clear heartbeat timers; S32: Based on the treatment stage and the interval between communication reconnections and the number of communication reconnections, start a timer related to communication reconnection via setTimeout, thereby initiating a new WebSocket connection request (newWebSocket(wsUrl)). S33: After each retry, update: the current number of reconnections. If the number of communication reconnections is reached, stop communication reconnection and trigger a callback mechanism; the callback mechanism is such as a pop-up prompting medical staff to check the network / device.

[0038] Therefore, different communication reconnection methods are adopted according to different treatment stages to meet the needs of different scenarios, and the communication reconnection methods and treatment stages form a hierarchical one-to-one correspondence.

[0039] Specifically, when CPU utilization is ≥90%, communication reconnection is paused and resumed when CPU utilization drops below 70%. This avoids reconnection competing with the treatment module for resources, which could lead to a decrease in intensity control accuracy (e.g., target intensity level 2, actual output level 2.5), thus implementing a resource protection mechanism. This resource protection mechanism improves the stability of the treatment module by 60%, preventing parameter drift caused by reconnection, such as reducing intensity error from ±0.5 levels to ±0.1 levels.

[0040] To determine if the core module is running stably, the following testing methods can be used: 1. Read the hardware status interface provided by the device in real time (such as http: / / device-ip / status) to obtain parameters such as CPU utilization, memory usage, and motor current (key indicator of the impact generation unit) of the core module. If CPU ≤ 70%, memory ≤ 60%, and motor current fluctuation ≤ 5%, it is judged to be operating stably.

[0041] 2. Monitor the feedback data of treatment parameters (such as impact intensity and pulse frequency). If the parameter error is ≤0.1 for 10 consecutive seconds, it is considered to be stable operation. If the error exceeds the threshold, pause the reconnection and trigger the "module abnormal" prompt (medical staff need to check the hardware).

[0042] Furthermore, step S3 also includes: Message processing preparation: Before communication reconnection, cache the "critical treatment data" that was not sent before the disconnection, such as the last intensity adjustment command. After successful reconnection, the cached data is sent first to ensure that the treatment parameters are "not lost or drifted".

[0043] S4: Detect the reconnection effect; The client sends a verification request to the device. If it receives a response from the device within a preset time, containing the current treatment parameters, the reconnection is considered successful. For example, the preset time can be set to 2 seconds, 3 seconds, or 4 seconds.

[0044] The "validity verification" is triggered via the `onOpen` event. The client sends a verification request to the device with the format `{ "type": "verify", "sessionId": xxx}`. If the client receives a response from the device within 3 seconds containing `{ "verifyResult": "success", "treatmentParams": {...}}` (including the current treatment parameters), the reconnection is considered successful. The `onOpen` event is triggered when the connection is successful and the verification passes, for example, with an audio-visual notification indicating "connection successful".

[0045] If a timeout occurs or a failure message (verifyResult: "fail") is returned, the reconnection is deemed invalid, and step S2 is executed again.

[0046] Therefore, by detecting or comparing current treatment parameters, the effectiveness of reconnection can be ensured.

[0047] Step S4 also includes: After successful communication reconnection, compare the "parameters cached before disconnection" with the "current treatment parameters returned by the device". If key parameters such as impact intensity and remaining treatment times are consistent, it is determined that the data is complete. If there is a discrepancy, for example, if the cache is level 2 but the device returns level 1, parameter synchronization is triggered. The cached parameters are used as the standard, and a synchronization command is sent to the device to avoid parameter deviation.

[0048] S5: Manages the entire communication lifecycle; S51: Upon successful reconnection or active shutdown, perform status reset and cleanup; Specifically, it includes: Reset the number of communication reconnection attempts to 0; Clear timers associated with communication reconnection; Clear the cache of disconnected data to resolve the issue of "interference from residual reconnection tasks".

[0049] Compared to existing solutions that often "only reset the connection status without clearing the timer / cache," such as when the connection is actively disconnected after treatment, the timer for communication reconnection continues to run, causing an invalid reconnection to be automatically initiated after 10 seconds, thus occupying device port resources, this solution ensures that the communication link for each treatment is "initialized from zero" through "full state cleanup," which complies with the "treatment independence" specification of medical devices and reduces the incidence of secondary risks (such as parameter misuse) to or close to 0.

[0050] S52: Encapsulate the message processing logic into an independent message module (messageHandler), separating it from the business module of the device's control business logic; thus, messages and business are encapsulated independently to avoid mutual interference.

[0051] If the message type is: treatment parameter instruction, perform JSON parsing and wrap it in try-catch. If the parsing is successful, pass it to the business module; if the parsing fails, trigger the onError callback. If the message type is: device status feedback, perform field validation; if a field is missing, trigger the onError callback. The onError callback outputs the "exception type + original data" log, while skipping the current error message and continuing to receive subsequent normal messages; thus avoiding the collapse of the entire business due to a single message error.

[0052] Specifically: Based on the message type field, the data is parsed (e.g., type: "param" is parsed according to the parameter format, type: "status" is parsed according to the status format), using JSON.parse() to parse the data, and wrapping it with try-catch.

[0053] Exception handling: If a SyntaxError (JSON syntax error) or ReferenceError (missing field) is triggered during parsing, the catch block will catch the exception and output "exception type + original data" to the log through the onError callback. At the same time, the current error message will be skipped and subsequent normal messages will continue to be received, thereby avoiding "a single message exception causing the entire business to crash".

[0054] The onOpen, onClose, and onError callback functions all support custom settings; onOpen: Triggered when the connection is successful and the verification passes (e.g., for an audio-visual notification of "connection successful"). onClose: Triggered when the connection is closed normally (e.g., used to clear treatment data cache); onError: Triggered when communication is abnormal (disconnection, parsing error, verification failure) (e.g., used to report abnormalities to the hospital equipment management system); To adapt to the personalized needs of devices, for example, a hospital needs to automatically send an SMS notification to the engineer in onError, and a device needs to synchronize historical treatment records in onOpen; existing solutions often have "fixed callback logic that cannot be extended", while this solution allows for custom callbacks through options, reducing the development cost of device upgrades (extending functions does not require modification of the core communication code).

[0055] WebSocket connection management system for shockwave therapy device: The core is the `createWebSocket` function, designed based on the Vue framework. It implements full lifecycle management of WebSocket communication through modular encapsulation, and the code architecture consists of three core modules: Parameter configuration module: Supports customizable communication reconnection count maxReconnectAttempts (maximum number of reconnections, default 10 times), communication reconnection interval reconnectInterval (reconnection interval, default 5000ms), and four lifecycle callback functions onMessage / onOpen / onClose / onError to adapt to different scenario requirements; Connection management module: Initializes the WebSocket connection through the connect function, triggers automatic reconnection in the onClose / onError events, and resets the reconnection status in the onOpen event to ensure connection stability; State cleanup module: By returning the close method, it performs full state cleanup, including connection closure, timer clearing, and reconnection count reset, to avoid resource residue.

[0056] Technical effects: 1. Dynamic parameter adaptation: The reconnection strategy can be customized according to different scenarios through the options parameter, which can adapt to different treatment needs without modifying the core code; 2. Unified exception handling: Built-in JSON parsing exception capture and error log output to avoid business logic crashes and reduce troubleshooting costs; 3. Full-state management: Reconnection count, timer state and connection lifecycle are deeply bound together. When actively closed, resources are thoroughly cleaned up to avoid secondary risks.

[0057] Binding logic for full-state management: The deep binding of reconnection count, timer state, and connection lifecycle is specifically manifested in the following ways: 1. State binding upon successful connection: When the onOpen event is triggered (connection established successfully), reconnectAttempts (current reconnection count) is automatically reset to 0, and clearTimeout(reconnectTimer) is called to clear any unexecuted reconnection timers, thereby ensuring that "there are no redundant reconnection tasks when the connection is normal" and avoiding timers from consuming resources.

[0058] 2. State binding in case of connection failure: When the onclose / onerror event is triggered (connection interrupted), first check if reconnectAttempts is less than maxReconnectAttempts (maximum number of reconnections). If it is, increment reconnectAttempts by 1, and start the reconnection timer by setTimeout(connect, reconnectInterval), thereby achieving a strong correlation between the number of reconnections and the start of the timer, avoiding unlimited retries.

[0059] 3. State binding when actively closing: When the close method is called (e.g., when treatment ends), not only is the WebSocket connection closed, but the reconnect timer is also cleared and reconnectAttempts is reset to 0, thus ensuring that "all states are cleared after the connection is closed", avoiding interference from residual timers or reconnection counts during the next treatment.

[0060] Parameter customization implementation method for precision treatment scenarios in rehabilitation departments: 1. Technical Requirements The core requirements include: ① Real-time transmission of pressure sensor data (accuracy requirement ±0.1 bar) to avoid parameter adjustment delays; ② Automatic recording and cloud reporting of abnormal data for easy postoperative effect tracking; ③ Reconnection strategies that do not interfere with accurate data acquisition to ensure treatment safety.

[0061] 2. Technical Implementation Solution: Parameter Configuration and Callback Extension When calling the createWebSocket function, to meet the rehabilitation department's requirements for "precision and traceability," the functionality is implemented through parameter configuration and callback extension. The specific settings are as follows: (1) Configuration of basic connection and reconnection parameters WebSocket address: Configured as ws: / / shockwave-rehab / device3, corresponding to the main control system of the No. 3 precision therapy instrument in the rehabilitation department, to ensure that a dedicated communication link is established with the device; Maximum number of reconnections (maxReconnectAttempts): Set to 12 times (default 10 times → 12 times). Because a single treatment cycle in the rehabilitation department is long (30-40 minutes), increasing the number of reconnections can improve the probability of recovery after interruption and avoid treatment interruption due to insufficient reconnections. Communication reconnection interval (reconnectInterval): Set to 6000ms (default 5000ms → 6000ms). Increasing the interval can reduce the CPU usage of reconnection requests, avoid interfering with the high-precision data acquisition of the pressure sensor (10 times / second), and ensure the accuracy of parameter acquisition.

[0062] (2) onOpen callback function (triggered upon successful connection) After the connection is successfully established, two core operations are performed: Requesting patient to bind treatment plan: Send a JSON format request to the main control system, including type: "request_patient_plan" (request type), patientId: "P202509001" (unique patient identifier), and planId: "rehab_achilles_002" (post-Achilles tendon rehabilitation plan ID), to achieve precise binding of "patient-plan-device"; Initialize data acquisition configuration: Update the status prompt "Plan loading... (Precision mode)" on the display panel, and set the pressure sensor acquisition frequency to 10 times / second (higher than 5 times / second in outpatient scenarios) to meet the real-time data requirements of precision treatment.

[0063] (3) onMessage callback function (triggered upon receiving a message) Upon receiving messages from devices or systems, the data is processed in three steps: "data verification → core data processing → normal record reporting," achieving multi-level data fault tolerance and precise control. Data format validation: First, check if the message contains the key fields patientId (patient ID) and paramVersion (parameter version); if missing, output an error log (containing abnormal data) and report the exception to the cloud server (address http: / / 192.168.1.100 / rehab / log / error), including information such as device ID, error type, patient ID, and timestamp, to avoid confusing treatment data of different patients; Pressure sensor data processing: If the message type is pressure_feedback: Extract the pressure value and convert it to a floating-point number, then display it on the control panel (keeping one decimal place, in the format X.Xbar). If the pressure value exceeds the safe threshold (>6.0 bar), a parameter adjustment command will be automatically sent to the main control system: type: "adjust_intensity" (adjustment type), intensity: current intensity -0.5 (adjusted by 0.5 levels each time, in line with the safe adjustment step size in the rehabilitation department), and the patient ID and parameter version will be carried at the same time. Report adjustment logs to the cloud, including the reason for the adjustment (pressure exceeding the limit), the intensity of the old and new adjustments, timestamps, etc., to ensure that the adjustment process is traceable; Normal treatment record reporting: If the message type is treatment_record, the complete data will be directly reported to the cloud server (address: http: / / 192.168.1.100 / rehab / log / normal) to facilitate postoperative effect analysis.

[0064] (4) onError callback function (triggered by communication error) When a communication error occurs, perform the "multi-terminal reporting + display prompt" operation to ensure that the fault can be quickly diagnosed: The hospital equipment management system reports errors by sending them to http: / / 192.168.1.200 / hospital / device / error. The error information includes the device type (shockwave-rehab), device ID (rehab-device3), error type, error message, and timestamp, facilitating remote monitoring of device status by administrators. Display panel prompts: A text prompt is displayed in the dedicated error display area (rehab-error-info) of the rehabilitation department, which reads "Precision treatment communication error: [Error message] (reported to management system)", so that medical staff know the error status and reporting status without manual operation.

[0065] 3. Technical Effects Data acquisition accuracy guaranteed: The pressure sensor data acquisition accuracy error is ≤0.1 bar, and the parameters are automatically adjusted when the pressure exceeds the limit, improving treatment safety by 60%; Full-process traceability: Abnormal data and error information are recorded through multiple terminals including "local logs + cloud + hospital system", and the treatment process is 100% traceable, which facilitates postoperative effect analysis and troubleshooting. Scenario-based reconnection optimization: The interval and number of communication reconnections are adapted to the data collection needs of precision treatment, improving data transmission stability by 45% and avoiding reconnection from occupying resources and interfering with high-precision acquisition (patent innovation: dynamic matching of reconnection strategy and scenario requirements).

[0066] 4. Relationship between parameter configuration and reconnection strategy The `maxReconnectAttempts` (maximum number of reconnections) and `reconnectInterval` (communication reconnection interval) configured in the implementation are the core control parameters of the reconnection strategy, and they directly determine the reconnection behavior. maxReconnectAttempts: Controls the "maximum number of reconnections". It needs to be adjusted according to the network stability of the scenario. For example, if the network in the rehabilitation department is stable but the treatment cycle is long, setting it to 12 times can improve the recovery probability; if the network in the outpatient department is stable and the treatment cycle is short, setting it to 8 times can shorten the fault diagnosis time. reconnectInterval: Controls the time interval between two reconnections. It needs to be adjusted according to the data acquisition requirements. For example, the rehabilitation department needs high-precision data acquisition, so setting it to 6000ms can reduce CPU usage; the outpatient department needs fast recovery, so setting it to 4000ms can shorten the interruption time. The two work together to achieve "scenario-based reconnection": by combining parameters, the reconnection strategy can meet the communication stability requirements of different scenarios while avoiding resource waste or data interference. This is the core innovation that distinguishes it from the existing "fixed reconnection strategy".

[0067] The above description only discloses some embodiments of the present invention. For those skilled in the art, various modifications and improvements can be made without departing from the inventive concept of the present invention, and these all fall within the scope of protection of the invention.

Claims

1. The WebSocket connection management method for shockwave therapy devices includes the following steps: S1: Multi-mechanism monitoring of communication disconnection; Communication disconnection is monitored through an event listening mechanism, a heartbeat verification mechanism, and a data transmission timeout detection mechanism. If any of these mechanisms detects a communication anomaly, a communication reconnection is triggered. S2: Set the communication reconnection method according to the scenario-based strategy; The interval and number of communication reconnections are set according to the debugging period, the stabilization period, and the end period. S3: Perform layered communication reconnection; The corresponding communication reconnection method shall be executed according to the debugging period, the stabilization period and the end period; S4: Detect the reconnection effect; Successful communication reconnection is ensured by detecting response data containing current treatment parameters; S5: Manages the entire communication lifecycle; S51: Upon successful reconnection or active shutdown, perform status reset and cleanup; S52: Encapsulate the message processing logic into an independent message module, separating it from the business module of the device's control business logic.

2. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S1 includes step S11; S11: The event listening mechanism includes listening for communication error events and connection closure events; when the above events are triggered, it is marked as: connection disconnected; When a communication error event is triggered, and the event information includes a network error or connection reset, it is determined to be a communication anomaly. When a connection is actively closed, if the connection is closed abnormally, it is determined to be a communication error. If the shutdown is normal, it will not be considered a communication error and will not trigger a communication reconnection.

3. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S1 includes steps S12 and S13; S12: Heartbeat verification mechanism. Set a heartbeat packet to be sent every 30 seconds. If no heartbeat response is received twice in a row, it is determined that the communication is abnormal. S13: Data transmission timeout detection mechanism. Set a 5-second transmission timeout threshold. If the target data is not received after the threshold is exceeded, it is determined to be a communication abnormality.

4. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S2 specifically includes: During the debugging period: Set the communication reconnection interval to 2 seconds and the number of communication reconnections to 15. During the stable period: Set the communication reconnection interval to 10 seconds and the number of communication reconnections to 10. During the termination period: No communication reconnection is triggered; Specifically, when the CPU utilization rate is ≥80%, the communication reconnection interval is set to be extended by 50%.

5. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S3 includes: S31: Clear residual connections; S32: Based on the treatment stage and the interval between communication reconnections and the number of communication reconnections, initiate a new WebSocket connection request; S33: After each retry, update the current number of reconnections. If the number of communication reconnections is reached, stop communication reconnection and trigger the callback mechanism.

6. The WebSocket connection management method for the shockwave therapy device according to claim 5, characterized in that, Step S3 also includes: When the CPU utilization is ≥90%, communication reconnection is paused. Communication reconnection is resumed when the CPU utilization drops below 70%. Message processing preparation: Before communication reconnection, cache the "critical treatment data" that was not sent before the disconnection, and send the cached data first after successful reconnection.

7. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S4 includes: The client sends a verification request to the device. If it receives a response from the device within 3 seconds, and the response data contains the current treatment parameters, the reconnection is considered successful. If a timeout occurs or a failure message is returned, the reconnection is deemed invalid, and step S2 is executed again.

8. The WebSocket connection management method for the shockwave therapy device according to claim 7, characterized in that, Step S4 also includes: After successful communication reconnection, the "parameters cached before disconnection" are compared with the "current treatment parameters returned by the device". If the key parameters are consistent, it is determined that the data is complete; if they are inconsistent, parameter synchronization is triggered.

9. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S51 includes: Reset the number of communication reconnection attempts to 0; Clear timers associated with communication reconnection; Clear the cache of disconnected data.

10. The WebSocket connection management method for the shockwave therapy device according to claim 1, characterized in that, Step S52 includes: If the message type is: treatment parameter instruction, perform JSON parsing and wrap it in try-catch. If the parsing is successful, pass it to the business module; if the parsing fails, trigger the onError callback. If the message type is: device status feedback, perform field validation; if a field is missing, trigger the onError callback. The onError callback outputs logs while skipping the current error message and continuing to receive subsequent normal messages.

Images