Multi-terminal collaborative household medication intelligent service method and device

Abstract

The invention discloses a multi-terminal collaborative household medication intelligent service method and equipment, and belongs to the technical field of household health management and intelligent man-machine interaction. In order to solve the problems that in the prior art, interaction for aging is insufficient, medicine taking reminding is unreliable, medicine taking behaviors cannot be audited, remote monitoring is asynchronous, and emergencies cannot be touched with high reliability, a system of cooperative operation of a terminal interaction layer, a cloud brain decision-making layer and a cooperative service layer is constructed. The terminal interaction layer realizes voice wake-up, voice interaction, local medication configuration management, regular reminding and emergency call; the cloud brain decision-making layer generates a structured control instruction by using semantic analysis and realizes reliable message distribution; the collaborative service layer is responsible for remote medication plan synchronization, automatic alarm of missed medication and emergency events and active inspection of the period of validity of medicines. The system is suitable for real-time reminding, behavior recording, remote collaboration and safety guarantee work of medication management of family old people.

Description

Technical Field

[0001] It involves smart health devices, IoT communication and voice interaction technologies, and in particular a multi-terminal collaborative medication management method for elderly users. Background Technology

[0002] With the aging population and the continuous expansion of the chronic disease patient group, long-term standardized medication in home settings has become a common need. To meet the basic medication management chain of "reminder-execution-confirmation-recording-collaboration," existing technologies have developed various solutions. Mobile apps are the most common reminder solution, configuring plans through a graphical interface and relying on local alarms or cloud-based scheduled tasks to push notifications to users. This method is widely used among younger users, but it has significant shortcomings in terms of age-friendliness: the interface is complex, the terminology is difficult to understand, and older users need a high learning curve to correctly set up medication plans; system power-saving strategies and do-not-disturb modes may suppress the display and sound of reminders, resulting in unstable reminders; after the notification is delivered, there is a lack of a verifiable closed loop, making it impossible to determine whether the user has actually picked up or taken the medication, and caregivers cannot obtain reliable feedback based on this.

[0003] Another type of technology is electronic medicine cabinets and timed reminder boxes, which help users manage medication through physical compartments and buzzer reminders. These devices have a simple structure and low cost, making them suitable for timed reminders for single or small amounts of medication. However, their functions are generally fixed and limited, only able to indicate simple medication times, making it difficult to support complex situations that frequently arise in actual medication use, such as dosage changes, postponements, or skipping. Furthermore, their interaction relies on buttons or small screens, resulting in unfriendly interfaces and frequent accidental touches. Most devices also lack the ability to synchronize data with remote monitoring devices, and they lack natural language understanding capabilities, making it impossible to provide personalized guidance and real-time responses based on user context. This makes it difficult for these devices to integrate into a complete family health management ecosystem.

[0004] Furthermore, while medical-grade, highly integrated dispensing devices offer comprehensive functions such as multi-channel drug storage, precise dispensing, dosage auditing, and log recording, they are primarily geared towards specialized institutions like hospitals and nursing homes. These devices are bulky, have demanding deployment requirements, and are expensive. Moreover, their interfaces are often closed, resulting in poor compatibility with home IoT ecosystems and a lack of age-friendly human-machine interaction modes, making large-scale deployment in homes difficult.

[0005] In terms of communication, data collaboration, and remote management, existing technologies typically rely on one-way reporting or simple polling mechanisms, failing to achieve real-time consistency in cross-device collaboration. Medication reminder systems also generally lack the ability to detect missed doses and automatically report them, making it impossible to form an auditable closed loop. In terms of emergency handling, various devices are often deeply coupled with the main program; once the main logic is blocked, they cannot respond to requests for help, and there is a lack of a multi-level message delivery system, making it difficult to deliver critical events to guardians in a timely manner.

[0006] In summary, existing technologies suffer from several drawbacks, including insufficient age-friendly interactive capabilities, a disconnect between medication reminders and monitoring, data asynchrony leading to a lack of collaboration, unauditable reminders, and the inability to reliably reach users during emergencies. Summary of the Invention

[0007] To address the shortcomings of existing technologies, such as insufficient age-friendly interactive capabilities, disconnect between medication reminders and monitoring, data asynchrony leading to lack of collaboration, unauditable reminders, and inability to reliably reach users in emergencies, the technical solution provided by this invention is as follows: A multi-terminal collaborative intelligent home medication service method includes: In the terminal interaction layer, initialize the audio input module, audio output module, voice wake-up detection module, voice interaction module, medication reminder module, MQTT subscription module and emergency call module and establish process coordination relationship, obtain the running environment for performing voice interaction and multimodal reminders and output the microphone status that can be read by the voice wake-up detection module. The wake-up event is obtained based on the continuous analysis results of the audio stream by the voice wake-up detection module, and the wake-up event is used as the recording trigger input of the voice interaction module, so that the voice interaction module takes over the audio input and outputs the text content obtained by speech recognition. Based on the text content output by the voice interaction module, semantic parsing is performed in the cloud brain decision layer to generate structured control instructions containing operation type, drug name, usage and dosage, and medication time. The structured control instructions are then used as input for updating the local medication configuration file and the corresponding medication records are output. The medication record generated based on the structured control instructions updates the local medication configuration file in the terminal interaction layer and uses the updated medication configuration file as the task construction input for the medication timed reminder module, thereby outputting the steps of the reminder task containing the drug name, usage and dosage and trigger time; When the reminder task is triggered, the drug name and dosage information are obtained and the audio output module and light output module are driven to perform voice reminders and light prompts. The reminder result is used as the input for medication confirmation detection and the steps of outputting medication confirmation record or missed dose record are completed. The steps involve writing the medication confirmation record or missed dose record into the cloud database in the collaborative service layer, and then having the event triggering program retrieve the new record, so that the new record can be used as the input for remote alarm triggering and output as alarm information sent to the monitoring terminal. Based on the structured change instructions generated by the remote operation of the medication plan in the collaborative service layer by the monitoring terminal, they are sent to the terminal interaction layer via MQTT. The structured change instructions serve as the input for updating the medication configuration file again and output new reminder tasks, thereby completing the remote synchronization step.

[0008] Furthermore, in a preferred embodiment, in the terminal interaction layer, the voice interaction module segments the text content obtained through speech recognition and generates segmented voice responses through a locally deployed speech synthesis model, so that the segmented voice responses serve as input for the user to continue interacting during playback.

[0009] Furthermore, in a preferred embodiment, in the terminal interaction layer, the medication timed reminder module performs real-time file monitoring of the local medication configuration file and automatically reloads the reminder task when the file content changes, so that the new reminder task serves as the input for triggering subsequent reminders.

[0010] Furthermore, in a preferred embodiment, in the terminal interaction layer, the emergency call module determines the interval of continuous pressing of the emergency call button and outputs an emergency event when the continuous pressing threshold is met, so that the emergency event is used as the priority input for the audio output module and the light output module.

[0011] Furthermore, in a preferred embodiment, in the collaborative service layer, a timed trigger program periodically scans the drug expiration date field stored in the cloud database and outputs drug near-expiration records based on the current server time, so that the drug near-expiration records can be used as input for triggering SMS notifications.

[0012] Furthermore, in a preferred embodiment, in the collaborative service layer, a timed trigger program periodically scans the drug expiration date field stored in the cloud database and outputs drug near-expiration records based on the current server time, so that the drug near-expiration records can be used as input for triggering SMS notifications.

[0013] Based on the same inventive concept, the present invention also provides a multi-terminal collaborative intelligent home medication service device, the device comprising: Audio input module, used to collect user voice signals; The audio output module is used to play prompt tones and voice replies; The voice wake-up detection module is used to identify wake-up words and trigger voice interaction; The voice interaction module is used to perform speech recognition, semantic parsing, and voice response. The medication reminder module is used to generate, trigger, and manage medication reminder tasks; The MQTT subscription module is used to receive remote instructions to change medication plans. The emergency call module is used to detect emergency button presses and execute high-priority alarms; The method is loaded into the central processing unit.

[0014] Based on the same inventive concept, the present invention also provides a computer storage medium for storing a computer program, wherein when the computer program is read by a computer, the computer executes the method described thereon.

[0015] Based on the same inventive concept, the present invention also provides a computer, including a processor and a storage medium, wherein when the processor reads a computer program stored in the storage medium, the computer executes the method described thereon.

[0016] Based on the same inventive concept, the present invention also provides a computer program product, which, when executed, implements the method described.

[0017] Compared with the prior art, the advantages of the technical solution provided by the present invention are as follows: The terminal interaction layer employs a locally deployed lightweight voice wake-up model and a local TTS model, enabling the device to still complete wake-up, recognition, and voice response even in weak network or no network environments, thus significantly improving the real-time performance and stability of voice interaction. Compared to existing smart voice reminder devices that rely on cloud models, and traditional APP solutions that become ineffective when completely offline, this feature avoids response delays and interaction interruptions caused by network fluctuations, allowing the elderly to obtain a sustainable interactive experience in a more accessible way.

[0018] The terminal adopts a modular architecture combining process decoupling and a process coordinator. It separates tasks such as voice interaction, scheduled reminders, MQTT synchronization, and emergency calls, and uses priority arbitration to achieve controllable scheduling of multi-task resources. This prevents resource contention and deadlocks when the system executes tasks such as voice conversations, light effects animations, recording, and scheduled reminders. Compared to the single-threaded or simple polling architecture of existing electronic medicine boxes, this solution's distributed process management significantly improves system stability and fault tolerance, ensuring uninterrupted reminders, conflict-free interactions, and preemptive emergency handling.

[0019] This solution employs a cloud-based large-scale model to perform deep semantic analysis of natural language and generate structured control commands. Users can freely express their opinions to perform operations such as setting, modifying, and deleting medications. The system can automatically understand and generate executable commands, significantly reducing configuration difficulty. Existing apps rely on graphical interfaces, which can lead to errors for elderly users when entering medication names, dosages, or times; electronic medicine cabinets are even more difficult to configure. In contrast, this solution directly generates standardized commands through natural language, greatly improving usability and interaction accuracy.

[0020] The local medication reminder module parses the Medicine file and, combined with a real-time thread loop and dynamic file monitoring mechanism, ensures that reminder tasks are refreshed and triggered accurately and instantly after plan modifications, guaranteeing the stability, timeliness, and accuracy of reminders. Existing mobile phone reminder solutions often experience delayed triggering due to system power-saving strategies, and traditional medicine cabinets rely on fixed time periods that are difficult to dynamically adjust. This solution, however, ensures that reminders are not affected by platform policies through a combination of local parsing and real-time monitoring.

[0021] The reminder trigger mechanism employs a multimodal output method, including voice broadcast, light strip animation, and button confirmation. It determines missed doses after a 120-second timeout and automatically notifies the guardian via an event trigger, forming a complete closed loop. Compared to traditional apps that cannot determine whether a user has actually taken their medication, and beeping medicine cabinets that lack confirmation logic, this mechanism enables auditable and traceable medication behavior management, allowing guardians to intervene promptly.

[0022] This solution employs a separate, high-priority emergency call process. A three-tap trigger algorithm distinguishes genuine calls for help and can forcibly interrupt the voice process, subsequently triggering dual-channel alarms via SMS and voice. This ensures that emergencies can still be addressed even in extreme circumstances. Existing devices typically integrate emergency functions with the main program; if the program is blocked, calls for help cannot be made. This solution significantly improves the reliability of emergency calls through process isolation and dual alarms.

[0023] Through a bidirectional messaging channel using MQTT over WebSocket, the mini-program can push structured instructions to the terminal in real time after modifying the medication plan. The terminal then updates its local files and reloads the scheduled task, achieving real-time consistency between the mini-program and the medicine cabinet. Compared to existing electronic medicine cabinets that generally lack remote collaboration or rely on polling methods leading to delays and desynchronization, this solution achieves true bidirectional real-time synchronization, providing a fundamental capability for multi-terminal collaboration in home medication use.

[0024] The collaborative service layer constructs a proactive service system through cloud-developed databases, event triggers, and timed functions. It can automatically handle missed doses, emergency calls, and near-expiration dates of medications, proactively sending SMS or voice reminders so that caregivers can obtain crucial information without constantly monitoring the interface. Compared to traditional solutions that rely on user checks or manual recording, this solution achieves automatic monitoring and outreach, making monitoring more timely and reliable.

[0025] Employing an embedded hardware architecture and multimodal interaction design (microphone, voice button, confirmation button, emergency button, and programmable LED light strip), this solution constructs an age-friendly, low-learning-cost user interface, allowing users to interact without needing to understand complex mobile phone interfaces. Compared to the visual dependence of apps and the small screen buttons of electronic medicine boxes, this solution achieves an interaction method truly suitable for elderly people with poor eyesight, limited operational skills, or unfamiliarity with smart devices.

[0026] It is suitable for real-time reminders, medication confirmation, remote monitoring, and emergency alarm coordination in family-based medication management for elderly people. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the overall system architecture; Figure 2 This is a diagram showing the hardware connections of the device. Figure 3 This is a diagram illustrating the triggering process for the reminder. Detailed Implementation

[0028] To make the advantages and benefits of the technical solution provided by the present invention clearer, the technical solution provided by the present invention will now be described in further detail with reference to the accompanying drawings, specifically: Implementation Method 1: This implementation method provides a multi-terminal collaborative intelligent home medication service method, including: In the terminal interaction layer, initialize the audio input module, audio output module, voice wake-up detection module, voice interaction module, medication reminder module, MQTT subscription module and emergency call module and establish process coordination relationship, obtain the running environment for performing voice interaction and multimodal reminders and output the microphone status that can be read by the voice wake-up detection module. The wake-up event is obtained based on the continuous analysis results of the audio stream by the voice wake-up detection module, and the wake-up event is used as the recording trigger input of the voice interaction module, so that the voice interaction module takes over the audio input and outputs the text content obtained by speech recognition. Based on the text content output by the voice interaction module, semantic parsing is performed in the cloud brain decision layer to generate structured control instructions containing operation type, drug name, usage and dosage, and medication time. The structured control instructions are then used as input for updating the local medication configuration file and the corresponding medication records are output. The medication record generated based on the structured control instructions updates the local medication configuration file in the terminal interaction layer and uses the updated medication configuration file as the task construction input for the medication timed reminder module, thereby outputting the steps of the reminder task containing the drug name, usage and dosage and trigger time; When the reminder task is triggered, the drug name and dosage information are obtained and the audio output module and light output module are driven to perform voice reminders and light prompts. The reminder result is used as the input for medication confirmation detection and the steps of outputting medication confirmation record or missed dose record are completed. The steps involve writing the medication confirmation record or missed dose record into the cloud database in the collaborative service layer, and then having the event triggering program retrieve the new record, so that the new record can be used as the input for remote alarm triggering and output as alarm information sent to the monitoring terminal. Based on the structured change instructions generated by the remote operation of the medication plan in the collaborative service layer by the monitoring terminal, they are sent to the terminal interaction layer via MQTT. The structured change instructions serve as the input for updating the medication configuration file again and output new reminder tasks, thereby completing the remote synchronization step.

[0029] In the terminal interaction layer, the voice interaction module segments the text content obtained through speech recognition and generates segmented voice responses through a locally deployed speech synthesis model, so that the segmented voice responses can serve as input for the user to continue interacting during playback.

[0030] In the terminal interaction layer, the medication timed reminder module monitors the local medication configuration file in real time and automatically reloads the reminder task when the file content changes, so that the new reminder task serves as the input for triggering subsequent reminders.

[0031] In the terminal interaction layer, the emergency call module determines the interval of continuous pressing of the emergency call button and outputs an emergency event when the continuous pressing threshold is met, so that the emergency event is given priority to the audio output module and the light output module to preempt input.

[0032] In the collaborative service layer, a timed trigger program periodically scans the drug expiration date field stored in the cloud database and outputs drug near-expiration records based on the current server time, so that the drug near-expiration records can be used as input for triggering SMS notifications.

[0033] In the collaborative service layer, a timed trigger program periodically scans the drug expiration date field stored in the cloud database and outputs drug near-expiration records based on the current server time, so that the drug near-expiration records can be used as input for triggering SMS notifications.

[0034] A multi-terminal collaborative smart home medication service device is also provided, the device comprising: Audio input module, used to collect user voice signals; The audio output module is used to play prompt tones and voice replies; The voice wake-up detection module is used to identify wake-up words and trigger voice interaction; The voice interaction module is used to perform speech recognition, semantic parsing, and voice response. The medication reminder module is used to generate, trigger, and manage medication reminder tasks; The MQTT subscription module is used to receive remote instructions to change medication plans. The emergency call module is used to detect emergency button presses and execute high-priority alarms; The method is loaded into the central processing unit.

[0035] A computer storage medium is also provided for storing a computer program, which, when read by the computer, executes the method.

[0036] A computer is also provided, including a processor and a storage medium, wherein the computer executes the method when the processor reads a computer program stored in the storage medium.

[0037] A computer program product is also provided, which, when executed, implements the method described.

[0038] Implementation Method Two: This implementation method is a further detailed description of the technical solution provided in Implementation Method One, specifically: This solution is designed for long-term, standardized medication use by elderly family users. It is based on a smart medicine box terminal with voice interaction and multimodal prompting capabilities, a cloud-based voice understanding and message distribution platform, and a remote collaboration mini-program for guardians. Through integrated hardware and software design, it forms a complete closed loop in actual use, from medication plan configuration, timed reminders, medication confirmation, missed dose reporting to emergency call alarms.

[0039] At the hardware level, this solution uses a Raspberry Pi 5 embedded development board as the main control unit. It connects to a microphone, speaker, physical buttons, tri-color LED indicators, and a WS2812 LED strip via its GPIO pins and USB interface. A UPS power bank and a voltage regulator expansion board are also included to ensure long-term stable power supply for the devices in a home environment. The USB driverless microphone continuously collects voice signals from the user's environment, while the USB driverless speaker outputs prompts and synthesized speech. The tri-color LEDs indicate the current microphone status and device operating status. The LED strip displays different animations for wake-up, reminders, and emergency alarms. The four GPIO buttons are defined as microphone control, voice interaction, medication confirmation, and emergency call buttons, allowing users to interact with the system through simple, low-barrier physical operations. Once the entire hardware setup is complete, it provides controllable input / output paths for subsequent software modules, enabling the software to read and write various device statuses through a unified GPIO and USB abstract interface. This hardware layer becomes the foundational input for the software initialization phase.

[0040] After the system powers on, the main manager module first takes over the operation control of the main control unit, completes the initialization of various hardware devices, and starts core and support modules such as voice wake-up detection, voice interaction, medication reminders, MQTT subscription, emergency call, LED management, and microphone status management. During startup, the main manager allocates an independent process or service to each module and establishes an inter-process communication mechanism to ensure that subsequent modules can exchange status information and control commands through a unified interface. The main manager writes the current system running status to a status file, allowing other modules to determine whether they can occupy audio devices or lighting resources. This overall status output by the main manager, indicating that "devices are ready and services are started," becomes the prerequisite input for the normal operation of subsequent processes such as voice wake-up, reminders, and emergency calls.

[0041] Once the system is running stably, the microphone device management module turns the microphone on or off based on the state of the microphone control keys, writing a flag indicating whether recording is currently allowed into a unified status file for the voice wake-up detection module to read. When the microphone is on, the voice wake-up detection module continuously acquires data from the audio input stream and analyzes the audio frames in real time using a locally deployed wake-up word detection model. Upon detecting a preset wake-up word, it immediately outputs a "wake-up successful" event. This wake-up event is forwarded by the process coordinator to the voice interaction module, simultaneously sending a command to the LED management service to switch the light strip to a "listening" animation effect, thus visually informing the user that the system is ready to receive voice commands. At this point, the wake-up event output by the voice wake-up detection module and the current user's voice audio stream become the input to the voice interaction module.

[0042] Upon receiving a wake-up event, the voice interaction module opens the audio input stream, resamples and caches the audio data collected from the microphone, and converts the audio content into text in real time via a cloud-based streaming speech recognition interface. During speech recognition, the module automatically determines the end of speech through voice activity detection and timeout detection, thus outputting a stable text content as the expression of the user's voice command. This text content, along with the device identifier and user context information, is sent to the semantic parsing module of the cloud brain decision layer, becoming the input data for the large language model to perform intent recognition and command generation.

[0043] Upon receiving a text request from the terminal, the semantic parsing module of the cloud brain decision layer guides the large language model to understand the text using pre-designed prompt word templates. It identifies whether the user wishes to set a new medication reminder, modify an existing reminder, delete a reminder, send a message to a guardian, or simply engage in general conversation. Depending on the intent, the model output includes both natural language responses and structured control instructions. The structured instructions contain key fields such as operation type, medication name, dosage, and administration time. These structured instructions, along with the natural language responses, are returned to the terminal interaction layer. The structured instructions are direct input to the medication plan management module and the timed reminder module, while the natural language responses are processed by the voice interaction module into one or more synthesized speech segments played to the user, indicating whether the current operation was successful or if additional information is needed.

[0044] When a structured instruction indicates that a user needs to add a medication reminder, the voice interaction module extracts the medication name, dosage, and administration time from the instruction and writes this information into a local medication configuration file. Each record corresponds to a specific medication, specific dosage information, and a specific administration time. Simultaneously, the same information is written to the reminder record set in the cloud database. Updates to local files are captured by the scheduled reminder module through the file monitoring module. Upon detecting changes to the file content, the file monitoring module notifies the scheduled reminder module to reload the medication plan. Therefore, the result of the structured instruction, i.e., the "new medication record," becomes the input to the task scheduling logic of the scheduled reminder module.

[0045] The timed reminder module re-parses the medication configuration file during initialization and each file change, calculates the most recent reminder trigger time for each record, and constructs an internal list of timed tasks. The module periodically checks the current system time and the trigger times of each reminder task via a background thread. When the trigger time of a task matches the current time, the module marks the task as needing execution, extracts the drug name, dosage, and serial number from the task as input for the reminder content, and passes this information to the LED management service and audio playback module, driving the device into medication reminder mode.

[0046] During medication reminder mode, the timed reminder module controls the LED strip to play specific reminder animations via the LED management service. Simultaneously, it uses a TTS (Text-to-Speech) model to convert text containing the medication name and dosage into speech, which is then broadcast through a speaker. At this stage, the reminder content containing medication information, the current reminder start time, and the status of the medication confirmation button for the current medication constitute the input for the user behavior collection logic. The timed reminder module repeatedly plays the reminder voice at fixed intervals within a specified reminder cycle, and polls the status of the medication confirmation button between each playback. If it detects that the user has pressed the medication confirmation button, it considers this action as "this medication has been taken," marks it as taken in the local record, and writes the corresponding medication record and timestamp to the cloud database for subsequent retrieval by the guardian. This medication record written to the database becomes the input data for displaying historical medication information on the remote monitoring interface.

[0047] If the medication confirmation button is not pressed within the preset reminder time window, the timed reminder module will classify this reminder as a missed dose event after the set waiting time has elapsed. It will then generate a missed dose record containing the medication name, the scheduled medication time, and the device identifier, and write this record to the corresponding missed dose set in the cloud database. Once this missed dose record is detected by a database trigger, a cloud function call is automatically triggered. The cloud function sends a text message explaining the missed dose to the guardian using the guardian's mobile phone number linked to the device. Other notification methods can also be used if necessary. Thus, the missed dose record, as input to the cloud function, is ultimately transformed into a reminder message pushed to the guardian's terminal, allowing the guardian to take subsequent intervention measures based on the missed dose situation.

[0048] In an emergency call scenario, a user requests help by rapidly pressing the emergency call button three times in quick succession. The emergency call module monitors the input signal of this button and judges the time interval between presses. When it detects that all three presses are within a set time threshold, it outputs an "emergency call triggered" event. This event is used by the module's internal logic to immediately update the emergency service status file, mark the system as an emergency, and send a signal to the voice interaction module, requesting the interruption of all current voice playback and recording operations. Simultaneously, it seizes control of the LED strip through the LED management service, switching to a high-priority emergency alarm animation. This emergency event is also encapsulated as a data record containing the trigger time and device identifier and written to the cloud database as an emergency call set. Similar to missed service events, the addition of a new record to this set triggers a cloud alarm function. After the cloud function finds the guardian's mobile phone number associated with the device, it sends an emergency SMS notification and initiates a phone call to the guardian through the integrated voice call interface, enabling the emergency event information to be transmitted in a dual-channel manner. The emergency event record thus becomes a direct input to the multimodal alarm process.

[0049] To enable guardians to remotely manage medication plans, this solution provides a WeChat mini-program-based front-end interface at the collaborative service layer. Guardians bind the device by scanning the QR code on the medicine cabinet and entering their mobile phone number. The binding information, including fields such as device identifier, guardian identifier, and guardian's mobile phone number, is written into a binding set in the cloud database. This binding record serves as the input basis for all subsequent remote commands and alarm messages. When a guardian adds, modifies, or deletes a medication plan in the mini-program interface, the mini-program backend encapsulates this operation into a structured command containing action type, record identifier, and timestamp. This command is then published to a dedicated topic corresponding to the device identifier via an MQTT over WebSocket connection with at least one delivery quality level. The MQTT subscription module on the terminal device subscribes to this topic. Upon receiving the command, it parses the action type and record identifier and uses this information to call the medication file management module to perform corresponding add, delete, or modify operations in the local medication configuration file. File changes are then detected by the timed reminder module, which recalculates the reminder task list, thus achieving a closed loop of "remote operation output as local reminder configuration input." Structured remote commands in the cloud thus become the direct input for local scheduled task overloading.

[0050] To strengthen the management of drug expiration dates, the collaborative service layer also utilizes a timed triggering mechanism of cloud functions to automatically scan the expiration date field of all drug records in the cloud database at a pre-arranged time each day. It compares the current date with the expiration date of each drug, generates a near-expiration list for drugs within the warning period, and uses this list as input for the SMS notification module to automatically send a reminder message to the guardian, reminding them that the drugs are about to expire or need to be replaced. Thus, the results of the timed cloud scan become the basis for proactive information delivery, transforming drug management from passive querying to proactive early warning.

[0051] Throughout the system, the LED management service, process coordinator, and audio device management module play a crucial role in cross-process resource scheduling. Whenever modules such as voice interaction, timed reminders, or emergency calls require the use of speaker or LED strip resources, they request resource allocation through the process coordinator and arbitrate according to preset priorities. For example, when the emergency call module is triggered, it will seize control of the LED strip with the highest priority and request a pause in the current voice dialogue and reminder animation, allowing the user to perceive the emergency situation visually and audibly immediately. When a medication reminder is in progress, the voice interaction module needs to check the reminder status upon receiving a user call. If the reminder is active at this time, it needs to temporarily avoid or interrupt the dialogue to prevent the user from being disturbed by multiple sounds. This resource coordination result, carried by status files and inter-process signals, becomes the logical input for whether each interaction module can continue to work, thus ensuring the system can still operate stably in complex, multi-tasking scenarios.

[0052] Through the above-mentioned hardware and software integration approach, this solution starts with hardware initialization and module startup after the device is powered on, takes voice wake-up as the entry point, medication plan settings as the core, forms a closed loop with timed reminders and button confirmations, drives remote collaboration and alarms with missed doses and emergency event reporting, and achieves dynamic management of medication data and drug status through remote configuration and timed inspections. This makes home medication management significantly more user-friendly for the elderly, reliable reminders, auditable behavior, and emergency response compared to existing technologies.

[0053] Implementation Method 3, in conjunction with Appendix Figure 1-3 This embodiment describes the technical solution provided above in further detail through specific examples. Specifically: This implementation adopts a three-layer architecture logic: terminal interaction layer - cloud brain decision layer - collaborative service layer, forming a technical route of terminal localization processing + cloud intelligent decision-making + multi-terminal real-time collaboration. The overall system architecture is as follows: Figure 1 As shown.

[0054] As the physical carrier directly facing users, the terminal interaction layer's core design goal is to ensure high reliability, real-time responsiveness, and user privacy and security within an interaction paradigm familiar to the elderly. To address the inherent shortcomings of pure cloud solutions in terms of network dependence, response latency, and privacy leaks, this layer innovatively adopts a "cloud-based collaboration, local-first" design philosophy. Through local deployment of key AI models and refined process management, it achieves service continuity and stability in complex network environments and user scenarios.

[0055] In terms of hardware, an embedded microprocessor serves as the main control core, integrating audio input devices, audio output devices, power management units, physical interaction modules, and visual indicator devices, thereby constructing a complete multimodal hardware interaction system.

[0056] On the software side, it is developed based on Python and adopts a modular and process-decoupled design to ensure that each function operates stably and without interference. Crucially, to protect user privacy, improve real-time interaction, and ensure the availability of core functions in offline environments, the terminal's interaction layer deploys a lightweight voice wake-up model and a text-to-speech (TTS) model locally. The software comprises the following five core modules and six supporting modules.

[0057] 1) Core modules and functions Main manager (start_smart_medicine_box.py + smart_medicine_box_manager.py): system startup and process management, GPIO resource coordination, anomaly monitoring and automatic recovery.

[0058] The voice interaction module (voice_to_ernie_bot.py) includes: voice wake-up → recording → real-time ASR to text conversion → large model processing → TTS voice generation; conversational wake-up suppression and wake-up health monitoring; LED animation linkage; and necessary data interaction with WeChat mini-programs / cloud.

[0059] The timed reminder module (medicine_timer.py) includes medication timed reminders, LED lights and voice prompts for medication administration, and records and reports of missed doses.

[0060] The MQTT subscription module (mqtt_subscriber.py) receives configuration changes from the mini-program in real time and automatically updates local medication configurations.

[0061] Emergency call module (emergency_call_service.py): Cloud push notifications of emergency call status, LED lights, and emergency voice prompts.

[0062] 2) Supported modules and functions The process coordinator module (process_coordinator.py) is responsible for inter-process communication and resource coordination.

[0063] LED Management Service Module (led_manager_service.py + led_client.py): Animation and Priority Arbitration.

[0064] Drug file management module (yao_file_manager.py): Manages medication configuration files.

[0065] Voice wake-up detection module (wake_word_detector.py): Voice wake-up function.

[0066] Audio device management module (audio_device_manager.py): Audio device configuration and management.

[0067] Microphone device management module (mic_button_service.py): Controls the microphone to turn on and off.

[0068] The workflow of the terminal interaction layer is as follows: After the system powers on, the main management module initializes all hardware and starts all services. The voice wake-up detection module continuously monitors in the background. When the wake-up word is recognized by the locally deployed wake-up model, the voice interaction module is activated. This module takes over the audio device, completes the recording, obtains semantic results through cloud-based ASR and large model services, and finally calls the local TTS model to generate voice feedback. At the same time, the timed reminder module runs independently. When the predetermined time arrives, it coordinates the LED management service and the audio device to issue an audio and visual reminder. Throughout the process, the process coordinator ensures that multiple audio and light tasks proceed in an orderly manner, while the MQTT subscription module maintains synchronization with the cloud configuration. Data upload, event triggering, and message passing operations are implemented by the terminal interaction layer actively modifying the collaborative service layer database. This design enables data acquisition, local preprocessing, instruction execution, and status feedback to form an efficient and stable closed loop.

[0069] The Cloud Brain Decision Layer, serving as the system's intelligent hub, leverages the powerful computing and data processing capabilities of the cloud to construct an efficient, reliable, and scalable decision-making and collaboration platform. This layer employs a core logic of "perception and understanding - intelligent decision-making - precise distribution," transforming front-end interactive data into executable, structured instructions and ensuring the orderly flow and precise delivery of these instructions among the system's components. Its specific technical solution is as follows: 1) Speech recognition module To ensure smooth voice interaction, this module integrates a cloud-based high-precision streaming automatic speech recognition service. This service can recognize and instantly return audio streams, continuously converting speech signals into text streams, thereby significantly reducing end-to-end interaction latency and providing a foundation for subsequent real-time semantic analysis.

[0070] 2) Semantic parsing module This module is the core of this layer, carrying the system's cognitive and decision-making capabilities. It employs a large language model deployed in the cloud as its core engine. Voice-to-text content uploaded from the terminal undergoes deep semantic understanding by the large model guided by prompt word engineering. The model can accurately extract user intent and key parameters from the user's natural language and output structured instructions according to preset business rules. The output instructions include two parts: control instructions for controlling terminal hardware (such as adding reminders or modifying configurations), with standardized formats for easy parsing and distribution by subsequent modules; and natural language responses for engaging in human-like, multi-turn voice dialogues with the user, providing services such as emotional support and health Q&A. This design offloads the complex task of natural language understanding to the cloud, allowing the terminal to achieve a top-tier intelligent interactive experience without requiring powerful AI computing power.

[0071] 3) Reliable message distribution module This module is responsible for building a secure and reliable data channel within the system, serving as the "information hub" for the information flow from the mini-program to the terminal. At its core, it is built on a cloud IoT platform and has the following functions: Device Identity and Security Management: Create an independent logical identity for each smart medicine box terminal in the IoT platform and assign unique MQTT connection authentication information (such as certificates and keys) to ensure the legitimacy of the connection.

[0072] Topic subscription and publish mechanism: The system assigns a unique MQTT topic containing its device identifier to each device. The mini-program or cloud decision module acts as the command publisher, publishing commands to the specific topic; the target terminal device acts as the subscriber, listening in real time for topics that match its identifier.

[0073] Precise command routing: Through the above mechanism, this module realizes precise one-to-one and one-to-many routing of commands, ensuring that control commands, configuration updates and other messages can be accurately, reliably and with low latency transmitted from the cloud to the target terminal device, realizing decoupling and seamless collaboration between system components.

[0074] The workflow of the cloud brain decision layer is as follows: Upon receiving the voice stream uploaded by the terminal interaction layer, it immediately invokes the cloud-based streaming speech recognition service to convert it into text in real time. Subsequently, the text is sent to a cloud-based large language model, specially optimized by the prompt word engineering, for deep semantic analysis to accurately identify the user's intent and simultaneously generate a response that combines structured control commands and natural language replies. Finally, this result is returned to the terminal interaction layer to drive hardware actions or provide voice feedback. In the command distribution path, the reliable message distribution module is responsible for processing control commands and data synchronization messages from the collaborative service layer. Through the message routing capabilities of the cloud IoT platform, it accurately publishes them to the MQTT topic bound to the unique identifier of the target device, thereby ensuring that the corresponding subscribed devices in the terminal interaction layer can receive and execute commands in real time and reliably, achieving precise collaboration between cloud-based decision-making and multi-terminal execution.

[0075] The collaborative service layer serves as the system's remote control and collaborative management entry point, primarily providing guardians with a cross-platform interactive interface and service support. This layer utilizes WeChat mini-programs as a lightweight front-end carrier, combined with cloud-based back-end services, to construct a collaborative service system integrating status monitoring, remote configuration, medication management, and multi-level alarms. Its core lies in achieving bidirectional data flow and closed-loop control between the person (guardian), the terminal (smart medicine box), and the cloud (cloud brain decision-making layer). The specific technical solution is as follows: 1) Lightweight front-end interface The front-end of the mini-program was developed based on the native WeChat framework, leveraging its "use and go" feature to provide guardians with a convenient management portal. Using the WXML / WXSS / JavaScript technology stack, user interfaces such as a homepage dashboard, message center, medication reminder configuration, and drug information management were built, enabling visualization of system status, remote modification of device parameters, and real-time data binding with backend services.

[0076] 2) Cloud-native backend service architecture The backend service is preferably built on the WeChat Cloud Development Platform, which fully leverages its cloud-native architecture advantages to achieve high availability and elastic scaling of the service, and has the following functions.

[0077] Unified data storage and synchronization: Using a cloud-developed database as the core data hub, the smart medicine box terminal directly writes information such as device status and medication records into the database by calling the cloud development SDK, realizing real-time and seamless synchronization of hardware data to the guardian's end.

[0078] Event-driven automated response: By utilizing database event triggers, corresponding cloud functions are automatically triggered when specific data changes (such as adding a missed service record or receiving an emergency call signal), realizing unattended and automatic execution of critical business logic and forming an automated closed loop of "data-driven business".

[0079] Scheduled task proactive inspection: Through cloud function timed triggers, information such as drug expiration dates in the database is automatically scanned periodically, and tasks such as drug expiration reminders are proactively triggered, realizing a functional upgrade from passive response to proactive service.

[0080] 3) Secure and reliable remote command channel To enable the mini-program to actively control the medicine box terminal, this layer establishes a secure remote command channel based on MQTT over WebSocket. The mini-program frontend integrates an MQTT client library and connects to the cloud-based IoT core suite via TLS-encrypted WebSocket. At the authentication level, the unique identity credential of the medicine box device in IoT Core is reused to ensure the security and legitimacy of the connection. When issuing commands, a structured JSON command is published to the target device's dedicated topic at a QoS1 (at least once) quality of service level, thereby ensuring the accurate, reliable, and real-time delivery of remote control commands (such as immediate reminders and configuration modifications).

[0081] 4) A hierarchical and collaborative multimodal message delivery system For system events of varying urgency, this layer constructs a hierarchical, multimodal message delivery system to ensure that guardians can obtain information in a timely manner through the most appropriate channels.

[0082] For routine reminders and alarms, text messages are sent to the guardian's mobile phone by integrating with a third-party SMS service platform API.

[0083] For the highest priority emergency call events, the system simultaneously sends an SMS notification and initiates a third-party voice call API to automatically make a voice call to the guardian. This dual "SMS + voice" insurance mechanism greatly improves the delivery rate and immediacy of critical alarms, forming an efficient and reliable hierarchical collaborative alarm network.

[0084] The workflow of the collaborative service layer is as follows: Users interact with the system through the front-end interface, bind their medicine cabinet on the homepage, and view messages transmitted by the terminal interaction layer in the message interface. Any remote modification to the medication plan is encapsulated as a structured instruction and published via the MQTT protocol to a specific topic containing the unique identifier of the target medicine cabinet, thereby achieving accurate and real-time instruction delivery and synchronous updates of terminal configuration. After the guardian maintains the medication data in the medication information management interface, a timed trigger deployed in the cloud will actively scan the medication expiration dates in the database. Once a medication that is about to expire is detected, an SMS reminder will be automatically triggered. At the same time, key actions reported by the terminal interaction layer (such as missed dose records and emergency calls) will be directly written to the cloud database and immediately trigger the corresponding event-driven cloud function to automatically execute collaborative alarm tasks such as SMS notifications or voice calls, ultimately forming a complete service loop from manual configuration to automatic system response.

[0085] Implementation examples based on specific devices: The intelligent medicine box device described in this embodiment uses a Raspberry Pi 5 embedded development board as the core computing and control unit, and integrates peripheral hardware modules to realize core functions. The connection relationships between the modules are described in [reference needed]. Figure 2 .

[0086] Main Controller: Utilizing a Raspberry Pi 5-8G as the main controller, it features a 64-bit quad-core Arm Cortex-A76 processor running at 2.4GHz, offering 2-3 times the CPU performance compared to the Raspberry Pi 4. It also includes an 800 MHz VideoCore VII GPU, providing a significant boost in graphics performance. Furthermore, it features 802.11ac dual-band Wi-Fi and Bluetooth 5.0. The Raspberry Pi connects to other modules via GPIO pins and a USB interface. The main controller is responsible for running all software modules, performing logical checks, and communicating with the cloud and other hardware components.

[0087] Audio input module: A USB driverless microphone connects to the Raspberry Pi via a USB interface. The microphone sensitivity is -47dB±4dB, operating voltage is 4.5V, frequency response is 100~16kHz, signal-to-noise ratio is better than -67dB, and it supports sampling rates of 44.1kHz and 48kHz. It is responsible for capturing voice wake-up signals and user voice commands.

[0088] Audio output module: The USB driverless speaker connects to the Raspberry Pi via a USB interface, operates at 5V, has a speaker diameter of 44.5mm, a frequency response of 40~18kHz, a signal-to-noise ratio of 95dB, and a distortion of 0.5-1.0%. It is responsible for playing TTS voice messages, reminder tones, and alarm tones.

[0089] Visual indicator module: Includes tri-color LEDs and a WS2812 LED strip. The tri-color LEDs are common cathode, 5V powered, with R, G, B, and GND interfaces connecting to the Raspberry Pi's GPIO23, GPIO24, GPIO25, and Ground pins respectively, responsible for indicating system status such as power on / off and microphone access permissions. The WS2812 LED strip is a 14-LED strip using WS2812 LEDs. Each LED can be individually controlled for color and brightness, with a data transmission speed of 800kHz and an operating voltage of 3.5V~7.5V. Its DO and GND interfaces connect to the Raspberry Pi's GPIO18 and Ground pins respectively, and its VCC interface connects to the 5V output interface of the regulated power supply extension board. It is responsible for displaying rich dynamic light effects such as voice wake-up, medication reminders, and emergency calls.

[0090] Physical interaction module: GPIO Button 1: Defined as the "microphone control button", its DO, VCC and GND interfaces are connected to the Raspberry Pi's GPIO16, 3V3 and Ground pins respectively. When the user presses it, the microphone is turned on for voice wake-up detection, and at the same time, the three-color LED lights up green as visual feedback.

[0091] GPIO Button 2: Defined as the "Voice Interaction Button", its DO, VCC and GND interfaces are connected to the Raspberry Pi's GPIO17, 3V3 and Ground pins respectively, as a backup solution for voice wake-up. When the user presses it, they can start talking to the medicine box, and pressing it again can stop the recording.

[0092] GPIO Button 3: Defined as the "Medication Confirmation Button", its DO, VCC and GND interfaces are connected to the Raspberry Pi's GPIO22, 3V3 and Ground pins respectively. Users can press this button to confirm medication after hearing the medication reminder.

[0093] GPIO Button 4: Defined as the "Emergency Call Button", its DO, VCC and GND interfaces are connected to the Raspberry Pi's GPIO27, 3V3 and Ground pins respectively. The user can trigger an emergency call by pressing this button three times in a row.

[0094] Power supply modules include a UPS mobile power supply module and a voltage regulator extension version. The UPS mobile power supply module has an output power of 5V 6A, a maximum output power of 40W, and a battery capacity of 72Wh. It supports simultaneous charging and discharging and uninterrupted power supply to ensure the continuous power supply needs of the medicine box. The voltage regulator extension version supports a wide voltage input of 6~24V and a constant 5V output with linear compensation, providing a stable power supply for the WS2812 LED strip.

[0095] Through the collaborative work of the above hardware units, this device constructs a complete multimodal human-computer interaction hardware system.

[0096] After the system powers on, the main control core module initializes all hardware devices and starts the main manager module (start_smart_medicine_box.py + smart_medicine_box_manager.py) in the software modules. The main manager module then coordinates the startup of other core and support modules. The microphone device management module (mic_button_service.py) provides the current microphone status to other modules by writing whether the microphone is disabled to the `mic_disabled` field in the unified file `status / mic_status.json`. Initially, the microphone device management module disables the microphone and sets the `mic_disabled` field to `false`. When the user presses the white microphone control button, the microphone device management module controls the microphone to turn on, sets the `mic_disabled` field to `true`, and sends a signal to the LED management service (led_manager_service.py + led_client.py) to make the tri-color LED light up green.

[0097] After the microphone is turned on, the voice wake-up detection module (wake_word_detector.py) starts running in the background. This module uses the locally deployed SnowBoy voice wake-up model to achieve voice wake-up. SnowBoy is an open-source voice wake-up engine that focuses on keyword detection on low-power devices. Compared to traditional solutions, SnowBoy's detection latency can be controlled within 100ms, and its memory usage is less than 20MB. The model supports the recognition of mono audio with a 16kHz sampling rate and 16-bit quantization. After recording five "Hello Xiaozhi" audio clips in SnowBoy's online training tool, the model file is obtained. Loading the model file on the Raspberry Pi allows the "Hello Xiaozhi" voice wake-up task to be executed. Since the microphone used only supports 44.1kHz and 48kHz sampling rates, in actual use, SciPy's FFT resampling is used to resample the 44.1kHz audio stream to 16kHz in real time before it is recognized by the SnowBoy voice wake-up model. When the user says "Hello Xiaozhi", the voice wake-up model detects the signal, the voice wake-up module immediately stops voice wake-up detection and calls the voice interaction module (voice_to_ernie_bot.py).

[0098] After the voice interaction module starts, it first sends a signal to the LED management service to light up the LED strip with a "Listening" animation (listening_animation.py). Then, it calls Baidu AI Cloud's real-time speech recognition API to convert speech to text, opens the PyAudio input stream, and uses SciPy's FFT resampling to resample the 44.1kHz audio stream to 16kHz in real time. It then establishes a Baidu real-time recognition WebSocket, declares a sampling rate of 16kHz, and starts a receiving thread to update the intermediate / final text. Automatic recording stop is implemented using VAD endpoint detection and speech recognition interface return judgment. VAD endpoint detection sends frames to the WebRTC VAD at 20ms intervals to determine if they are speech frames; if four consecutive silent frames are detected, recording stop is triggered. Speech recognition interface return judgment determines recording stop by checking if the real-time speech recognition interface returns content; if no content is returned within 1.6 seconds, recording stop is triggered. Both automatic recording stop methods run simultaneously; automatic recording stop is triggered when either condition is met.

[0099] After recording and speech-to-text conversion are completed, the voice interaction module sends the converted text to the semantic parsing module of the cloud brain decision layer. The semantic parsing module uses the Ernie-4.5-turbo-vl large model, guided by prompt word engineering, to recognize the user's intent in voice commands and generate corresponding structured instructions. Its response mechanism specifically includes the following six cases: If the user's intent is to set a medication reminder, and the provided medication name, dosage, and medication time information are complete and correct, the returned format will be: "1 Set [Medication Name] [Dosage Information] [Time 1] [Time 2]...".

[0100] If the user's intent is to send a message to the mobile device, the returned format is: "2 [the specific message content to be transmitted]".

[0101] If the user's intent is to modify the set medication reminder, the returned format is: "4 Modify [Drug Name] [Dosage Information] [Time 1] [Time 2]...".

[0102] If the user's intent is to delete medication reminders, the returned format is: "5 Delete [Medication Name]".

[0103] If the user's intent does not fall under 1, 2, 4, or 5 above, the returned format will be: "3 [Intelligently generated reply based on user input]".

[0104] In addition, as a special case: if a user intends to set a medication reminder but provides incomplete information, the system will handle it according to step 3 above and actively guide the user to complete the missing information in the reply.

[0105] The structured instructions generated by the large model are streamed to the voice interaction module of the terminal decision layer for processing. The processing method is determined based on the first character of the returned content, and corresponding processing is performed accordingly. There are five processing methods for the five types of returned content: Upon detecting "1. Setting", a record is added to the `reminders` collection in the cloud development database. This record contains fields "name", "dosage", "time", and "boxid", corresponding to the drug name, dosage information, medication time, and authentication information, respectively. "name", "dosage", and "boxid" are of string type, and "time" is of array type. Subsequently, a medication reminder record is added to the local "Medicine" file, in the format "(drug name, dosage, medication time, number)". If a drug has multiple dosage times, a record is added for each time. Simultaneously, TTS (Text-to-Speech) is invoked to convert the set drug information into audio. After adding the information, a preset audio is played, displaying the message "Okay, I have set a medication reminder". After the preset audio finishes playing, the TTS-generated audio is played. After the response audio finishes playing, the program continues to generate medication reminder audio in the background, playing it at the preset time.

[0106] If "2" is detected, a record is added to the messages collection in the cloud development database. This record contains "event", "createTime", and "boxid" fields, which correspond to the specific information to be transmitted, the time of transmission, and authentication information, respectively. "event" and "boxid" are of string type, and "createTime" is of date type. After adding the record, a preset audio is played, which reads, "Okay, I have sent the information to the guardian. Is there anything else you need?"

[0107] Upon detecting "3", the program begins detecting the content of the streaming response. First, all content undergoes illegal character detection and replacement via code, deleting or replacing content that TTS cannot convert with legal characters. Then, the response content is segmented. Each time a punctuation mark is detected, the generated content is segmented, and the segment is converted into audio using TTS. Once the audio of the first two segments is generated, the program begins playing the response audio segment by segment, while continuing to convert the next segment, thus achieving streaming segmented speech synthesis.

[0108] If "4" is detected, the system will locate the corresponding record in the "Medicine" file based on the drug name information in the reply. Then, the usage, dosage, and administration time will be compared and modified. Additionally, the corresponding fields in the corresponding record of the "reminders" collection in the cloud development database will be modified. After modification, a pre-set audio message will play: "Okay, I have modified the medication reminder."

[0109] If "5" is detected, the record in the "Medicine" file and the cloud development database will be deleted based on the drug name information in the reply. After deletion, a preset audio will be played, saying "Okay, I have deleted the medication reminder."

[0110] The TTS model used in the processing adopts the TTSArmLinux dedicated model under the PaddleSpeech open source framework ecosystem. This model uses the Paddle Lite inference engine, runs on Arm Linux, and is perfectly compatible with resource-constrained scenarios of embedded hardware such as Raspberry Pi. The model is deployed locally on Raspberry Pi to realize voice response.

[0111] The timed reminder module (medicine_timer.py) is one of the core components of the smart medicine cabinet. It is primarily responsible for parsing medication plans, accurately triggering timed reminders, providing multimodal reminders (voice + light), and reporting missed doses. The detailed implementation process is as follows: 1. Initialization phase (__init__) When the program starts, the MedicineTimer class performs basic environment configuration: Hardware interface: Initialize the Raspberry Pi GPIO (default pin 22) to detect the user's "Confirm Medication" button.

[0112] Configuration loading: Read boxid.txt to obtain the unique ID of the medicine box, and load the configuration (AppID, Secret) of the WeChat Mini Program for subsequent data reporting.

[0113] Status synchronization: Initializes the status updater to write the current status (whether a notification is being sent) to status / medicine_timer_status.json so that other modules (such as voice dialogue) can avoid it.

[0114] 2. Timer Management (_setup_timers, _timer_thread) This is the "heart" of the module, responsible for maintaining the schedule: Reading plan: The _setup_timers method parses the local Medicine file. Each line in this file represents a medication reminder (the format includes: medication name, dosage, time, and number).

[0115] Calculation time: _get_next_trigger_time will determine the trigger time based on the current time: if the set time has not yet arrived, it will be set to trigger today; if the set time has passed, it will be set to trigger tomorrow.

[0116] Main loop monitoring: _timer_thread is a persistent background thread that checks all timers once per second. Once the current time exceeds the set next_trigger, the alarm handling function _alarm_handler is triggered.

[0117] 3. Dynamic file monitoring (_start_file_monitor) To support remote modification reminders, the module uses the watchdog library to monitor the Medicine file. Once the Medicine file changes (for example, if a user modifies the medication schedule via the mini-program), the program automatically triggers _setup_timers, reloading all timers in real time without requiring a program restart.

[0118] 4. Alarm Trigger Process (_alarm_handler) When the timer expires, a separate thread is started to handle the reminder. First, the system status is marked as `alarm_active=True` to pause the voice interaction function and prevent conflicts. Next, audio and light resources are prepared, the reminder audio is played, and the LED controller is invoked to flash the reminder light. Then, a loop reminder phase begins, playing the audio every 5 seconds. During the loop, the GPIO button status is monitored in real time: if the user presses a button, the audio and light immediately stop, it is marked as "medication taken," and the loop exits; if no button is pressed within 120 seconds, it is considered "missed dose." The specific process is as follows: Figure 3 As shown.

[0119] Upon detecting a missed medication event, the module immediately initiates the missed medication handling process: First, it sends a signal to the LED management service to activate the "emergency reminder" animation on the LED strip (emergency_animation.py). Then, the module obtains WeChat API access credentials and adds a record to the `missed` collection in the cloud development database. This record contains three fields: "name," "time," and "boxid," representing the medication name, missed medication time, and authentication information, all of which are string types. The database activates an event trigger to listen for record additions to the `missed` collection. When a new record is detected, a cloud function is invoked to send a missed medication SMS reminder to the bound mobile phone number. Subsequently, the module performs a cycle reset: recalculating and updating the next trigger time, and releasing the system state lock (alarm_active=False) to restore the normal operation of other services, thus completing a full medication reminder and monitoring loop.

[0120] Emergency Call is a separate, high-priority daemon dedicated to handling users' emergency requests for help. Its core design goals are "speed" and "stability," ensuring it can respond independently even if other modules are stuck or overloaded. The detailed implementation process is as follows: 1. Startup and initialization (__init__, start) Run independently: This script is designed to run as an independent process, and attempts to increase the system scheduling priority by using os.nice(-5) to ensure response speed.

[0121] Locking mechanism: At startup, an emergency_service.lock file is created in the status / directory to isolate the voice module and avoid logical conflicts.

[0122] GPIO Listening: Initialize the Raspberry Pi GPIO pin (default GPIO 27, red button), set it to input mode and enable pull-up resistors.

[0123] 2. Trigger detection (_on_red_press) To prevent accidental presses, the system employs a "three-click trigger" mechanism: the program continuously listens for button press events, incrementing a counter with each press. If the interval between two clicks exceeds 2.0 seconds, the counter automatically resets to zero. Only three consecutive presses within a short period are considered an "emergency call" and enter the handling process (_handle_emergency).

[0124] 3. Emergency Response Procedures This is the core business logic, and the execution order is as follows: Status Lockdown: Write to status / emergency_status.json to mark the status as active. Send a SIGUSR1 signal to the voice process to forcibly pause the currently ongoing voice conversation or audio playback to make way for the alarm.

[0125] Visual alarm: Call create_led_controller to create an LED controller with extremely high priority, light up the "emergency alert" animation (emergency_animation.py), and preempt all current lighting effects.

[0126] Cloud-based reporting: The WeChat Access Token is obtained through the WechatMiniProgramDB class. A record is then written to the `call` collection in the cloud development database. This record contains two fields: "time" and "boxid," representing the time the emergency call was triggered and the authentication information, respectively. "Time" is of type date, and "boxid" is of type string. The database uses an event trigger to listen for record additions to the `call` collection. When a new record is detected, a cloud function is invoked to send an emergency call SMS and phone call alert to the bound mobile number.

[0127] Sound alarm: Try playing the local alarm audio (alarm.wav).

[0128] Restore the scene: After the alarm ends, stop the LED animation, send a SIGUSR2 signal to the voice process, allowing it to restore the previous state; update the state file to idle, and wait for the next trigger.

[0129] The collaborative service layer provides guardians with remote management capabilities through WeChat mini-programs. Using the WXML / WXSS / JS technology stack, it constructs user interfaces including a homepage dashboard, message center, medication reminder configuration, and drug information management. Its core lies in leveraging cloud-native backend services and secure messaging channels to achieve remote synchronization of medication plans, proactive monitoring of drug expiration dates, and event-driven multi-level alarms. The specific implementation process is as follows: 1. Service initialization and device binding When a guardian uses the device for the first time, they complete the binding of the medicine box by scanning the device's QR code and entering their mobile phone number on the mini-program's homepage. The mini-program backend creates a unique logical record for the device in the `number` collection of the WeChat Cloud Development database. This record contains four fields: "boxid," "createTime," "openid," and "phonenumber," representing the medicine box's unique ID, binding time, guardian's account ID, and bound mobile phone number, respectively. "boxid," "openid," and "phonenumber" are string types, while "createTime" is a date type. Simultaneously, in the Baidu IoT Core suite on the cloud IoT platform, a dedicated MQTT logical device is assigned to the medicine box with the specified `boxid`, and MQTT connection information is obtained. A record is created in the `iotcore` collection of the cloud development database to store this MQTT connection information, containing five fields: "Broker," "ClientID," "Password," "Username," and "boxid." "Broker," "ClientID," "Password," and "Username" contain the MQTT connection information, while "boxid" is the medicine box ID.

[0130] 2. Remote synchronization process for medication plans When a guardian modifies the plan in the "Medication Reminder Configuration" interface of the mini-program, the following collaborative operation is triggered: Command Generation: The mini-program backend encapsulates the modification operation (such as add, delete, or update), the corresponding record ID in the database, and timestamp parameters into a structured JSON data packet. This data packet has three fields: "action", "id", and "timestamp". The value of "action" represents the user's operation, which may be "add", "delete", or "change", representing add, delete, and update, respectively. "id" is the ID of the record in the database that has changed. In a special case, when the user performs a delete operation, the mini-program backend will copy the deleted record to the delete collection, and the "id" in the data packet will be the ID of the newly added record in the delete collection. "timestamp" is the current timestamp.

[0131] Command issuance: The mini-program, through the integrated Paho-MQTT client, uses MQTT connection information stored in the iotcore collection in the database to publish JSON data packets to the target device's dedicated theme smartbox / ${boxid} / sync, with QoS 1 service quality. This connection is based on WebSocket over TLS encryption, ensuring the security and reliability of command transmission.

[0132] Terminal Reception and Execution: The MQTT subscription module (mqtt_subscriber.py) on the terminal device continuously subscribes to its dedicated topic. Upon receiving a command, it parses the JSON packet, determines the user's action based on the "action" field, locates the changed record in the database based on the "id" field, and then uses the drug file management module (yao_file_manager.py) to locate and update the corresponding record in the local Medicine configuration file. This ensures data consistency between the two ends, achieving real-time, bidirectional synchronization of medication plans.

[0133] 3. Proactively inspect the expiration date of medicines. The system uses cloud function timed triggers to manage drug expiration dates, automatically executing the following processes daily: Scheduled Scan: A cloud function configured to trigger at noon every day is activated to automatically scan the "dateStr" field of all drug records in the cloud development database medicine collection.

[0134] Warning judgment: The validity period of each record is compared with the current server date. If the validity period is found to be within the preset warning days, it is judged as "near-expiry medicine".

[0135] Proactive outreach: The cloud function calls integrate a third-party SMS service platform API to automatically send warning SMS messages to the mobile phone number bound to the guardian. The messages include the name of the medicine and the expiration date, forming a proactive closed loop for medicine management.

[0136] 4. Event-driven multi-level alarm triggering Critical events reported by the terminal (such as missed service or emergency calls) trigger automated, tiered remote alarms: Event writing: The terminal timed reminder module and emergency call module directly write event records to the missed and call collections in the database through the WeChat Cloud Development SDK.

[0137] Trigger Response: When a new record is detected, the event trigger configured in the database immediately calls the preset alarm cloud function.

[0138] Tiered alarm execution: Cloud functions execute different strategies based on event type. For missed service events, the SMS API is called to send a notification; for the highest priority emergency call events, the SMS API and voice call API are called in parallel to achieve dual-insurance alarms of "SMS + voice", which greatly improves the timeliness and reliability of information delivery.

[0139] Through the above process, the collaborative service layer enables guardians to remotely, in real-time, and reliably collaborate on the entire medication management process, effectively solving the problems of data silos and delayed response in traditional solutions.

[0140] The above description of several specific embodiments further details the technical solution provided by the present invention in order to highlight the advantages and benefits of the technical solution provided by the present invention. However, the above-described specific embodiments are not intended to limit the present invention. Any reasonable modifications and improvements to the present invention, combinations of embodiments, and equivalent substitutions based on the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-terminal collaborative intelligent home medication service method, characterized in that, include: In the terminal interaction layer, initialize the audio input module, audio output module, voice wake-up detection module, voice interaction module, medication reminder module, MQTT subscription module and emergency call module and establish process coordination relationship, obtain the running environment for performing voice interaction and multimodal reminders and output the microphone status that can be read by the voice wake-up detection module. The wake-up event is obtained based on the continuous analysis results of the audio stream by the voice wake-up detection module, and the wake-up event is used as the recording trigger input of the voice interaction module, so that the voice interaction module takes over the audio input and outputs the text content obtained by speech recognition. Based on the text content output by the voice interaction module, semantic parsing is performed in the cloud brain decision layer to generate structured control instructions containing operation type, drug name, usage and dosage, and medication time. The structured control instructions are then used as input for updating the local medication configuration file and the corresponding medication records are output. The medication record generated based on the structured control instructions updates the local medication configuration file in the terminal interaction layer and uses the updated medication configuration file as the task construction input for the medication timed reminder module, thereby outputting the steps of the reminder task containing the drug name, usage and dosage and trigger time; When the reminder task is triggered, the drug name and dosage information are obtained and the audio output module and light output module are driven to perform voice reminders and light prompts. The reminder result is used as the input for medication confirmation detection and the steps of outputting medication confirmation record or missed dose record are completed. The steps involve writing the medication confirmation record or missed dose record into the cloud database in the collaborative service layer, and then having the event triggering program retrieve the new record, so that the new record can be used as the input for remote alarm triggering and output as alarm information sent to the monitoring terminal. Based on the structured change instructions generated by the remote operation of the medication plan in the collaborative service layer by the monitoring terminal, they are sent to the terminal interaction layer via MQTT. The structured change instructions serve as the input for updating the medication configuration file again and output new reminder tasks, thereby completing the remote synchronization step.

2. The method for providing intelligent home medication services with multi-terminal collaboration according to claim 1, characterized in that, In the terminal interaction layer, the voice interaction module segments the text content obtained through speech recognition and generates segmented voice responses through a locally deployed speech synthesis model, so that the segmented voice responses can serve as input for the user to continue interacting during playback.

3. The method for providing intelligent home medication services with multi-terminal collaboration according to claim 1, characterized in that, In the terminal interaction layer, the medication timed reminder module monitors the local medication configuration file in real time and automatically reloads the reminder task when the file content changes, so that the new reminder task serves as the input for triggering subsequent reminders.

4. The multi-terminal collaborative intelligent home medication service method according to claim 1, characterized in that, In the terminal interaction layer, the emergency call module determines the interval of continuous pressing of the emergency call button and outputs an emergency event when the continuous pressing threshold is met, so that the emergency event is given priority to the audio output module and the light output module to preempt input.

5. The method for multi-terminal collaborative intelligent home medication service according to claim 1, characterized in that, In the collaborative service layer, a timed trigger program periodically scans the drug expiration date field stored in the cloud database and outputs drug near-expiration records based on the current server time, so that the drug near-expiration records can be used as input for triggering SMS notifications.

6. The method for providing intelligent home medication services with multi-terminal collaboration according to claim 1, characterized in that, In the collaborative service layer, a timed trigger program periodically scans the drug expiration date field stored in the cloud database and outputs drug near-expiration records based on the current server time, so that the drug near-expiration records can be used as input for triggering SMS notifications.

7. A multi-terminal collaborative intelligent home medication service device, characterized in that, The device includes: Audio input module, used to collect user voice signals; The audio output module is used to play prompt tones and voice replies; The voice wake-up detection module is used to identify wake-up words and trigger voice interaction; The voice interaction module is used to perform speech recognition, semantic parsing, and voice response. The medication reminder module is used to generate, trigger, and manage medication reminder tasks; The MQTT subscription module is used to receive remote instructions to change medication plans. The emergency call module is used to detect emergency button presses and execute high-priority alarms; The method of claim 1 is loaded into the central processing unit.

8. A computer storage medium for storing computer programs, characterized in that, When the computer program is read by the computer, the computer executes the method of claim 1.

9. A computer, comprising a processor and a storage medium, characterized in that, When the processor reads the computer program stored in the storage medium, the computer executes the method of claim 1.

10. A computer program product, as a computer program, is characterized by: When the computer program is executed, it implements the method of claim 1.

Images