Help alarm data processing method, system and device for intelligent public toilet and medium

Abstract

The application discloses a kind of for intelligent public lavatory's help alarm data processing method, system, equipment and medium, it is related to data processing technical field, method includes: obtaining target area in public lavatory, multiple help alarm buttons are set on target area, obtain historical button state data and response result data;Obtain historical button state data, obtain the press duration data sequence of help alarm button in target area;According to the response level data corresponding to n previous response result data of current time, obtain corresponding response level data;According to the response level data corresponding to n previous response result data and the press duration data sequence of help alarm button, obtain the importance weight of help alarm button, obtain help alarm response strategy based on the importance weight of help alarm button and current button state data.The application has the advantages of response distinction, dynamic weight correction and hierarchical response.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method, system, device, and medium for processing emergency alarm data in smart public toilets. Background Technology

[0002] In the field of intelligent public toilet management, the false alarm rate and response efficiency of multi-compartment emergency alarms have long been problems. Currently, multiple emergency buttons are installed in each compartment (e.g., buttons are set at 1m, 1.3m or 1.5m). Existing technologies all use simple counting or single threshold triggering mechanisms. If multiple buttons are pressed at the same time or a single button is pressed for more than a fixed time, a unified response is initiated, which leads to three defects.

[0003] Specifically, firstly, some buttons at lower locations are frequently accidentally pressed (e.g., by children playing or accidentally bumping into them), and are treated the same as other buttons as emergency alarm events, resulting in ineffective alarm processing; secondly, different types of events (accidental touches, equipment malfunctions, or more serious health crises) cannot be differentiated in response, potentially masking genuine medical distress signals; thirdly, the correlation between button location characteristics and historical behavior is not utilized—buttons with low accidental touch rates (e.g., buttons at higher locations) should have higher decision-making weights, but current methods do not dynamically adjust button settings, simply assigning the same importance to all buttons. This means that a button at 1m low might be accidentally pressed for 10 seconds consecutively, potentially triggering a higher response level than a button at 1.5m high might be pressed briefly for 7 seconds; simultaneously, existing technology lacks dynamic learning capabilities based on historical feedback, making it unclear how to dynamically adjust the importance weights of buttons. For example, when a button is frequently associated with accidental touch records (e.g., 8 out of 10 presses are accidental touches), its subsequent triggers should have a lower urgency assessment, but the current mechanism still mechanically accumulates the number of presses / duration, causing resource misallocation. Therefore, there is an urgent need for a new method that can integrate button location characteristics, historical false alarm patterns, and event classification, and dynamically generate classified response strategies by quantifying the decision value of different buttons in real events. Summary of the Invention

[0004] In response to the technical problems mentioned in the background art, the present invention provides a method, system, device and medium for processing emergency alarm data in smart public toilets.

[0005] A method for processing emergency alarm data in a smart public toilet includes: acquiring a target area within the public toilet, setting multiple emergency alarm buttons located at different positions within the target area, and acquiring historical button status data and response result data of the target area; acquiring historical button status data corresponding to the first n response result data at the current moment, and acquiring a sequence of press duration data for each emergency alarm button within the target area based on the historical button status data corresponding to the first n response result data; acquiring corresponding response level data based on the first n response result data at the current moment; acquiring the importance weight of each emergency alarm button based on the response level data corresponding to the first n response result data and the press duration data sequence of each emergency alarm button, and acquiring an emergency alarm response strategy based on the importance weight of each emergency alarm button and the current button status data.

[0006] Optionally, obtaining the corresponding response level data based on the n response results data at the current moment includes: obtaining standard level data; when the response result data is determined to be an unintentionally triggered event, using -1 times the standard level data as the response level data corresponding to the response result data; when the response result data is determined to be an equipment failure event, using 1 times the standard level data as the response level data corresponding to the response result data; when the response result data is determined to be a health crisis event, using 2 times the standard level data as the response level data corresponding to the response result data.

[0007] Optionally, obtaining the importance weight of each help alarm button based on the response level data corresponding to the first n response results and the press duration data sequence of each help alarm button includes: multiplying each data in the press duration data sequence of the i-th help alarm button in the target area by the response level data corresponding to the first n response results, and obtaining the product sequence of the i-th help alarm button in the target area; summing all the data in the product sequence of the i-th help alarm button in the target area and obtaining the sum of the products of the i-th help alarm button in the target area; and obtaining the importance weight of each help alarm button in the target area based on the sum of the products of each help alarm button in the target area.

[0008] Optionally, obtaining the importance weight of each help alarm button in the target area based on the sum of the products of each help alarm button in the target area includes: obtaining the unprocessed value of each help alarm button in the target area based on the sum of the products of each help alarm button in the target area; adding up the unprocessed values ​​of all help alarm buttons in the target area to obtain the comparison total; dividing the unprocessed value of each help alarm button in the target area by the comparison total to obtain the proportion of each help alarm button in the target area, and using the proportion of each help alarm button in the target area as the importance weight of each help alarm button in the target area.

[0009] Optionally, obtaining the pending value of each emergency alarm button in the target area based on the sum of the products of each emergency alarm button in the target area includes: if the sum of the products of the i-th emergency alarm button in the target area is greater than or equal to zero, then the sum of the products of the i-th emergency alarm button is added to a preset base value to obtain the pending value of the i-th emergency alarm button; if the sum of the products of the i-th emergency alarm button in the target area is less than zero, then the preset base value is used as the pending value of the i-th emergency alarm button.

[0010] Optionally, obtaining the help alarm response strategy based on the importance weight of each help alarm button and the current button status data includes: obtaining the real-time pressing duration of each help alarm button in the target area; multiplying the real-time pressing duration of each help alarm button in the target area by the importance weight of each help alarm button to obtain the urgency of the target area; and obtaining the help alarm response strategy according to the urgency of the target area.

[0011] A data processing system for emergency alarms in smart public toilets is also provided, which implements the aforementioned data processing method for emergency alarms in smart public toilets. The system includes: a first data acquisition module, used to acquire a target area located within the public toilet, where multiple emergency alarm buttons are set at different locations, and to acquire historical button status data and response result data of the target area; a second data acquisition module, used to acquire historical button status data corresponding to the first n response result data at the current time, and to acquire a sequence of press duration data for each emergency alarm button in the target area based on the historical button status data corresponding to the first n response result data; a first data processing module, used to acquire corresponding response level data based on the first n response result data at the current time; and a second data processing module, used to acquire the importance weight of each emergency alarm button based on the response level data corresponding to the first n response result data and the sequence of press duration data for each emergency alarm button, and to acquire an emergency alarm response strategy based on the importance weight of each emergency alarm button and the current button status data.

[0012] Optionally, the second data processing module is further configured to: obtain the real-time pressing duration of each help alarm button in the target area; multiply the real-time pressing duration of each help alarm button in the target area by the importance weight of each help alarm button to obtain the urgency of the target area; and obtain a help alarm response strategy based on the urgency of the target area.

[0013] An electronic device is also provided, comprising: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement a data processing method for emergency alarms in smart public toilets.

[0014] A non-transitory computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements a method for processing emergency alarm data for smart public toilets.

[0015] The beneficial effects of this invention are reflected in:

[0016] In the entire data processing method for emergency alarms in smart public toilets, firstly, by introducing response level data and combining it with button location characteristics, different types of events are fundamentally distinguished, avoiding the equating accidental touches of low-position buttons with genuine emergency calls. Secondly, the importance weight of buttons is dynamically calculated based on historical response results—the historical pressing duration sequence of each button is integrated and analyzed with the response level data of the corresponding event, increasing the weight of buttons that are frequently associated with real health crises (such as high-position buttons), while decreasing the weight of buttons that are frequently associated with accidental touches, thereby automatically correcting the decision value of the buttons. Finally, the real-time button pressing duration is combined with dynamic weights to calculate the regional urgency, and a graded response strategy is generated based on the urgency. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0018] Figure 1 This is a partial flowchart of one embodiment of the emergency alarm data processing method for smart public toilets according to the present invention;

[0019] Figure 2 This is a schematic diagram of another part of the process of the emergency alarm data processing method for smart public toilets according to one embodiment of the present invention;

[0020] Figure 3 This is a partial flowchart of one embodiment of the emergency alarm data processing method for smart public toilets according to the present invention.

[0021] Figure 4 This is a schematic diagram illustrating the steps of the emergency alarm data processing method for smart public toilets according to the present invention;

[0022] Figure 5 This is a schematic diagram of part of step S3 in the emergency alarm data processing method for smart public toilets of the present invention;

[0023] Figure 6 This is a schematic diagram of a portion of step S4 in the emergency alarm data processing method for smart public toilets of the present invention;

[0024] Figure 7 This is a schematic diagram of a portion of step S43 in the emergency alarm data processing method for smart public toilets of the present invention;

[0025] Figure 8 This is a schematic diagram of a portion of step S431 in the emergency alarm data processing method for smart public toilets of the present invention;

[0026] Figure 9 This is a schematic diagram of another part of step S4 in the emergency alarm data processing method for smart public toilets of the present invention;

[0027] Figure 10 This is a block diagram illustrating an electronic device according to an embodiment of the present invention.

[0028] Figure label:

[0029] 700 - Electronic device; 701 - Processor; 702 - Memory; 703 - Multimedia component; 704 - I / O interface; 705 - Communication component. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0031] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0032] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0033] like Figures 1 to 4 As shown, a method for processing emergency alarm data for smart public toilets is provided. In one embodiment, the method includes:

[0034] S1. Obtain the target area located inside the public toilet, and set up multiple emergency alarm buttons in different locations on the target area, and obtain the historical button status data and response result data of the target area;

[0035] S2. Obtain the historical button status data corresponding to the first n response results at the current moment, and obtain the press duration data sequence of each help alarm button in the target area based on the historical button status data corresponding to the first n response results.

[0036] S3. Obtain the corresponding response level data based on the n response results at the current moment;

[0037] S4. Obtain the importance weight of each help alarm button based on the response level data corresponding to the first n response results and the press duration data sequence of each help alarm button, and obtain the help alarm response strategy based on the importance weight of each help alarm button and the current button status data.

[0038] In this embodiment, it should be noted that in S1, a structured historical and current observation foundation is established for subsequent analysis to address the shortcomings of existing solutions in false alarm filtering, event differentiation, and dynamic adjustment. This step first clearly defines the basic unit of operation—namely, individual "target areas" located within the public restroom. These are typically independently operating cubicles (each cubicle constitutes a target area, and a public restroom may have multiple), emphasizing information processing at the scale of local space to ensure the regional focus of the analysis and the clarity of event attribution. Within each such target area, key physical interaction points are deployed: multiple emergency alarm buttons located at different physical locations within the area (at least three are set, for example, one at a lower, easily accessible location, one at a medium height, and one at a higher location requiring active hand-raising). These buttons not only have an identification and guidance function, but their combination is also preset to carry information on the degree of urgency (e.g., pressing multiple buttons simultaneously may indicate a more serious situation).

[0039] More importantly, the S1 step establishes a continuously accumulating database with event backtracking capabilities. S1 captures and stores two types of historical data: first, historical button state data for each button, the core information of which is the actual duration for which the button was pressed each time an event occurred (e.g., not being pressed is recorded as 0 seconds, and being pressed for 10 seconds is recorded as 10 seconds), accurately depicting the physical intensity and time investment of the user or environment in the button's action; second, historical response result data that is strictly correlated with it, which records the actual root cause of the problem ultimately confirmed based on each help alarm event, providing an authoritative annotation of the true meaning behind the button pressing behavior, and categorizing it into "accidental touch / intentional pressing by a child", "internal device malfunction", "personal health problems (such as fainting due to illness)" or "other undetermined problems".

[0040] Furthermore, the press duration data of buttons at different physical locations within the same target area (e.g., low-lying buttons prone to accidental touches and high-lying buttons difficult to touch) are strictly separated and stored separately, and each is matched with the finally confirmed event category label (accidental touch, malfunction, illness, etc.). This provides a basis for subsequent steps to identify the correlation between button location characteristics and event authenticity. For example, the press duration records of low-lying buttons that frequently appear in accidental touch events and the records of high-lying buttons that only appear in real health crisis events form a natural contrast in the database, providing raw material for learning "which button presses are more likely to indicate a real emergency." At the same time, the detailed record of press duration, rather than a simple binary state of "pressed or not pressed," contains potential information about the user's operation state (short touches and long presses are different scenarios), which plays a crucial role in understanding behavioral intent and distinguishing between accidental operations (such as short touches) and real difficulties (such as continuous pressing).

[0041] In S2, a "time window" or "sample size" for analysis is first determined—that is, the n most recent emergency alarm events before the current moment whose final response results have been confirmed (n is a configurable value representing the range of historical data to be considered). Next, instead of simply obtaining the status of all buttons at these n time points, it traces back the historical states that strictly correspond to these events based on the final response result type of these n events (e.g., all are "equipment malfunction," or all are "personnel illness," etc.).

[0042] For each specific emergency alarm button within the target area (e.g., button A installed at a low position of 1 meter inside the compartment, or button B installed at a high position of 1.5 meters), S2 specifically extracts the button press duration records at the time of the aforementioned n specific response result events. For example, assuming that the selected n events are all judged as "equipment malfunction," then for button A, it finds out how long button A was pressed during each of these n equipment malfunction events (the record may be not pressed, pressed briefly, or pressed for a long time). In this way, for each button, a set of duration sequences with a fixed length of n is compiled, where each data point clearly corresponds to a specific type of event (such as equipment malfunction) and the duration of that button's behavior.

[0043] Furthermore, S2 closely correlates the physical location of the button (implied in the button label) with its pressing behavior patterns in categorized, clearly defined events, enabling subsequent steps to quantify the strength or reliability of a button's indication for a specific type of event at a particular location. For example, by extracting the pressing duration sequence of a button mounted low in the past n "accidental touch / child's deliberate" events, it can be observed whether it is frequently triggered briefly or for extended periods (reflecting its susceptibility to interference).

[0044] Similarly, by extracting the press duration sequence of the same button in the past n "personnel illness" events, we can observe its participation pattern in real crises (whether it is triggered and for how long). This button behavior sequence constructed for similar events clearly isolates the confusing influence of different event natures on button behavior (e.g., avoiding conflating the behavior of buttons in accidental touch events with their behavior in real crises), providing a clean and clear historical evidence basis with both physical (location) and behavioral (duration pattern under similar events) meaning for the subsequent calculation of the importance weight (S4) of each button.

[0045] In S3, these different types of events are assigned numerical signals with directional and intensity indications, namely response level data. The purpose is to transform abstract event categories (such as being judged as accidental touches) into specific numerical values ​​that can quantify the impact of the event on the subsequent evaluation of the button's reliability and urgency. This value carries the essential attributes of the event (such as whether it is a distraction or a genuine request for help) as well as its corresponding priority and credibility adjustment direction.

[0046] First, S3 defines a standard level data, which serves as the baseline unit for calculating the impact of different event levels. Next, this step calculates the corresponding response level data based on a fixed mapping rule for the root cause of each confirmed event in the historical response results data: if the event is ultimately determined to be unintentionally triggered (e.g., accidental touch by a user or deliberate pressing by a child), the base standard level data is multiplied by a negative coefficient (e.g., -1) to determine the response level data; if the event is determined to be a device malfunction, the base standard level data is multiplied by a positive coefficient (e.g., 1) to determine the response level data; if the event is determined to be an emergency crisis involving user health and safety (e.g., sudden illness and fainting), the base standard level data is multiplied by a larger positive coefficient (e.g., 2) to determine the response level data. In this way, by introducing positive and negative signs and multiples of different sizes, the adjustment direction (whether to enhance or weaken the weight of the button) and the relative strength of the adjustment (whether to affect the weight by a small, medium or large margin) are clearly expressed when different event types affect the importance of the learning button.

[0047] Furthermore, negative ratings (for accidental / intentional touches by children): These aim to lower the importance of buttons frequently associated with non-emergency events (especially accidental touches), particularly those positioned low (e.g., at 1 meter) and easily interfered with. When subsequent analysis finds that a button frequently appears in the historical sequence of these low-confidence events, its response rating data will be negative, causing the historical press data associated with that button to make a negative contribution in subsequent calculations, ultimately lowering its importance weight.

[0048] Positive rating (for equipment failure): Indicates a neutral event requiring a response, with a relatively moderate adjustment in importance weight. It can distinguish genuine equipment problems and avoid confusion with health crises.

[0049] Larger positive value rating (for health crises): This rating aims to significantly increase the weight of buttons that demonstrate importance in high-belief events (such as real health crises), especially those positioned high (e.g., 1.5 meters), less prone to accidental triggering, and more likely to reflect the true intent when triggered. When a button is frequently or for extended periods in the history of real emergency events, its response rating data will have a large positive value. This will cause these historical press data to make a significant positive contribution to subsequent calculations, thereby greatly increasing the importance weight of that button.

[0050] Therefore, the response level data sequence output by S3 (each group of n events corresponds to a group of n level data) is essentially a value label attached to each group of button historical press duration sequences extracted by event type in S2: it tells how much intensity (multiple) and in which direction (positive or negative) the pull should be applied to these data when processing this group of historical data, so that the credibility ranking and weight dynamic adjustment of buttons in different positions and different behavior patterns can be effectively performed based on historical experience (serving S4).

[0051] In S4, based on the input information from S3, the importance weight of each emergency call button within the target area relative to the current assessment point in time is calculated. This process is dynamic and based on historical experience, aiming to quantify the reliability and decision-making value of buttons in different locations and under different behaviors when indicating real emergency situations.

[0052] The specific implementation path is as follows: For each specific emergency call button within the target area (such as the button at a low height of 1 meter or a high height of 1.5 meters discussed earlier), the historical press duration value obtained in step S2 (this sequence is associated with n events of a specific type) is multiplied sequentially by the response level data determined for each of these n events in step S3. This is equivalent to weighting the impact of each past button press according to the final nature and severity of the event to which that press belongs—for example, a prolonged press during a genuine health crisis (high positive level) will receive a large positive contribution value, while a press during a false trigger (negative level) will receive a negative contribution value.

[0053] Next, for the same button, the weighted impact contribution values ​​of all its presses are summed to obtain a total representing the button's accumulated "value" or "strength of credible evidence" over the last n historical events. Then, by comprehensively comparing this sum with the sums calculated for all other buttons (e.g., by performing standardized ratio calculations to ensure that the sum of the weights of all buttons meets certain conditions), this relative ratio value calculated for each button is finally determined as the importance weight of that button at the current moment.

[0054] Essentially, this weight reflects the degree to which the button's triggering behavior (duration record) is associated with high-confidence, high-urgency events (positive-level events) or low-confidence events (negative-level events) in historical experience. Buttons positioned higher and less prone to accidental touches will have their weight gradually increased if their pressing behavior is more frequently associated with genuine emergency events; conversely, buttons positioned lower and more easily accidental touches will have their weight decreased due to frequent association with accidental touch events.

[0055] Furthermore, S4 ultimately combines the dynamically calculated importance weights of each button with the actual button status currently occurring in the target area to accurately assess the urgency and formulate corresponding response strategies. To this end, this step first obtains the actual press duration of all buttons in the target area within the current time period (e.g., starting from when any button is pressed, recording the status of all buttons within a certain time period; zero if not pressed, and the duration of each press is recorded). Then, instead of simply summing the press durations of all buttons or relying solely on certain fixed rules as in existing technologies, it multiplies the current real-time press duration of each button by its importance weight, which reflects its historical credibility and value and was just calculated in the first half of step S4.

[0056] For example, a button that is positioned high, is less likely to be accidentally pressed, and has a history of being reliably triggered in real emergencies (it will be given a higher weight), will have its contribution amplified even if it is pressed for a shorter time; conversely, a button that is positioned low and has a history of being frequently associated with accidental press events (its weight will be reduced), will have its contribution suppressed even if it is pressed for a longer time.

[0057] Next, the weighted press duration contributions of all buttons within the target area are summed to obtain a value representing the overall urgency of the entire area. This urgency value integrates real-time user behavior information (which buttons were pressed for how long) and the credibility information of each button learned from historical experience (reflected through weights).

[0058] Finally, based on the calculated urgency level, and referring to preset rules or threshold ranges, the appropriate response strategy is determined. For example, a very low urgency level might only trigger a minor local alert or no response; a slightly higher level might trigger a remote monitoring system; a higher level might trigger equipment inspection and maintenance; and an extremely high level might immediately trigger emergency medical assistance and the highest priority warning. In this way, the final response strategy is no longer a rigid "press N seconds and dispatch an ambulance" approach, but rather a tiered action matched to the actual risk, based on a comprehensive assessment of the current specific context and the button's historical reliability information. This effectively avoids wasting resources on invalid alarms and ensures a rapid and accurate response when a real crisis occurs.

[0059] In summary, the data processing method for emergency alarms in smart public restrooms firstly distinguishes between events of different natures by introducing response level data and combining it with button location characteristics, avoiding the misinterpretation of accidental presses of low-positioned buttons as genuine emergency calls. Secondly, it dynamically calculates button importance weights based on historical response results—by fusing and analyzing the historical press duration sequence of each button with the response level data of the corresponding event, the weight of buttons frequently associated with real health crises (such as high-positioned buttons) is increased, while the weight of buttons frequently associated with accidental presses is decreased, thus automatically adjusting the decision value of the buttons. Finally, it combines real-time button press duration with dynamic weights to calculate the urgency of the area, generating a tiered response strategy based on the urgency level. In conclusion, this method filters invalid signals based on location characteristics and dynamically adjusts evaluation criteria based on historical behavior, reducing false alarm interference while ensuring that high-priority events such as health crises receive a matching rapid response, ultimately reducing the risk of resource misallocation and improving the overall effectiveness of the alarm system.

[0060] like Figure 5 As shown, in one implementation, S3, obtaining the corresponding response level data based on the n response results at the current time includes:

[0061] S31. Obtain standard grade data;

[0062] S32. When the response result data is determined to be an unintentionally triggered event, -1 times the standard level data will be used as the response level data corresponding to the response result data.

[0063] S33. When the response result data is determined to be a device failure event, the standard level data will be used as the response level data corresponding to the response result data.

[0064] S34. When the response result data is determined to be a health crisis event, twice the standard level data shall be used as the response level data corresponding to the response result data.

[0065] In this embodiment, it should be noted that in S31, a benchmark reference system for quantifying event levels is established. A universal numerical scale is preset as the reference origin for classifying various types of events. This standard level data is not associated with specific event types, but only serves as a unified benchmark unit for subsequent calculation of response level data. Specifically, when taking values ​​for the standard level data, the initial value can be set to 0.5 (an empirical value) to ensure that the numerical difference between different event levels reasonably reflects the actual priority difference. Then, it is dynamically adjusted based on the historical false alarm rate. If the historical false alarm rate is >30%, the standard level data is increased to twice, i.e., 1.

[0066] In S32, when historical response results are confirmed to be unintentional triggers (such as accidental touches or unintentional touches by children), S32 employs a negative multiplier conversion mechanism. Multiplying the standard rating data by -1 essentially marks such events as confidence-degrading events. For example, when a low-positioned button installed at 1 meter frequently triggers such events, the resulting negative rating data will be attached to the button's historical behavior record like a warning label. This processing intuitively reflects physical characteristics—low-positioned buttons are more easily touched unintentionally, requiring proactive suppression of their decision-making influence.

[0067] In S33, a 1:1 mapping principle is used to assign standard level values. These events must maintain a neutral characteristic: neither completely invalid false alarms (hence not negative values) nor possess the urgency of a health crisis (hence not doubled). For example, when a button frequently generates error signals due to poor contact, its corresponding level value accurately reflects the characteristic of "requiring maintenance but not an emergency response." This process ensures that equipment malfunctions are not erroneously escalated, thus congesting medical resources, nor that necessary maintenance reminders are overlooked due to excessively low levels. Especially in areas with dense button usage, this level effectively distinguishes between genuine user requests for assistance and equipment malfunctions.

[0068] In S34, a 2x multiplier mechanism marks health crises as the highest priority events. This exponential increase stems from the special nature of such events: first, they pose a real risk to personal safety; second, their frequency of occurrence is usually far lower than accidental touch events. For example, if a button at a height of 1.5 meters is repeatedly pressed during a real fainting incident, the double priority value will increase the button's influence in future assessments. Simultaneously, this mechanism automatically creates a location-filtering effect—buttons at heights are less likely to be accidentally touched, making it easier to accumulate high-priority records. It is important to emphasize that the 2x multiplier is a balanced value validated in real-world scenarios: it ensures priority response to critical events while avoiding oversensitivity that could lead to escalation of misjudgments.

[0069] like Figure 6 As shown, in one implementation, the importance weight of each help / alarm button in S4, based on the response level data corresponding to the first n response results and the press duration data sequence of each help / alarm button, includes:

[0070] S41. Multiply each data point in the press duration data sequence of the i-th emergency alarm button in the target area by the response level data corresponding to the previous n response results data, and obtain the product sequence of the i-th emergency alarm button in the target area.

[0071] S42. Add up all the data in the product sequence of the i-th emergency alarm button in the target area and get the total product of the i-th emergency alarm button in the target area;

[0072] S43. Obtain the importance weight of each emergency call button in the target area based on the sum of the products of each emergency call button in the target area.

[0073] In this embodiment, it should be noted that in S41, for each button within the target area, its historical press duration sequence (e.g., [0s, 5s, 7s]) is time-aligned with the corresponding response level data (e.g., [-1, 0.5, 2]). This operation is equivalent to re-examining the past behavior of each button using an "event value lens": a button that is only pressed for 3 seconds during a health crisis will receive a positive contribution of 6 units after a 2x weighting; while the same button that is pressed for 10 seconds during a mis-touch event will become a negative contribution of -10 units after a -1x weighting.

[0074] In S42, the sum of all elements of the product sequence generated in S41 yields a single value representing the button's overall performance score across n historical events. For example, buttons frequently associated with negative-level events may have a negative sum, reflecting low reliability of their historical records; while buttons strongly associated with health crises will receive a significantly positive value. It is important to note that this sum has a time decay characteristic—only the most recent n events are calculated to ensure continuously updated understanding.

[0075] In S43, the value to be processed is first set based on the sum of the products (a basic protection mechanism is used to prevent the weight from dropping to zero when the value is negative). Then, the total value of all buttons in the area is calculated, and finally, the weight is allocated through proportional conversion. For example, in a scenario with three buttons, even if a low-positioned button has a negative total due to accidental touch, its weight will still retain its basic proportion; while a high-positioned button may gain more than 40% weight through continuous positive accumulation. This design ensures that: the weight distribution range is stable between [0,1]; the total weight is constant at 1; and all buttons have decision-making participation. In particular, the setting of the basic value reserves the minimum voice for buttons that are prone to accidental touch, avoiding the complete neglect of operation signals in certain areas.

[0076] like Figure 7 As shown, in one embodiment, obtaining the importance weight of each emergency call button in the target area based on the sum of the products of all emergency call buttons in the target area in step S43 includes:

[0077] S431. Obtain the pending values ​​of each emergency alarm button in the target area based on the sum of the products of each emergency alarm button in the target area.

[0078] S432. Add up the pending values ​​of all emergency call buttons in the target area and obtain the total comparison value;

[0079] S433. Divide the pending values ​​of each help alarm button in the target area by the total comparison to obtain the proportion of each help alarm button in the target area, and use the proportion of each help alarm button in the target area as the importance weight of each help alarm button in the target area.

[0080] In this embodiment, it should be noted that in S431, this step is a key preprocessing step before weight allocation. It is responsible for converting the sum of the buttons into a value to be processed that can be used for weight allocation. Its core design is to solve the hidden danger of weight failure when the historical behavior score may be negative.

[0081] When the sum of the products of a button (from S42) is negative (indicating that the button has frequently been associated with low-belief behaviors in historical events), directly using it for weight calculation would cause a logical contradiction—for example, negative values ​​cannot participate in proportional allocation. A basic protection mechanism is established here: a non-negative baseline value is preset as the weight floor for all buttons. The specific operation involves two paths: if the sum of the products of a button is non-negative, the preset baseline value is directly added to the sum to form its pending value, allowing high-performing buttons to receive higher values; if the sum of the products is negative, the preset baseline value is directly used as the pending value, preventing negative values ​​from disrupting the rationality of the weighting system. For example, a button installed at a low height of 1 meter that is prone to accidental touches may accumulate a negative sum due to multiple accidental touches, but through this mechanism, its pending value at least retains the baseline value, neither gaining negative weight nor completely losing decision-making power, but only being reduced in weight.

[0082] In S432, the denominator benchmark for weight allocation is established by summing the pending values ​​of all buttons within the area. The pending values ​​of all buttons after processing in S431 (all non-negative numbers) are accumulated one by one to obtain an overall scale representing the comprehensive performance of components within the area—the total comparison value. This value essentially constitutes the capacity of the weight pool: the weight of each subsequent button is the proportion of its pending value to this total. For example, in a compartment containing three buttons (high, low), if the high-position button receives a higher pending value due to its higher reliability, while the low-position button only retains the benchmark value due to its negative history, the total value formed by adding the three values ​​directly determines the final weight allocation range.

[0083] It should be noted that this step mandates that all buttons participate in the accumulation (without any exclusion mechanism) to ensure that the weighting system fully covers all components within the area. The dynamic nature of the total calculation enables automatic adaptation to different configuration areas—when some buttons are replaced after maintenance in a certain compartment, the initial baseline value of the new buttons will be included in the total calculation.

[0084] In S433, abstract numerical values ​​are mapped to specific weight allocation strategies, and normalized weight transformation is performed. This involves dividing the pending value for each button (from S431) by the total comparison (from S432), and the result is the importance weight of that button (a decimal between 0 and 1, and the sum of all button weights is always 1). This proportional allocation mechanism ensures that high-ranking buttons may receive a weight of 0.7 because their pending values ​​account for 70% of the total, indicating their decision-making dominance; it also ensures that the sum of all button weights is 1, avoiding weight overflow or imbalance.

[0085] For example, if a low-position button is frequently accidentally pressed, resulting in only 20% of the total pending values, its final weight is 0.2; while a historically reliable high-position button, contributing 50% of the values, receives a weight of 0.5, thus widening the gap in decision-making influence.

[0086] like Figure 8 As shown, in one embodiment, obtaining the unprocessed value of each emergency alarm button in the target area based on the sum of the products of each emergency alarm button in the target area in S431 includes:

[0087] S431a. If the sum of the products of the i-th emergency call buttons in the target area is greater than or equal to zero, then add the preset base value to the sum of the products of the i-th emergency call buttons to obtain the value to be processed for the i-th emergency call button.

[0088] S431b If the sum of the products of the i-th emergency call buttons in the target area is less than zero, then the preset base value is used as the value to be processed for the i-th emergency call button.

[0089] In this embodiment, it should be noted that in S431a, when the sum of the products of a certain button is greater than or equal to zero (indicating that the button has not had a negative impact or has made a positive contribution in historical events), a gain strategy is adopted: a preset base value is added to the sum of their products to obtain the value to be processed. The preset base value is chosen to ensure that even buttons that are frequently accidentally touched have a weight of no less than 1 / (total number of buttons in the area × k), where k is a redundancy coefficient (usually 2~3). For example, when there are 3 buttons in the area, the preset base value should ensure that the minimum weight is ≥0.11 (i.e., 1 / (3×3)).

[0090] This stacking operation prevents weights from dropping to zero. Even if a high-ranking button has a mediocre historical performance (the sum is close to zero), it can still obtain the baseline weight after stacking. It also enables positive accumulation, allowing buttons with significantly positive sums to further amplify their advantages through the stacking mechanism. Furthermore, it enables the construction of gradient differences. For example, if two buttons have sums of 5 and 10 respectively (assuming the base value is 5), the values ​​to be processed become 10 and 15, and the weight difference increases from 2 times to 3 times.

[0091] In S431b, when the sum of the products of a button is detected to be less than zero, the negative data is discarded directly, and the value to be processed for that button is reset to a preset base value. This processing can eliminate negative value interference, preventing negative values ​​from offsetting the positive contributions of other buttons during the summarization stage; it can also maintain basic participation, ensuring that buttons with high false-touch rates do not completely lose their influence (preserving basic weight), and preventing the omission of real alarms due to complete signal blocking. Essentially, this mechanism uses technical truncation to compress the decision-making influence of frequently falsely touched buttons to a minimum feasible range, while preserving their functional integrity as basic sensors.

[0092] like Figure 9 As shown, in one implementation, the strategy for obtaining the help / alarm response based on the importance weight of each help / alarm button and the current button status data in S4 includes:

[0093] S44. Obtain the real-time pressed duration of each emergency alarm button within the target area;

[0094] S45. Multiply the real-time pressing duration of each emergency call button in the target area by the importance weight of each emergency call button to obtain the urgency level of the target area.

[0095] S46. Obtain the emergency alarm response strategy based on the urgency of the target area.

[0096] In this embodiment, it should be noted that in S44, when an alarm is triggered in the target area, the instantaneous state and duration of all buttons are captured. For example, in a squatting cubicle, a button at 1 meter is pressed for 3 seconds, one at 1.5 meters is not triggered, and one at 1.3 meters is briefly touched for 1 second. Unlike existing methods that only record the state of a single button, this step requires acquiring all button data simultaneously—regardless of whether they are pressed (not pressed is recorded as 0 seconds). This comprehensive monitoring avoids missing compound events: for example, a user might accidentally press a lower button first, and then trigger a higher, valid button.

[0097] In S45, the real-time press duration of each button is multiplied by its dynamic weight. For example, a button pressed for 5 seconds at a height of 1.5 meters (weight 0.6) generates 3 units of urgency, while a button pressed for 8 seconds at a height of 1 meter (weight 0.2) only contributes 1.6 units. The sum of the contributions from all buttons forms the overall urgency assessment value for the target area.

[0098] In S46, abstract urgency levels are mapped to specific action plans. Multi-level response thresholds are preset: for example, urgency < 5 requires only a light alert; 5-15 requires administrator verification; 15-30 requires equipment maintenance; > 30 requires immediate medical assistance. In a typical scenario, when a high-level button is repeatedly pressed by a vulnerable group, the weighted urgency level will quickly exceed the medical response threshold; while when multiple low-level buttons are accidentally pressed, the weighted suppression may only trigger the lowest level alert. Threshold range settings may consider the statistical distribution of historical event response resource consumption, but most importantly, they create a non-linear response—for every 10-unit increase in urgency, the response intensity may increase by two levels. This design ensures that resource allocation is always proportional to the actual risk.

[0099] A help alarm data processing system for smart public toilets is also provided. This system implements the aforementioned help alarm data processing method for smart public toilets. The system includes:

[0100] The first data acquisition module is used to acquire the target area located inside the public toilet, and to acquire the historical button status data and response result data of the target area, which has multiple emergency alarm buttons located in different positions.

[0101] The second data acquisition module is used to acquire the historical button status data corresponding to the first n response results at the current moment, and to acquire the press duration data sequence of each help alarm button in the target area based on the historical button status data corresponding to the first n response results.

[0102] The first data processing module is used to obtain the corresponding response level data based on the n response results data at the current moment;

[0103] The second data processing module is used to obtain the importance weight of each help alarm button based on the response level data corresponding to the first n response results and the press duration data sequence of each help alarm button, and to obtain the help alarm response strategy based on the importance weight of each help alarm button and the current button status data.

[0104] In one embodiment, the second data processing module is further configured to: obtain the real-time pressing duration of each help alarm button in the target area; multiply the real-time pressing duration of each help alarm button in the target area by the importance weight of each help alarm button to obtain the urgency of the target area; and obtain a help alarm response strategy based on the urgency of the target area.

[0105] In this embodiment, it should be noted that the specific method of performing the above-mentioned emergency alarm data processing system for smart public toilets has been described in detail in the embodiments of the emergency alarm data processing method for smart public toilets, and will not be elaborated here.

[0106] Figure 10 This is a block diagram of an electronic device for processing emergency alarm data in a smart public toilet, according to an exemplary embodiment. Figure 10 As shown, the electronic device 700 may include: a processor 701 and a memory 702. The electronic device 700 may also include one or more of a multimedia component 703, an I / O interface 704 (input / output interface), and a communication component 705.

[0107] The processor 701 controls the overall operation of the electronic device 700 to complete all or part of the steps in the above-described method for processing emergency alarm data in a smart public toilet. The memory 702 stores various types of data to support the operation of the electronic device 700. This data may include, for example, instructions for any application or method operating on the electronic device 700, and application-related data such as contact data, sent and received messages, images, audio, video, etc. The memory 702 can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 702 or transmitted via communication component 705. The audio component also includes at least one speaker for outputting audio signals. I / O interface 704 provides an interface between processor 701 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 705 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0108] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method for processing emergency alarm data for smart public toilets.

[0109] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, these program instructions implement the steps of the above-described method for processing emergency alarm data for a smart public toilet. For example, the computer-readable storage medium may be the memory 702 including the program instructions, which may be executed by the processor 701 of the electronic device 700 to complete the above-described method for processing emergency alarm data for a smart public toilet.

[0110] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the above-described method for processing emergency alarm data for smart public toilets when executed by the programmable device.

[0111] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0112] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0113] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

[0114] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A help alarm data processing method for an intelligent public toilet, characterized in that, The method comprises the following steps: acquiring a target area located in a public toilet, and setting a plurality of help-seeking alarm buttons at different positions on the target area, and acquiring historical button state data and response result data of the target area; acquiring historical button state data corresponding to n response result data before the current time, and acquiring a press duration data sequence of each help-seeking alarm button in the target area according to the historical button state data corresponding to the n response result data; acquiring corresponding response level data according to the n response result data before the current time, comprising: acquiring standard level data; when the response result data is determined to be a non-intentional triggering event, taking -1 times the standard level data as the response level data corresponding to the response result data; when the response result data is determined to be a device failure event, taking 1 times the standard level data as the response level data corresponding to the response result data; when the response result data is determined to be a health crisis event, taking 2 times the standard level data as the response level data corresponding to the response result data; acquiring importance weights of each help-seeking alarm button according to the response level data corresponding to the n response result data and the press duration data sequence of each help-seeking alarm button, and acquiring a help-seeking alarm response strategy based on the importance weights of each help-seeking alarm button and the current button state data.

2. The help alarm data processing method for intelligent public toilets according to claim 1, characterized in that, The method of acquiring the importance weights of each help-seeking alarm button according to the response level data corresponding to the n response result data and the press duration data sequence of each help-seeking alarm button comprises: multiplying each data in the press duration data sequence of the i th help-seeking alarm button in the target area by the response level data corresponding to the n response result data in turn, and obtaining a product sequence of the i th help-seeking alarm button in the target area; adding all data in the product sequence of the i th help-seeking alarm button in the target area to obtain a product sum of the i th help-seeking alarm button in the target area; acquiring the importance weights of each help-seeking alarm button in the target area according to the product sums of each help-seeking alarm button in the target area. 3.The method for processing data of a help alarm in a smart public toilet according to claim 2, wherein, The method of acquiring the importance weights of each help-seeking alarm button in the target area according to the product sums of each help-seeking alarm button in the target area comprises: acquiring a to-be-processed value of each help-seeking alarm button in the target area according to the product sums of each help-seeking alarm button in the target area; adding the to-be-processed values of all help-seeking alarm buttons in the target area to obtain a comparison total amount; dividing the to-be-processed values of each help-seeking alarm button in the target area by the comparison total amount to obtain a proportion amount of each help-seeking alarm button in the target area, and taking the proportion amount of each help-seeking alarm button in the target area as the importance weight of each help-seeking alarm button in the target area.

4. The help alarm data processing method for the intelligent public toilet according to claim 3, characterized in that, The method of acquiring the to-be-processed value of each help-seeking alarm button in the target area according to the product sum of each help-seeking alarm button in the target area comprises: if the product sum of the i th help-seeking alarm button in the target area is greater than or equal to zero, adding a preset basic value to the product sum of the i th help-seeking alarm button to obtain the to-be-processed value of the i th help-seeking alarm button. If the product sum of the ith help-alarm button in the target area is less than zero, a preset basic value is taken as the to-be-processed value of the ith help-alarm button. 5.The method for processing data of help alarm in intelligent public toilet according to claim 1, characterized in that, The help-alarm response strategy is acquired based on the importance weight of each help-alarm button and the current button state data. The real-time pressing time length of each help-alarm button in the target area is acquired. The real-time pressing time length of each help-alarm button in the target area is multiplied by the importance weight of each help-alarm button, and the emergency degree of the target area is obtained. The help-alarm response strategy is acquired according to the emergency degree of the target area.

6. A help alarm data processing system for an intelligent public toilet, characterized by, The system is used to implement the help-alarm data processing method for the intelligent public toilet according to any one of claims 1 to 5, and the system comprises: A first data acquisition module is configured to acquire a target area in a public toilet, set a plurality of help-alarm buttons at different positions on the target area, and acquire historical button state data and response result data of the target area. A second data acquisition module is configured to acquire historical button state data corresponding to the last n response result data at the current time, and acquire pressing time length data sequences of each help-alarm button in the target area according to the historical button state data corresponding to the last n response result data. A first data processing module is configured to acquire response level data according to the last n response result data. A second data processing module is configured to acquire importance weight of each help-alarm button according to the response level data corresponding to the last n response result data and the pressing time length data sequences of each help-alarm button, and acquire a help-alarm response strategy based on the importance weight of each help-alarm button and the current button state data.

7. The help alarm data processing system for intelligent public toilets according to claim 6, characterized in that, The second data processing module is further configured to: Acquire real-time pressing time length of each help-alarm button in the target area. Multiply the real-time pressing time length of each help-alarm button in the target area by the importance weight of each help-alarm button, and obtain the emergency degree of the target area. Acquire a help-alarm response strategy according to the emergency degree of the target area.

8. An electronic device, comprising: Comprise: A memory having a computer program stored thereon; A processor configured to execute the computer program in the memory to implement the help-alarm data processing method for the intelligent public toilet according to any one of claims 1 to 5.

9. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the help-alarm data processing method for the intelligent public toilet according to any one of claims 1 to 5.

Images